Klondike - 16 chip ASIC Open Source Board - Preliminary

[chanberg]

ok cool, so what is the recommended way to power on the psu?  Are people mainly going to have these plugged into pc's?

edit:
ok I got a few psu's laying around but I am unsure how to power on the power supplies without a host pc, what I'd like to do is have a nexus 7 or netbook run cgminer, how do I switch the power supply on? is there a switch I can buy for this?

I picked-up one of these.  It is a bit easier on your Power Supply by  placing a small load on the 3.3 volt rail to stabilize it.

http://www.ebay.com/itm/251029201991?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1439.l2649

that is the ugliest switch i have ever seen!~...

Search Cablez he makes switches that look clean

Danny

[Japs2013]

I'm planning to use these: http://highflow.nl/toebehoren/waterkoeling-toebehoren/psu-bridging-tool-20-pin.html

[pixl8tr]

that is the ugliest switch i have ever seen!~...

Search Cablez he makes switches that look clean

Danny

They are clean looking, but for my use, difficult to mount Cablez rocker switch thru the existing round hole in my case.  

[freeworm]

If I hook up my USB via a cheap pocket hub to my notebook the error rate drops right off to < 1% (short test so far). So there's a quick fix for those wanting to see if the USB noise is causing the error issues.
My guess is that the hub has correct EMI filtering beads on it's connections and acts as the filter we need.
Looking at this now - EMI2121
http://www.onsemi.com/pub_link/Collateral/EMI2121MT-D.PDF

More report.

Now I have all the 16 chips mounted on the board running at 256MHZ. The HW error rate is higher than before at ~ 30%.
If I lower the freq to 128MHz, the HW error rate drops to less than 10%.

From the chip statistics, I can see that some time 15 chips are working but at most time 13 chips.

I just grabbed a 4 port USB hub the same as this

http://www.canadacomputers.com/product_info.php?cPath=48_794_259&item_id=038391

but it doesn't help the HW.

I think the key is the report signal clock generation circuit or the capacitor value (I am using 30pF).
I don't know why your clock signal is so sharp. Are you using 74AUP1G02 NOR gate?


Update:

The error rate lowers to ~5% @256MHz after I moved from a desktop to a laptop.

[BkkCoins]

If I hook up my USB via a cheap pocket hub to my notebook the error rate drops right off to < 1% (short test so far). So there's a quick fix for those wanting to see if the USB noise is causing the error issues.
My guess is that the hub has correct EMI filtering beads on it's connections and acts as the filter we need.
Looking at this now - EMI2121
http://www.onsemi.com/pub_link/Collateral/EMI2121MT-D.PDF

More report.

Now I have all the 16 chips mounted on the board running at 256MHZ. The HW error rate is higher than before at ~ 30%.
If I lower the freq to 128MHz, the HW error rate drops to less than 10%.

From the chip statistics, I can see that some time 15 chips are working but at most time 13 chips.

I just grabbed a 4 port USB hub the same as this

http://www.canadacomputers.com/product_info.php?cPath=48_794_259&item_id=038391

but it doesn't help the HW.

I think the key is the report signal clock generation circuit or the capacitor value (I am using 30pF).
I don't know why your clock signal is so sharp. Are you using 74AUP1G02 NOR gate?

I've added the inverters on mine. Immediately before PIC one each on clk and data.
Same as clock buffer - NL27WZ14.
But even before that I was getting much better error rates. I consider 3-5% to be bad enough and on my notebook without hub that's what I get. The hub doesn't do as well as the RaspPi though. It consistently gets <1%.

The new board revision has both Dual NOR gate and inverters, I've completed it now except for adding beads on the USB signals. I worked all night on the ferrite beads on the ASICs, moving the PIC to make room for the beads, and generally improving the routing here or there.

[freeworm]

I've added the inverters on mine. Immediately before PIC one each on clk and data.
Same as clock buffer - NL27WZ14.
But even before that I was getting much better error rates. I consider 3-5% to be bad enough and on my notebook without hub that's what I get. The hub doesn't do as well as the RaspPi though. It consistently gets <1%.

The new board revision has both Dual NOR gate and inverters, I've completed it now except for adding beads on the USB signals. I worked all night on the ferrite beads on the ASICs, moving the PIC to make room for the beads, and generally improving the routing here or there.

Excellent work, BBKCoins! I will do more test trying to improve the error rate and I will let you know when I have new findings.

[rocks]

Now that the chips are arriving hopefully soon,  what power supplies and cabling do people plan to use or recommend? There was a discussion in this thread a while back, but I think that was before the overclocking rates were known.

The best I found was this discussion below, but haven't been able to find definite conclusions on what will work for an array of K16's or what is best:

https://bitcointalk.org/index.php?topic=239377.msg2536272#msg2536272

[fasmax]

Some people have been struggling with getting cgminer and klondike working on RasPi. Here are the steps I used that worked. This assumes you create a Rasbian server boot SD card, and that you can get it to boot, start networking either with LAN or Wifi, and login with ssh.

sudo apt-get update
sudo apt-get install autoconf  libtool libncurses-dev yasm curl libcurl4-openssl-dev pkg-config libusb-1.0

git clone https://github.com/bkkcoins/cgminer-klondike

cd cgminer-klondike
./autogen.sh --enable-klondike

make

./cgminer 2>>cgminer.log

(add -D if you want lots of debugging info during testing)

You can edit ~/.cgminer/cgminer.conf and add a klondike-options item or use the cmd line.

Did this just to get acquainted with the RasPi . It worked using 2013-05-25-wheezy-raspbian.img.
Next I flashed a DIP version of the PIC after building Kondike.X with MPLABXIDEv1.80 .
I bread boarded the USB & LED of the PIC and connected to RasPi.
Running as root cgminer detected the PIC and Kln device as expected.
But what I didn't expect was cgminer showing (5s):1.038G (avg):1.046Ghs
All the other hashing stats were 0 as expected.

[BkkCoins]

Did this just to get acquainted with the RasPi . It worked using 2013-05-25-wheezy-raspbian.img.
Next I flashed a DIP version of the PIC after building Kondike.X with MPLABXIDEv1.80 .
I bread boarded the USB & LED of the PIC and connected to RasPi.
Running as root cgminer detected the PIC and Kln device as expected.
But what I didn't expect was cgminer showing (5s):1.038G (avg):1.046Ghs
All the other hashing stats were 0 as expected.

Haha. Yes, the the hash count in your virtual K16 is timer based. But it's a bug that the driver detects hashing when not in 'W' state. Looks like it is seeing each status update, which has the same hash count (because not changing) as a full loop. It actually notes in the scanwork function a todo that I need to detect cycle reset from workid not hashcount overflow. Still a todo though.

For anyone who wants to test with ktest on Ubuntu (12.04), they are way behind in the libusb version python wrapper. The only way I've found to get an up to date pyusb was from github, with steps as below.

sudo apt-get install libusb-1.0-0
git clone http://github.com/walac/pyusb
cd pyusb
sudo python setup.py install

[BkkCoins]

From the chip statistics, I can see that some time 15 chips are working but at most time 13 chips.

Things I can think to check:

- obviously check power to each chip, btut it hash multiple connections for power so make sure it's getting to all of them. It's pretty hard to fully test that since the pads are underneath. So you have to kind of go by inspection and whether it looks like it's "dry".

- check the reset pin, it needs to be high. Don't measure at the resistor but try to get right to the pin. If it's still low then it's being held in reset.

- check the clock is getting to those chips.

- If the chips are both sequential in the chain, then the first will block the second, so focus first on the one lower in the chain. I don't have a good diagram yet - todo. The chain order is

Bank 0: U6, U8, U5, U7, U2, U4, U1, U3
Bank 1: U9, U11, U10, U12, U13, U15, U14, U16

The weird order is because I laid out the chips before we had the docs, so took a guess as to which way the pins oriented for chaining.

- what method did you use for soldering ASICs? oven or reflow air gun? I had one that shorted power and I couldn't see it. I was lucky that reheating with the air gun and giving it a small bump with tweezers got the bridge under to clear. I've found that less paste is better than more.

- if you have a scope then view the data inputs, and chain outputs.

- you can alter the code that sets up the NonceRange values to push zeros for other chips and a start value for that chip close to the expected nonce. That will have that chip find it first before others, so if triggering then you should see what it outputs. But you cannot know if it actually came from that chip except by timing - quickly, or later in the the cycle. Init to just before the nonce on that chip and just after for others gives max difference between them.

- note the chip order above. If any chip is not working then ones after it could be but may not get data from up the chain.

That's all that pops into my head atm.

[freeworm]

From the chip statistics, I can see that some time 15 chips are working but at most time 13 chips.

Things I can think to check:

- obviously check power to each chip, btut it hash multiple connections for power so make sure it's getting to all of them. It's pretty hard to fully test that since the pads are underneath. So you have to kind of go by inspection and whether it looks like it's "dry".

- check the reset pin, it needs to be high. Don't measure at the resistor but try to get right to the pin. If it's still low then it's being held in reset.

- check the clock is getting to those chips.

- If the chips are both sequential in the chain, then the first will block the second, so focus first on the one lower in the chain. I don't have a good diagram yet - todo. The chain order is

Bank 0: U6, U8, U5, U7, U2, U4, U1, U3
Bank 1: U9, U11, U10, U12, U13, U15, U14, U16

The weird order is because I laid out the chips before we had the docs, so took a guess as to which way the pins oriented for chaining.

- what method did you use for soldering ASICs? oven or reflow air gun? I had one that shorted power and I couldn't see it. I was lucky that reheating with the air gun and giving it a small bump with tweezers got the bridge under to clear. I've found that less paste is better than more.

- if you have a scope then view the data inputs, and chain outputs.

- you can alter the code that sets up the NonceRange values to push zeros for other chips and a start value for that chip close to the expected nonce. That will have that chip find it first before others, so if triggering then you should see what it outputs. But you cannot know if it actually came from that chip except by timing - quickly, or later in the the cycle. Init to just before the nonce on that chip and just after for others gives max difference between them.

- note the chip order above. If any chip is not working then ones after it could be but may not get data from up the chain.

That's all that pops into my head atm.

Hi BBKCoins,

Thanks a lot for your information and great contribution. I have to say this is very very useful for people who are debugging this board.

I used a reflow air gun for soldering ASICs one by one. After soldering each ASIC, I double checked every PIN to make sure the power, GND, CLK, config, report were correct on my oscilloscope. When the ASIC became hot after powered on and the config signal came out at the output PINs, I knew it worked and I would do the next one.

I have moved from a desktop to a laptop and the HW error rate drops to less than 5%. It has been running for 4 hours at 256MHz hashing stably at 3.0~3.2GH/s on eligius.st. Here's chip statistics

           "Errors / Chip 0": "0000 0000 0035 0037 0042 0036 0041 0019 0041 0027 0027 0000 0034 0035 0027 0033",
            "Nonces / Chip 0": "0005 0000 0742 0682 0776 0684 0741 0739 0706 0725 0737 0010 0726 0732 0749 0772",

It shows that one chip returns only 5 nonces, one returns 10 and another one returns 0 in 4 hours. The rest 13 chips are all working as expected (256M * 13 * 0.95 =3.162G).
I think maybe the 3 problem ASICs are also working but their reports cannot be totally captured by the PIC. Since I soldered chips and tested them in cgminer one by one, I am pretty sure the problem ASICs are located at the half board far from the PIC.
This may indicate that you need to pay some attention on the PCB wire routing for the report PINs of the ASICs far from the PIC.

I will use your method to locate the problem ASICs and hopefully the real reason can be identified soon.

[bebfoo]

Great to see troubleshooting mindsets hard at work. Impressive effort, with a great community support. It tickles me that the open source solution is likely to beat BFL, KNC, and even Avalon end units (post-batch #1).

Many of us very well may be hashing these boards by August, and even earlier would be kick-ass.
It's like the gold rush days but moving 100X as fast.

[BkkCoins]

K16 Board Revision is completed. Here is a list of changes:

v0.3.0 - Final testing

- Dual NOR gate replaces Single NOR gate
- Inverters added before PIC on result data, clk
- Schottky Diode added across Fan terminals
- 1K resistor added to pull down FET gate
- Ferrite beads added to AVDD on ASIC PLL supply
- Ferrite beads added to USB D+/D-/GND and shield to GND
- moved PIC decoupling capacitor to be closer to PIC
- added 2 more decoupling capacitors near PIC and inverters
- added NPTh for PICe connector to support horizontal version
- Phoenix 2 pin power connector removed
- new logo added (thanks Laserhorse!)
- moved thermistor to between U7,U8
- moved large input capacitors a little for better PCIe clearance
- small edits to clean up traces here and there
- repositioned a few parts
- footprints verified and updated against data sheets

I've added that to the release notes to get updated today.

I haven't pushed it up yet because I'm doing a full run through on part footprint verification to the data sheets. I'm adding a check list to the part list for this. Once pushed up I'd suggest people review the design files and wait a bit before sending them for production. I know time is tight, but if something gets pointed out to me within a day or two it'll be safer.

I'll work on the QFN version this afternoon, so should be pushed around the same time. Then tonight can start on K1 revision.

I'm going to order boards in a couple days. I'll be posting here to take orders for anyone who wants to get in on my initial batch - boards only. This time they'll be BLUE. They'll be low cost and should be treated as final beta - ie. no warranty, but my best effort to ensure 99% chance of full utility.

So, stand ready. Boards usually take 3-4 days to produce and 7-8 days to arrive here. If I have a big enough order that it's worth it I can add Express shipping and have them faster. Then I'll re-pack small orders and ship out. These are for hardcore DIY use only. Your average tinkerer is not going to want to get into this (it took me 6 hours to hand place the parts, 3 minutes to cook, and many hours of testing). I'll be writing up a PDF guide later.

If you want a plug n play board you need to go with one of the vendors making a real product.

 

[BkkCoins]

I will use your method to locate the problem ASICs and hopefully the real reason can be identified soon.

You should be able to tell from chip order and nonce range affected.

If it works as planned then bank 0 (U6...) should have it's high bit = 0, and bank 1 (U9...) should have it's high bit = 1. One thing I'm not certain about is when pushed if they get picked up in order or reverse order by the chain. Some testing on that should tell. I could tell my board I have 8 chips and then see which 4 don't get any hashes.

So in the stats chips 0-7 should be U6, U8, U5, U7, U2, U4, U1, U3
and chips 8-15 should be starting from U9, U11, U10, U12, U13, U15, U14, U16

So in theory your problem chips are U6, U8 and U12.
But if reverse order then would be U3, U1 and U13.

Testing with a lower chip count ought to show but I haven't thought about the right way to prime the ranges.

[bebfoo]

K16 Board Revision is completed. Here is a list of changes:

v0.3.0 - Final testing

Very very happy to read that!

[Foofighter]

great news!

[Bicknellski]

Whew.... K16 so so so so close...

Avalon chips ... so so so so close...


Wow. So much respect BKKCoins. Can't wait to sell out our K1s and pass on your developer fees as soon as possible.

[southerngentuk]

I'm going to order boards in a couple days. I'll be posting here to take orders for anyone who wants to get in on my initial batch - boards only. This time they'll be BLUE. They'll be low cost and should be treated as final beta - ie. no warranty, but my best effort to ensure 99% chance of full utility.

So, stand ready. Boards usually take 3-4 days to produce and 7-8 days to arrive here. If I have a big enough order that it's worth it I can add Express shipping and have them faster. Then I'll re-pack small orders and ship out. These are for hardcore DIY use only. Your average tinkerer is not going to want to get into this (it took me 6 hours to hand place the parts, 3 minutes to cook, and many hours of testing). I'll be writing up a PDF guide later.

If you want a plug n play board you need to go with one of the vendors making a real product.

 

Are you planning on doing a kit with components (loose not soldered) at a later date, I would love an original final beta even if I never populate it. 

Would be g8 if I could have a k16 and a few of k1's then I`ll get kits later and swap the boards out. Any Idea on prices..

Keep up the G8 work.

[JLM]

K16 Board Revision is completed. Here is a list of changes:

v0.3.0 - Final testing

- Dual NOR gate replaces Single NOR gate
- Inverters added before PIC on result data, clk
- Schottky Diode added across Fan terminals
- 1K resistor added to pull down FET gate
- Ferrite beads added to AVDD on ASIC PLL supply
- Ferrite beads added to USB D+/D-/GND and shield to GND
- moved PIC decoupling capacitor to be closer to PIC
- added 2 more decoupling capacitors near PIC and inverters
- added NPTh for PICe connector to support horizontal version
- Phoenix 2 pin power connector removed
- new logo added (thanks Laserhorse!)
- moved thermistor to between U7,U8
- moved large input capacitors a little for better PCIe clearance
- small edits to clean up traces here and there
- repositioned a few parts
- footprints verified and updated against data sheets

I've added that to the release notes to get updated today.

I haven't pushed it up yet because I'm doing a full run through on part footprint verification to the data sheets. I'm adding a check list to the part list for this. Once pushed up I'd suggest people review the design files and wait a bit before sending them for production. I know time is tight, but if something gets pointed out to me within a day or two it'll be safer.

I'll work on the QFN version this afternoon, so should be pushed around the same time. Then tonight can start on K1 revision.

I'm going to order boards in a couple days. I'll be posting here to take orders for anyone who wants to get in on my initial batch - boards only. This time they'll be BLUE. They'll be low cost and should be treated as final beta - ie. no warranty, but my best effort to ensure 99% chance of full utility.

So, stand ready. Boards usually take 3-4 days to produce and 7-8 days to arrive here. If I have a big enough order that it's worth it I can add Express shipping and have them faster. Then I'll re-pack small orders and ship out. These are for hardcore DIY use only. Your average tinkerer is not going to want to get into this (it took me 6 hours to hand place the parts, 3 minutes to cook, and many hours of testing). I'll be writing up a PDF guide later.

If you want a plug n play board you need to go with one of the vendors making a real product.

 

Grrrrrrrrrrrrrrrrrrrrrreat!!

[bassclef]

Fantastic!

Pretty good timing too