Klondike - 16 chip ASIC Open Source Board - Preliminary

[BkkCoins]

My 3 module Avalons vary between 1.1% and 2.2% HW according to formula of CK: 100 * HW / (diff1shares + HW)

I'm not sure what the formula is. I was just going by the value reported at the top of screen as HW: and comparing it to A: value also at top of screen. Not very sophisticated.

Regarding interrupts, GIE isn't disabled when handling an interrupt, so interrupts can be interrupted. But if I do set GIE=0 then that causes enough disruption to the USB stack in terms of timing delays while waiting for the servicing that is chokes and disconnects. I'm not worried now as I have solved that sufficiently that it no longer disconnects and the result capture hasn't so far had overruns related to not being service quickly enough.

[BenTuras]

Regarding interrupts, GIE isn't disabled when handling an interrupt, so interrupts can be interrupted. But if I do set GIE=0 then that causes enough disruption to the USB stack in terms of timing delays while waiting for the servicing that is chokes and disconnects. I'm not worried now as I have solved that sufficiently that it no longer disconnects and the result capture hasn't so far had overruns related to not being service quickly enough.

Great!

[dimka890]

the temptation to jump in a press the boards is high....
Im in a similar position, but have said I wont press them till they are stable, evan if this mean I miss batch 1

+1 that is the best move for everyone involved. Measure twice cut once.

In Ukraine and Russia says "measure seven times, cut onec", but we have Russian "aвocь" 
I think this PCB's will be work with some fixes.

[lexis200]

I guess your problem is blocking of interrupts while handling an interrupt.
Are you taking too much time to handle an interrupt ?
Can you create a low-level assembly interrupt routine that only gets one byte of data, stores it in a circular buffer and returns again ?
This low level routine can then handle both usb and result bytes input.
Higher level routines can then poll for data in the circular buffer.

Originally I had disabled the USB interrupts during result capture (32 bits, 4 bytes, 8uS/byte) as I wanted to ensure that nothing disturbed that. That was unacceptable to the USB stack as presumably it has to react to bus hardware conditions. After I removed that code the disconnects stopped but I feared the results would overrun if the USB stack took too much time. That doesn't appear to be an issue. I had the UART interrupt handling one byte but now have modified it to handle both bytes the PIC could have in it's FIFO before letting go. So as long as the USB doesn't take >16uS right in the middle of a result nonce it won't overrun, and if it does then it gets detected and counted. So far I've not seen any counted overruns so it seems to not be the reason for HW errors, which do occur still sometimes.

Looking at a screen shot on the forums for a USB Erupter running under cgminer it indicated around 10% HW errors, so I wonder if higher HW errors is normal compared to GPU mining where I can go for weeks with no HW errors. If Avalons typically run with HW errors then I'm maybe wasting my time trying to get it down to GPU levels? Any input from Avalon owners about typical HW error counts?

Not sure if this info is what you were looking for, but Burnin seems to have got his board to run with zero hardware errors... https://bitcointalk.org/index.php?topic=179769.msg2637343#msg2637343. No idea how long that board was running for though.

I don't understand much of what you're talking about but it's fun following this thread anyway 

[BkkCoins]

Regarding interrupts, GIE isn't disabled when handling an interrupt, so interrupts can be interrupted. But if I do set GIE=0 then that causes enough disruption to the USB stack in terms of timing delays while waiting for the servicing that is chokes and disconnects. I'm not worried now as I have solved that sufficiently that it no longer disconnects and the result capture hasn't so far had overruns related to not being service quickly enough.

Great!

Just saw a result overrun... sheesh.

Not sure if this info is what you were looking for, but Burnin seems to have got his board to run with zero hardware errors... https://bitcointalk.org/index.php?topic=179769.msg2637343#msg2637343. No idea how long that board was running for though.

I don't understand much of what you're talking about but it's fun following this thread anyway 

I don't see mention of what chip he changed or what problem it solved. But it makes me feel better that I'm not the only one having to struggle with problems.

In Ukraine and Russia says "measure seven times, cut onec", but we have Russian "aвocь"  
I think this PCB's will be work with some fixes.

1. See fix1.pdf on github in kicad/nano directory. It shows the fix for the power error.
2. Need to scrape GND connection on USB bottom side because it doesn't connect to GND plane where it should due to name mismatch in file.
3. Bend PIC pins to fit narrow pads.
4. Add another NOR gate for result capture, not yet documented as that was just worked out yesterday. This is the hard one as those NOR gates are so tiny. You may be better off replacing with a 74AUP2G02 and adjusting pcb traces to fit 8 pins instead of 6 pins. That also needs a resistor added, 100 ohm and chg capacitor from 30pF to 220pF (or a bit higher perhaps).

[andrewsg]

Not sure if this info is what you were looking for, but Burnin seems to have got his board to run with zero hardware errors... https://bitcointalk.org/index.php?topic=179769.msg2637343#msg2637343. No idea how long that board was running for though.

I don't understand much of what you're talking about but it's fun following this thread anyway 

I don't see mention of what chip he changed or what problem it solved. But it makes me feel better that I'm not the only one having to struggle with problems.

He replaced one Avalon chip for another, on a fully populated board.

[fasmax]

Not sure if this info is what you were looking for, but Burnin seems to have got his board to run with zero hardware errors... https://bitcointalk.org/index.php?topic=179769.msg2637343#msg2637343. No idea how long that board was running for though.

I don't understand much of what you're talking about but it's fun following this thread anyway 

I don't see mention of what chip he changed or what problem it solved. But it makes me feel better that I'm not the only one having to struggle with problems.

He replaced one Avalon chip for another, on a fully populated board.

How do you know what chip he replaced ?

[itod]

He replaced one Avalon chip for another, on a fully populated board.

How do you know what chip he replaced ?

Burnin reported it in earlier post, one Avalon chip was causing him problems from the beginning.

[fasmax]

He replaced one Avalon chip for another, on a fully populated board.

How do you know what chip he replaced ?

Burnin reported it in earlier post, one Avalon chip was causing him problems from the beginning.

I have followed the burnin development thread and don't recall him saying it was an Avalon chip.

I saw this post.

https://bitcointalk.org/index.php?topic=179769.msg2623157#msg2623157


Then I saw this.
http://[url]https://bitcointalk.org/index.php?topic=179769.msg2631282#msg2631282
[url]

Did I miss something else?

[ampu]

He replaced one Avalon chip for another, on a fully populated board.

How do you know what chip he replaced ?

Burnin reported it in earlier post, one Avalon chip was causing him problems from the beginning.

I have followed the burnin development thread and don't recall him saying it was an Avalon chip.

I saw this post.

https://bitcointalk.org/index.php?topic=179769.msg2623157#msg2623157


Then I saw this.
http://[url]https://bitcointalk.org/index.php?topic=179769.msg2631282#msg2631282
[url]

Did I miss something else?

This?
https://bitcointalk.org/index.php?topic=179769.msg2637343#msg2637343

[fasmax]

No we were trying to decide what chip was replaced to get rid of the HW errors on nonce read back.

[cp1]

If you want advice on the PIC interrupt or really anything PIC related, I'd recommend asking on piclist.com.  They always sort me out pretty quickly there.

[itod]

I have followed the burnin development thread and don't recall him saying it was an Avalon chip.

...

Did I miss something else?

Probably this:
https://bitcointalk.org/index.php?topic=179769.msg2631282#msg2631282

He explicitly said he fried the ASIC resulting in 1/2 board inactive (in Burnin design ASICs are orginized in 2 chains of 10 chips).

[cardcomm]

No we were trying to decide what chip was replaced to get rid of the HW errors on nonce read back.

Did you see what specific chip he replaced to fix the problem? I've followed that thread, but I didn't see it stated what chip it was faulty.

It sounds to me like the bad ASIC was a separate issue.

[Bluestreak66]

I have followed the burnin development thread and don't recall him saying it was an Avalon chip.

...

Did I miss something else?

Probably this:
https://bitcointalk.org/index.php?topic=179769.msg2631282#msg2631282

He explicitly said he fried the ASIC resulting in 1/2 board inactive (in Burnin design ASICs are orginized in 2 chains of 10 chips).

I've been following that thread and didn't see him explicitly say it was a asic. What I've deduce is that is was something between the asic chain and the pic32 or the pic itself. Does anybody know if there are any closeups of the board showing component numbers? Or better yet any schematic or references to how he uses the pic to comunicate with the acics? I would like to see the scematic and compare it to the klondike but it doesn't seem he is going to release it until boards are shipped

[fasmax]

I have followed the burnin development thread and don't recall him saying it was an Avalon chip.

...

Did I miss something else?

Probably this:
https://bitcointalk.org/index.php?topic=179769.msg2631282#msg2631282

He explicitly said he fried the ASIC resulting in 1/2 board inactive (in Burnin design ASICs are orginized in 2 chains of 10 chips).

I've been following that thread and didn't see him explicitly say it was a asic. What I've deduce is that is was something between the asic chain and the pic32 or the pic itself. Does anybody know if there are any closeups of the board showing component numbers? Or better yet any schematic or references to how he uses the pic to comunicate with the acics? I would like to see the scematic and compare it to the klondike but it doesn't seem he is going to release it until boards are shipped

I suspect he replace the device receiving the report signals from the ASIC's with a Schmitt trigger device that feeds the PIC chip. But that is just a guess.

[cp1]

I suspect he replace the device receiving the report signals from the ASIC's with a Schmitt trigger device that feeds the PIC chip. But that is just a guess.

Bkk was worried about the shape of his signals.  I think the PIC only has its Schmitt triggers enabled when the hardware functions are used.  If you just use RC0 etc they're just TTL inputs.

[BkkCoins]

I suspect he replace the device receiving the report signals from the ASIC's with a Schmitt trigger device that feeds the PIC chip. But that is just a guess.

Bkk was worried about the shape of his signals.  I think the PIC only has its Schmitt triggers enabled when the hardware functions are used.  If you just use RC0 etc they're just TTL inputs.

I use the USART inputs but my reading was that Schmitts were present on normal input but perhaps not on USART - though I find it quite ambiguous. Currently I have Schmitt triggers on the clock signal but the data signal is still direct. Scoping shows the data rises quite quickly and early enough to be captured by the clock but to be extra sure I may test with added Schmitt buffers to both to see if any improvement results.

[cp1]

I use the USART inputs but my reading was that Schmitts were present on normal input but perhaps not on USART - though I find it quite ambiguous. Currently I have Schmitt triggers on the clock signal but the data signal is still direct. Scoping shows the data rises quite quickly and early enough to be captured by the clock but to be extra sure I may test with added Schmitt buffers to both to see if any improvement results.

Oh I thought you were using I2C instead of serial to communicate with the chips.  According to the datasheet the USART inputs are Schmitt Triggers but I think if that's only if you use them in hardware mode.

[Bicknellski]

"handling an interrupt, so interrupts can be interrupted."  BKK "Don Rumsfeld" Coins  



“There are interrupted interrupts; there are things we interrupt that we interrupt.
There are interrupts uninterrupted; that is to say, there are things that we now interrupt we don't interrupt.
But there are also uninterrupted uninterrupts – there are things we do not interrupt we don't interrupt.”

—Klondike Secretary of Design, BKK "Donald Rumsfeld" Coins