Official Open Source FPGA Bitcoin Miner (Last Update: April 14th, 2013)

[NF6X]

ArtForz claims to get 190MH/s out of an XC6SLX150. While I haven't seen this with my own eyes I think he's trustworthy enough to rely on it.
He also claimed to be currently prototyping a 2U rackmount rig with 32 of them, reaching 6GH/s and using like 300 watts of power. He said that he's planning to sell machines like this, estimating a time to market of about 2 months and a cost of $6K-$8K.

Thanks for the data point!

Yeah, I think 240MH/s should be doable with these, possibly even a bit more.
What about trying to officially get permission to let them mine during the nights?

Back when we were a start-up, I would have done it without asking. Now that we've been bought by a much larger company, and then bought again by a huge company, it wouldn't fly. They made a point of bussing us all a hundred miles to the headquarters and showing us how closely they watch everything in their NOC... I might be able to sneak some trial synthesis runs into the queues, though.

Regarding the comments about the relative utility of FPGAs vs. GPUs, I'll say that if FPGAs had no utility beyond Bitcoin mining, they wouldn't be sold in the first place. With a little thought about the feature set required by other users, FPGA mining-optimized platforms can be made to serve a larger market than just Bitcoin miners. Also, with an XC6LX150 costing around $160 in single quantity, I think they'd easily resell for half of that to somebody who would desolder and reball them. FPGAs are quite useful; they just have utility to a different market than GPUs.

The price of the FPGA itself is only part of the reason for the relatively high cost of generic FPGA evaluation boards that are suitable for mining experiments. The FPGAs which have enough gates for an unrolled mining engine also have a large number of IOs, and are generally in big BGA packages. The eval boards bring all of that IO out, and it takes a lot of layers to escape so many nets from the chip. An LX150 requires about 16 layers for full die escape in a mainstream PCB process. The Virtex 5 board on my desk has 20 layers. We have big emulation machines at work with over 50 Virtex 6 parts mounted on 38 (!) layer boards (before you ask, no, I don't have access to those for mining experiments!). Off the shelf FPGA boards don't look price-competitive with GPUs, but the gap should be much smaller on low-layer-count boards optimized for high gate count, low IO applications. Things start to look even more interesting in hypothetical larger arrays, when you factor in the costs of computers, power supplies and cooling to host bunches of GPUs vs. the lower power and cooling requirements of FPGAs.

[1714252266]

1714252266

[1714252266]

1714252266

[1714252266]

1714252266

[BkkCoins]

If someone was considering the money to build ASICs wouldn't it be smarter to approach Xilinx/Altera about a specially packaged FPGA solution. Say the one above, XC6SLX150, with some optimizations improving the parts needed for better SHA speeds and in a small package with only a few pins? I don't know if their engineers ever do custom solutions, nor how many they sell of the high end units, but given some good quantity of needed parts it seems like it may work.

[NF6X]

If someone was considering the money to build ASICs wouldn't it be smarter to approach Xilinx/Altera about a specially packaged FPGA solution. Say the one above, XC6SLX150, with some optimizations improving the parts needed for better SHA speeds and in a small package with only a few pins? I don't know if their engineers ever do custom solutions, nor how many they sell of the high end units, but given some good quantity of needed parts it seems like it may work.

A well-designed ASIC should be able to achieve much higher hash rates than any FPGA implementation in a given amount of die area. A custom-packaged FPGA would just change the packaging cost with no performance benefit, and the package cost is a smallish portion of the entire chip cost. It wouldn't even affect the PCB cost significantly, since we have the option of simply leaving a lot of the IO pins unconnected. The Spartan 6 FPGAs have a lot of pins, but they're not on a terribly fine pitch so it doesn't take advanced PCB design rules to route the outer few rows of pins and leave the inner rows of IO pins unconnected.

If you're willing to spend ASIC money, you want to end up with an ASIC when you're done.

[makomk]

Very cool!   Looks like he has put further development on hold, due to the heavy cost of building prototypes. It's a CE115 based design, and those chips aren't cheap! I wonder if the design is compatible with a smaller chip ...

That's a very good question indeed, especially since I seem to recall that an appropriately-compiled version of my modifications to your original miner just fits on the EP4CE75 at a claimed 100 MHash/sec (with something like 97% usage, IIRC). I assume the EP3C80 would give similar performance too.

Edit: I'd have mentioned this before but I've been distracted and the cost saving isn't really enough.

Edited to add:

Would it be possible to incorporate this optimization in to the fpga core? http://forum.bitcoin.org/index.php?topic=22965.0

I saw that earlier. In theory, the FPGA synthesis tools automatically carry out optimisations like that for you; they optimise logic in a fundamentally different way to OpenCL compilers. Not sure how true this is in practice.

[lame.duck]

Edited to add:

Would it be possible to incorporate this optimization in to the fpga core? http://forum.bitcoin.org/index.php?topic=22965.0

I saw that earlier. In theory, the FPGA synthesis tools automatically carry out optimisations like that for you; they optimise logic in a fundamentally different way to OpenCL compilers. Not sure how true this is in practice.

Some times ago i read a comment on this: 'Every cs student have to learn to work with Karnough Veight Diagrams and how the Quine McClusky algorithm work. When it goes to practice the synthesis software puts all in a lut'. Since there are 3 input variables there should be nothing to do.

[newMeat1]

I will merge my hardware thread with this software thread just to get everything in one place. Here's the download location for all of my hardware files:
http://www.filedropper.com/pcbtoupload62611

It would be great to have a few more sets of eyes check my design over, especially the pin connections and the circuit board. If we can raise ~$460, I'll give it another shot. I'm at $1.50 so far   

How cool would it be to have a ~140 Mhash/s rig, 4.4 Watts, submerged in mineral oil, and completely quiet? Cost for the board =$426, maybe another $15 for the mineral oil bath.

[lame.duck]

It would be great to have a few more sets of eyes check my design over, especially the pin connections and the circuit board. If we can raise ~$460, I'll give it another shot. I'm at $1.50 so far   

How cool would it be to have a ~140 Mhash/s rig, 4.4 Watts, submerged in mineral oil, and completely quiet? Cost for the board =$426, maybe another $15 for the mineral oil bath.

Is the FPGA dead, or is there a chance to get the chip reballed? I could send you some 0,5 mm balls if you want to try it yourself. If the chip is working at all, you could also try add a better power suppy connection with  Cu foil. Maybe you could even get around a nonworking pll by supplying the clock with direct clocking the design.

[newMeat1]

It's dead, unfortunately. I shorted the 1.2V core to 3.3V...

[TheSeven]

Looking at your board I seriously doubt that your power supply is stable enough for the FPGA to run reliably. I don't see any bypassing caps or switching regulators? Can that couple of SMD voltage regulators really supply like 10 amps on 1.2V?
Usually a 6+ layer board would be used for this. Doing it with 4 layers is tough. 2 layers seems to be impossible.

[newMeat1]

Looking at your board I seriously doubt that your power supply is stable enough for the FPGA to run reliably. I don't see any bypassing caps or switching regulators? Can that couple of SMD voltage regulators really supply like 10 amps on 1.2V?

Thank you, seriously, for the input.

The 2 LDO's are rated for 3A*1.2V each. There are bypass caps on each LDO (just like their datasheets say). Keep in mind, this thing only consumes 4.4W. So I give it plenty of power. From exploring with an oscilloscope, it looks like all the peripherals are working. I'm more worried about whether the pins are hooked up right.

In the most recent revision, I added another LDO for the 2.5V. (Previously I was using diodes to drop from 3.3V to ~2.5V, but that was sketchy).

Yeah, it is hard to fit it on 2 layers. But I followed all the rules (with a few exceptions that are mentioned in the design concerns file).

The advantages of 2 layers are:
1) it's cheap
2) better cooling on the back side of the chip

[TheSeven]

Looking at your board I seriously doubt that your power supply is stable enough for the FPGA to run reliably. I don't see any bypassing caps or switching regulators? Can that couple of SMD voltage regulators really supply like 10 amps on 1.2V?

Thank you, seriously, for the input.

The 2 LDO's are rated for 3A*1.2V each. There are bypass caps on each LDO (just like their datasheets say). Keep in mind, this thing only consumes 4.4W. So I give it plenty of power. From exploring with an oscilloscope, it looks like all the peripherals are working. I'm more worried about whether the pins are hooked up right.

In the most recent revision, I added another LDO for the 2.5V. (Previously I was using diodes to drop from 3.3V to ~2.5V, but that was sketchy).

Yeah, it is hard to fit it on 2 layers. But I followed all the rules (with a few exceptions that are mentioned in the design concerns file).

The advantages of 2 layers are:
1) it's cheap
2) better cooling on the back side of the chip

Have you actually measured that the FPGA doesn't use more than 4.4 watts? Don't trust the simulation tools here, we're pushing this thing very close to its limits, and at least the power consumption estimated for my FPGA by the Xilinx tools was way off.

Usually you should have lots of bypassing caps immediately below the FPGA. ArtForz reported that he sticked to the Xilinx reference design which already had some of those, and that it still just wasn't sufficient for our purposes. I don't see any of them in that area on your board, so I'm not very confident that this will work.

Did you realize that using LDOs means that it isn't the FPGA that needs most cooling, but rather the LDOs? You're running at ~35% efficiency there, so they'll need to dissipate like 8 watts, assuming the 4.4 watts for the FPGA are correct.

[newMeat1]

No, to be honest with you, I didn't look at LDO efficiency. Now that I know it depends on Vout/Vin, I see the problem. 1.2V/3.3V isn't very good     

But, I also realized I can drop the 3.3V supply and do everything with 2.5V. That will be a lot simpler all around and also help with the LDO efficiency. Thanks

[fpgaminer]

Have you actually measured that the FPGA doesn't use more than 4.4 watts?

The 4.4 watt figure was established using my C120 dev kit, which has a power meter on it, so it's fairly accurate.

[lame.duck]

The FPGA Vendors write in their design  guides, a 10 nF capacitor per power/ground Pin pair.  For most designs, this will be not needed since you don't toggle every other flipflop per clock cycle. But using a heavy piplined design means a lot of toggeling flipflops, and  constantly the same. So i think 4 layers are a minimum, with one massive ground and on massive, maybe split power plan for the voltages. And maybe you should use a 1mm or even 0,5 mm board, to keep inductance of the vias low. You can omit bypass capacitors 'completely', if you have a board with 10+ layers.

[TheSeven]

No, to be honest with you, I didn't look at LDO efficiency. Now that I know it depends on Vout/Vin, I see the problem. 1.2V/3.3V isn't very good     

But, I also realized I can drop the 3.3V supply and do everything with 2.5V. That will be a lot simpler all around and also help with the LDO efficiency. Thanks

If you want to spend a few bucks more (still neglegible compared to the FPGA), and want way less heat dissipation, you might consider to use switchers instead. I'd consider it most practical to have a 5V input, and LDO to 2.5V, and a switcher to 1.2V. That way you can easily avoid problems with the connector's voltage drop.

I just had a quick look at what's available at digikey and spotted this one: http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=811-2213-1-ND
Output voltage is programmable from 0.6 to 3.3V, at 1.2V it accepts 2.4V-5.5V input, provides 6A output, and operates at 85-90% efficiency.
Price ranges from $13 for one of them to $830 for 100.

[newMeat1]

OK, OK... I will plan for some type of switching power supply.  And I'll put plenty of bypass caps around the chip's edges.

I really don't think 2 layers is a problem. Yes, it's a 484-pin chip, but how many pins get interesting signals? Maybe about 5. The top layer is the ground plane. Probably 70% of the pins go there. The bottom layer is half 2.5V, half 1.2V. Somewhere you have to make room for a clock pin and a few JTAG pins (those are all concentrated in one area)

I took a look around eBay for some cheap used FPGA boards today, but there's not much there. That and the fact that miners are dropping out --> more motivation to finish this project

[comboy]

I've been trying to run this miner from repo under linux, but I have problems with TclUrl. I did not have it, so I downloaded it and compiled, but now I get:

ERROR: Can't load library: libTclCurl7.19.6.so. The operating system reports the following error: libTclCurl7.19.6.so: wrong ELF class: ELFCLASS64

any hints on how to solve it?

[lame.duck]

I've been trying to run this miner from repo under linux, but I have problems with TclUrl. I did not have it, so I downloaded it and compiled, but now I get:

ERROR: Can't load library: libTclCurl7.19.6.so. The operating system reports the following error: libTclCurl7.19.6.so: wrong ELF class: ELFCLASS64

any hints on how to solve it?

Sounds to me as you try to use a 64bit  lib on a 32 bit linux.  For me, your aproach  works fine.

[comboy]

I've been trying to run this miner from repo under linux, but I have problems with TclUrl. I did not have it, so I downloaded it and compiled, but now I get:

ERROR: Can't load library: libTclCurl7.19.6.so. The operating system reports the following error: libTclCurl7.19.6.so: wrong ELF class: ELFCLASS64

any hints on how to solve it?

Sounds to me as you try to use a 64bit  lib on a 32 bit linux.  For me, your aproach  works fine.

That was a good hint. I still don't understand it though. I'm on 64bit, I've compiled it and also tried debian 64bit binary, in both cases getting mentioned error. After your post I gave some 32bit binary a try (on my 64bit system), and it worked. And so the adventure begins It definitely needs some leds blinking I was also wondering, do these chips have any built-in temperature sensor?

[TheSeven]

I've been trying to run this miner from repo under linux, but I have problems with TclUrl. I did not have it, so I downloaded it and compiled, but now I get:

ERROR: Can't load library: libTclCurl7.19.6.so. The operating system reports the following error: libTclCurl7.19.6.so: wrong ELF class: ELFCLASS64

any hints on how to solve it?

Sounds to me as you try to use a 64bit  lib on a 32 bit linux.  For me, your aproach  works fine.

That was a good hint. I still don't understand it though. I'm on 64bit, I've compiled it and also tried debian 64bit binary, in both cases getting mentioned error. After your post I gave some 32bit binary a try (on my 64bit system), and it worked.

Sounds like you're running 32bit Tcl on a 64bit system and tried to load a 64bit module, which won't work.