Klondike - 16 chip ASIC Open Source Board - Preliminary

[ryepdx]

Which is kind of dumb since why bother using 0402 parts if using as much space as 0603.

Are you talking about the C1005X7S1A474K? (The one with 192 pieces on the BOM.) Because that would be pretty awesome, considering stock of the 0402 version is starting to run low at most places. Could we use a 0603 version instead, then?

[Bicknellski]

I wish I could double check everything and help "proof" read all the changes and make sure the new additions to the files are error free, clean and ready to go. Those lurking and following the thread with some experience in this can you go through BKKCoins changes and make sure he has posted corrected files?

I think if we can help him double check things in that way it would go a long way to getting a finished working board that everyone will be able to produce.

+1 to everyone helping and I hope we all can do whatever we can to help BKKCoins push this to the finish line.

Let us know how we can help proof the work BKKCoins.

[chaoztc]

some updates from the i2c front (a little bit technical):

connect to pic with serial #1, notice the 3 attached slaves:

Code:

./ktest
/dev/Klondike
4d 00 10 01 00 00 00 4b 31 36 00 00 00 00 00
Version:10, Serial#:1, ProductID: K16
Cmds [WAISCE.Q]: s
53 00 52 10 03 00 00 ff 00 00 00 00 00
State:R, ASICs:16, Slaves:3, WorkQ:0, Current WorkID:0, Temp:255, Fan:0, HashCount:0, ErrCount:0

connect to 1st slave:

Code:

Cmds [WAISCE.Q]: .
Target Address: 1
Address changed to  1
Cmds [WAISCE.Q]: i
49 01 10 02 00 00 00 4b 31 36 00 00 00 00 00
Version:10, Serial#:2, ProductID: K16

connect to 2nd slave:

Code:

Cmds [WAISCE.Q]: .
Target Address: 2
Address changed to  2
Cmds [WAISCE.Q]: i
49 02 10 03 00 00 00 4b 31 36 00 00 00 00 00
Version:10, Serial#:3, ProductID: K16

connect to 3rd slave:

Code:

Cmds [WAISCE.Q]: .
Target Address: 3
Address changed to  3
Cmds [WAISCE.Q]: i
49 03 10 04 00 00 00 4b 31 36 00 00 00 00 00
Version:10, Serial#:4, ProductID: K16
Cmds [WAISCE.Q]: q

and now unplug usb and plug usb to pic with serial #2, without reset of the system, notice the 3 attached slaves:

Code:

./ktest
/dev/Klondike
4d 00 10 02 00 00 00 4b 31 36 00 00 00 00 00
Version:10, Serial#:2, ProductID: K16
Cmds [WAISCE.Q]: s
53 00 52 10 03 00 00 e7 00 00 00 00 00
State:R, ASICs:16, Slaves:3, WorkQ:0, Current WorkID:0, Temp:231, Fan:0, HashCount:0, ErrCount:0

connect to 1st slave:

Code:

Cmds [WAISCE.Q]: .
Target Address: 1
Address changed to  1
Cmds [WAISCE.Q]: i
49 01 10 01 00 00 00 4b 31 36 00 00 00 00 00
Version:10, Serial#:1, ProductID: K16

connect to 2nd slave:

Code:

Cmds [WAISCE.Q]: .
Target Address: 2
Address changed to  2
Cmds [WAISCE.Q]: i
49 02 10 03 00 00 00 4b 31 36 00 00 00 00 00
Version:10, Serial#:3, ProductID: K16

connect to 3rd slave:

Code:

Cmds [WAISCE.Q]: .
Target Address: 3
Address changed to  3
Cmds [WAISCE.Q]: i
49 03 10 04 00 00 00 4b 31 36 00 00 00 00 00
Version:10, Serial#:4, ProductID: K16
Cmds [WAISCE.Q]: q

I will forward the i2c code now to bkkcoins.

[ecliptic]

Which is kind of dumb since why bother using 0402 parts if using as much space as 0603.

Are you talking about the C1005X7S1A474K? (The one with 192 pieces on the BOM.) Because that would be pretty awesome, considering stock of the 0402 version is starting to run low at most places. Could we use a 0603 version instead, then?

If it's a standard 0402 cap, if one specific manufacturer part on one vendor runs low or out, there are 5-10x other vendors with the same part, and probably another 10x manufactuer parts (each listed on the vendor sites) that will work

The only part i saw that was tricky to source was the PIC, i had to order it directly from the manufacturer and it had a ~2 week leadtime.

[fasmax]

Nice! where does the serial number come from?

[ryepdx]

If it's a standard 0402 cap, if one specific manufacturer part on one vendor runs low or out, there are 5-10x other vendors with the same part, and probably another 10x manufactuer parts (each listed on the vendor sites) that will work

Derp. Thanks. I feel a bit silly now. :-p

[chaoztc]

serials come from each pic, read directly (master) or via i2c (slaves).

[BkkCoins]

If it's a standard 0402 cap, if one specific manufacturer part on one vendor runs low or out, there are 5-10x other vendors with the same part, and probably another 10x manufactuer parts (each listed on the vendor sites) that will work

Derp. Thanks. I feel a bit silly now. :-p

In the case of caps and resistors I put part #s mostly just as example. For the most part I didn't select specific ones based on extended criteria, other than sometimes choosing low ESR, or appropriate voltage rating. The inductors tend to be more specific since the DCR is directly linked to efficiency. The ICs obviously tend to be very specific, though maybe some parts have second sources that would work.

some updates from the i2c front (a little bit technical):
...
I will forward the i2c code now to bkkcoins.

Thanks! Awesome.

Nice! where does the serial number come from?

Each PIC is programmed with a serial#. This can be automated with the Microchip Hexmate utility. Since there will be multiple vendors I'd suggest something like taking the high 8 bits as a vendor id and maybe I'll keep a register so that serial # ranges don't overlap. The only real use of the serial# is so that I2C slave arbitration is ensured that any slave has a priority when enumerating so that each one gets a unique address.

[fasmax]

If it's a standard 0402 cap, if one specific manufacturer part on one vendor runs low or out, there are 5-10x other vendors with the same part, and probably another 10x manufactuer parts (each listed on the vendor sites) that will work

Derp. Thanks. I feel a bit silly now. :-p

In the case of caps and resistors I put part #s mostly just as example. For the most part I didn't select specific ones based on extended criteria, other than sometimes choosing low ESR, or appropriate voltage rating. The inductors tend to be more specific since the DCR is directly linked to efficiency. The ICs obviously tend to be very specific, though maybe some parts have second sources that would work.

some updates from the i2c front (a little bit technical):
...
I will forward the i2c code now to bkkcoins.

Thanks! Awesome.

Nice! where does the serial number come from?

Each PIC is programmed with a serial#. This can be automated with the Microchip Hexmate utility. Since there will be multiple vendors I'd suggest something like taking the high 8 bits as a vendor id and maybe I'll keep a register so that serial # ranges don't overlap. The only real use of the serial# is so that I2C slave arbitration is ensured that any slave has a priority when enumerating so that each one gets a unique address.

So each vendor needs to make sure each K16 they produce has a unique serial number programed into the PIC chip?

[jdape]

Donated 0.11 BTC.  Thanks!

[BkkCoins]

So each vendor needs to make sure each K16 they produce has a unique serial number programed into the PIC chip?

Yes, if they want them to chain together with no chance of collision. It's also possible to serialize later if that function is added into the firmware, as a boot loader option, but I haven't written that code yet. It's just a unique 32 bit integer.

[turtle83]

If it's a standard 0402 cap, if one specific manufacturer part on one vendor runs low or out, there are 5-10x other vendors with the same part, and probably another 10x manufactuer parts (each listed on the vendor sites) that will work

Derp. Thanks. I feel a bit silly now. :-p

In the case of caps and resistors I put part #s mostly just as example. For the most part I didn't select specific ones based on extended criteria, other than sometimes choosing low ESR, or appropriate voltage rating. The inductors tend to be more specific since the DCR is directly linked to efficiency. The ICs obviously tend to be very specific, though maybe some parts have second sources that would work.

some updates from the i2c front (a little bit technical):
...
I will forward the i2c code now to bkkcoins.

Thanks! Awesome.

Nice! where does the serial number come from?

Each PIC is programmed with a serial#. This can be automated with the Microchip Hexmate utility. Since there will be multiple vendors I'd suggest something like taking the high 8 bits as a vendor id and maybe I'll keep a register so that serial # ranges don't overlap. The only real use of the serial# is so that I2C slave arbitration is ensured that any slave has a priority when enumerating so that each one gets a unique address.

Question: Is the PIC firmware flashing possible at runtime? I.e. using the USB connector? Or would it require un-soddering the PIC and hooking it to a programmer? The reason to ask is i would ideally like to be able to change the serial# to include information about the boards position in the cluster.

[BkkCoins]

Question: Is the PIC firmware flashing possible at runtime? I.e. using the USB connector? Or would it require un-soddering the PIC and hooking it to a programmer? The reason to ask is i would ideally like to be able to change the serial# to include information about the boards position in the cluster.

Currently the PIC is programmed by pressing the PICKit3 pins against the ICSP pads on the board - no need to unplug as it needs power on. After I add bootloader code that supports both I2C and USB it will also be re-programmable for most code sections via the USB, using either a special utility or perhaps the cgminer driver (probably by placing a firmware file in the right directory).

If programming via the PICKit3 you would need to disconnect the fan briefly as well since the fan tachometer output shares an ICSP line. If using a 2 pin fan with no tach feedback then this doesn't apply.

Another way to ID position would be to connect I2C one- by-one noting each serial# as they register. Since I2C is a bus and not daisy chain there is no built in way to determine position and address.

[loshia]

Bkk,
With latest overclocking info and measurements,
https://bitcointalk.org/index.php?topic=140539.msg2552912#msg2552912

Measured at the wall (plug) it is about 10% increase from 300 to 350.

Do you think that power regs and other parts in K16 will be able to stand the high power consumption due to overclocking?

I will be very glad when you reach the hashing point to measure Avalon chip consumption at 350

My personal oppinion is that you should consider the overclocking in this stage of development and change some elements on the fly if needed for K16

Pls comment

10X

[BkkCoins]

Do you think that power regs and other parts in K16 will be able to stand the high power consumption due to overclocking?

Going by the numbers it looks borderline maximum. How well it works in reality, I don't know yet.

He reports 350MHz draws 576W PSU output. With 240 chips thats 2.4W/chip or 2A @ 1.2V. For 8 chips/bank that's the rated limit of the regulator, 16A.

[loshia]

Do you think that power regs and other parts in K16 will be able to stand the high power consumption due to overclocking?

Going by the numbers it looks borderline maximum. How well it works in reality, I don't know yet.

He reports 350MHz draws 576W PSU output. With 240 chips thats 2.4W/chip or 2A @ 1.2V. For 8 chips/bank that's the rated limit of the regulator, 16A.

That are bad news. Is there more powerful reg that can be used? If not I will go with K14

[Ente]

My personal oppinion is that you should consider the overclocking in this stage of development and change some elements on the fly if needed for K16

I agree to look at overclocking headroom early.
I believe the most important factor in deciding which avalon platform to use is which one is available first.
Then, immediately, comes which platform can overclock. This would even be more of a priority than the price for the board, as the chips are a lot mor expensive and the platform will cost in the same ballpark.
You people know how fast time runs in bitcointalk. I don't think a lot of avalon-miners with no overclock option will be sold just one month after first shipment.

BKKCoins, many people would go insane in your position. Hats off to you for staying sane! :-)

Ente

[Bicknellski]

My personal oppinion is that you should consider the overclocking in this stage of development and change some elements on the fly if needed for K16

I agree to look at overclocking headroom early.
I believe the most important factor in deciding which avalon platform to use is which one is available first.
Then, immediately, comes which platform can overclock. This would even be more of a priority than the price for the board, as the chips are a lot mor expensive and the platform will cost in the same ballpark.
You people know how fast time runs in bitcointalk. I don't think a lot of avalon-miners with no overclock option will be sold just one month after first shipment.

BKKCoins, many people would go insane in your position. Hats off to you for staying sane! :-)

Ente

Agreed also.

If you need extra cash or support for rapid redevelopment in this direction please let us know. We are keen on being ahead of the curve in terms of overclock so we can run these boards longer before they are crushed by faster chips.

[BkkCoins]

Unfortunately when I started the design I hadn't heard anything about over clocking Avalons and didn't design that in. I added some head room on the power supply just out of safety. I'm not aware of any higher current easy to swap regulator solution so the 3 options I see are:

1. Just place 14 chips / board. The wasted 2 chip board space isn't much of a loss.

2. Scrub the extra power connector behind the PCIe and add a IR3897 9A reg there to supply 4 of the end chips. This would cost a bit extra for parts - rough guess, about $5 maybe.

3. As #2 but extend the board by about 2cm and add 4 more chips, plus a full 16A IR3895 reg behind the PCIe conn. This would supply 6 chips, with 2 of those taken from current 16, making a 20 chip board. This would cost only a bit more than #2 due to higher board cost and the parts being a bit more costly, rough guess, about $8 maybe, but a more radical design change due to heat sink size also being different.

Another data point - the IR3895 over current protection kicks in at 18A minimum, so how well it behaves at max load probably depends a lot on how well it's cooled. Also, some of the reported power use in the other thread is for control board, 3.3V supply and fans so it could be somewhat less for actual ASIC power.

[loshia]

Unfortunately when I started the design I hadn't heard anything about over clocking Avalons and didn't design that in. I added some head room on the power supply just out of safety. I'm not aware of any higher current easy to swap regulator solution so the 3 options I see are:

1. Just place 14 chips / board. The wasted 2 chip board space isn't much of a loss.

2. Scrub the extra power connector behind the PCIe and add a IR3897 9A reg there to supply 4 of the end chips. This would cost a bit extra for parts - rough guess, about $5 maybe.

3. As #2 but extend the board by about 2cm and add 4 more chips, plus a full 16A IR3895 reg behind the PCIe conn. This would supply 6 chips, with 2 of those taken from current 16, making a 20 chip board. This would cost only a bit more than #2 due to higher board cost and the parts being a bit more costly, rough guess, about $8 maybe, but a more radical design change due to heat sink size also being different.

Another data point - the IR3895 over current protection kicks in at 18A minimum, so how well it behaves at max load probably depends a lot on how well it's cooled. Also, some of the reported power use in the other thread is for control board, 3.3V supply and fans so it could be somewhat less for actual ASIC power.

As i said K14 is the easiest path. thank you for the detailed update BKK!