Topic: [CLOSED] Bitmine CoinCraft A1 28nm chip distribution / DIY support - page 11. (Read 81287 times)

I pulled it from git and compiled it on the RPi yesterday with no issues.  I'm not sure why you'd receive that error.

I have some problem in comfile the cgminer-bitnime-A1-scratchpad.

https://github.com/bitmine-ch/cgminer/tree/bitmine-A1-scratchpad

in making process...Message like this.

  CC     cgminer-api.o
  CC     cgminer-logging.o
  CC     cgminer-usbutils.o
  CC     cgminer-driver-SPI-bitmine-A1.o
In file included from driver-SPI-bitmine-A1.c:19:0:
spi-context.h:4:25: fatal error: linux/types.h: No such file or directory
 #include
                         ^
compilation terminated.
make[2]: *** [cgminer-driver-SPI-bitmine-A1.o] Error 1
make[2]: Leaving directory `/home/Note/cgminer-bitmine-A1-scratchpad'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/Note/cgminer-bitmine-A1-scratchpad'
make: *** [all] Error 2


It is missing some libraries?

Congrats Zefir，You deserve it!

I used the supply margining feature and got the core voltage up to 0.85V. I'm still getting exactly the same results.

I poked around online and found some other test vectors. I don't get the same results as they do either, but I consistently get the same (incorrect) nonce's so I guess that's good I'm running multiple jobs through each chip and looping through the whole test five times (just running one chip at a time currently).

I'm seeing peak to peak ripple of about 50mV on the scope so power looks to be good. I would also expect to not get such consistent behavior if I had a power issue?

So perhaps I have a nasty bug somewhere…

Thanks!

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? 

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!

Congratulations!

Congrats. You've certainly earned it.

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

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

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

Sorry for my english.

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.

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!

Ahh, that explains it.  Thanks!

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.

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://bitcointalksearch.org/topic/m.4454746

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!

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?

It looks simple and great.

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

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.

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