Can't this still be done in the driver like with the Avalon miner?

Yes, this has to be done in the driver. One of the beauties of open source is we don't have to solve every problem as if it's new.

So I'll be using what I can from the Avalon driver, and modifying it to use a more cmd/reply protocol over the USB. The main reason to change anything is that it could reduce data transfer demands. Since we have a CPU on each board we don't need to repeat redundant data.

Firmware Overview

The firmware works with simple cmds for which I've already coded a skeleton. It's a compromise between readable text and compactness. I could have gone totally binary but I'd like to be able to see USB/I2C data if I need to spy on it for debugging.

[cmd char][address- 3 digits][binary data]
eg.
W003blablahdataherecannotread...

Current cmds I have laid out:

W - start work (the meaning of life... )
E - enable/disable work (for reducing power draw when no work available)
S - get status (eg. fan speed, temperature, chip count, board count, work state)
T - set temperature limit (a safe default will be coded)
F - firmware upgrade (send new program code, don't worry will need handshake to confirm)
(maybe more as needed)

The address is always 000 for the primary USB board, and >= 001 for subsequent chained boards. For chained boards it simply relays the cmd to the I2c bus.

The primary board auto-detects what chained boards are present using "serial# as address" arbitration and assigns a unique I2C 7 bit address. So the possible range for destinations the host can talk to is 000-112 (some I2C addresses are reserved). This would be the max boards per chain. I didn't go with 10 bit addressing as it would probably be beyond the limits of what even 400kbps could support on I2C, and at first I'll be working with 100kbps until there's time to test faster. And there's no real need either - at the USB level having 100+ boards on each port of a hub is economically cheap, and more flexible.

Each PIC also auto-detects how many chips are on board and adjusts it's work splitting to match. The number of chips is relayed as status info for the host but the host doesn't really need to know - more for user overview, monitoring problems.

Just throwing this out there so everyone knows what I'm doing next: filling in the code needed to support the cmds above.

Yes, remotely possible. Not boards per chain, but chips per board. I split the 16 into 2 banks primarily to reduce work load time but also it helps with this. What happens in the case of collision depends on how smart the ASIC reporting circuit is. It uses a wired-OR output logic, weak pull-up resistors, so that it is possible to detect a collision and back off. I don't know if it does that - probably not. A collision would be very rare and the only loss would be one share (even more rare to have a collision with a winning share).

The wired-OR scheme allows for arbitration of the data (it's benefit over a tri-state bus), and the ASIC could detect a collision, but it may not bother due to how rare it would be. If it detects and backs off then no data corruption occurs, but if it doesn't back off then corruption can occur.

I don't think bus contention on the report pins is an issue since each chip should be working on separate nonce ranges.

I'm surprised the avalon asic provides no indication that it has finished searching the problem space.  Without this the s/w must estimate the work time and guess when to send new work.

In my miners  I use a single entry fifo in h/w to store the next piece of work, once the range has been exhausted the hw pops the next piece of work and starts working, the sw then reloads the fifo.  The fifo is flushed by the sw using long polling when a new block is found to reduce stale results.

Perhaps later on we can do the speed estimating in the PIC to reduce the load on the usb connection.

It's still not clear from docs how quickly the results are shifted out. It's no doubt derived form the main clock but whether it's tightly set at 4Mbps or not I don't know. That's the suggested timing from the protocol diagram but no comment on how it's derived from the main clock. If we fed 16MHz as main clock and used the PLL to scale up appropriately, which seems to be within specs, would the shift rate halve? Until some tests are done, or more docs come out we can't be sure.

No, you only shift in one copy of the clock data and hash data and then one word per chip for the starting nonce for that chip. This would be max(2^32)/numchips.

That makes sense.
So last chip in the chain starts to work after it receives its nonce.
How does the ASIC tell the difference between receiving its nonce and new work coming down.

Thanks for your answers, you've really thought this through.  I'm trying to keep to the essentials here and not contribute to the noise.

It would be great to put a logic analyser on an Avalon to mitgate this risk but I guess the chances are slim....

If I'm reading that correctly...35mm width x 35mm length x 165mm height ~(1.4 x 1.4 x 6.5 inches)? Made of aluminum? Where do I sign up for 200 of them?!? (I have 800 chips on order.)

Or is that 35x165mm to cover one side of the board (8 ASICs)

Side note...would that be one full extruded aluminum piece and NOT two-part (base with fins mechanically attached)?

 

Please read through the thread.

4 layer board with VIAS in the pcb to transfer heat to the heat sink.
Heat sinks to be determined he has a few sample heat sinks coming his way and will test them and report back.

Check the design out at the git hub for details. https://github.com/bkkcoins/klondike