Pages:
Author

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

newbie
Activity: 26
Merit: 0

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! Smiley
member
Activity: 102
Merit: 10
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
newbie
Activity: 26
Merit: 0
Both Wink  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 Smiley

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.
donator
Activity: 919
Merit: 1000
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.
donator
Activity: 919
Merit: 1000
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 Wink  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.

newbie
Activity: 4
Merit: 0
Another noob question here...

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


Regards,

jelle
newbie
Activity: 26
Merit: 0
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!
newbie
Activity: 40
Merit: 0
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
legendary
Activity: 1610
Merit: 1000
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. Huh
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 Grin
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. Huh Thanks loshia!
Wink
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
newbie
Activity: 2
Merit: 0
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. Huh
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 Grin
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. Huh Thanks loshia!
legendary
Activity: 1610
Merit: 1000
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. Huh
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 Grin
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


newbie
Activity: 2
Merit: 0
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?
legendary
Activity: 1484
Merit: 1004
I've got some goodies too! :-)

Thanks Zefir!

Like this! Keep me in touch!  Grin
newbie
Activity: 40
Merit: 0
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 Smiley

jbcheng
RHA
sr. member
Activity: 392
Merit: 250
@marto74:
We see 279.6 GH/s - it would be very awesome but why there is WU 51.2/m only?

newbie
Activity: 5
Merit: 0
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!
donator
Activity: 919
Merit: 1000
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.
sr. member
Activity: 476
Merit: 262
EOSABC
I also get next samples batch Smiley


Thanks Zefir Smiley


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

Nice one Dex Cheesy

( Dexter is part of my Dev team Smiley  )
newbie
Activity: 40
Merit: 0
Hi Zefir,

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

Thanks

Jbcheng
newbie
Activity: 58
Merit: 0

...

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.
Pages:
Jump to: