Klondike - 16 chip ASIC Open Source Board - Preliminary

[BkkCoins]

BTW my fridge and the small magnifier ring light both cause enough EMI on the power line here to cause a USB disconnect. Probably the source of much random noise. Half the time when the fridge turns on, cgminer re-inits the KLn device. They're on the same outlet circuit.

How have you connected the outer shield of the usb plug to gnd?
I have often seen at various hubs - that the other shield is also connected via some ferrite beads to gnd.

The outer shield is connected to direct to GND. But you gave me an idea.
I haven't seen it happen again after changing the USB cable to the high quality one from my Canon camera that has a ferrite core near the board connector. I was using the other one because it's short and less clutter on my work bench.

I've wired in the inverters now. The signal has very sharp/fast rise times now and it's easy to see the clock delay is 50nS. I tested it manually in ktest and got all GOOD nonces up to 420 MHz doing repeat work filling the queue . At 430 MHz they came back BAD.

Unfortunately on cgminer the error rate hasn't improved. I haven't run that long yet but I'm seeing 3% - 5% error rates. I believe this is now related to noise on the PLL and instability. It can go quite a long time with no errors, and just when I think Ok, it's down to 1% now, but then a bunch pop up and it's back to 3%.

I'm moving onto final board revisions now. Hope to have a new K16 release later today and k1 tomorrow sometime.

Reading through burnin's and others designs it looks like these chips probably exceed 2A each if you overclock more than a little bit.  Have you had any results running say, 8 chips on a 16A regulator (or 16 on 2x 16A regulators) and overclocking/overvolting?

Your buck is at 600khz while avalon's is at 300kHz, both spec'd at 2A/chip, so you should have somewhat better OCability, unless the current is the first limit you hit.

I haven't really tested the O/C range yet. I do brief tests up higher but not any long runs. I'm waiting on a set of spare leads for my Ammeter to cut into a PCIe cable for current measurements.

If there is anything you need that can be sourced in Australia, let me no.. Am flying to BKK on the 21st and can bring it with me...

Thanks. The AUS power cords aren't much use here due the curious angled blades. My sister lives near Brisbane but I haven't been to see her in years. I hope to get down there again before too long.

I'm going to order a couple RFI power line filters from Mouser in my next order. There's two kind I looked at but I'll probably cheap out and order the $4 one instead of $22 one.

10VR3 $22.46

16WGF1 $4.40

[1713547492]

1713547492

[1713547492]

1713547492

[1713547492]

1713547492

[BkkCoins]

New scope pr0n... with extra inverters, showing a 1 bit and two 0 bits.

I think this was at 390 MHz. Shows fixed 50nS delay on clock trailing edge on input to PIC. Note this inverts data and clock so now the code is set for falling edge capture and no longer inverts RCREG upon read.

[vs3]

New scope pr0n... with extra inverters, showing a 1 bit and two 0 bits.

I think this was at 390 MHz. Shows fixed 50nS delay on clock trailing edge on input to PIC. Note this inverts data and clock so now the code is set for falling edge capture and no longer inverts RCREG upon read.

https://i.imgur.com/NmZ6qQN.jpg

BKK - That spike in the red line at -50nS (when the yellow goes down 1->0) - is that introduced by possibly too long probes?
If not - that's 0.8V from peak to peak and I'm wondering if it introduces any other issues at higher frequencies ...
My guess is that it could be either due to the red and yellow wires being too close, or most likely sneaking in via the power lines ... maybe some more decoupling capacitors?

That's just an observation. If it doesn't cause any issues please disregard my note and let's stick with the K.I.S.S. principle

edit: there is also that huge spike when it goes from 0 to 3V3 (4.4V peak when just the red switches, or 5V when both switch). Again - if it's not an issue - don't bother fixing it.

[terrahash]

Our sample board is now working at all the way up to 347 MHz. I was using a NTE NOR gate IC that I bought at FRYs, for both NORs (I wasn't using the one on the board). Looks like its fall or rise times are a little too much. I played around with a lot of capacitors. I finally modified the circuit to use the on-board nor gate chip for the first NOR and the FRYs one for the second. And now everything is working fine. The board is hashing very well at 300 MHz.

[BkkCoins]

New scope pr0n... with extra inverters, showing a 1 bit and two 0 bits.

I think this was at 390 MHz. Shows fixed 50nS delay on clock trailing edge on input to PIC. Note this inverts data and clock so now the code is set for falling edge capture and no longer inverts RCREG upon read.

https://i.imgur.com/NmZ6qQN.jpg

BKK - That spike in the red line at -50nS (when the yellow goes down 1->0) - is that introduced by possibly too long probes?
If not - that's 0.8V from peak to peak and I'm wondering if it introduces any other issues at higher frequencies ...
My guess is that it could be either due to the red and yellow wires being too close, or most likely sneaking in via the power lines ... maybe some more decoupling capacitors?

That's just an observation. If it doesn't cause any issues please disregard my note and let's stick with the K.I.S.S. principle

edit: there is also that huge spike when it goes from 0 to 3V3 (4.4V peak when just the red switches, or 5V when both switch). Again - if it's not an issue - don't bother fixing it.

The fast edges does tend to cause small surges in power use that can show as ringing in nearby traces. This is probably made worse by the thin wires and long exposed traces on the proto board. I don't think it's an issue as it shows up now, and the final board layout should lessen it. I was thinking of adding another decoupling cap to the PIC and this actually looks like a good place to put one.

Our sample board is now working at all the way up to 347 MHz. I was using a NTE NOR gate IC that I bought at FRYs, for both NORs (I wasn't using the one on the board). Looks like its fall or rise times are a little too much. I played around with a lot of capacitors. I finally modified the circuit to use the on-board nor gate chip for the first NOR and the FRYs one for the second. And now everything is working fine. The board is hashing very well at 300 MHz.

Excellent!

I'm treating your use of all 16 chip locations as verification of the current PCB, so that I can revise and release an update without myself having to put 12 more on. Every day counts right now. I've completed the NOR gate, inverter and fan control revisions. Next up is ferrite beads and moving the thermistor. Then the PIC QFN version, and new logo. I'm also going to move the big caps in the middle just a smidge since the latch for the PCIe connector is a bit close.

I just ran for two hours off the RasPi instead of my notebook and for whatever reason the error rate dropped to around 0.7% - over 2 hours! That made me very happy as I've been trying to get it down to <1% and this indicates that noise may be a real factor. Let's hope the ferrite beads really clean this up.

Another thought I had was whether the USB stack provide dy Microchip actually has robust error checking. If not, or if it's an option not turned on (which I didn't see) then USB errors not being re-transmitted would cause corrupt work data being sent to the ASIC. I'll have to go explore that code and find the error checking routines and see how they are treated. I thought of this since putting it on the Pi means a different USB host controller and perhaps different noise.

( btw it's nice to be able to just pop in to frys and get stuff. I stayed a while in LA for work and had a rent a car so I'd check it out almost daily. Where I am now it's impossible to find anything and overall it's a small miracle that I did as much as I have here. A lot of community support really helped. I may have packed it in long ago if not for so much interest and cheering on. )

[Bicknellski]

Serial numbers for customers?

Wondering about PCBs fabrication is it simple enough to get serial numbers on the K1 / K16 during fabrication so that customers can let us know should they get a dud K1 / K16 or was the serial numbers going to be some how built into the firmware?

Sorry for my ignorance in advance.

[BkkCoins]

Lovin This:
(running off RasPi)

Serial numbers for customers?

Wondering about PCBs fabrication is it simple enough to get serial numbers on the K1 / K16 during fabrication so that customers can let us know should they get a dud K1 / K16 or was the serial numbers going to be some how built into the firmware?

Sorry for my ignorance in advance.

Serial # in the firmware. It would be costly to have them printed on the board but it may make sense to add a silk screen label spot for hand writing the number when flashing the PIC. Don't know if that's something vendors would want to do or not. The serial# in firmware is easily viewed on screen. I should also add it in the API stats so it can be used in automated ways.

[turtle83]

Serial # in the firmware. It would be costly to have them printed on the board but it may make sense to add a silk screen label spot for hand writing the number when flashing the PIC. Don't know if that's something vendors would want to do or not. The serial# in firmware is easily viewed on screen. I should also add it in the API stats so it can be used in automated ways.

+1 for serial number in stats. Im thinking of making a different tool to suck stats from cgminer and maintain history per device, and help identify the exact location of a particular device (which may be having errors) by comparing serial number with usb bus/port ids.

[Bicknellski]

+1 BKKCoins thanks again!

[AtomSea]

More Cheers! Lovin' the ASICs pr0n!
I haven't watched Netflix for a month!
I check updates and look up all your guys' funky words.
Love this thread - it's a wannabe nerds' dream.


 

[simon66]

@BkkCoins I lost track a few pages ago lol.

Is the k16 working? I saw the image above but a few pages ago you said that the hashes per second was wrong. So is that "real"?

Thanks

[ryepdx]

Any word on testing the chaining capabilities? I'm hesitant to start producing boards if I can't be sure they'll be chainable.

Thanks for all your hard work, BkkCoins. Wouldn't be doing any of this if it weren't for you! :-)

[cardcomm]

( btw it's nice to be able to just pop in to frys and get stuff. I stayed a while in LA for work and had a rent a car so I'd check it out almost daily. Where I am now it's impossible to find anything and overall it's a small miracle that I did as much as I have here. A lot of community support really helped. I may have packed it in long ago if not for so much interest and cheering on. )

I don't see how you do it at all with such limited resources. I'm so spoiled living where I do. To think I complain because the nearest Fry's is 60 miles away!

I can see how the community support could help keep you going, but I don't buy it that you would have packed it in long ago - I'm betting that wouldn't fit your personality.

Thanks again for the awesome update, and the continued hard work! Very, VERY impressive. You ARE the man

[cad_cdn]

gotta say, love reading the technical details, and thx for all the work being done!
 

[siran]

Serial # in the firmware. It would be costly to have them printed on the board but it may make sense to add a silk screen label spot for hand writing the number when flashing the PIC. Don't know if that's something vendors would want to do or not. The serial# in firmware is easily viewed on screen. I should also add it in the API stats so it can be used in automated ways.

What about DS18x20? This can measure temperature (a 'bit' pricier than thermistor) but also has unique 64bit serial number. And it's 1-wire.

[BkkCoins]

@BkkCoins I lost track a few pages ago lol.

Is the k16 working? I saw the image above but a few pages ago you said that the hashes per second was wrong. So is that "real"?

Thanks

It's coming along. Most of the basic mining functions are working well now. The speed is correct. I'm still only testing with 4 chips but Terrahash has a full 16 chip board and are working on getting that running better. That screen shot above is running off my Raspberry Pi. On my notebook it gets higher error rates. So there is some debugging to do as to why that happens.

Any word on testing the chaining capabilities? I'm hesitant to start producing boards if I can't be sure they'll be chainable.

Thanks for all your hard work, BkkCoins. Wouldn't be doing any of this if it weren't for you! :-)

Chaoztc took my basic I2C code and re-wrote and debugged it. He sent me that and I just need to integrate it in. He tested with 3 PICs, 1 master and 2 slaves and says it was working ok like that. So after I get the hardware revisions done and boards ordered then I have two main tasks to do before I get new boards back.

#1 priority is getting a bootloader written. There's lots of examples, and it's not so hard. I don't expect that to take too long but this one is different as it needs to support bootloading via USB and I2C in Klondike protocol, so that users don't need to disassemble their rigs to upgrade. It should be a fairly transparent process that only takes maybe 10-15 seconds per device, and can even be automated within the cgminer driver so that downtime is minimal. In fact, it's not really a bootloader per se, because you don't need to reboot anything manually.

#2 Integrate the I2C in so that when I have a few boards at hand I can test how that works while mining is active.

The bootloader is first because any one who buys/builds a board is going to want an easy upgrade path. We don't want users having to send boards back to be re-programmed. So even very basic firmware with a bootloader allows for upgrading on the fly as more stuff gets debugged and tweaked with improvements.

What about DS18x20? This can measure temperature (a 'bit' pricier than thermistor) but also has unique 64bit serial number. And it's 1-wire.

A but pricier? I looked on mouser and it seems to run about $4-5/chip unless I got the wrong one. Thats 3x the price of the PIC controller. Anyway, I'm not going to start into that at this late time.

[siran]

A but pricier? I looked on mouser and it seems to run about $4-5/chip unless I got the wrong one. Thats 3x the price of the PIC controller. Anyway, I'm not going to start into that at this late time.

Ouch...It's ~1$ in Poland :/ Anyways, you're right according to sheduling and other more important stuff. Sorry for buggin

I must say, that I can't live an hour without checking this thread. You are doing a tremendously good job sir!

[dnaleor]

is special coding necessary for cgminer or will it just plug and play (or just ad an option like the icarus-options for USB block erupters)?


Keep up the good work!

[Scornflakes]

Reading the play by play on the development of these Klondike boards is amazing.  BkkCoins and terrahash, thank you for all of your hard work on this.  And big props to everyone else who is making this a reality in such an aggressive time frame.

[terrahash]

I'm treating your use of all 16 chip locations as verification of the current PCB, so that I can revise and release an update without myself having to put 12 more on. Every day counts right now. I've completed the NOR gate, inverter and fan control revisions. Next up is ferrite beads and moving the thermistor. Then the PIC QFN version, and new logo. I'm also going to move the big caps in the middle just a smidge since the latch for the PCIe connector is a bit close.

Yea, you can count on it. Our error rate is still quiet high, but all the chips are hashing. Below is the latest stat:

Code:

        {
            "Fan RPM 0": 0, 
            "STATS": 0, 
            "Clock 0": 150.0, 
            "Calls": 0, 
            "Min": 99999999.0, 
            "Max": 0.0, 
            "USB Delay": "r0 0.000000 w0 0.000000", 
            "Errors / Chip 0": "0326 0327 0307 0323 0323 0306 0312 0350 0311 0304 0303 0327 0340 0344 0337 0319", 
            "Nonces / Chip 0": "2538 2514 2480 2505 2500 2556 2530 2434 2435 2432 2354 2439 2539 2521 2512 2436", 
            "USB Pipe": "0", 
            "Elapsed": 42506, 
            "Fan Percent 0": 50, 
            "Temp 0": 41.72, 
            "ID": "KLN0", 
            "Wait": 0.0
        },