Hello,

a diverging hashrate at pool and cgminer simply means you are losing shares through HW errors.

What you need to consider is:

a) a detected HW error also implies that there were errors on true results; the related probability needs to be derived correctly, but I would assume that when you have a HW error rate of 5% it also means you are missing 5% of real results

Did Bitmine change chips specs?

Wasn't turbo 40GH? Now it is 33GH... But still same price... But I do agree I don't see way to get them to 40GH with normal cooling...

EDIT2: And from what I see you can't get 33GH out at 0.85V more like 0.985 to 1 V. Also 1W in Turbo mode is fantasy... More like 1,3 to 1,5W... Hard to say how much is the loss on chip power supply...

Have you been able to measure the current or power consumed by one chip at 800Mhz?

Assuming you have a 12MHz ref clock, try this:

• set pll_postdiv and pll_prediv to 2
• set fbdiv to (target_sys_freq / 3), i.e. you can set your sys_clock in increments of 3MHz, with fbdiv being 9 bit you can go to 1.5+GHz

Thanks for feedback and good luck (you're almost there )

Having some trouble with getting 0x04 responce on the 0x04 reset command.
I'm doing the HW reset as described. The signals from raspi passed through level shifters.
Chip select DI CLK are ok. I see 0x04 passing into the chip but there is nothing at the output.
The VDDcore is 0.7 volts. Maybe it is too low?

You will notice that you get back 4 results, although the job has 5 winning nonces. That is because the A1 has an output queue of 4 elements, so one of the results is overwritten. To get them all, you need to pull the results early enough while chip is still hashing. Have a look at the reference driver to check how to do this continuously.

What you get back from the chip is a valid Diff1 share, while your pool is obviously asking for higher difficulty shares. That's absolutely normal, i.e. you will see this trace log with every HW that produces Diff1 shares. cgminer then drops all those below pool's difficulty.

So perhaps I have a nasty bug somewhere…

I will work on getting the voltage up to 0.85V.

Hm, this to me looks like a power issue - at least the effects you observe are similar to what we had here until we got the DCDC stabilized.

First of all, try to not go below 200 MHz sysclock, since I am not sure if the PLL settings are correct for low values or how low it can really get. Operating the chip at 200MHz even without cooling is no problem.

Then ensure the supply voltage is above 0.85V and ripple is within valid tolerance. Same goes for reference 1V8, reset and SPI signals. If you got access to the register, I guess you did that correctly. You can try to stress-test the inter-chip SPI by continuously reading the register of each chip over a longer period to ensure there are no issues.

Usually, the serious troubles begin when you supply the chips with work and they start to hash. The power draw immediately spikes for order of magnitudes and if DCDC is not capable to handle that, the voltage ripple eventually will exceed the tolerance. The chip then usually resets itself, and with that you usually lose access to it, since the chip becomes unaware that it is part of a chain. To regain access to it, you need to HW reset the whole chain and re-enumerate the chips again.

A strong indication that the chip was reset after it started hashing is the inability to read out its register, i.e. you e.g. write 0x0a02 to get register of chip 2, and you read back 0x0a02 instead of 0x1a02, meaning there is no chip 2 in the chain any more.

We detected problems in the DCDC by scoping the levels long term and triggering for levels outside the tolerance range.


As for your other issue with the endianess of the job command: the provided driver uses 8bit transfers and the create_job() function prepares the data for byte-wise operation. If you are not using 16bit and did not modify the source code, please post a trace of the related SPI transfer and I will double check with my logs.

OK, so got boards back this week and initial checks all look good! Have reliable SPI comms with all four chips and power looks to be nice and stable (for at least low frequency operation, need to add cooling before pushing them).

Zefir, your bring up instructions were very helpful - thank you! I was having trouble getting the chip to accept a job and then I finally realized I wasn't reading your instructions properly (had skipped a section). Fixed that and the chips are hashing

But, I'm not getting the same result as you test vector at https://bitcointalk.org/index.php?topic=294235.msg4454746#msg4454746

The registers all look to be good. I can submit the first and second job. The appropriate job active bits are set and the correct job id is set. But, I only get one nonce: 47 b8 a6 62

I get this same single nonce on both jobs and the two chips I've tried. I've looked over the test vector and compared it to my code as well as capturing the SPI bus on a SPI analyzer and it all looks correct…

Might anyone have some suggestions on what I'm missing?

Thanks!

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.

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.

There are no related restrictions documented or known and I am not aware that anyone from the working designs is keeping some defined bring-up order. The only requirement documented is the reset sequence (1s low, then 1s high before first command is sent).