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

The approach you are describing is similar to what I implemented as a calibration tool. It consists of a dummy cgminer that feeds the chains with reference test vectors and collects per-chip statistics over the complete parameter range. Ideally, the output of such a calibration run would provide you the optimal settings for each chip for a given power consumption / hashrate target. Unfortunately those statistics showed the unreliable characteristics I described above.

As for your high-level approach, two components to consider:
a) voltage control is completely done outside of cgminer over i2c-tools. Accessing the voltage regulator gives means to damage the chips, so for liability reasons I need to check first if and under which conditions I can publish the relevant information.
b) you are right, there is no per-board or per-chip configuration support in the A1 driver currently. This is considered useless for now, since it would lead to a configuration hell (like you don't know which slots are populated in your product and how to assign them individual configs).

If you are familiar with the cgminer source code, you can help yourself with b) easily by implementing an extension to the --bitmine-a1-options parser to consider sys_clock not as a global value but as a comma separated array and provide individual clocks for each board. For this you obviously need to be able to build your own cgminer binary, i.e. replace Bitmine's FW with a full RPi distribution including build tools. With some related howto posts in this forum this should be easy.

Good luck.

So what failed, and would you be wiling to release the schematic and PCB under a GPL license

Your experience and observation is why it would benefit vendors (or maybe Innosilicon) to do a  AGPLv3 reference design board we can all experiment with. They'd sell more chips if us software/system guys had a full system we could tweak the design for.

I have been thinking about doing a single-chip A1/A2 miner design using KiCad (open source PCB tool) just for that reason.

I don't know for *sure* on the details of the CCD, but you should be able to modify CGminer ( driver-SPI-bitmine-A1.c ) to set voltages and clock speeds individually for each hash board. I'd be very interested in seeming some code that does this. The problem is going to be the optimal tuning point is going to change with temperature and a whole bunch of other things (including how much power each of the other boards are drawing and the corresponding voltage and/or noise on the 12v power supply lines). You're going to want some control algorithm to do the adjustment, and maybe using something from http://en.wikipedia.org/wiki/Maximum_power_point_tracking might be relevant (you want 'peak hash tracking').

The other thing to watch out for is to check the *actual accepted shares* rate, because what I've found is sometimes the reported hashrate by cgminer *looks* really good but the actual accepted shares is horrible if the chip is too hot or overclocked too much.

Now if only we could get new A1 silicon that has on-die temp sensors and maybe even a http://en.wikipedia.org/wiki/Ring_oscillator we could read from the registers to track individual chip silicon temp/performance.

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.

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.

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

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:

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.

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?

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.

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:


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?

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.

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).

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

Hi!

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

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?

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

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

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 ', but it does not seem to be working right.