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

[Bicknellski]

Hello,
If some of 50pcs slots are still available i'd like to book one. Otherwise if someone want to sell part of the 50pcs please PM me.

There are some left until end of this week. Please follow order process described in OP.

[nafta]

Thanks Zefir,
Coincraft A1 received.
I visited Bitmine Headquarters with my team. I really appreciate your job.
I will post our test result!

Nafta

[zefir]

I post and respond to this PM here, since it is of general relevance.

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!

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.

[dplusf]

I post and respond to this PM here, since it is of general relevance.

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!

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.

[drinkmorecoffee]

...

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.

Thank you so much for this response! 

I understand that there is a big difference between a prototype and a product, and indeed I've had projects get hung up on this transition before.  But you beautifully confirmed my suspicion about initial board bring-up being as simple as it appears to be.  Thank you again, not only for this response (which was stellar), but for all your work in these forums and for the community in general.

[jbcheng]

Hi Zefir,

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

Thanks

Jbcheng

[Felipeo]

I also get next samples batch


Thanks Zefir

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

Nice one Dex

( Dexter is part of my Dev team   )

[zefir]

Hi Zefir,

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

Thanks

Jbcheng

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

[mhmmd]

Hello everybody

Please forgive me for the following questions, few of which have been already put (hope to read something that will update and simplify the previous answers) and some perhaps very stupid:

1) As a diy who want to start from the scratch, meaning the principle of hashing, the hardware development and the use and elaboration of fw and sw, where do you suggest me to start and to collect material to study?
2) I would love to use the A1 chip: to buy them and build my miners with them; is there some generous one which would give me schematic to build working boards or at least sell them to me for a friendly price?
3) While I promise to study and try my best to become independent or even better, a contributor to the forum, is there someone who can help me with the programming?

Thanks in advance for the patience with my naif post.

As a very modest contribution I would like to announce that living in North Italy, just two hours away from Bitmine.ch, I'm ready to help anybody who can benefit from that.

Good day!

[RHA]

@marto74:
We see 279.6 GH/s - it would be very awesome but why there is WU 51.2/m only?

[jbcheng]

Hi Zefir,

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

Thanks

Jbcheng

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

Hi Zefir,

Payment made and please proceed the shipment for my 50 Sample. Thanks

jbcheng

[valkir]

I've got some goodies too! :-)

Thanks Zefir!

Like this! Keep me in touch! 

[zhuxiaowei123]

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?

[loshia]

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?

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

[zhuxiaowei123]

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?

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

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!

[loshia]

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?

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

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!

try another pool then....
I still do not get it what exactly are you going to test without a board and chips but...it is up to you

[jbcheng]

Hi guys,

How do you track your chips order with bimine? there phone seems never got answer? I rang and wait for 30 minutes and no one pick up the phone?

Thanks

Jbcheng

[totalslacker]

Zefir,

I was reading through your cgminer driver and had a question:

In the A1_scanwork function I see the following code:

Code:

		hexdump("A1 RX", a1->spi_rx, 8);
		if ((a1->spi_rx[5] & 0x02) != 0x02) {
			work_updated = true;
			struct work *work = wq_dequeue(&a1->active_wq);
			assert(work != NULL);

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?

Thank you!

[jrkalf]

Another noob question here...

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


Regards,

jelle

[zefir]

In the A1_scanwork function I see the following code:

Code:

		hexdump("A1 RX", a1->spi_rx, 8);
		if ((a1->spi_rx[5] & 0x02) != 0x02) {
			work_updated = true;
			struct work *work = wq_dequeue(&a1->active_wq);
			assert(work != NULL);

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?

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.

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

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.