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

[[gadget]]

more progress:

fan header:
https://i.imgur.com/U4mDcso.jpg

fan header attached:
https://i.imgur.com/N47X0nd.jpg

heatsinked rig in operation:
https://i.imgur.com/JMRo5Kz.jpg

[1714783904]

1714783904

[[gadget]]

Quick question:

How many functional cores are you guys getting on your chips?
I've tested 4 tonight, and they all seem to only have 1 out of 32.
Are all sample chips like this? Or am I really, really unlucky?

The time to complete the test job is 5.2 sec @ 800MHz, which is consistent with
only 1 of 32 cores going. The chips aren't heating up much at all, either. Even
at 800MHz.

[zefir]

Quick question:

How many functional cores are you guys getting on your chips?
I've tested 4 tonight, and they all seem to only have 1 out of 32.
Are all sample chips like this? Or am I really, really unlucky?

The time to complete the test job is 5.2 sec @ 800MHz, which is consistent with
only 1 of 32 cores going. The chips aren't heating up much at all, either. Even
at 800MHz.

No, that is for sure not ok. As a rule of thumb, I would classify the chips as follows:

• grade A: 31 - 32 working cores: run at full speed
• grade B: 26 - 30 working cores: run at reduced speed (50-80% of nominal), bears low risk to disturb chain
• grade C: 25 and less working cores: disable chip (or enable only after proper inspection), bears high risk to disturb chain

Alas, I have never seen a chip with only one working core so far. Are you sure your power supply is stable at ~850mV and you assert reset for ~1s before you issue the BIST command?

[Dexter770221]

I've had similiar problem. The problem was power supply. When I send write reg first and underclock chip to 200MHz then bist fix returned 31 cores, otherwise it was 1 (bist fix first then write reg).

[hozer]

Quick question:

How many functional cores are you guys getting on your chips?
I've tested 4 tonight, and they all seem to only have 1 out of 32.
Are all sample chips like this? Or am I really, really unlucky?

The time to complete the test job is 5.2 sec @ 800MHz, which is consistent with
only 1 of 32 cores going. The chips aren't heating up much at all, either. Even
at 800MHz.

What code are you running for the test job? Is there a github for some test/bringup/validation code that I just haven't found yet?

I saw the same issue you did until I raised the supply voltage.

Now I can start hashing but there appear to be power supply stability issues, and I would like to run some simple test code in a loop rather than the whole full-blown cgminer, or at least run 'cgminer --benchmark' or 'cgminer --benchfile <somefile>', but it does not seem to be working right.

[hozer]

Quick question:

How many functional cores are you guys getting on your chips?
I've tested 4 tonight, and they all seem to only have 1 out of 32.
Are all sample chips like this? Or am I really, really unlucky?

The time to complete the test job is 5.2 sec @ 800MHz, which is consistent with
only 1 of 32 cores going. The chips aren't heating up much at all, either. Even
at 800MHz.

What code are you running for the test job? Is there a github for some test/bringup/validation code that I just haven't found yet?

I saw the same issue you did until I raised the supply voltage.

Now I can start hashing but there appear to be power supply stability issues, and I would like to run some simple test code in a loop rather than the whole full-blown cgminer, or at least run 'cgminer --benchmark' or 'cgminer --benchfile <somefile>', but it does not seem to be working right.

I ended up pointing cgminer at a local p2pool instance, and answered my own question with "If it works with cgminer, why waste time with test code".

Now I'm starting to wonder crazy things like how much of p2pool could I make run on http://micropython.org/ and have that talk directly to the A1 chips instead of all this MMU and userspace nonsense in a Raspberry Pi

[Wolke]

Anyone need reference board PCB?

I'm selling reference board PCB with stencil.

Here is my site.

http://theminingware.com/

This board has a granted public licence on github for 2-chip PCB, so what are you selling then ?

You're selling produced boards or what ?

24 USD per board ? Assembled, without A1 chips or just board and nothing else ?

this board is on github ? i can't find, do you have a link for me ?
thanks...


EDIT:
ok i found it, thx
https://github.com/bitmine-ch/bitmine

[Dimoza]

Does anybody know whether Bitmine have any plans to reduce prices for Coincraft samples? Difficulty have risen dramatically since February and in the measure of price/watt ratio it looks like almost 0 profitability. Even in good market prognosis.

NB. I remember here was somebody form Bitmine co-owners?

[Dimoza]

There is a TI TXB0106 -based level translator I made to talk to A1s. Requires VCC from the MCU board for high voltage side to function and translate correctly. Also provides 1.8V for A1s data interface. The LDO on the left is TI LP3871-1.8V. The circuit is trivial.

I need a second one and it takes too much time to build on a protoboard. I'm routing a PCB, will post when ready.

https://www.circuitsathome.com/wp/wp-content/uploads/2014/04/bc_levelshifter.jpg

Hi!

is it really necessary to have level translator for RPi connection? why nobody mention it before (or I miss something?)

[Dimoza]

By the way, guys, why just don't use some sort of FTDI  USB-SPI converter instead of RPi?

http://www.ftdichip.com/Products/ICs/FT221X.html
or this monster (that I have) http://www.ftdichip.com/Products/ICs/FT2232H.htm

[[gadget]]

Sorry for the late reply guys, just moved half way across the world

Zefir and Dexter - thank you for the advise. I ended up rewriting a clean version of the test code and can now confirm that the order of

• HARD_RESET
• SOFT_RESET
• BIST_CHECK
• BIST_FIX
• REG_READ

works just fine. Still not sure what was causing the problem before, but it's gone now

I've shared the test code in my github here

PS.
With regard to the level shifter, yes, it is indeed necessary, unless you can find something that talks SPI at 1.8V directly (possible but rare).

[jpo]

Hello all,

After a few failed attempts I have decided to liquidate my remaining bitmine chips.  This endeavor ended up taking to much of our time and we made the choice to move on.  To those with working boards or under development this could be a great way to get a few extra mining chips fast.

So we have 35 untouched bitmine chips  These were purchase from Zefir a few months back.  At $3.5 per GH we are asking $3050 for them.  It would ship same day payment is received.  If you are local to the United States I would ship them overnight.  We also have 15 chips that were soldered on at one point, but have since been removed.  They didn't receive voltage spikes, it was mainly just bad board design.  Given the condition and buyer beware on these 15, if you are interested we could give them to you for $2 per GH so $750.

If anyone is interested please let me know.  If you in the United States I can give you a call for verification and peace of mind.

Here's the chips:

http://i.imgbox.com/8N1LhRcE.jpg

And here is one of our failed designs: 

http://i.imgbox.com/jCgloLVU.jpg
http://i.imgbox.com/jCgloLVU.jpg

Thanks All.

[[gadget]]

I'm starting to play around with cgminer (Zefir's version from sometime in Jan-Feb, before it was integrated). One thing I noticed was that the HW_RESET was not being done, thus it must be done by hand. No problem there. This next issue however is somewhat puzzling to me:

I set the sysclk to 200000 kHz (200MHz) in the --bitmine-a1-options, the debug output confirms this:

Code:

 [2014-05-02 07:57:20] Started cgminer 3.9.0                    
 [2014-05-02 07:57:20] SPI '/dev/spidev0.0': mode=1, bits=8, speed=800000                    
 [2014-05-02 07:57:20] spidev0.0: Found 2 A1 chips                    
 [2014-05-02 07:57:20] Setting PLL: CLK_REF=12MHz, SYS_CLK=200MHz                    
 [2014-05-02 07:57:20] Setting PLL to pre_div=2, post_div=4, fb_div=133: 0x88 0x85 0x21 0x84 0x00 0x00

I did my testing between 180MHz and 480MHz, and the temps got as hot as 50C. Now, at 200MHz they get blazing hot! I can't even touch them anymore.

Is this to be expected? Or is the PLL being misset somehow and I end up running at closer to 800MHz?

[zefir]

I'm starting to play around with cgminer (Zefir's version from sometime in Jan-Feb, before it was integrated). One thing I noticed was that the HW_RESET was not being done, thus it must be done by hand. No problem there. This next issue however is somewhat puzzling to me:

I set the sysclk to 200000 kHz (200MHz) in the --bitmine-a1-options, the debug output confirms this:

Code:

 [2014-05-02 07:57:20] Started cgminer 3.9.0                    
 [2014-05-02 07:57:20] SPI '/dev/spidev0.0': mode=1, bits=8, speed=800000                    
 [2014-05-02 07:57:20] spidev0.0: Found 2 A1 chips                    
 [2014-05-02 07:57:20] Setting PLL: CLK_REF=12MHz, SYS_CLK=200MHz                    
 [2014-05-02 07:57:20] Setting PLL to pre_div=2, post_div=4, fb_div=133: 0x88 0x85 0x21 0x84 0x00 0x00

I did my testing between 180MHz and 480MHz, and the temps got as hot as 50C. Now, at 200MHz they get blazing hot! I can't even touch them anymore.

Is this to be expected? Or is the PLL being misset somehow and I end up running at closer to 800MHz?

Please take a look at latest cgminer driver. The PLL code was re-written to match updated specs quite some time ago and was merged upstream just recently. The issue was a misinterpretation of the PLL formula that got clarified with the latest chip documentation. It affected system clocks below 250MHz, so exactly your case. Please let me know if the problem remains.

As for the chip temps: as soon as the chip starts hashing, it instantly gets very hot. At nominal 800MHz, if you have no top heatsink installed, it reaches almost immediately 60°C with proper back heatsinks and more than that without. Obviously this also highly depends on the supply voltage, which is supposed to be on a safe side over 820mV. This requirement is unfortunately chip specific, so you might find some boards going just fine with 760mV while other are more picky with chips resetting immediately below 820mV.

As for the HW reset: this is always board specific. As reference, please check the A1 board selector sources where reset is performed with different types of i2c board expanders.

[[gadget]]

Please take a look at latest cgminer driver. The PLL code was re-written to match updated specs quite some time ago and was merged upstream just recently. The issue was a misinterpretation of the PLL formula that got clarified with the latest chip documentation. It affected system clocks below 250MHz, so exactly your case. Please let me know if the problem remains.

As for the chip temps: as soon as the chip starts hashing, it instantly gets very hot. At nominal 800MHz, if you have no top heatsink installed, it reaches almost immediately 60°C with proper back heatsinks and more than that without. Obviously this also highly depends on the supply voltage, which is supposed to be on a safe side over 820mV. This requirement is unfortunately chip specific, so you might find some boards going just fine with 760mV while other are more picky with chips resetting immediately below 820mV.

As for the HW reset: this is always board specific. As reference, please check the A1 board selector sources where reset is performed with different types of i2c board expanders.

Zefir, thank you for the quick reply. I am going through the code right now. I just wanted to quickly confirm something with you - the integrated code is specific to the CoinCraft Desk and communicates over libusb (rather than RPi SPI headers), correct? Thus, I will be merging some of the new stuff (such as the updated PLL code) into the old RPi A1 driver code?

[zefir]

Please take a look at latest cgminer driver. The PLL code was re-written to match updated specs quite some time ago and was merged upstream just recently. The issue was a misinterpretation of the PLL formula that got clarified with the latest chip documentation. It affected system clocks below 250MHz, so exactly your case. Please let me know if the problem remains.

As for the chip temps: as soon as the chip starts hashing, it instantly gets very hot. At nominal 800MHz, if you have no top heatsink installed, it reaches almost immediately 60°C with proper back heatsinks and more than that without. Obviously this also highly depends on the supply voltage, which is supposed to be on a safe side over 820mV. This requirement is unfortunately chip specific, so you might find some boards going just fine with 760mV while other are more picky with chips resetting immediately below 820mV.

As for the HW reset: this is always board specific. As reference, please check the A1 board selector sources where reset is performed with different types of i2c board expanders.

Zefir, thank you for the quick reply. I am going through the code right now. I just wanted to quickly confirm something with you - the integrated code is specific to the CoinCraft Desk and communicates over libusb (rather than RPi SPI headers), correct? Thus, I will be merging some of the new stuff (such as the updated PLL code) into the old RPi A1 driver code?

The driver code accesses the chips directly over the Linux spidev user space SPI driver (Win not supported), the layering goes like: spidev -> spi-context -> A1_chip -> A1_chain -> board_selector

If you need to replace direct SPI access through some USB->SPI bridge, your best take is to replace the existing spi-context.c file with something that provides the spi_transfer() function to do a full duplex data exchange with the A1.

Same goes for the upper layer: if you want to use the driver as is, you need to implement a board selector for your product variant. It needs at least to provide a reset_all() method which should issue a HW reset to all chips of a selected board.

Let me know if you need further assistance. I tried to implement the A1 driver in a way that allows to cover a wide range of variants and would like to keep it generally usable - in contrast to e.g. having slightly modified copies of existing ones (e.g. BitFury) for every variant out there. If something is missing to support your variant, please let me know.

[ntekcomputers]

Anyone interested in purchasing some Coincraft A1 28nm chips? PM me if you are interested. Happy to use an escrow service.

Payment through BTC, Wire Transfer, or PayPal

We have around 2,500 A1 chips right now and will be getting more so please let me know if you need any. Price is negotiable and will consider all reasonable offers.

These chips are from the production batch that Bitmine.ch sent us at the end of January 2014:

[Mork]

Hello Zefir,

Sorry if this thread is inappropriate, but this is the only place I have found to discuss technical stuff about coincraft.
I have a question about the coincraft cgminer implementation, that maybe you can answer me:

Can you set different clocks and voltages for each module within a coindesk with cgminer?
I have one module that is quite prone to errors and one module I can push quite hard. Right now I have to use the settings of the bad module for both, which wastes a lot of power, which again, given the bitmine circumstances, really hurts. :|

Also, did you manage to get the temperature readings working in cgminer somehow?

If both are possible, I'm thinking about creating a little autotune tool do automaticaly determine the best settings for the modules in terms of efficiency. This requires me to read accurate temperature data of each of the modules and to be able to set the settings for each module individualy.
I could do it more low level, but that doesn't pay of for the 400GH/s I own anymore in any way, so I'd like to go with something "easy" to implement.

Thank you and best!
mork

[zefir]

Hello Zefir,

Sorry if this thread is inappropriate, but this is the only place I have found to discuss technical stuff about coincraft.
I have a question about the coincraft cgminer implementation, that maybe you can answer me:

Can you set different clocks and voltages for each module within a coindesk with cgminer?
I have one module that is quite prone to errors and one module I can push quite hard. Right now I have to use the settings of the bad module for both, which wastes a lot of power, which again, given the bitmine circumstances, really hurts. :|

Also, did you manage to get the temperature readings working in cgminer somehow?

If both are possible, I'm thinking about creating a little autotune tool do automaticaly determine the best settings for the modules in terms of efficiency. This requires me to read accurate temperature data of each of the modules and to be able to set the settings for each module individualy.
I could do it more low level, but that doesn't pay of for the 400GH/s I own anymore in any way, so I'd like to go with something "easy" to implement.

Thank you and best!
mork

Hi,

are you talking about a DIY design, or Bitmine's CoinCraft?

First to your generic question about PLL: yes, you can set the PLL individually for each chip. In the current driver, at initialization phase lower grade chips (those with a reduced number of working cores) are already set to work at lower speed (check https://github.com/ckolivas/cgminer/blob/master/driver-SPI-bitmine-A1.c#L403). The same mechanism can be used to 'optimize' individual chips in a chain.

Assuming you are operating a CCD 400, the response to the temperature sensor is as follows: temperature data is not meant to be accurate enough to be used for optimization. In the CCD, there are up to two 1-wire sensors attached to the back heat-sink of defined boards. Sensors are not accessed from cgminer but from within a polling system daemon that uses the monitored data to stop cgminer on overheat.

I don't want to demotivate you, but what I can tell you is this: over the past ~3 months I worked intensively on auto-tuning mechanisms and have to admit that I did not came up with something useful. There is a bunch of inter-dependent system parameters (chip grade, supply voltage, clock, etc.). While itself not trivial, the dependencies are neither static (e.g. change with temperature) nor linear nor continuous. Sometimes they are even not deterministic   With that, for me it looks almost impossible to provide some generally usable auto-tuning mechanism.


Nevertheless, I wish you best of luck and would gladly see your code contributed upstream.

[Mork]

Hello Zefir,

thank you for your response and sharing what you have learned!
I was talking about a CCD200/400, yes. I'm more the software guy so I figured creating my own board, which I very wanted to do, would not make sense at all. Too much to learn from scratch and not enough time to do so. :|

I've followed your thread and posts over the last months and read that you we're trying to create such an autotune tool on your own, but more low level than I'm trying right now. As far as I remember you wanted to tune the chips individually, which would get the most out of them. I cannot do that at all, so I try to tune the individual boards inside the CCD instead, which should be easier and still would be better than nothing.
For that I though about using some existing high-level software to set a clock speed and voltage, let it hash for X minutes and evaluate the shares/stales/hw errors - and watch the temperature of course. With that, go through a list of clock speeds and voltage combinations to check where I get the best share/error/power consumption. I already did this manually to some degree, but it is very time consuming, so I wanted to automate that.

The basic idea was to use cgminer to set those settings to the CCD modules individually, in my CCD400 there are two of them.
As far as I can see, I can only set 1 clock and 1 voltage settings for the whole CCD, but I'd need to set those individually for the two modules, as they behave different - one generally needs more voltage than the other to not produce too much HW errors with the same clockspeed. Right now I have to use the conservative settings that make the "bad" module run at an acceptable performance, but it wastes potential on my second module, which could do much more.

But this is only possible if I can set the voltage and clock speed individually for each board in a CCD, using cgminer, which I think is not possible right now? Or maybe it's even not possible by design?
I tried to have a look at the A1* files in git, but I don't understand a thing of the low level stuff being done there.