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

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.

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.

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.

In the A1_scanwork function I see the following code:
I assume this is checking a "work done" flag in the register, however I don't see this bit defined in the data sheet?

Actually, while I'm here it also seems that the driver code is setting the PLL values differently than in the data sheet. The code sets pre_div to be the first two bits in the register data whereas the data sheet defines it as being bits 44:40. Is the data sheet wrong or am I just reading this incorrectly?

Will the A1 driver you've written in your github be ported back to the main cgminer development?

haha, I am a fresh man. I have no coincraft chips yet, but i have just got a Rasp board, so i test A1 SPI driver on it first.
I think ip/mask/gw of Rasp is right, ping stratum.btcguild.com, can reply from 198.245.63.145, but cgminer always failed to resolve, i don't know what is wrong. Thanks loshia!

Dude,
I can not imagine that you ask such a question here.
Any way please save people time and check your dns/IP/mask and GW of pi

then do


nslookup stratum.btcguild.com
Server:  ****************
Address:  192.168.0.222

Non-authoritative answer:
Name:    stratum.btcguild.com
Address:  198.245.63.145

Is that hard?
And before you play with software make sure you are having a board to plug into Rasp(Raspbian). You have one, do you? I bet you do of course
Have in mind that PI produces 0 GH alone. it is used just for communication between your mining hardware a board with coincraft chips and internet

Hi Zefir,

I have got and build the A1 SPI driver on Rasp(Raspbian).
run ./cgminer, then input pool serverdetails:
URL:
stratum+tcp://stratum.btcguild.com:3333
Username:
xxx
Passwrod:
xxx

output:
Failed to resolve (?wrong URL) stratum.btcguild.com:3333
Pool setup failed.

What is wrong?

I've got some goodies too! :-)

Thanks Zefir!

Yes, please follow the order process described in the OP.

Hi Zefir,

Can I order 50 chips from you? any chips still available?

Thanks

Jbcheng

And here is my beauty:
http://imgur.com/M72XLOq
Some borring uC wiring left but is almost done

...

There are two levels of experience I can share. The first one is from the logical link layer / SW side (my domain): when I got the FPGA simulator to work on the cgminer driver I attached it to RPi's SPI interface, sent it a job and got a result returned. I was like 'whoa if that is how the real chip works, that will be easy'. Then when I got to test the driver on a real A1, the same driver still worked and the chip crunched the whole nonce range in 160ms. I was like 'whoa, this is incredibly easy!'. If you take a look at the initial cgminer driver, you'll see what I mean.

Then there is the productizing level - which is not my domain and I can only report from my experience with HW hacking sessions over lots of sleepless nights. There it turns soon out that the 'easy' preconditions the chip requires (as depicted here) are not exactly trivial to ensure. You might end up opening your Champagne bottle after seeing your board hashing for hours flawlessly - just to notice it stopped over night. And after endless debug sessions to find out that one chip reset itself since your power supply had a larger than tolerated ripple at a very specific temperature. Or that one single bit in inter-chip SPI communication toggled due to parasitic effects from adjacent PCB layers - which as result kills a chip chain in case a command is interpreted wrongly by the chip.


So in essence: yes, the chip is really that easy. Ensure you keep the requirements met and it will hash right away. As for communication, there is not much you can mess up there: I have been trying the RPi's SPI port, bit-banging over GPIO, or proxying the access over STM32 SPI port - all work with master SPI clocks between 5 kHz and 10 MHz.

To make a working product out of it is a different story then. Getting it to hash for some hours is still easily doable - but building a board that runs for months untouched under various environmental conditions is not. That is why Bitmine has not yet started shipping products. And that might be the reason we see only marto74 reporting back successful operation of his design - he has a great experience with his Avalon / BitFury boards and started off from a design with verified signal integrity. Others starting from scratch might need to learn first.

In retrospect my advice would be: follow a KISS approach; start with a single or 2-chip design first and ensure your DCDC is capable to keep up the required power stability (for reference: marto74 and Bitmine provide 50A); in a second step, copy paste that design to form larger chains. While the A1 is meant to be chained up to 250 chips, 8-chip chains seem to be a sweet spot between overhead and communication latency.


Good Luck.