Quote from: totalslacker on February 18, 2014, 10:59:58 PM

Quote from: zulunation on February 18, 2014, 10:56:33 PM

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?

That's pretty likely too low. I had similar issues when I was running the chip that low. 0.8V seems to be pretty reliable for at least basic comms for most chips. A couple wouldn't hash at that voltage but once I brought it up to about 0.84V they were fine.

Of course, now those chips run hotter than the others

This. The sample chips need 850mV min, not sure if the chips from the production batch are better suitable for down-volting - but obviously everybody is looking to up-volt them anyway

Quote from: totalslacker on February 18, 2014, 11:15:30 PM

Before going faster I need to get some cooling in there though. I noticed on your bring up page you mention keeping the temps below 50C. Is this a hard limit?

I was just doing a longer test where I kept all four chips completely busy with your test vector and verified that the correct nonces came out. Running at 240Mhz a couple of the chips did get a little hot. The two running at 0.8V stayed well below 50C but the two at 0.84V got up to about 61C.

No errors during the 12 minutes I ran the test. Theoretical hash rate is 32 * 240Mhz = 7.68GH/s and actual turned out to be 7.62GH/s.

But, how bad is it to run the chips that hot? Is that a might get bad results now and then or a might damage chips?

No, it is not a hard limit but given to us by chip manufacturer during bring-up to exclude temperature as root-cause for troubles. And the 50°C were for heat-sink, so there should be some margin left.

If you reach the hot area, you'll notice invalid results first. What I noticed is a fail-safe behaviour (not sure if intended): if chip gets way too hot, it eventually will reset itself and stop working. With that, you corrupt the chain (that chip won't respond until after next HW-reset and re-enumeration), but it survives potential burnouts.

Wish I had such a burnout protection built-in

Quote from: zulunation on February 18, 2014, 11:21:24 PM

I have just tested with 0.84V. Still no responce.
zefir mentioned earlier that at the startup chip is configured at 12MHz reference clock. And the SPI speed must not be > system clock. I wounder what is the PLL multiplier at the startup to calculate the system clock.
Or maybe it doesn't matter what SPI speed to use for initialization? I guess what i wrote above is applied to SPI speed between the chips not between uC and 1st chip.
Currently when i run cgminer i see 500khz SPI speed. Is that sufficient?

The reset value for PLL multiplier is 800/12, i.e. with 12MHz ref clock chip is clocked at nominal 800MHz. As long as you do not hash, you do not need to modify the PLL register at all, even without proper cooling. The default SPI divider is 64, so you should measure 12.5MHz inter-SPI clock. Your host clock needs to be below that, which with 500kHz it is.

If you still don't get any feedback from the chip, please double check that the RSTn is kept at 1V8 for at least 1s before your first command to the chip.

Oh, and maybe to state the obvious: if you have a chip chain and you write a broadcast command, you need to send zeros to push the command to the last chip and back. See how the polling in the reference driver ensures to write enough data to get the commands through the chain.