Klondike - 16 chip ASIC Open Source Board - Preliminary

[wrenchmonkey]

@BKKCoins... did you see my post: https://bitcointalk.org/index.php?topic=190731.msg2086152#msg2086152 Can you say something about the questions?

How worthfully is the reference design? https://github.com/BitSyncom/avalon-ref

Can someon build a miner only with this info and the asic-chips?

No, they still need protocol specs. This is hardware specs only.

You mean the chip communications? Then it has to be judged then, when this is out too if it could be ordered at some specialized company?

But then there is still firmware and so on. The minersoftware should work already when the design is the same like the normal avalon miners.

But i asked that question in the thread now too so that this isnt in the wrong thread...

If you're intending to build an exact clone of the Avalon boards, you can do so with the existing specs, but their system uses an FPGA as the communication controller, so you'd have to figure out that aspect to actually make those boards useable.

[SebastianJu]

@BKKCoins... did you see my post: https://bitcointalk.org/index.php?topic=190731.msg2086152#msg2086152 Can you say something about the questions?

How worthfully is the reference design? https://github.com/BitSyncom/avalon-ref

Can someon build a miner only with this info and the asic-chips?

No, they still need protocol specs. This is hardware specs only.

You mean the chip communications? Then it has to be judged then, when this is out too if it could be ordered at some specialized company?

But then there is still firmware and so on. The minersoftware should work already when the design is the same like the normal avalon miners.

But i asked that question in the thread now too so that this isnt in the wrong thread...

If you're intending to build an exact clone of the Avalon boards, you can do so with the existing specs, but their system uses an FPGA as the communication controller, so you'd have to figure out that aspect to actually make those boards useable.

And the fpga is something im wondering if klondike wouldnt be cheaper at the end. Especially the 64 chip pcb...

[wrenchmonkey]

@BKKCoins... did you see my post: https://bitcointalk.org/index.php?topic=190731.msg2086152#msg2086152 Can you say something about the questions?

How worthfully is the reference design? https://github.com/BitSyncom/avalon-ref

Can someon build a miner only with this info and the asic-chips?

No, they still need protocol specs. This is hardware specs only.

You mean the chip communications? Then it has to be judged then, when this is out too if it could be ordered at some specialized company?

But then there is still firmware and so on. The minersoftware should work already when the design is the same like the normal avalon miners.

But i asked that question in the thread now too so that this isnt in the wrong thread...

If you're intending to build an exact clone of the Avalon boards, you can do so with the existing specs, but their system uses an FPGA as the communication controller, so you'd have to figure out that aspect to actually make those boards useable.

And the fpga is something im wondering if klondike wouldnt be cheaper at the end. Especially the 64 chip pcb...

I'm no EE, but I'm assuming we won't know for certain until after the communication protocol is available, BKK seems confident that it can be done without it, and the FPGA would only be useful for larger scaleability. I tend to trust his opinion, but nothing's for certain until we have the full reference specs for the chips. 

[steamboat]

I will be offering fully assembled boards in my thread once I have finalized numbers. The initial numbers will be based on Avalon's design, as all the documentation (minus the BOM) is available now. Once BkkCoins has working prototypes built, I will get pricing for those boards as well.

Klondike is expected to cost less than the Avalon clone because of hardware and software optimizations, namely removing the need for the FPGA.

The idea is to use the Avalon board to get hard numbers people can base their decisions off, and update for the Klondike board once the design is finished and there are functioning prototypes. As long as the performance, pricing, and lead time are equal or better than Avalon, Klondike will be the platform I choose.

Those who purchase chips through my thread will have the option of having their chips sent to assembly along with mine to ensure the fastest turnaround possible.

[je1p7u7]

Why do you guys believe you can get rid of the FPGA?

UPDATE: Ok I managed to read through it Found https://bitcointalk.org/index.php?topic=190731.msg2066226#msg2066226

Even if the reason for choosing the Spartan 6 was due having a large stock of it, I am still skeptical if a microcontroller will be able to handle so much chips. But then again I have no idea how the hashing works nor am I an EE. Just find this really odd.

[wrenchmonkey]

Why do you guys believe you can get rid of the FPGA?

UPDATE: Ok I managed to read through it Found https://bitcointalk.org/index.php?topic=190731.msg2066226#msg2066226

Even if the reason for choosing the Spartan 6 was due having a large stock of it, I am still skeptical if a microcontroller will be able to handle so much chips. But then again I have no idea how the hashing works nor am I an EE. Just find this really odd.

It depends on what you mean by "so many chips". The avalon uses 240 chips, and the FPGA seems to have been significant overkill for that number of chips. I don't think that the ONLY reason they went with the Spartan was the fact that they had plenty on hand. I think it also worked out that they are already quite familiar with them, had vendors worked out, the Spartain made their systems scaleable to much larger systems (like for their own mining operations), and (as I understand it) acts as a host controller, allows the system to operate as a standalone appliance that you can just plug into the network and go, without requiring a host computer. Hell, I think they even come already set up pointed to a pool for you... You literally plug it in, turn it on, and away you go. You might have to use SSH or an HTTP interface to enter some REALLY basic settings, like worker credentials, but I think that's about it.

Since I wager that the majority of us plan on running these through a small host computer, like a Raspberry pi, or maybe even through a Linux-based Nexus tablet (I hope, I hope, I hope), as a host controller anyway, possibly even as a peripheral appliance to GPU mining rigs, etc, the FPGA seems like it is an unnecessary component.

Let the host computer handle the networking and handoff, if you've got one dedicated to the purpose anyway. For somebody who's gonna build a few terahash farm with these things, one FPGA is probably capable of controlling traffic for that entire system. For guys like me who will be starting off with 1-2 K64 units, and building from there, the FPGA is probably just a wasted cost.

Again, I'm no EE, and I've never even considered purchasing the Avalon rig, so my understanding of how that unit functions may be WAY off.

We'll just have to wait until people smarter than me get a look at the communication protocol, and hash out [no pun intended] the details.

[je1p7u7]

What about the BFL designs? I saw that they are using both an FPGA and a microcontroller. It seems strange that they would include the FPGA if it wasn't absolutely required. There are only two ASIC chips on the 5GHz miner.

[jspielberg]

One possibility of the FPGA on the reference avalon design might for future proofing. 

They stated that the hashing modules would be upgradable to newer tech over time.  I don't know the choke points in their design, but if they are moving up to a next generation terahash blade (pure speculation) the extra bandwidth provided by the fpga may be required for adequate communication.

[wrenchmonkey]

What about the BFL designs? I saw that they are using both an FPGA and a microcontroller. It seems strange that they would include the FPGA if it wasn't absolutely required. There are only two ASIC chips on the 5GHz miner.

You're saying that the Jalapeno contains an FPGA? Is that true? I haven't really seen the guts, but that surprises me. No wonder they didn't hit projected power specs. 

[turtle83]

and (as I understand it) allows the system to operate as a standalone appliance that you can just plug into the network and go, without requiring a host controller.

No. They use the TP-LINK WR703N as the host controller. The sparatan has nothing to do with that.

[wrenchmonkey]

and (as I understand it) allows the system to operate as a standalone appliance that you can just plug into the network and go, without requiring a host controller.

No. They use the TP-LINK WR703N as the host controller. The sparatan has nothing to do with that.

Okay, maybe I'm using the wrong lingo here, but I would have classified the WR703N as a network/LAN controller. I meant to say "host computer" in that last line. I went back and fixed it.

In my brain, a host controller would be be the unit that takes data from the network controller and relays and converts that data between the network controller, and the actual processing units (ASICs, in this case). Basically doing what your computer running a mining software does, but at a hardware level. Again, I'm no expert here, so feel free to correct me.

What IS the function of the FPGA in an ASIC logic board, if not just a lazy/overkill method of divvying up the data among the various chips on the bus, and relaying the results back to the network; and/or allowing the unit to operate as a standalone unit, without need for separate software controls?

[BkkCoins]

Ok. Let me try to explain some details about how the hashing works, and why either an FPGA or CPU can work, so that we can move beyond this.

In order for the hash engine to work it needs 3 pieces of data:

( midstate, fixed_data, nonce )

Midstate and fixed_data are provided for each work unit by cgminer.

Nonce is a 32 bit range that will counted up through so that every value is hashed, ie max 4 billion odd hashes.

When cgminer sends a work unit to the Avalon it sends some control info (like fan speeds, module number, asic count) and then the (midstate and fixed_data), and then it appends on the starting nonce value for each ASIC in the target chain module. So for Avalon that is 10 copies of the nonce start value. This all comes down USB and into the FTDI chip which sends it into the FPGA.

The FPGA accepts this in a super long shift register and acts on it. It has to send a stream of data for each ASIC in the chain - so that means repeating the ( midstate, fixed_data, start_nonce_value )  serially into the data input of the ASICs. This is quite a bit of data actually:

( 256 bits midstate, 96 bits fixed_data, 32 bits nonce ) x 10 ASICs in chain = 3840 bits.

It holds the midstate+fixed_data and repeats it for each ASIC appending on the nonce_start.

Avalon uses an FPGA because it's doing this process for each of the 32 modules it contains because it is the one central controller in the box.

The way Klondike works is different but results in the same data going into the ASIC.

Klondike has a PIC controller with USB integrated. So it talks to cgminer just like Avalon, but will use a different driver. This driver will send the (midstate, fixed_data) to Klondike via USB and the PIC stores this in it's RAM (44 bytes total). It doesn't need to calculate and send the nonce, the PIC will take care of that. So total data sent for each work unit is 44 bytes.

The PIC will take this data in RAM and serially push it into the ASICs and then append on a nonce start value (by masking the high 4 bits, thus giving it a range equal to 1/16th of the total). It will repeat this for each ASIC in the chain. Since it's only managing it's own module it doesn't have to switch and control 31 other modules like the Avalon FPGA.

The Klondike has 16 ASICs but I have split them into 2 banks of 8 each. This allows pushing the data in twice as fast, and also means if one ASIC is damaged then only 8 cannot function, instead of 16. While the data is pushed into an ASIC the hashes it calculates are invalid, so the faster the new work start data is pushed in the less time the hashing is stalled.

Klondike also performs a few secondary tasks. It sets up a PWM register to control fan speed. It now and then takes a voltage reading off the thermistor or internal sensor. And it also accepts work data from the USB host that is not intended for it's own ASIC chains. A 44 byte work unit can arrive that is for some other module. In this case it simply receives it and sends it right out again on the I2C bus. Since the PIC has a hardware I2C controller this takes very little code or work.

So the same thing happens in both systems but in Avalon the FPGA has to handle 32 times more data than the PIC. With 16 ASICs at 282 MHz a nonce range of 32 bits will take about,

2^32 / 16 / 282,000,000 = 0.95189878 seconds.

The PIC has to receive 44 bytes of data in just under a second for itself, and then repeatedly shift it into the ASICs as initialization for hashing. This should take about 3% or less of it's time depending on how fast the ASIC shifting is done. The other 97% of it's time it's waiting for results, relaying data or fiddling with it's fan. Since most of these are handled by interrupts it's basically idling.

I may stick a 320x240 LCD touch screen on the front of my Klondike master so I can see status. The I2C bus would allow this and give the PIC something to do when idle.

[SebastianJu]

Im more confident in your plan the more you write... *lol*

[Kushedout]

I know some of the words he used 

Also like the touch screen front panel LCD concept.

in short.... SHUT UP AND TAKE MY MONEY!!!

[ektwr]

Dear BBK

I want to show you my idea for cooling those chips. It is a PCB with square holes to the size of the metal bottom plate of the avalon chip.
The metal fridge could be any aluminum metal plate. The square cooling metals are sitting their positions with a boring screw in the middle.
With little silicone paste it can be a nice, stable solution.
Of course we can talk about it with other ideas too.

[BkkCoins]

Dear BBK

I want to show you my idea for cooling those chips. It is a PCB with square holes to the size of the metal bottom plate of the avalon chip.
The metal fridge could be any aluminum metal plate. The square cooling metals are sitting their positions with a boring screw in the middle.
With little silicone paste it can be a nice, stable solution.
Of course we can talk about it with other ideas too.

One thing I considered was putting a big drill hole under each chip and then inserting a copper plug cut from a rod. I think that would give ultimate heat flow to the heat sink. I decided it was too experimental to use for this project when time is tight, and rewards diminish so quickly. And I don't think the heat is going to be that big an issue. Even Core2Duo mobile CPUs can push 32W into a much smaller heat sink and not melt down.

[je1p7u7]

Im more confident in your plan the more you write... *lol*

+1. Thanks for your awesome input BkkCoins!

Point taken that the Avalon rig has 320 chips and Klondike 16. As for the BFL board it has the same design for all 3 hashrates so the FPGA is probably overkill for the 5GH/s unit but a single design makes sense for lowering production/maintenance costs.

This bitcoin madness is really going to enhance my electronic engineering knowledge

Off to analyzing https://github.com/BitSyncom/cgminer/blob/avalon/driver-avalon.c

[wrenchmonkey]

BKK confirmed what I thought, but in much more technical jargon than I could have ever understood it in. Thanks for taking the time to write that up! I still don't understand the nuts and bolts of the function, but I've definitely got a great 20' view, after understanding about 30% of what you wrote.  

As to cooling, I realize that water cooling MIGHT be overkill, but if we're thinking in terms of power efficiency, what could be more efficient than passive water cooling? If we're having heat-sinks made, would it actually be that much more difficult to have waterblocks made instead? Just throwing it out there...

Also, exactly how scaleable is the klondike system? I know you have the k64. Would each k64 just plug into a different USB port on the host machine, or is it possible to just continue daisy-chaining the cards indefinitely, say, for example, into a 320 chip system, or something. Is there a point where, A: we need to use a separate USB port (to avoid signal degradation, or whatever), or B: where we just need to dedicate a new host machine to the system?

Sorry if this has already been answered.

[BigZee]

Will you provide an assembly service as well?

[hoss]

First off, forgive me if this should be a PM or moved to another thread.

Nice write up BkkCoins. (i wont quote it because its large).  My question is how do you return the data from the ASICs? This might be the big 'unknown' until we have specs, but it seems to me passing that data back through the PIC would not be feasible. Can the data dump be passed directly to the USB controller?  (I have about 15 other scenarios but would zzZZzz this thread so I will save them)

Also, I am in for some serious bulk PCB funding (cash in the Ks USD or BTC), but I would need to see a working prototype (even if its on a test board) before committing.