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

OK that's sounds good

Your % aren't quite correct (when you divide the work up, the range for each is of course the division, not 2^32), but the numbers are small enough that indeed it appears it's better to lose a nonce once in a while than slow things down by more than that resolving the problem.

Average nonce per 2^32 is of course 1.
However, 4 isn't all that rare (hmm I think I'll add a stats counter for the BFLSC to see how often >1 does happen - that one's the easiest to do it)

Ok. So assuming we refill the UART close to optimally then we could probably get the dead zone to (32+8+16)/12 = 5, say 6uS maybe. Which should be a very, very tiny loss in nonce data, maybe around 0.0000015/5 = 0.0000003%. And maybe double if your average work has 2 nonces but it seems like most have 1 or 2, and a few have 3.

So it's probably not worth delaying nonces to avoid the dead zone. You could lose more due to block change if delayed. The main thing is it completely frees up the IRQ timing constraints.

usart timing is at page 375 of the pic datasheet - not what you searched in detail -but still interesting.

page 270 and page 271:
Maximum set-able baud-rate:
Desired Baud Rate = FOSC / (4 * (SPBRGH:SPBRGL +1))

48MHZ / 4 = 12MHz - thats "fast"

Just roughly figured this...

Assuming we accept a dead zone then reading by the PIC can be at it's full speed using the UART input in master mode. I didn't check but maybe 1 MHz is feasible, so 32 uS roughly for dead zone, plus re-arm time, say 8uS, so say 40uS. Since a nonce takes 9.1 uS (@450 MHz clk / 128 output speed), that means potentially the 4 nonces after a result nonce are dead. But nonces could occur on any of 16 chips so that's x16 = 64 nonces could be found during a dead zone making the probability 64/2^32 of that happening, ie. 0.0000015%. Something most users can live with in terms of income loss.

Not sure if that's right but my first look at it.

Also, I'm not sure what the max data rate on the UART is. It's not in the timing specs for the PIC. If it can handle 4 MHz then the dead zone is more like 12uS. The firmware gains mostly because it has control of handling data rather than being at the mercy of random ASIC output. Multiple nonces could be received by the SRAM when armed but when the PIC gets around to handling them the dead zone would occur.

Sigh, this is (sort of) what the Icarus bitstream does also - if 2 nonces arrive at the same time, you lose one.
The only catch of course is that "at the same time" can be a long time frame with regards to hashing nonces ... which increases how often it happens.
Hopefully here "at the same time" is a VERY small window.

Just realized the CS line probably needs to be used as well, though maybe it can be somehow merged with OE.

I'm not sure a dead zone after each nonce is a problem anyway as the chances of two nonces being sequentially close is quite low. The probability is likely low enough that losing the second nonce would have no noticeable effect on overall performance.

However, if the work units are fast (16 chips is pretty fast, 0.9 secs), then the delay of waiting for new work to grab nonces isn't long. The SRAM can capture all the nonces sequentially for a work unit. Then just before pushing new work we read the SRAM and push new work. That way the deadzone happens during duplicate nonce time which are ignored anyway. So the tick counter would trigger nonce read and then work push. The nonces can be read until a zero word is read, and then rewritten with zeros, and armed for write.

the dead-zone could be avoided if the nonce is read from the sram and then rearm the sram.
only after this send the next hash to the asic.
(and not much "time" is lot as not every hash gives a nonce?)

I will give it a try (already ordered the part)

I have another idea I wanted to test but due to work load  and how long it takes me to get chips here I haven't pursued it. I wanted to use an 8-pin serial SRAM and 4 normal I/O pins on the PIC. In this setup the ASIC output needs to go thru NOR gate and Schmitt input tristate buffer with OE hooked to PIC.

SI - goes to PIC and output of RES_N buffer
SO - goes to PIC
SCK - goes to PIC and output of NOR via buffer
OE (of buffer) - goes to PIC

In operation the PIC the disables the ASIC output and sends data to the SRAM to configure it for writing. Then it enables the ASIC output and waits, monitoring the SI line for change. When data comes from the ASIC it writes into the SRAM (sequential mode, auto increments) which can handle up to 16 MHz. Once 32 bits are written, the PIC takes control and sends signals to Read the data back, and re-init for write mode again.

This method has a brief dead zone after each nonce obviously but allows high speed capture with no timing issues, and uses only a small 8pin part with no-programming necessary. Regarding the dead zone, we have that with current method too as while the first nonce is being sent to host the PIC won't be able to respond quickly to result interrupts. The dead zone could be removed by using 2 SRAM chips but it starts getting complicated.

Here's a low cost serial SRAM - 0.57 in qty 100. That was the cheapest I found.
http://mouser.com/ProductDetail/Microchip-Technology/23K640-I-SN/?qs=sGAEpiMZZMs6Aik9Fp479oRJ8qzeMKM7vL%2fWRv1ed7o%3d

Currently, I have to re-write code so that as much as possible is handled in the main polling loop, outside ISR time. This means eg. I2C code will have to be run in the main loop but state changes are triggered by interrupt. Any interrupt needs to be only a couple uS. USB will need to use the polling method.

There's probably lots of ways to hook them up but the way I planned on when designing it was that boards would be side by side, either with standoffs or mounted on a larger heatsink. The klego 2x2 headers then line up next to each other and a 10 pin female header block with pins wired correctly can slip over them. The spacing from board edge is 0.127 so that both boards touching would be a 1 pin gap.

Also, I was going to make a touch screen 3.2" 320x240 display by interfacing it to I2C and having it sit on the bus as monitor/control device. But it could just as easily be interfaced to the RasPi and probably is more generically useful. The one I have here is below but I haven't had time to actually hook it up and write software to talk to it. It only cost $12 and just needs an 8 bit interface. Has touch controller and SD card on board. So much to do and no time. I could see this on the front of a rack or enclosure for a K16 array.

http://www.ebay.com/itm/3-2-inch-TFT-LCD-module-Display-touch-panel-SD-card-240x320-than-128x64-lcd-/200908823757?pt=LH_DefaultDomain_0&hash=item2ec7195ccd

Hold fire boys, check this thread before buying........

https://bitcointalksearch.org/topic/m.2671338

Kano`s on the job   

regarding cpld:
There are no small pincount but many macrocell cplds available.
The smallest I have found is from latice with QFN 32, that has enough space to fit a i2c slave and the receive logic.

But if it's possible to go without cpld it would be the better way - but will need some rework of the isr handling.

..just came home from the weekend, reading this!
You are awesome! :-)

Ente

Electrically there must be some sort of header and cable.  Physically there's a standoff.

How would these K16's connect together exactly? I see the I2C pins, i've seen diagrams, but are they locked together via plastic? have to be connected via wires?

I like your design. It's simple and works good. 60MHZ span is good enough for most situations where the best hashing rate is selected for long run. Geeks can change the capacitor any way.

You use two NOR gates and a RC circuit to delay the clock and sharp the edge. I didn't verify it but I think you can move the RC circuit to PIN-1 of the first NOR gate (delay the signal at PIN-1) and get rid of the second NOR gate. It may work and be simpler.

Great job! I'm following this thread semi-closely and things seem to be going well. The small hashrate increase is a nice bonus.

Bkk, I want to thank you again for all the time and energy you are investing in this. One question... do you still plan on offering the boards and parts for sale once a stable design is completed?

I was inspired by that project as well, however I will be using Graphic ST7565 Negative LCD (128x64) http://www.adafruit.com/products/438 instead. I want to be able to display moving graphs among other things

I wonder if it's possible to do a minimal parts setup without the nor gates and just use the capture compare or interrupt on change pins to read out from the ASICs.  Not sure if they're fast enough to grab it bit by bit though.  It would be cool to have something very DIY for people with left over single chips.

I saw that RPI miner host project - looks like a blast. I was just filling my shopping cart on adafruit for that last night. Gotta go back and order it
http://learn.adafruit.com/piminer-raspberry-pi-bitcoin-miner/