Quote from: hashblue on May 11, 2013, 06:56:58 AM

Quote

The result data gets back from the ASIC to the PIC via a secondary route as serial data. It is only a 4 byte nonce (I believe), and so is a very small amount to return back to the USB host.

It looks like the hash chip sends back the report data asynchronously. Is a PIC controller capable of concurrently clocking in results from multiple chips?

It's a wired OR bus, all outputs join together into one PIC input. The PIC does have a UART and amazingly I just hooked REPORT_P to that pin.

What's even better is it has IOC (interrupt on change) so I don't have to poll it.

Quote from: quiksilver911 on May 11, 2013, 06:59:44 AM

Quote from: BkkCoins on May 10, 2013, 10:08:21 PM

The Klondike has 16 ASICs but I have split them into 2 banks of 8 each. This allows pushing the data in twice as fast, and also means if one ASIC is damaged then only 8 cannot function, instead of 16.

I hope there is a mistake in what you have said, because it scares me a lot. We don't know what the yields are on Avalon chips, and I would seriously prefer a solution where only the damaged ASIC is the one that does not function. Losing a bank of 8 is significant, imho.

Also, what happens if a bank is not full, e.g. 6 chips instead of 8? I imagine there are plenty of people who don't who's total number of chips don't divide nicely by 8, and if we are shipped untested chips then yields could make that worse.

Just like the Avalon, the Klondike will work with how the ASIC was designed to be used. Instead of 10 chips/bank I'll have 8. For partial fills I haven't decided yet what I'll do - either I'll have to divide the range by N chips, or I'll just ignore that and divide by the next higher binary multiple, but only shift N sets of data. While it won't check every single hash in the range the probability of finding one doesn't change. You just have a lower hash rate due to less chips.