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.

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.

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.