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

^^^^^^^^^^^^^^^^^ What he said!!

Fantastic!

Pretty good timing too

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.

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.

great news!

Very very happy to read that!

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.

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.

 

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.

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.

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

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.

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://bitcointalksearch.org/topic/m.2536272

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.

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.

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.

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

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