Pages:
Author

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

sr. member
Activity: 297
Merit: 250
Hi BBKcoins,

I would like to share my experiences so that you can have more samples to evaluate your design and find the potential instability

As I mentioned before I am using the exact circuit as you drew for the clock generation with RC values 100ohm and 30Pf.  The two NOR gates are all 74AUP1G02 on your BOM. From my oscilloscope I can see that the rising and falling edge are not as sharp as yours but better than using only one NOR gate.

I mounted 8 chips on the board and currently 6 chips are fully working. I have checked pins of the last two chips again and again. I cannot find any soldering problem and all the signals are correct (clock, config, report, powers). I'll re-solder them later.

I have been running this board for a while (~ 1 hour) at 300MHz. The HW is above 10% which is similar to terrahash's board. Here's the statistics
Code:
            "Errors / Chip 0": "0000 0000 0048 0037 0028 0034 0020 0036 ", 
            "Nonces / Chip 0": "0002 0000 0281 0276 0276 0273 0302 0268 ",

Very strange the last chip returned only two good nonces after 1 hour running.

I want to thank you for your great work. The board is working basically. However, I have to say when it's massively produced, HW might be a big issue. Some boards like yours may work great with low HW but others like mine and terrahash's may not.
member
Activity: 86
Merit: 10
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
        },
newbie
Activity: 24
Merit: 0
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.
legendary
Activity: 1470
Merit: 1000
Want privacy? Use Monero!
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!
newbie
Activity: 18
Merit: 0
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 Smiley

I must say, that I can't live an hour without checking this thread. You are doing a tremendously good job sir!
hero member
Activity: 784
Merit: 1009
firstbits:1MinerQ
@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 Smiley
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.
newbie
Activity: 18
Merit: 0
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.
hero member
Activity: 560
Merit: 500
gotta say, love reading the technical details, and thx for all the work being done!
 
sr. member
Activity: 294
Merit: 250

( 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 Smiley
hero member
Activity: 714
Merit: 500
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! :-)
sr. member
Activity: 423
Merit: 250
@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 Smiley
full member
Activity: 143
Merit: 100
So sexy, it hurts.
More Cheers! Lovin' the ASICs pr0n! Cheesy
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.
Smiley

 
hero member
Activity: 924
Merit: 1000
+1 BKKCoins thanks again!
sr. member
Activity: 322
Merit: 250
Supersonic
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.
hero member
Activity: 784
Merit: 1009
firstbits:1MinerQ
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.
hero member
Activity: 924
Merit: 1000
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.
hero member
Activity: 784
Merit: 1009
firstbits:1MinerQ
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.

http://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 Smiley

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. )
member
Activity: 86
Merit: 10
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.
vs3
hero member
Activity: 622
Merit: 500
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.

http://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 Smiley

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.
hero member
Activity: 784
Merit: 1009
firstbits:1MinerQ
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.

Pages:
Jump to: