Quote from: babcoccl on July 04, 2013, 09:51:20 PM

PLL might be a good place to start looking. Just make sure your PLL maintains a good lock.

I wouldn't be at all surprised if now and then the PLL unlocks and the clock shifting causes error results. I would also guess that is more likely to occur closer to the clock limit values, eg. ~512 where I am now, and by moving up to 600 it has more stability. (@half clock is 128 vs 150).

Next board revision will have that ferrite bead on the PLL power inputs, and can only help. I don't know if one of the debug outputs maybe indicates PLL lock but I otherwise have no way to know. It would be nice to know what the 2 debug outputs are but I haven't seen any docs about them.

Quote from: Taugeran on July 05, 2013, 12:57:09 AM

How difficult/possible would it be to rework the FW to do 1 job per chip?

That would require a set of data inputs and outputs for each chip, which is a lot, and isn't possible with the current design. ie. 4 lines per chip and a lot more firmware overhead to handle it. The chips are designed to chain, splitting jobs, and there isn't any efficiency gain by running a job per chip.

Quote from: fasmax on July 05, 2013, 02:00:02 AM

If you have 5 chips you could put 4 of them on the K16 board and it should work quit well.
For example using the current design you would place the ASIC's at U6,U8,U9,U11.
Maybe use the extra chip in a K1.

That's right but also if you add the 5th chip it will break nonce ranges as if 6 are present which will still work but will leave 1/6th of the ranges unchecked. This doesn't cause problems and since any range is good as another, as long as each chip is checking unique ranges, it's still efficient. A job will finish slightly more often (4 split vs 6 split), so that's the only overhead timing loss.

I haven't verified the code yet but during device init it sends known good data to each chip with a specific nonce count such that a known delay will produce a result. It then counts the results that come back sequentially, and uses this to determine chip count. Due to the chaining connections (hardware) the chips must be installed in a given order, and optimally it's best to balance between banks. I'll be testing this chip count code when I get more chips on board.