Klondike - 16 chip ASIC Open Source Board - Preliminary

[Bitcoin_Bing]

The point is you need to leave this thread and beg for a loan elsewhere...this isn't for general discussion of different asicminers but for the development of the Klondike miners.

My apologies. Post deleted. Did not mean to get anybody upset.

[dimka890]

Recived today from China
http://i.piccy.info/i7/953566f729f904799f954698573db4ea/4-63-63/26540632/DSC_0966_800.jpghttp://i.piccy.info/a3/2013-07-02-20-42/i7-4798681/799x535-r/i.gif
BKKoins, can You write some manual how to flash that PIC?
P.S. Ssory for my English, I am from Ukraine 

[cp1]

Just hook your programmer up to the ICSP pins, compile, and flash the hex file.

[Sophokles]

Recived today from China
http://i.piccy.info/i7/953566f729f904799f954698573db4ea/4-63-63/26540632/DSC_0966_800.jpghttp://i.piccy.info/a3/2013-07-02-20-42/i7-4798681/799x535-r/i.gif
BKKoins, can You write some manual how to flash that PIC?
P.S. Ssory for my English, I am from Ukraine 

Nice! Where did you order those? How long did it take? How much did you pay?

[-Redacted-]

?  Where did these come from ?

(Yes.  China.)  I didn't realize there was a Klondike-1 in the works.   And people are having boards delivered already?

[BkkCoins]

BKKoins, can You write some manual how to flash that PIC?
P.S. Ssory for my English, I am from Ukraine 

If you've been following the thread you'll know there are several errors on this board that need to be fixed before you can power it. And you'll have to bend the PIC pins under to fit the pads. I really don't have time now to write up a manual for a test board. You won't get good result capture unless you add another NOR gate off board. All reasons why people should not order boards based on prototype design files, as warned.

[joeventura]

BKKoins, can You write some manual how to flash that PIC?
P.S. Ssory for my English, I am from Ukraine 

If you've been following the thread you'll know there are several errors on this board that need to be fixed before you can power it. And you'll have to bend the PIC pins under to fit the pads. I really don't have time now to write up a manual for a test board. You won't get good result capture unless you add another NOR gate off board. All reasons why people should not order boards based on prototype design files, as warned.

Are you working with Terrahash?? They mentioned recently they are ordering boards.
Hopefully the right ones

[BkkCoins]

BKKoins, can You write some manual how to flash that PIC?
P.S. Ssory for my English, I am from Ukraine 

If you've been following the thread you'll know there are several errors on this board that need to be fixed before you can power it. And you'll have to bend the PIC pins under to fit the pads. I really don't have time now to write up a manual for a test board. You won't get good result capture unless you add another NOR gate off board. All reasons why people should not order boards based on prototype design files, as warned.

Are you working with Terrahash?? They mentioned recently they are ordering boards.
Hopefully the right ones

I haven't heard a peep from them so have no idea what they're up to or if they have made new boards or software.

[gateway]

BKKoins, can You write some manual how to flash that PIC?
P.S. Ssory for my English, I am from Ukraine 

If you've been following the thread you'll know there are several errors on this board that need to be fixed before you can power it. And you'll have to bend the PIC pins under to fit the pads. I really don't have time now to write up a manual for a test board. You won't get good result capture unless you add another NOR gate off board. All reasons why people should not order boards based on prototype design files, as warned.

I have a feeling that lots of people are already pressing boards before you even fully get yours working, fixed, or debugged.. oh well.. they have been warned

[cardcomm]

BKKoins, can You write some manual how to flash that PIC?
P.S. Ssory for my English, I am from Ukraine  

If you've been following the thread you'll know there are several errors on this board that need to be fixed before you can power it. And you'll have to bend the PIC pins under to fit the pads. I really don't have time now to write up a manual for a test board. You won't get good result capture unless you add another NOR gate off board. All reasons why people should not order boards based on prototype design files, as warned.

Are you working with Terrahash?? They mentioned recently they are ordering boards.
Hopefully the right ones

I haven't heard a peep from them so have no idea what they're up to or if they have made new boards or software.

I guess it can be very complex deciding the best vendor or group buy for purchasing chips and board assembly. I sure hope I chose the right one!    haha

But for anyone that's been following this thread, it was clear that Terrahash was jumping the gun taking preorders and (allegedly) ordering boards knowing full well the design was not finished. Hopefully for those that purchased from them, they will ultimately deliver a product.

I'm really excited by this project, and I'm sure the design will be successful. Now if we can all just get through the chip arrival and board assembly process, we can be happily mining away...  

[Bicknellski]

Let's let BKKCoins post what needs to post here. This is a critical moment in the board development so we all need to let the people with the requisite skills communicate.  Time for questions about manuals, other builds and wow look they have K1s should be better placed in another thread.

If you have nothing to add to the technical aspects that BKKCoins is posting maybe it is better we all just step back and watch while they work. This thread is how they work.

[dimka890]

BKKoins, can You write some manual how to flash that PIC?
P.S. Ssory for my English, I am from Ukraine 

If you've been following the thread you'll know there are several errors on this board that need to be fixed before you can power it. And you'll have to bend the PIC pins under to fit the pads. I really don't have time now to write up a manual for a test board. You won't get good result capture unless you add another NOR gate off board. All reasons why people should not order boards based on prototype design files, as warned.

We hurried and ordered. Renewal came a week after the order(

Just hook your programmer up to the ICSP pins, compile, and flash the hex file.

i don't see hex files on github repository (( Maybe i doing something wrong?

Recived today from China
http://i.piccy.info/i7/953566f729f904799f954698573db4ea/4-63-63/26540632/DSC_0966_800.jpghttp://i.piccy.info/a3/2013-07-02-20-42/i7-4798681/799x535-r/i.gif
BKKoins, can You write some manual how to flash that PIC?
P.S. Ssory for my English, I am from Ukraine 

Nice! Where did you order those? How long did it take? How much did you pay?

www.szviivtech.com
100pcs - 149USD

[itod]

We hurried and ordered. Renewal came a week after the order(
...
100pcs - 149USD

At least price was not high for 100pcs. Better not order anything yet since not only PCB but BOM also are subject to change.

[evilscoop]

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

[Bicknellski]

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.

[BkkCoins]

I've solved the USB disconnect issue - I think. It hasn't done that for quite a while now. It was an issue with interrupt handling in the PIC. But the solution creates a timing sensitive condition where I've had to make the USB have priority and this could cause result bytes to be misread. I'm looking for a way to handle this now. Result bytes need to be handled in < 8uS and originally I had this block all interrupts to catch them (32uS blackout), but this is enough to throw the USB into fits, so I need a way they can co-operate but guarantee the result bytes get moved.

Ever since upgrading to cgminer 3.3.1 I've noticed that the screen updates very slowly. Sometimes it doesn't output any info for many seconds - up to 10 seconds. I have no idea what change was made that causes this now. If anyone knows why this happens please inform me. It seems to still work and the log file has entries every 2-3 seconds but the screen sometimes doesn't seem to get it's update.

I've also enhanced the PIC code to use a circular buffer for USB writes to host so that it can handle collisions gracefully. I'm not sure if this was part of the issue but I do see some data overruns which this should prevent.

edit: Actually the result overrun doesn't seem to be an issue because if an that occurs it increments the PIC error count and I've yet to see that occur. I just modified the result capture to handle multiple bytes in one ISR call, which means it can stand up to 16 uS of USB takeover.

Knock on wood - I'm seem to be seeing better capture now as I've hit 8 accepted nonces without HW errors. So I smell improvement.

[BenTuras]

It was an issue with interrupt handling in the PIC. But the solution creates a timing sensitive condition where I've had to make the USB have priority and this could cause result bytes to be misread. I'm looking for a way to handle this now. Result bytes need to be handled in < 8uS and originally I had this block all interrupts to catch them (32uS blackout), but this is enough to throw the USB into fits, so I need a way they can co-operate but guarantee the result bytes get moved.

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.

[BkkCoins]

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?

[loshia]

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?

Bkk,

About HW errors with current Avalon Implementation they are less that 1.5% clocked at 350

[BenTuras]

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?

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

I am not trying to be smart, just trying to help with my common sense (and a long gone history of assembly hacking)

I had a quick look at the PIC16(L)F1454/5/9 preliminary data sheet, focussing on interrupts. If I understand correctly, an interrupt occurs, it does automatic context saving, it jumps to the interrupt service routine(ISR) and there you need to determine the source of the interrupt by polling the interrupt flag bits, handle the interrupt, reset the global interrupt enable bit(GIE) and return from interrupt(RETFIE) which restores the context. If a new interrupt is pending, it will be handled after one instruction has been executed after returning from the interrupt.

Maybe your 'unacceptable to the USB stack' was caused by the fact that a second interrupt became pending while you were still handling the first interrupt ?