Klondike - 16 chip ASIC Open Source Board - Preliminary

[Rakessh]

I suspect the red pcb contain the schimtt triggers and nand gate? Just a wild guess

[BkkCoins]

Dear BkkCoins,

Can you please elaborate a little about the changes that you made to the circuit, to make it work? I know about the missing power to the PIC, and the little jumper cable that you soldered to power it. What is that small red PCB doing? I also got a sample board made around the time you did. I also got 2 sample chips that I have mounted. But for some reason the board is not hashing.

The red board has 2 NOR gates wired as I described a few posts back up above.

I use a trailing edge delay circuit. The first NOR gate has P and N, and it's output goes to A of 2nd NOR gate, then through a 100R resistor to B of 2nd gate. B has the 30pF to GND. So the 2nd NOR is ORing the clock with a delayed clock. The UART is set for rising edge capture, and data is inverted when read out of FIFO (~RCREG). This will be updated in the schematic very soon.

The reason it's on a second board is that I had changed the parts so many times on the main board that the PCB traces lifted off. I tried at first to wire the 2nd NOR gate in dead bug style next to the first, but the legs on that tiny gate are too delicate for me and kept coming off. I think I wasted about 4 or 5 over the time I did all that. Once I dug out that board and soldered it down it was easy to connect wires and hook it to the sides of the pullup resistors on main board. The NOR gate on main board was removed because it's output pad had lifted and leg broke off.

Make sure you placed the first ASIC at either location U6 or U9. If U9 then you may need to alter the source code slightly from what I posted since I'm testing on U6. The chips are daisy chained so if you mount one elsewhere then it won't get data.

Even without changing the NOR gate circuit you should get result data, so if you're not then you'd need to start debugging the circuit. I would double check all your QFN pins and make sure none are shorted. Check power is correct for all 3 supply outputs. For one of my chips I had a short underneath that shutdown the 1.2V supply.

If power looks ok then you'll need a scope probably to go further. You can set a falling edge trigger on one lead and then look at the inputs to U6 while sending work with ktest. You should be able to count the pulses and see brief stretched pulses where the data type changes - clock cfg, merkle, precalc, midstate, precalc, nonces. For one or 2 chips the nonces are easy to see as they will be all zero, except the last bit which rises just slightly before the end. If you have data in that looks correct then start scoping the result pins.

The source code is changing hourly here but I try to post when it's working. I fixed some bugs this morning after rewriting the result rx code. It took forever to figure out why the timing was all off. Turns out some compiler bug causes it to not handle const data correctly. It was pushing garbage into the nonce values. It didn't do that before but when I removed the const keyword from the BankRanges array it started sending correct nonces again.

[c-tek]

BkkCoins, What are you using under linux to compile the source for the pic? And can you try to make the hex under win also to see if there are diff?
Just curious if there will be significant differences between.

Best regards

[gill83]

Dear BkkCoins,

Can you please elaborate a little about the changes that you made to the circuit, to make it work? I know about the missing power to the PIC, and the little jumper cable that you soldered to power it. What is that small red PCB doing? I also got a sample board made around the time you did. I also got 2 sample chips that I have mounted. But for some reason the board is not hashing.

The red board has 2 NOR gates wired as I described a few posts back up above.

I use a trailing edge delay circuit. The first NOR gate has P and N, and it's output goes to A of 2nd NOR gate, then through a 100R resistor to B of 2nd gate. B has the 30pF to GND. So the 2nd NOR is ORing the clock with a delayed clock. The UART is set for rising edge capture, and data is inverted when read out of FIFO (~RCREG). This will be updated in the schematic very soon.

The reason it's on a second board is that I had changed the parts so many times on the main board that the PCB traces lifted off. I tried at first to wire the 2nd NOR gate in dead bug style next to the first, but the legs on that tiny gate are too delicate for me and kept coming off. I think I wasted about 4 or 5 over the time I did all that. Once I dug out that board and soldered it down it was easy to connect wires and hook it to the sides of the pullup resistors on main board. The NOR gate on main board was removed because it's output pad had lifted and leg broke off.

Thanks a lot. Do the latest Kicad files in the Git repository reflect these changes?

[terrahash]

There is a small issue with the Kicad files that I want to bring to your notice. The module references do not show up on the Front Silk Screen gerber files when plotting. This is because in the k16.brd file, all the Capacitors, Resistors and Diodes are marked to be on layer 26, whereas they should be on layer 21 (T0 and T1 lines for each module, value 9 is 26). I replaced all "V 26 N" with "V 21 N" and all "I 26 N" with "I 21 N", and now the references show up on the gerber files. I am not sure how this can be fixed from within PCBNew.

[terrahash]

Dear BkkCoins,

Can you please elaborate a little about the changes that you made to the circuit, to make it work? I know about the missing power to the PIC, and the little jumper cable that you soldered to power it. What is that small red PCB doing? I also got a sample board made around the time you did. I also got 2 sample chips that I have mounted. But for some reason the board is not hashing.

The red board has 2 NOR gates wired as I described a few posts back up above.

I use a trailing edge delay circuit. The first NOR gate has P and N, and it's output goes to A of 2nd NOR gate, then through a 100R resistor to B of 2nd gate. B has the 30pF to GND. So the 2nd NOR is ORing the clock with a delayed clock. The UART is set for rising edge capture, and data is inverted when read out of FIFO (~RCREG). This will be updated in the schematic very soon.

The reason it's on a second board is that I had changed the parts so many times on the main board that the PCB traces lifted off. I tried at first to wire the 2nd NOR gate in dead bug style next to the first, but the legs on that tiny gate are too delicate for me and kept coming off. I think I wasted about 4 or 5 over the time I did all that. Once I dug out that board and soldered it down it was easy to connect wires and hook it to the sides of the pullup resistors on main board. The NOR gate on main board was removed because it's output pad had lifted and leg broke off.

Thanks a lot. Do the latest Kicad files in the Git repository reflect these changes?

AFAIK, it does not. I still see only one NOR gate.

[BkkCoins]

There is a small issue with the Kicad files that I want to bring to your notice. The module references do not show up on the Front Silk Screen gerber files when plotting. This is because in the k16.brd file, all the Capacitors, Resistors and Diodes are marked to be on layer 26, whereas they should be on layer 21 (T0 and T1 lines for each module, value 9 is 26). I replaced all "V 26 N" with "V 21 N" and all "I 26 N" with "I 21 N", and now the references show up on the gerber files. I am not sure how this can be fixed from within PCBNew.

I don't think there is a way to edit that in Kicad, as I looked hard for it, even though you can edit the position/size, which I did to make them less jumbled. How  they got onto layer 26 I don't know, but I did look in the brd file and saw they were incorrect. Perhaps this was a result of the Eagle > Kicad conversion but it doesn't entirely make sense as many parts were added after. Unless it set something that later kept using that layer. At one point I went in and changed the ICs manually because I wanted them to show at least but I was worried about mucking it up and didn't search/replace everything. If this doesn't cause any problems then I'll do that. Now it's on github it's easy enough to revert.

[BkkCoins]

Thanks a lot. Do the latest Kicad files in the Git repository reflect these changes?

AFAIK, it does not. I still see only one NOR gate.

I haven't pushed the new changes yet. I'm still editing the board file and added the new part to the library but if I push the schematic then someone's going to run the netlist over to the board and have problems.

[terrahash]

There is a small issue with the Kicad files that I want to bring to your notice. The module references do not show up on the Front Silk Screen gerber files when plotting. This is because in the k16.brd file, all the Capacitors, Resistors and Diodes are marked to be on layer 26, whereas they should be on layer 21 (T0 and T1 lines for each module, value 9 is 26). I replaced all "V 26 N" with "V 21 N" and all "I 26 N" with "I 21 N", and now the references show up on the gerber files. I am not sure how this can be fixed from within PCBNew.

I don't think there is a way to edit that in Kicad, as I looked hard for it, even though you can edit the position/size, which I did to make them less jumbled. How  they got onto layer 26 I don't know, but I did look in the brd file and saw they were incorrect. Perhaps this was a result of the Eagle > Kicad conversion but it doesn't entirely make sense as many parts were added after. Unless it set something that later kept using that layer. At one point I went in and changed the ICs manually because I wanted them to show at least but I was worried about mucking it up and didn't search/replace everything. If this doesn't cause any problems then I'll do that. Now it's on github it's easy enough to revert.

Yea, I search/replaced all those value and everything worked fine. I believe its safe for you to replace them all.

[terrahash]

We basically have 3 boards right now. One with NO Asics, one with 2 Asics and another with all 16 Asics. The first two work as expected. The red LED blinks on commands and everything. The problem with the third board (with 16 Asics) is that its green LED turns on, but the red one does not. I measured the voltage across the red LED and its 3.2 V. I believe those LEDs don't work if the voltage is over 2.4 V. Any ideas why its so high? This particular board is the original design (with only one NOR gate), nothing modified except for the jumper to power the PIC.

Update: When the USB cable is connected, the voltage across the LED drops to 0 V. When a command is issued, it again goes up to 3.2 V and comes back down.

[BkkCoins]

We basically have 3 boards right now. One with NO Asics, one with 2 Asics and another with all 16 Asics. The first two work as expected. The red LED blinks on commands and everything. The problem with the third board (with 16 Asics) is that its green LED turns on, but the red one does not. I measured the voltage across the red LED and its 3.2 V. I believe those LEDs don't work if the voltage is over 2.4 V. Any ideas why its so high? This particular board is the original design (with only one NOR gate), nothing modified except for the jumper to power the PIC.

Update: When the USB cable is connected, the voltage across the LED drops to 0 V. When a command is issued, it again goes up to 3.2 V and comes back down.

If you're measuring the LED voltage on the end near the PIC, as it sounds like, then the voltage should vary between 3.2 and GND as it gets flashed. This voltage is not entirely across the LED as there is a resistor after it to GND which will have a voltage drop across it equal to the difference of 3.2V and the Fwd Voltage of the LED. The resistor ensures too much current doesn't pass thru the LED. If it has 3.2V on it and doesn't light up then it's either damaged or the connection to board is bad or similar with resistor next to it.

The LED is turned on only when a Cmd is processed and turned off after approx. 1/4 second (SlowTick in the code). So it won't flash unless a USB cable is attached and a Cmd is received and processed successfully. If you plug in USB and send a Cmd with ktest and it doesn't flash then probably there is some USB problem, though generally if ktest can't access the device it would probably fail. Hardware wise verify the USB pins aren't shorted, which can be hard to see if underneath.

[Tad3j]

USB problem?

From USB wikipedia ...

A charging port supplies up to 500 mA at 5 V, up to the rated current at 3.6 V or more, and drop its output voltage if the portable device attempts to draw more than the rated current. The charger port may shut down if the load is too high.

[terrahash]

We basically have 3 boards right now. One with NO Asics, one with 2 Asics and another with all 16 Asics. The first two work as expected. The red LED blinks on commands and everything. The problem with the third board (with 16 Asics) is that its green LED turns on, but the red one does not. I measured the voltage across the red LED and its 3.2 V. I believe those LEDs don't work if the voltage is over 2.4 V. Any ideas why its so high? This particular board is the original design (with only one NOR gate), nothing modified except for the jumper to power the PIC.

Update: When the USB cable is connected, the voltage across the LED drops to 0 V. When a command is issued, it again goes up to 3.2 V and comes back down.

If you're measuring the LED voltage on the end near the PIC, as it sounds like, then the voltage should vary between 3.2 and GND as it gets flashed. This voltage is not entirely across the LED as there is a resistor after it to GND which will have a voltage drop across it equal to the difference of 3.2V and the Fwd Voltage of the LED. The resistor ensures too much current doesn't pass thru the LED. If it has 3.2V on it and doesn't light up then it's either damaged or the connection to board is bad or similar with resistor next to it.

The LED is turned on only when a Cmd is processed and turned off after approx. 1/4 second (SlowTick in the code). So it won't flash unless a USB cable is attached and a Cmd is received and processed successfully. If you plug in USB and send a Cmd with ktest and it doesn't flash then probably there is some USB problem, though generally if ktest can't access the device it would probably fail. Hardware wise verify the USB pins aren't shorted, which can be hard to see if underneath.

The commands are going to the PIC. Ktest can identify it, check the status, set clock etc. Maybe the LED is damaged. One more question. When we send some work with the 'W' command, in Ktest, the status changes to W and then to R after a little while. But no result is passed back. How can we check the result?

[BkkCoins]

One more question. When we send some work with the 'W' command, in Ktest, the status changes to W and then to R after a little while. But no result is passed back. How can we check the result?

The result is always sent if it is captured, so not getting one back means it didn't capture one. Check the error count value. If it has changed then it means the UART got too much data before the code could remove it to queue for sending. This doesn't happen so often, so the loss of result data seems to be either corruption on the input side, meaning there may not be a result, or the signal conditioning on the result capture isn't adequate. This is why I added the extra NOR gate to improve the capture side.

I'm still working today on changes to handle capture with more chips, more reliably. Once I put 4 on I found a serious timing error but fixing that increased the interrupt rate and has affected result capture again. Once I get it stable again, I'll push up a new version.

[Jumpsu]

Bkk, can you take closer picture red card and can you make circuit diagram?

Tnx

[Bicknellski]

Bkk, can you take closer picture red card and can you make circuit diagram?

Tnx

Seriously...

No time for camera direction let the guy work.

[BkkCoins]

    I'm having a terrible day here.

[joeventura]

  I'm having a terrible day here.

HAHAH Now thats high tech!!!

[Igor_Rast]

Nice drawing

Did you guys see the .Avalon Chips beeing shiped ?

http://imgur.com/a/GR0e3#oDE6OW1
http://www.reddit.com/r/Bitcoin/comments/1hzzmo/impressive_pictures_of_a_huge_avalon_chips_order/

looks like the time of truth is fast approaching :p

[Taugeran]

Nice drawing

Did you guys see the .Avalon Chips beeing shiped ?

http://imgur.com/a/GR0e3#oDE6OW1
http://www.reddit.com/r/Bitcoin/comments/1hzzmo/impressive_pictures_of_a_huge_avalon_chips_order/

looks like the time of truth is fast approaching :p