I post and respond to this PM here, since it is of general relevance.
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.
Hello!
I know you're crazy busy so I'll keep this short. First of all, thanks for all your amazing work bringing up new miners for these ASICs!
I want to design a PCB for the Coincraft A1 chip but I'm not sure where to begin. I'm a EE but this will be my first miner design. I see the A1 datasheet on the website but I'm having trouble believing it's as simple as making a footprint, providing power and a clock, and breaking out the SPI headers for a RasPi. Is that really all there is to it?
If I make a multi-chip PC-based design can I just get an FTDI serial <--> SPI converter (something like this) and call it a day?
It seems WAY too simple, and I just wanted to make sure I'm not missing something important. I don't want to waste a bunch of money reinventing the wheel when so many of you seem to have the process of PCB design for new miner ASICs down to a science already.
Also, if you'd rather see this in a public forum post, let me know and I'll leave your inbox alone.
Thanks for your time!
I know you're crazy busy so I'll keep this short. First of all, thanks for all your amazing work bringing up new miners for these ASICs!
I want to design a PCB for the Coincraft A1 chip but I'm not sure where to begin. I'm a EE but this will be my first miner design. I see the A1 datasheet on the website but I'm having trouble believing it's as simple as making a footprint, providing power and a clock, and breaking out the SPI headers for a RasPi. Is that really all there is to it?
If I make a multi-chip PC-based design can I just get an FTDI serial <--> SPI converter (something like this) and call it a day?
It seems WAY too simple, and I just wanted to make sure I'm not missing something important. I don't want to waste a bunch of money reinventing the wheel when so many of you seem to have the process of PCB design for new miner ASICs down to a science already.
Also, if you'd rather see this in a public forum post, let me know and I'll leave your inbox alone.
Thanks for your time!
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.
Simply Wow. Thanks for the insight Zefir.
