Only drawback is the expensive power module. Once I get this board working, I'll spend some time designing my own 30A VCORE supply.
Top:
Bottom:
Topic: [CLOSED] Bitmine CoinCraft A1 28nm chip distribution / DIY support - page 21. (Read 81287 times)
January 08, 2014, 02:52:15 PM
Thanks! Here is my board: 145mm x 95mm, adjustable VCORE, power module on/off control, support for selecting between 2 oscillators, FTDI232H for SPI (no microcontroller), 75mm pitch holes to support standard LGA115X heatsinks, and a +12V fan header.
Only drawback is the expensive power module. Once I get this board working, I'll spend some time designing my own 30A VCORE supply.
Top:
Bottom:
Only drawback is the expensive power module. Once I get this board working, I'll spend some time designing my own 30A VCORE supply.
Top:
Bottom:
January 08, 2014, 01:46:20 PM
Is there another thread where people are discussing their DIY A1 designs? I don't want to hijack Zefir's thread with renderings if there is a better place...
I don't mind, since this ought to be also the DIY support thread. If someone is starting new A1 design related threads, please let me know so I can add a reference. Otherwise feel free to stay here.
January 08, 2014, 01:19:13 PM
Is there another thread where people are discussing their DIY A1 designs? I don't want to hijack Zefir's thread with renderings if there is a better place...
-a[g
-a[g
January 08, 2014, 01:40:59 AM
The queue was required for the very first sample chips with limited availability. Following waves will be available in volumes and should not need to register.
As for the clock: the eval board in China uses 12MHz clock, Bitmine's 16MHz - both work. PLL settings allow arbitrary setting of divider, configuration tables for the PLL settings for 12 and 16MHz input clock and different system clock rates will be added to the documentation ASAP. If you design a multi-chip board, to feed all chips with one oscillator you need - guess what - clock buffers (no kidding here).
Cheers,
zefir
As for the clock: the eval board in China uses 12MHz clock, Bitmine's 16MHz - both work. PLL settings allow arbitrary setting of divider, configuration tables for the PLL settings for 12 and 16MHz input clock and different system clock rates will be added to the documentation ASAP. If you design a multi-chip board, to feed all chips with one oscillator you need - guess what - clock buffers (no kidding here).
Cheers,
zefir
Crap, that means another 6 months until we get chips.Edit: Removed excess text.
Correct. I should have avoided attempts being humorous in such a serious and sensitive field, sorry.
To clarify: if you are building a multi-chip board, you either need to provide an oscillator to every A1, or use one common clock and connect it to all A1s over clock distribution ICs (TI uses the term 'clock buffers' for their related product family).
January 07, 2014, 08:21:10 PM
The queue was required for the very first sample chips with limited availability. Following waves will be available in volumes and should not need to register.
As for the clock: the eval board in China uses 12MHz clock, Bitmine's 16MHz - both work. PLL settings allow arbitrary setting of divider, configuration tables for the PLL settings for 12 and 16MHz input clock and different system clock rates will be added to the documentation ASAP. If you design a multi-chip board, to feed all chips with one oscillator you need - guess what - clock buffers (no kidding here).
Cheers,
zefir
As for the clock: the eval board in China uses 12MHz clock, Bitmine's 16MHz - both work. PLL settings allow arbitrary setting of divider, configuration tables for the PLL settings for 12 and 16MHz input clock and different system clock rates will be added to the documentation ASAP. If you design a multi-chip board, to feed all chips with one oscillator you need - guess what - clock buffers (no kidding here).
Cheers,
zefir
Crap, that means another 6 months until we get chips.Edit: Removed excess text.
January 07, 2014, 02:42:34 PM
Well, as pure SW guy I can provide only limited HW related feedback, so please double check.
I understood that the eval board used in China (the one you saw in the pictures) for testing has a level shifter for input and output signals, while Bitmine's boards use resistors to lower the input signals and a level shifter for the output signal (MISO) - seem to work both.
Thanks, I'll try both. I have both a level shifter and the option to use an inline resistor to drop the 3.3V signal down to 1.8V on my test board similarly to how some Bitfury designs have implemented it. Have you investigated doing that, or just feeding 3.3V straight in?
I understood that the eval board used in China (the one you saw in the pictures) for testing has a level shifter for input and output signals, while Bitmine's boards use resistors to lower the input signals and a level shifter for the output signal (MISO) - seem to work both.
If we're working on a DIY board for the A1, how do we get in the queue for sample chips?
can you clarify the clock frequency required for the PLL. On the datasheet it quotes either 12MHz or 32MHz. Will either 12MHz or 32MHz give access to the full PLL range, or would the option of selectable external clocks in the 12-32MHz range be useful?
can you clarify the clock frequency required for the PLL. On the datasheet it quotes either 12MHz or 32MHz. Will either 12MHz or 32MHz give access to the full PLL range, or would the option of selectable external clocks in the 12-32MHz range be useful?
The queue was required for the very first sample chips with limited availability. Following waves will be available in volumes and should not need to register.
As for the clock: the eval board in China uses 12MHz clock, Bitmine's 16MHz - both work. PLL settings allow arbitrary setting of divider, configuration tables for the PLL settings for 12 and 16MHz input clock and different system clock rates will be added to the documentation ASAP. If you design a multi-chip board, to feed all chips with one oscillator you need - guess what - clock buffers (no kidding here).
Cheers,
zefir
Crap, that means another 6 months until we get chips. January 07, 2014, 01:48:30 PM
Well, as pure SW guy I can provide only limited HW related feedback, so please double check.
I understood that the eval board used in China (the one you saw in the pictures) for testing has a level shifter for input and output signals, while Bitmine's boards use resistors to lower the input signals and a level shifter for the output signal (MISO) - seem to work both.
The queue was required for the very first sample chips with limited availability. Following waves will be available in volumes and should not need to register.
As for the clock: the eval board in China uses 12MHz clock, Bitmine's 16MHz - both work. PLL settings allow arbitrary setting of divider, configuration tables for the PLL settings for 12 and 16MHz input clock and different system clock rates will be added to the documentation ASAP. If you design a multi-chip board, to feed all chips with one oscillator you need - guess what - clock buffers (no kidding here).
Cheers,
zefir
I have both a level shifter and the option to use an inline resistor to drop the 3.3V signal down to 1.8V on my test board similarly to how some Bitfury designs have implemented it. Have you investigated doing that, or just feeding 3.3V straight in?
I understood that the eval board used in China (the one you saw in the pictures) for testing has a level shifter for input and output signals, while Bitmine's boards use resistors to lower the input signals and a level shifter for the output signal (MISO) - seem to work both.
If we're working on a DIY board for the A1, how do we get in the queue for sample chips?
can you clarify the clock frequency required for the PLL. On the datasheet it quotes either 12MHz or 32MHz. Will either 12MHz or 32MHz give access to the full PLL range, or would the option of selectable external clocks in the 12-32MHz range be useful?
can you clarify the clock frequency required for the PLL. On the datasheet it quotes either 12MHz or 32MHz. Will either 12MHz or 32MHz give access to the full PLL range, or would the option of selectable external clocks in the 12-32MHz range be useful?
The queue was required for the very first sample chips with limited availability. Following waves will be available in volumes and should not need to register.
As for the clock: the eval board in China uses 12MHz clock, Bitmine's 16MHz - both work. PLL settings allow arbitrary setting of divider, configuration tables for the PLL settings for 12 and 16MHz input clock and different system clock rates will be added to the documentation ASAP. If you design a multi-chip board, to feed all chips with one oscillator you need - guess what - clock buffers (no kidding here).
Cheers,
zefir
January 07, 2014, 12:28:31 PM
If we're working on a DIY board for the A1, how do we get in the queue for sample chips?
I should have my design done this week.
Zefir: can you clarify the clock frequency required for the PLL. On the datasheet it quotes either 12MHz or 32MHz. Will either 12MHz or 32MHz give access to the full PLL range, or would the option of selectable external clocks in the 12-32MHz range be useful?
thanks!
-a[g
I should have my design done this week.
Zefir: can you clarify the clock frequency required for the PLL. On the datasheet it quotes either 12MHz or 32MHz. Will either 12MHz or 32MHz give access to the full PLL range, or would the option of selectable external clocks in the 12-32MHz range be useful?
thanks!
-a[g
January 07, 2014, 04:51:33 AM
Any news on the design competition?
Intermediate Results Relevant for DIY
The following is a short list of things tested and relevant for DIY projects:
- PLL configuration working: arbitrary system clock selectable and usable
- AVDD must be 1.8V, input is not 3.3 V tolerant
- host SPI interface: level shifter from/to 1.8V required
- SPI chain termination: the last chip in the chain needs to have SDI_L and SDO_L connected to close the loop
- chips need to be HW reset (by pulling RESETn to ground) for proper operation
- hashing engines work, chip produces exactly the expected hashrate (number of engines * system clock)
- the initial cgminer driver published works as is
- chip is designed to dissipate ~70% through the PCB and 30% over top side, therefore heat-sink is mandatory
Thanks for clearing this up.
January 07, 2014, 04:49:04 AM
Thanks for the update zefir.
I have both a level shifter and the option to use an inline resistor to drop the 3.3V signal down to 1.8V on my test board similarly to how some Bitfury designs have implemented it. Have you investigated doing that, or just feeding 3.3V straight in?
I have both a level shifter and the option to use an inline resistor to drop the 3.3V signal down to 1.8V on my test board similarly to how some Bitfury designs have implemented it. Have you investigated doing that, or just feeding 3.3V straight in?
I have all these three options on the prototype board:)
The datasheet is less then conclusive I'm afraid.
January 07, 2014, 02:11:38 AM
Thanks for the effort there Zefir doing all that work for all of us out here.
January 06, 2014, 09:25:22 PM
Any news on the design competition?
Currently everyone at Bitmine is busy testing the chip and I suspect they just lack time to plan and announce it. I'll post when I know more.
Update: Initial Tests with real Chips
Sample Chips
The first wave of sample chips has been shipped by Bitmine to the following people / projects (2 chips each): WASP, marto74, MrTeal, danchoo, Felipeo, Lucko, intron, burnin. They should arrive this week. Next wave will be available (in higher volumes) in week 3-4/2014.
Chip Testing
I visited Bitmine over the weekend for the initial chip bring-up. Test was performed on the first revision of the 8-chip boards that will be used in the rigs delivered to customers. We fought some very basic issues half night through - and finally we made the chips working. The cooling design is still worked on (and will be adapted to the findings during the tests), therefore we had to work without top heatsink. As a result, we could perform tests with reduced clocks so far, which is sufficient to validate the communication, chaining, and hashing. During the next days the cooling should be available and I will be able to explore the edges and post performance figures.
Intermediate Results Relevant for DIY
The following is a short list of things tested and relevant for DIY projects:
- PLL configuration working: arbitrary system clock selectable and usable
- AVDD must be 1.8V, input is not 3.3 V tolerant
- host SPI interface: level shifter from/to 1.8V required
- SPI chain termination: the last chip in the chain needs to have SDI_L and SDO_L connected to close the loop
- chips need to be HW reset (by pulling RESETn to ground) for proper operation
- hashing engines work, chip produces exactly the expected hashrate (number of engines * system clock)
- the initial cgminer driver published works as is
- chip is designed to dissipate ~70% through the PCB and 30% over top side, therefore heat-sink is mandatory
That's all for now. I will post a follow-up when cooling is properly applied to push the clocks to nominal ranges. By next weekend we could also get initial feedback from some of the DIY projects listed above.
Cheers,
zefir
January 06, 2014, 08:18:26 PM
Thanks for the update zefir.
I have both a level shifter and the option to use an inline resistor to drop the 3.3V signal down to 1.8V on my test board similarly to how some Bitfury designs have implemented it. Have you investigated doing that, or just feeding 3.3V straight in?
I have both a level shifter and the option to use an inline resistor to drop the 3.3V signal down to 1.8V on my test board similarly to how some Bitfury designs have implemented it. Have you investigated doing that, or just feeding 3.3V straight in?
January 06, 2014, 05:40:01 PM
Any news on the design competition?
Currently everyone at Bitmine is busy testing the chip and I suspect they just lack time to plan and announce it. I'll post when I know more.
Update: Initial Tests with real Chips
Sample Chips
The first wave of sample chips has been shipped by Bitmine to the following people / projects (2 chips each): WASP, marto74, MrTeal, danchoo, Felipeo, Lucko, intron, burnin. They should arrive this week. Next wave will be available (in higher volumes) in week 3-4/2014.
Chip Testing
I visited Bitmine over the weekend for the initial chip bring-up. Test was performed on the first revision of the 8-chip boards that will be used in the rigs delivered to customers. We fought some very basic issues half night through - and finally we made the chips working. The cooling design is still worked on (and will be adapted to the findings during the tests), therefore we had to work without top heatsink. As a result, we could perform tests with reduced clocks so far, which is sufficient to validate the communication, chaining, and hashing. During the next days the cooling should be available and I will be able to explore the edges and post performance figures.
Intermediate Results Relevant for DIY
The following is a short list of things tested and relevant for DIY projects:
- PLL configuration working: arbitrary system clock selectable and usable
- AVDD must be 1.8V, input is not 3.3 V tolerant
- host SPI interface: level shifter from/to 1.8V required
- SPI chain termination: the last chip in the chain needs to have SDI_L and SDO_L connected to close the loop
- chips need to be HW reset (by pulling RESETn to ground) for proper operation
- hashing engines work, chip produces exactly the expected hashrate (number of engines * system clock)
- the initial cgminer driver published works as is
- chip is designed to dissipate ~70% through the PCB and 30% over top side, therefore heat-sink is mandatory
That's all for now. I will post a follow-up when cooling is properly applied to push the clocks to nominal ranges. By next weekend we could also get initial feedback from some of the DIY projects listed above.
Cheers,
zefir
January 02, 2014, 04:30:24 AM
Any news on the design competition?
January 01, 2014, 07:07:02 AM
We are in for the early samples "The Wasp Project Collective" ...
.. happy new year ..
.. happy new year ..
December 31, 2013, 01:12:37 PM
Please note: only the very first sample chips are scarce as gold. If your design is ready and waiting for chips (like I know from WASP and marto74), please confirm to me you would like 2 chips from the pilot run. If you are still designing and would be fine with sample chips second half of January 2014, please be fair and leave the samples to those who need them more urgently.
I forgot if I registered for the first group or not, but I'm okay with going into the second group (W3/4).
December 31, 2013, 12:40:41 PM
Great news.
We are in for samples.
Test boards dusting on the desk for more than two weeks already
We are in for samples.
Test boards dusting on the desk for more than two weeks already
December 31, 2013, 05:36:45 AM
[...] I have some feeling that next year will be a good one for the DIY scene.
Ok, coordination between timezones was bad: Giorgio posted the good news minutes ago: chip is working
The bad news are: there are only ~20 sample chips available for DIY projects in W1/2014.
Then again, the good news are: up to 10 projects will be provided with 2 free chips each.
More good news are, sample chips in volumes will be available in W3-4/2014.
The sample chips will be sent out by Bitmine; I will provide them the list of DIY projects that already registered, which will be supplied with higher priority over those registering hereafter.
Please note: only the very first sample chips are scarce as gold. If your design is ready and waiting for chips (like I know from WASP and marto74), please confirm to me you would like 2 chips from the pilot run. If you are still designing and would be fine with sample chips second half of January 2014, please be fair and leave the samples to those who need them more urgently.
Cheers,
zefir
December 31, 2013, 04:56:47 AM
Update: Preliminary Findings relevant for DIY Designs
Well, it was more an inspect-and-guess than a reverse-engineering
- outcome is already included in the driver and described below.
Getting and building the A1 driver branch
I was approached by users having problems accessing the driver sources, since I wrongly assumed everybody is used to work with git. Here are the steps required to get and build the A1 SPI driver on a Linux host:
Known limitations
This is what I got from the FPGA emulator and therefore preliminary, but assuming the chip behaves the same, it is essential for HW designs out there: the BIST_START command that runs the auto-addressing process and enumerates the chips in a chain seems to work only once after chip reset. In subsequent calls it returns zero number of chips. The RESET command does not help here, therefore to start from a defined state you should provide means to HW-reset the chip in your design.
Undocumented features
Some bits in the register[23:8] range (tagged as reserved in section 3 of current spec doc) seem to have the following functionality:
register[17]: 2nd job active - if 0, host can feed another job to input queue
register[16]: 1st job active - if 0, chip is job-less and not hashing any more
register[15:12]: job_id of 2nd input item
register[11:8]: job_id of 1st input item
Again, these are preliminary assumptions that need to be confirmed by chip designing company. But since this bits are used in the current driver to greatly improve the feeding of input queues, assume them to be final.
These updates will be added to the chip specification document as soon as we double-check with real chips and get confirmation from chip manufacturer - which I expect to happen by end of this week.
Partitioning chip chain
As you can read from the driver sources, the working units visible to cgminer are chip-chains. Instead of having long chains exposed to the risk of a single chip bricking the chain, Bitmine follows a modular concept with one STM32F1x controlling sub-chains on its SPI interfaces and transparently behaving like a chip-chain to the host as SPI-slave. I started working on this FW, which will be made open source as soon as it passes testing. If you are following the same concept with your design and are interested in working together on the SW side, please PM me.
That's for this year. I have some feeling that next year will be a good one for the DIY scene.
Cheers,
zefir
What were the hidden features, which you managed to reverse engineer?
Well, it was more an inspect-and-guess than a reverse-engineering
- outcome is already included in the driver and described below.Getting and building the A1 driver branch
I was approached by users having problems accessing the driver sources, since I wrongly assumed everybody is used to work with git. Here are the steps required to get and build the A1 SPI driver on a Linux host:
Code:
# 1) checkout our repository
git clone https://github.com/bitmine-ch/cgminer.git
# 2) in cgminer/ switch to our branch
cd cgminer
git checkout -t origin/bitmine-A1-scratchpad
# 3) run autogen and make
./autogen.sh --enable-bitmine_A1
make
Known limitations
This is what I got from the FPGA emulator and therefore preliminary, but assuming the chip behaves the same, it is essential for HW designs out there: the BIST_START command that runs the auto-addressing process and enumerates the chips in a chain seems to work only once after chip reset. In subsequent calls it returns zero number of chips. The RESET command does not help here, therefore to start from a defined state you should provide means to HW-reset the chip in your design.
Undocumented features
Some bits in the register[23:8] range (tagged as reserved in section 3 of current spec doc) seem to have the following functionality:
register[17]: 2nd job active - if 0, host can feed another job to input queue
register[16]: 1st job active - if 0, chip is job-less and not hashing any more
register[15:12]: job_id of 2nd input item
register[11:8]: job_id of 1st input item
Again, these are preliminary assumptions that need to be confirmed by chip designing company. But since this bits are used in the current driver to greatly improve the feeding of input queues, assume them to be final.
These updates will be added to the chip specification document as soon as we double-check with real chips and get confirmation from chip manufacturer - which I expect to happen by end of this week.
Partitioning chip chain
As you can read from the driver sources, the working units visible to cgminer are chip-chains. Instead of having long chains exposed to the risk of a single chip bricking the chain, Bitmine follows a modular concept with one STM32F1x controlling sub-chains on its SPI interfaces and transparently behaving like a chip-chain to the host as SPI-slave. I started working on this FW, which will be made open source as soon as it passes testing. If you are following the same concept with your design and are interested in working together on the SW side, please PM me.
That's for this year. I have some feeling that next year will be a good one for the DIY scene.
Cheers,
zefir
Jump to: