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

I suppose you are...



lol

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

HAHAH Now thats high tech!!!

    I'm having a terrible day here.

Seriously...

No time for camera direction let the guy work.

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

Tnx

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.

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?

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.

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.

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.

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

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.

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.

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

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.

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

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

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


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.