[CLOSED] Bitmine CoinCraft A1 28nm chip distribution / DIY support

[intron]

The core voltage in turbo mode is 0.85V. The current from datasheet is 30A.
So we have 26W in turbo mode.
But in turbo mode the speed is 40 GH/s and power usage is 1W/GH.

It seems that consumption current must be about 50A in turbo mode.

Puzzles me also...

[zefir]

Update: initial A1 cgminer driver released


DIY folks and miners,

as announced before, some days ago I received one of this FPGA boards to develop the initial cgminer driver. This board is configured to emulate two daisy-chained A1 chips with 4 cores each, running at ~10% of the expected nominal clock. This is as close at it gets without having the real chip in hand, i.e. I was able to implement and test all documented features (plus some I reverse engineered).

While the emulated HW is limited in terms of clock and number of cores, all basic features (hashing, queue management, chaining) are working. At this stage I am quite confident that if the ASIC behaves exactly like emulated, it can start hashing immediately after it is put on its PCB.

I am running the FPGA board connected to a RasPi. Running over night cgminer settles the average hashrate to 650MHps, which corresponds to ~26GHps for the A1 (4x the cores @ 10x the clock).

Those interested can find the cgminer branch on github here.


Wish you all peaceful and pleasant holidays and a truly successful start in 2014 - with chips to play in hand soon.

zefir

[Bicknellski]

Thanks Zefir and Merry Xmas to you as well and prosperous new year.

Is 1st week in January still the possible for these chips?

[RHA]

Congratulations, Zefir.

What were the hidden features, which you managed to reverse engineer?

[zefir]

Update: Preliminary Findings relevant for DIY Designs

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

[zefir]

[...] 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

[marto74]

Great news.
We are in for samples.
Test boards dusting on the desk for more than two weeks already

[vs3]

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).

[darkfriend77]

We are in for the early samples "The Wasp Project Collective" ...
.. happy new year ..

[Bicknellski]

Any news on the design competition?

[zefir]

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

[MrTeal]

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?

[goxed]

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

excellent, I will get my boards ready in time for next batch of chips.

[Bicknellski]

Thanks for the effort there Zefir doing all that work for all of us out here.

[intron]

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 all these three options on the prototype board:)
The datasheet is less then conclusive I'm afraid.

[intron]

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.

[goodney]

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

[zefir]

Well, as pure SW guy I can provide only limited HW related feedback, so please double check.

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?

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

[MrTeal]

Well, as pure SW guy I can provide only limited HW related feedback, so please double check.

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.

Thanks, I'll try 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?

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.

[ChipGeek]

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.

I think he means you need clock buffers on the board, not on the chips.  No need to worry yet.

Edit: Removed excess text.