Topic: Klondike - 16 chip ASIC Open Source Board - Preliminary - page 132. (Read 435369 times)

Is the 300 MHz a border somehow? I read in the avalon miner threads that overclocking to that value is possible only. I thought its because of the avalon miner design. But is it a chip-restriction?

That's about right. I would use 2W as safer value.

Avalon reported power as 6.6W/GH @ 282MH/s that's 1.86 each but many people will want to overclock to 300 and it should be considered baseline for testing. I don't know if it's actually linear but,

300/282*1.86 = 1.98W

Thank you for all your comments here. Very helpful. I would appreciate a PM with your past comments as I have not been following your discussions with other ASIC devs. If I can at least scan it may be able to avoid something that gives you headaches later.

Yes. It can receive cmds at any time. The only time it may not respond immediately is while pushing the work data sequence to the ASIC since this must be done with software. The USB serial engine should be able to accept cmds from the host even during this period as it has dual-port buffer memory, but the PIC may not reply until it's pushed the work out, since I'll disable interrupts during the push sequence.

I know, it's a zombie. I plan to push work and then set a hardware timer interrupt (based on clk rate and chip count table) that will allow me to know when I can push the next work with minimal lag. I'm unsure yet how much of a queue I can have as some RAM will be used for other purposes but there is 1K and I expect some chunk of that will be available. If midstate+data is 48 bytes then I'm guessing now at least 4, maybe 8 work items possibly.

I thought of this but hadn't coded it yet. Probably right after the address digits a unique ID byte that is just some work array index on the miner. Any nonce returned would also have that byte. My plan was for any nonce result to be immediately pushed to the host. The master PIC would use polling to detect slave nonce results but it should catch them quickly as it won't have much to do once work is pushed to the ASIC. Even PWM fan control and fan speed measurement is mostly delegated to hardware functions.

How about an Abort cmd, 'A' which replies with amount of partial hashes done (which would be based off timer tick counts since the ASIC can't tell me anything). So if new work is prefixed with A, eg. AW002 then the queue is cleared, partial count returned, and new work immediately pushed. If useful multiple work tasks could be sent at once to fill the queue. I could just check the length and process them in sequence. I'll leave that for later refinement.

Quote from: kano on May 25, 2013, 04:13:26 AM

It's also nice to be able to stop all work if the e.g. a temperature report says something cgminer or the user has decided is too high
Handling overheat should have 2 levels:
1) The device has a critical level that aborts work
2) The miner has an optional lower level it can use commands to do things like increase the fan or reduce the clock or even stop mining to wait for it to cool down

I was planning that the cfg C cmd would allow setting target temp and the PIC will use tach reading and pwm fan control to keep the device below the target. There are two temperature sensors - one internal to the PIC and one a thermistor near an ASIC, that can be read to monitor this and a critical temp reading would directly disable the hash clock, and set status values the host can query. This can be refined easily later.

Quote from: kano on May 25, 2013, 04:13:26 AM

Make sure there is a clear way to identify the version of the protocol used
And PLEASE put a name in iManufacturer and iProduct and a unique serial number for each device in iSerial
I will be using iSerial (or some other unique id if it exists) to handle reanimating ZOMBIE devices soon in the code
(e.g. when a hotplug is detected for a device that was lost and it matches the exact same device by e.g. iSerial, it will make sense to reanimate the ZOMBIE device rather than creating a new one like it does at the moment)

Will look into setting those values in the Microchip USB stack.
Each board will have a unique serial# embedded in the firmware which is also used internally for slave detect arbitration and ID assignment when detecting how many boards are chained off the master. Good idea on protocol version and I'll add that to the status query reply. The status reply will also contain a slave board count, which would be the max ID for slaves. But if useful it could also reply with an array of serial#s and chip counts per board. I wouldn't store them in the master PIC as it's not very useful and uses RAM, but if useful for the host miner (user curiosity/diagnostics) I could easily query each ID on I2C bus and then relay back all the serial#s and chip counts in sequence.

Quote from: kano on May 25, 2013, 04:13:26 AM

Adapt the driver-bflsc.c

Will look at that and use it as guide.
This is exactly what I needed to know to get started in the right direction. Thank you.

Hi all
Heat power of chips is 1'7-1'8W each one?

Next week I will do some test with 2W simulation with different profiles.

The scheme above sounds good since it is an actual (simple) protocol, not simply send data and receive answers.
I'd risk making the comment (but it is true) that of all the working devices so far, the BFL ASIC has the best protocol and MCU design.
BFL polling for an answer sux however, but since it has a 20 length output queue, there is no need to poll much more often than a reply is expected
(it also has a 20 length input queue)

Anyway,
The ability to send status commands and get replies while mining is important. I can't tell from your comments if it can or not.
Having to halt/finish mining to send a status request or get a status reply e.g. is very inadvisable.

The Avalon also does something right out of left field ...
It mines the work it is given continuously until more work is given - so if it reaches 0xffffffff it will start from 0x00000000 again and repeat the work.
Hopefully that ... weird ... idea hasn't been incorporated.

Having an input queue (which is what yours sounds like) is of course the best thing to avoid lost processing power (latency) between work items.
Hopefully the design is to allow adding items to the queue when it isn't full - so if it is a 1 length pre-process queue, we'd add 1 item each time a work item completes and thus there would always be work waiting for when a work item completes.
A bigger queue is way better and since on windows it's REALLY unreliable timing stuff, the bigger the queue the better.

Adding an ID (a few bytes) would be pretty much necessary if there is an input queue - where the miner could pass in an ID of it's choice and that would be returned with the nonces.
i.e. the miner would simply send a unique ID it could use on reply to identify the work source - an input queue with an ID solves any work source confusion

For LP we need to be able to abort all work and start new work (and even better if it can be done in a single command), but knowing how much work was already done at this point is necessary since at this point any incomplete work that has not provided any answers is indeed valid work done that counts towards the device performance.
It's also nice to be able to stop all work if the e.g. a temperature report says something cgminer or the user has decided is too high
Handling overheat should have 2 levels:
1) The device has a critical level that aborts work
2) The miner has an optional lower level it can use commands to do things like increase the fan or reduce the clock or even stop mining to wait for it to cool down

Make sure there is a clear way to identify the version of the protocol used
And PLEASE put a name in iManufacturer and iProduct and a unique serial number for each device in iSerial
I will be using iSerial (or some other unique id if it exists) to handle reanimating ZOMBIE devices soon in the code
(e.g. when a hotplug is detected for a device that was lost and it matches the exact same device by e.g. iSerial, it will make sense to reanimate the ZOMBIE device rather than creating a new one like it does at the moment)

Don't adapt the Avalon driver.
I don't want more serial-USB code in cgminer.
Adapt the driver-bflsc.c
No doubt once it's done I'll just rewrite it, but use that as a basis anyway for how to use usbutils.c
(there are 3 in there already modminer, bitforce and bflsc, and I'm doing icarus right now to complete all the non avalon USB drivers)
If you do it correctly, hotplug is enabled, device identification is simple (and easy to avoid overlap for devices with the same USB chip by checking iManufacturer and iProduct), and device failure is handled by usbutils.c automatically (among other things like very helpful development statistics automatically stored for devices)
Of course usbutils.c will be enhanced over time as required and the aim is for those enhancement to cover all devices automatically.

I can ramble more, but that's just repeating stuff I've spoken to the ASIC vendors about before that I've written down and you've probably already dealt with anyway.
If you want I can PM a bunch of old comments on the subject.

I can produce 1 of my design and send it to you for testin.
I'll put a few in production in monday .
I will be able to dispatch Wednesday
PM me delivery address.

Ya I have both fabricators on speed dial from China.

Thing is to be honest whichever one looks best I am going to basically get a drawing made to the specs and have it made in bulk here in Indonesia as we have quite a few Aluminum foundry / extruder companies right in Jakarta so I am pretty sure it is cheaper just ordering them in bulk here. Avoid the shipping weight and save on bulk. Be creative and I trust you will find an elegant solution, those heat sinks do not have to be shipped back to me obviously, so even if you have to cut them and Frakenstein something for testing please go for it. Also love the idea of longer heat sinks and use them as support when racking / klegoing.

I think you can take a rest in that dept. I hope you kept track of which are which and from where.
I better label them when they come in.

The USB connector has no metal thru-hole pins, just a plastic stress relief. I just double-checked the board to make sure those two are non-plated, and they're only 1.1mm so won't extend past the board bottom.

I thought someone mentioned the Avalon had resin filled vias - I'll have to test that as preventing wicking thru the holes would be good. How well that fits into an assembly I don't know. I guess they would handle it like another mask layer.

I'll order a couple myself on ebay, just to see how they work. I'd like to know as well how effective it is when 2mm short, and they're very cheap. I'd like to test cutting it down the middle and placing one on each side, with a gap for the connector and this is a cheap one to try that on - so will get 2.

Not 80mm? Think that is too small. Can you find something that is at least 90 x 80 and send it to BKKCoins? If he is ok with that?

My wife is going to shoot me if I keep shipping stuff to Thailand on the credit card. 

I though it would be interesting to test a range of heights... that way if they all work people can pick anything they like really in that range.

I think really after seeing that fubar gloop job on the Avalon modules we are going to have little or no problems with heat. The concern will be tenting the vias I think making sure the solder doesn't wick. I think overclocking boards with a big assed fan slapped on top pointing down on the heat sink is going to be a winner and ultimately the cheapest solution.

Could you get one of these as well for testing?

http://www.befr.ebay.be/itm/10CM-100x76x21mm-Aluminum-Heat-Sink-for-4-6pcs-3W-LED-Power-Transistor-Cooling-/390557019421?pt=LH_DefaultDomain_0&hash=item5aef032d1d#shId

100x76 / 21mm height @ 3 USD

I'd be interested to know whether those 2 mm missing on the sides are really important...

Awesome. I really like that you've got several heights coming.

I think you may be right. Back to the drawing board.

There is a few differences between how the Avalon and the Klondike handle data, even though the same data needs to end up going into each ASIC.

In the Avalon driver it divides the nonce range and passes it with the work data. In Klondike this is done in the PIC local to the ASIC chain, to reduce data xfer.

In the Avalon the pre-calc is done in the FPGA but in Klondike this will be done either in the driver or the PIC. I'd prefer to fit it in the PIC so that less data is xfer'd (24 bytes/work task).

If an Avalon work task is 56 bytes then that must be without the nonce start values as that alone is 40 bytes (10 chips x 4 bytes).

Things like clock config, fan speed, temp target, will be handled in the PIC so they don't need to keep being re-sent by the host driver but there are a couple cmds to query/set them.

The Avalon sends back a result nonce together with the original work data but in Klondike I don't plan to store the work data after pushing it to the ASIC, as this space can be used for queueing work. So the host driver would need a table of work sent for each board.

For Klondike a work task would look like this: (where 002 is an example board id)

W002
where W is work cmd and 002 is board ordinal id, then binary data follows. Each PIC can queue a 1-2 work tasks so that when a nonce range is finished it can immediately push new work. Each PIC can use a local clock hash rate so that all boards aren't limited by the slowest (don't know if there is much variance in chips). Each PIC uses a hardware timer tick count to know when a nonce range should be completed.

And result nonce would come back to the host driver as,
R002
so the driver can know which work unit it matches for checking and relaying.

The "master" PIC with the USB connection would be ordinal id 000, and any data with other ID would be simply copied out to the I2C bus, where the correct chain board would recognize it's ID and use it. Hence, the number of boards chained is limited by the utilization of the I2C bus.

My intention is to reduce host data xfer so that as many boards can be chained as feasible on a 100 KHz I2C bus.

Status items like fan speed, temperature, board count can be queried as needed by the host using a status cmd S, or set using a config cmd C. Both with board id, eg. S003. There is also an enable cmd E which can enable/disable a board to save power when no work is available - this just controls the clock to the ASICs.

This is the scheme I'm coding right now. My intention is to keep it simple, both to understand and for the PIC to work with, but also flexible enough that a long rigid data structure like the Avalon uses isn't required. I am interested in feedback before I get too far along, especially from ckolivas or kano who have had to code several drivers and know where difficulties may lie. My plan is to write the driver by adapting from the Avalon one where needed, but perhaps there is a better/simpler driver model for this cmd based architecture.

Each avalon task is 56 bytes. One is sent to reset the device only on startup, and then one for each (10) chips to start working or go idle, so a fully configured 3 bank avalon is sent 24 separate tasks each cycle. Therefore on each cycle of work, 24*56bytes is sent, and a share result is 64 bytes and on average one share is found per work item, so 24*64 bytes is returned. The timeframe depends on the Mhz it's running at, with 300 being the max. At 300Mhz it completes a full work cycle of one nonce range / 10 / 300Mhz so 2^32 / 10 / 300,000,000 = 1.43  seconds.
The current MCU has no synchronisation/EOL to tell you where results start and finish and a clunky mechanism to start receiving more work and can only take a full set of work at a time for all chips instead of separately.