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

[zefir]

Update: 2-Chip Evaluation Board Reference Design published by Bitmine


I have been approached numerous times from designers asking for a A1 reference design. Today, Bitmine added their 2-chip eval board design to their GitHub repository.

We used this board for initial verification - it runs with the provided cgminer driver as is over RPi's SPI interface.

[1714157119]

1714157119

[1714157119]

1714157119

[1714157119]

1714157119

[totalslacker]

Both   I must have started developing the driver based on an initial version of the specs and did not modify naming to the updated ones. Will be fixed in the driver I'll provide for upstream integration.

As for the 'work done' flag: this is something I found out tracking the register (already described somewhere in this thread) and which is currently being worked on to get integrated into the data sheet update by Bitmine. They are currently in the final steps of ramping up production, so please be patient for that.

OK - thank you! I think I saw that original post a long time ago and then failed to recall it

The chip chain partitioning comment there is also a good one. I currently have a four chip chain in my board (just got it back, am testing it now), I will look at partitioning that in the next revision.

[goodney]

This was already addressed in this thread somewhere. Generally: yes I plan to push it upstream and also remain maintainer of that driver. Since that involves quite some initial and ongoing efforts, I need to be sure that it is useful for other projects. Right now, all projects I know do not communicate directly to the A1 but use FW to wrap control over the chip chain from some uC. At the same time, it turned out that for driving Bitmine's products it was required to add lots of HW specific code (like for programmable potis, i2c multiplexers, voltage regulators, temp sensors), so that I doubt the specialized drivers will be usable for anyone beside Bitmine. Here my approach is to wait and see other direct SPI based designs and modularize the driver in a generic part (basically what is already out + some cleanups and updates) and derivate code.

FYI my design is a direct USB-SPI design. I know there are some concerns about CPU load on the host when communicating this way, but to me direct USB-SPI is the fastest way to a working board since I don't have to develop µ-controller firmware.

-a[g

[totalslacker]

FYI my design is a direct USB-SPI design. I know there are some concerns about CPU load on the host when communicating this way, but to me direct USB-SPI is the fastest way to a working board since I don't have to develop µ-controller firmware.

I went a similar route although I have both a micro controller and a host SPI interface. I just used the header interface that totalphase.com uses for their beagle and aardvark SPI/I2C monitor/host adapters. This way I can use the aardvark tool to test out the SPI (and I2C that I use for other functions) functionality on the board without writing any code (they have a pretty nice cross-platform application for this) and then as I bring up the micro-controller I can monitor what actually happens on the bus.

So far it's working well, although I'm currently testing out the power supplies, getting the A1's going will be soon!

[ernie-]

Update: 2-Chip Evaluation Board Reference Design published by Bitmine


I have been approached numerous times from designers asking for a A1 reference design. Today, Bitmine added their 2-chip eval board design to their GitHub repository.

We used this board for initial verification - it runs with the provided cgminer driver as is over RPi's SPI interface.

That's great news, I hope someone starts making the 2 chip boards for the low end of the market.

[bitcoin_miner]

how much
http://bitmine.ch/?page_id=919 ?

Hashing power of 200 / 400 / 600 / 800 / 1000 / 1200 / 1400 / 1600 GH/s in power save mode.
Hashing power of 350 / 700 / 1050 / 1400 / 1750 / 2100 / 2450 / 2800 GH/s in turbo mode.

[end18]

Update: 2-Chip Evaluation Board Reference Design published by Bitmine


I have been approached numerous times from designers asking for a A1 reference design. Today, Bitmine added their 2-chip eval board design to their GitHub repository.

We used this board for initial verification - it runs with the provided cgminer driver as is over RPi's SPI interface.

It looks simple and great.

I checked BOM, it's cheap and almost item can be ordered immediately, but LTC3811 is in back-order  

[drinkmorecoffee]

Update: 2-Chip Evaluation Board Reference Design published by Bitmine


I have been approached numerous times from designers asking for a A1 reference design. Today, Bitmine added their 2-chip eval board design to their GitHub repository.

We used this board for initial verification - it runs with the provided cgminer driver as is over RPi's SPI interface.

Can you comment on the LTC3811, and more specifically the current draw of the A1 itself?  The datasheet suggests 20A nominal, 30A peak current draw.  The LTC3811 you guys call out on the reference design doesn't clearly state its maximum current output in the datasheet (link), but it makes a couple general references to a 10A and/or 15A limit (buried in the text somewhere).  How are you using it to power two chips?  Are they just running at dramatically reduced performance, or do we not have to supply as much current as stated in the datasheet?

[totalslacker]

OK, so got boards back this week and initial checks all look good! Have reliable SPI comms with all four chips and power looks to be nice and stable (for at least low frequency operation, need to add cooling before pushing them).

Zefir, your bring up instructions were very helpful - thank you! I was having trouble getting the chip to accept a job and then I finally realized I wasn't reading your instructions properly (had skipped a section). Fixed that and the chips are hashing

But, I'm not getting the same result as you test vector at https://bitcointalk.org/index.php?topic=294235.msg4454746#msg4454746

The registers all look to be good. I can submit the first and second job. The appropriate job active bits are set and the correct job id is set. But, I only get one nonce: 47 b8 a6 62

I get this same single nonce on both jobs and the two chips I've tried. I've looked over the test vector and compared it to my code as well as capturing the SPI bus on a SPI analyzer and it all looks correct…

Might anyone have some suggestions on what I'm missing?

Thanks!

[MrTeal]

Update: 2-Chip Evaluation Board Reference Design published by Bitmine


I have been approached numerous times from designers asking for a A1 reference design. Today, Bitmine added their 2-chip eval board design to their GitHub repository.

We used this board for initial verification - it runs with the provided cgminer driver as is over RPi's SPI interface.

Can you comment on the LTC3811, and more specifically the current draw of the A1 itself?  The datasheet suggests 20A nominal, 30A peak current draw.  The LTC3811 you guys call out on the reference design doesn't clearly state its maximum current output in the datasheet (link), but it makes a couple general references to a 10A and/or 15A limit (buried in the text somewhere).  How are you using it to power two chips?  Are they just running at dramatically reduced performance, or do we not have to supply as much current as stated in the datasheet?

The LTC3811 isn't an integrated switch regulator like the TPS53355 you see used in some other designs. It's a controller and gate driver like the ADP1850, so the maximum current the VRM can handle will be determined by the external FETs and inductors.

[drinkmorecoffee]

Update: 2-Chip Evaluation Board Reference Design published by Bitmine


I have been approached numerous times from designers asking for a A1 reference design. Today, Bitmine added their 2-chip eval board design to their GitHub repository.

We used this board for initial verification - it runs with the provided cgminer driver as is over RPi's SPI interface.

Can you comment on the LTC3811, and more specifically the current draw of the A1 itself?  The datasheet suggests 20A nominal, 30A peak current draw.  The LTC3811 you guys call out on the reference design doesn't clearly state its maximum current output in the datasheet (link), but it makes a couple general references to a 10A and/or 15A limit (buried in the text somewhere).  How are you using it to power two chips?  Are they just running at dramatically reduced performance, or do we not have to supply as much current as stated in the datasheet?

The LTC3811 isn't an integrated switch regulator like the TPS53355 you see used in some other designs. It's a controller and gate driver like the ADP1850, so the maximum current the VRM can handle will be determined by the external FETs and inductors.

Ahh, that explains it.  Thanks!

[totalslacker]

OK, so got boards back this week and initial checks all look good! Have reliable SPI comms with all four chips and power looks to be nice and stable (for at least low frequency operation, need to add cooling before pushing them).

Zefir, your bring up instructions were very helpful - thank you! I was having trouble getting the chip to accept a job and then I finally realized I wasn't reading your instructions properly (had skipped a section). Fixed that and the chips are hashing

But, I'm not getting the same result as you test vector at https://bitcointalk.org/index.php?topic=294235.msg4454746#msg4454746

The registers all look to be good. I can submit the first and second job. The appropriate job active bits are set and the correct job id is set. But, I only get one nonce: 47 b8 a6 62

I get this same single nonce on both jobs and the two chips I've tried. I've looked over the test vector and compared it to my code as well as capturing the SPI bus on a SPI analyzer and it all looks correct…

Might anyone have some suggestions on what I'm missing?

Thanks!

So I realized that the midstate and wdata might be in the improper byte order so I swapped them using the create_job function from zerfir's driver as a reference. No joy though as now I'm not getting any nonce solutions.

It was interesting though that the first chip initially was taking a very long time to run the two jobs - as in a good 30 seconds (at 90Mhz PLL). Chips 2 and 4 ran it in a few seconds as expected (chip 3 in my chain doesn't seem to be functional - SPI communications look to be good until I send it a job at which point it stops responding).

I powered the system down for a while then tried again, chip 1 was back to running at normal. So that's a tad concerning (the PLL had successfully locked in the first test where it was slow and the SPI clock was at the correct frequency for 90Mhz operation). Maybe some hash engines weren't functional (even though it reported all 32 as good)?

Any pointers on my incorrect nonce results would be greatly appreciated!

Thanks!

[zefir]

OK, so got boards back this week and initial checks all look good! Have reliable SPI comms with all four chips and power looks to be nice and stable (for at least low frequency operation, need to add cooling before pushing them).

Zefir, your bring up instructions were very helpful - thank you! I was having trouble getting the chip to accept a job and then I finally realized I wasn't reading your instructions properly (had skipped a section). Fixed that and the chips are hashing

But, I'm not getting the same result as you test vector at https://bitcointalk.org/index.php?topic=294235.msg4454746#msg4454746

The registers all look to be good. I can submit the first and second job. The appropriate job active bits are set and the correct job id is set. But, I only get one nonce: 47 b8 a6 62

I get this same single nonce on both jobs and the two chips I've tried. I've looked over the test vector and compared it to my code as well as capturing the SPI bus on a SPI analyzer and it all looks correct…

Might anyone have some suggestions on what I'm missing?

Thanks!

So I realized that the midstate and wdata might be in the improper byte order so I swapped them using the create_job function from zerfir's driver as a reference. No joy though as now I'm not getting any nonce solutions.

It was interesting though that the first chip initially was taking a very long time to run the two jobs - as in a good 30 seconds (at 90Mhz PLL). Chips 2 and 4 ran it in a few seconds as expected (chip 3 in my chain doesn't seem to be functional - SPI communications look to be good until I send it a job at which point it stops responding).

I powered the system down for a while then tried again, chip 1 was back to running at normal. So that's a tad concerning (the PLL had successfully locked in the first test where it was slow and the SPI clock was at the correct frequency for 90Mhz operation). Maybe some hash engines weren't functional (even though it reported all 32 as good)?

Any pointers on my incorrect nonce results would be greatly appreciated!

Thanks!

Hm, this to me looks like a power issue - at least the effects you observe are similar to what we had here until we got the DCDC stabilized.

First of all, try to not go below 200 MHz sysclock, since I am not sure if the PLL settings are correct for low values or how low it can really get. Operating the chip at 200MHz even without cooling is no problem.

Then ensure the supply voltage is above 0.85V and ripple is within valid tolerance. Same goes for reference 1V8, reset and SPI signals. If you got access to the register, I guess you did that correctly. You can try to stress-test the inter-chip SPI by continuously reading the register of each chip over a longer period to ensure there are no issues.

Usually, the serious troubles begin when you supply the chips with work and they start to hash. The power draw immediately spikes for order of magnitudes and if DCDC is not capable to handle that, the voltage ripple eventually will exceed the tolerance. The chip then usually resets itself, and with that you usually lose access to it, since the chip becomes unaware that it is part of a chain. To regain access to it, you need to HW reset the whole chain and re-enumerate the chips again.

A strong indication that the chip was reset after it started hashing is the inability to read out its register, i.e. you e.g. write 0x0a02 to get register of chip 2, and you read back 0x0a02 instead of 0x1a02, meaning there is no chip 2 in the chain any more.

We detected problems in the DCDC by scoping the levels long term and triggering for levels outside the tolerance range.


As for your other issue with the endianess of the job command: the provided driver uses 8bit transfers and the create_job() function prepares the data for byte-wise operation. If you are not using 16bit and did not modify the source code, please post a trace of the related SPI transfer and I will double check with my logs.

[tvskit]

Somebody already got chips on hand from BITMINE CoinCraft? For the second month brain stem with supply ASIC.

Sorry for my english.

[zefir]

Somebody already got chips on hand from BITMINE CoinCraft? For the second month brain stem with supply ASIC.

Sorry for my english.

Of course chips were delivered. There are more that 20 projects supplied with chips - read this thread for some confirmations.

[zefir]

Announcement: Clarification on my personal Involvement with Bitmine


Dear DIY folks and miners,

as written in the OP, with the chips I ordered and distributed here, I have been Bitmine's largest customer from the beginning. With my ongoing work as consultant for SW and support during bring-up phase, I must have made at least something right: I have been offered a substantial stake of the company's shares and with that since this week I am also a board member.


How does this change the DIY chip distribution?
Definitively only for the better. Running this proxy service for the community already turned out to be error prone and impractical for higher demands. With manual processing, I already messed several orders up (delaying them or sending twice). The first action implemented for that was to make sample chips available from Bitmine's online shop.

Now that the first wave of DIY volumes was delivered, I expect not much further demands for 50+ volumes - those with working design will sure go for 500+ chip orders. To keep the door always open for late comers, I will pursue the integration of smaller order quantities in the online shop.

From this position I have a better influence on Bitmine's day business, so if there is something that can be improved for the DIY scene (I know there is), please let me know, either by posting here publicly or via PM.



Thank you all for the trust and support so far,
zefir

[Cheshyr]

Congrats. You've certainly earned it.

[drinkmorecoffee]

Announcement: Clarification on my personal Involvement with Bitmine


Dear DIY folks and miners,

as written in the OP, with the chips I ordered and distributed here, I have been Bitmine's largest customer from the beginning. With my ongoing work as consultant for SW and support during bring-up phase, I must have made at least something right: I have been offered a substantial stake of the company's shares and with that since this week I am also a board member.


How does this change the DIY chip distribution?
Definitively only for the better. Running this proxy service for the community already turned out to be error prone and impractical for higher demands. With manual processing, I already messed several orders up (delaying them or sending twice). The first action implemented for that was to make sample chips available from Bitmine's online shop.

Now that the first wave of DIY volumes was delivered, I expect not much further demands for 50+ volumes - those with working design will sure go for 500+ chip orders. To keep the door always open for late comers, I will pursue the integration of smaller order quantities in the online shop.

From this position I have a better influence on Bitmine's day business, so if there is something that can be improved for the DIY scene (I know there is), please let me know, either by posting here publicly or via PM.



Thank you all for the trust and support so far,
zefir

Congratulations!

[totalslacker]

Hm, this to me looks like a power issue - at least the effects you observe are similar to what we had here until we got the DCDC stabilized.

First of all, try to not go below 200 MHz sysclock, since I am not sure if the PLL settings are correct for low values or how low it can really get. Operating the chip at 200MHz even without cooling is no problem.

Then ensure the supply voltage is above 0.85V and ripple is within valid tolerance. Same goes for reference 1V8, reset and SPI signals. If you got access to the register, I guess you did that correctly. You can try to stress-test the inter-chip SPI by continuously reading the register of each chip over a longer period to ensure there are no issues.

Usually, the serious troubles begin when you supply the chips with work and they start to hash. The power draw immediately spikes for order of magnitudes and if DCDC is not capable to handle that, the voltage ripple eventually will exceed the tolerance. The chip then usually resets itself, and with that you usually lose access to it, since the chip becomes unaware that it is part of a chain. To regain access to it, you need to HW reset the whole chain and re-enumerate the chips again.

A strong indication that the chip was reset after it started hashing is the inability to read out its register, i.e. you e.g. write 0x0a02 to get register of chip 2, and you read back 0x0a02 instead of 0x1a02, meaning there is no chip 2 in the chain any more.

We detected problems in the DCDC by scoping the levels long term and triggering for levels outside the tolerance range.


As for your other issue with the endianess of the job command: the provided driver uses 8bit transfers and the create_job() function prepares the data for byte-wise operation. If you are not using 16bit and did not modify the source code, please post a trace of the related SPI transfer and I will double check with my logs.

zefir,

So my core voltage was a bit low - I had it at the lower end at 0.82V. I started with changing that to 0.84V as that was easy (to get to 0.85V I need to muck with the trim registers in the power supply - the documentation isn't really clear and I can way over volt the chip if I get it wrong so I didn't want to try that right away).

Things did get much better, but still not 100% so I think you are spot on for the power issue. All four chips are at least claiming they can process jobs.

When I was getting that single nonce that was with sending the data you had posted directly rather than going through create_job. If I fix the endianness with create job I get no results… I am using a byte wise SPI transfer so I believe any 16 bit endiness issues should be ok.

The data I am uploading to chip 1 is (this is in transfer order):

17 01 49 4b f3 70 41 71 f3 e8 3f ea 17 04 10 d8
dc 17 8f 80 2f 12 6d cd b7 e4 2c 25 0a d8 18 a3
1f 8c 01 8e 98 d6 52 66 1f 27 19 10 0a b6 00 00
00 00 ff ff 00 1d ff ff ff ff

I did try faster PLL's and am not seeing any difference in behavior.

I will work on getting the voltage up to 0.85V.

Thank you!

[drinkmorecoffee]

Quick question with regard to USB/SPI comms.  I know of this chip, and that it's been used in other designs in the past to allow SPI comms on the chip to be accessible from a PC over the USB port. 

I'm curious how this affects cgminer, specifically with zefir's driver having been written for an Rpi, which has an SPI port natively available.  My first design will just use the Rpi, but for future implementations I'd like to make it usable from a PC over standard USB.  I can handle the board changes to incorporate the chip, but I'm less sure of the changes that might be required to get the drive to encapsulate SPI commands within USB packets. 

Or is the chip/driver already smart enough to handle this on its own?