Thank you for the answer.

As will all of us involved with Bitcoin.  It is good to see a Bitcoin business drive this point home.

By the way, BitSyncom, will customers who purchase your chips in bulk receive a few samples before the 10-week lead time on the production units?  So custom PCB designs can be tested before production parts arrive.

Best of luck Avalon team!  Thank you for the timely update.

I just did a scan over the 7 series datasheets to see their relative performance.  Here is a summary of the important figures; I figure they might be helpful for this and any other 7-series based projects:

Everything is for the -2 speed grade

The FIFO Fmax (block ram) has been a fairly good measure of the absolute maximum frequency we can expect to see out of hashing cores.  My rough estimates show that Artix 7 is likely to have a better MH/s/$ based on these figures alone, and single unit prices.  However, it is difficult to tell for sure, because I suspect that the Artix is crippled in some other way.  I have not check each chip's routing and CLB configurations.

Vivado said ~8-9W, but I don't have it set up with the right information for it to make an accurate measurement.  Using my Kill-a-Watt I estimate about 15W.

I hacked support into MPBM for this new firmware, and she's happily mining away now.  Die temperature is 62C using just the stock cooling on the KC705. 

I just updated the repo with a DSP48E1 design, for Kintex 7.  400MH/s using 80% of the DSPs, and ~25% of random logic.  I don't have an Artix-7 to port to, but I think they also have DSP48E1's.  I plan to start revamping the code base to better support multi-core designs and standardize the communication modules.  Hope to get my Kintex up to at least 1GH/s by throwing in two regular hashing cores.

I don't know about you, but my two X6500s still earn $100 per month.  Not sure why someone would want to trade-in or sell their FPGA rigs.  They don't even require maintenance beyond a good dusting every few months.

Quick Note: I'm trying to move over to my fpgaminer github account.  The links in the OP should have been updated, but there are also a lot of people still following the older repo.  I will continue to push updates to both repos for awhile, but expect https://github.com/fpgaminer/Open-Source-FPGA-Bitcoin-Miner to receive the majority of my attention.

I have just pushed the experimental KC705 code to the repo.  Here is the project.  This is a DSP48E1 based design, and I have compiled and run it at 400MH/s.  Included with this new design is a UART interface, instead of JTAG, since the KC705 kit has an on-board USB-UART bridge.  See the README for more information on how to use the UART interface.  As an additional surprise, this code includes support for the Kintex's on-die temperature sensor.  Temperature readings are reported over UART, allowing external software to monitor the chip.  In the future I will add automatic shutdown on over-temp conditions.

Let me know if you run into any difficulty getting the project to compile with Vivado 2013.1 (or later).  I have never distributed a Vivado project before.  As usual, you will need an appropriate Xilinx license to compile the design.

It only generates compressed public keys.

Rewind the clock a few months, when ASICs were expected to ship within weeks, and you'll see why most FPGA based companies probably backed out of the market.  Beyond that, FPGAs are still at least twice as expensive as the current ASIC offerings and four times the power consumption.  Development of a new FPGA based miner would take weeks before shipping, if the firmware were even ready for it.  If you want to blame anyone, blame all the ASIC companies that poisoned the market and failed to deliver.

Of course, I continue to tinker with my FPGA designs in case some new fruit is found.  I now have 400MH/s firmware for the Kintex 7 chips running at ~15W.  FPGAs can also now do vanitygen.

Haha, that's some great schwag! How was the visit, by the way?

Yes, a single, fully pipelined DSP48E1 core.

Sure.  I want to finish the UART comm and then I'll make a push.  I'm quite interested to see how the Artix chips work out.

Compile and test for 400MH/s just finished.  KC705 officially beats the X6500.  Quad boards, you're next.

I downloaded the latest Vivado IDE, and finally hammered out the code for my DSP48E1 miner.  It is now working happily on my KC705 devkit, which has a Kintex 7 on it.  I haven't pushed the clock rate up yet, so for now it's only running at 300MH/s.  Should be able to get between 400 and 450MH/s out of a fully pipelined DSP48E1 hashing core, depending on how close to the DSP48E1's max spec I can get on this speed grade (-2).  No accurate power measurements yet.  Back of the napkin says 11W, but that seems a bit high; probably a lot of static power usage.

The design is currently using 80% of the DSP48E1's on that chip, and about 25% of other resources.  My goal is to at least get 1GH/s out of this chip, ideally 2GH/s.  Regardless, even 400MH/s will beat the ole X6500's, which needed two chips to get 400MH/s


On a slightly related note, I released my FPGA-based vanitygen code today: https://bitcointalk.org/index.php?topic=152444.0.

EDIT: By the way, I'm pretty happy with the KC705 so far. Lots of great bells and whistles to play with, and most importantly ... they included long USB cables. I can't tell you how many times I get developer-grade equipment with dinky pig-tail USB cables.  Beyond that, the kit comes with an on-board USB-UART bridge, on-board USB-JTAG, and a heatsink-fan combo for the Kintex 7 which I will be sure to cook breakfast on.

The first Open Source Vanity Address Generation for FPGAs firmware is now available on Github!  This first release targets the Altera Cyclone III C120 Development Board, and is more a proof of concept than anything else.  It's functional, but only runs at ~40Kk/s.  Feel free to dive in and port to your own FPGA boards.

I have more performant code under development (unrolled/pipelined).

See the OP for links to the source code and such.

Copy of OP from March 12th, 2013 - Copied, since the OP has been replaced with something more useful.

I just finished testing my implementation of vanitygen on an Altera Cyclone 3 development kit.  It got lucky and generated 1fpgaw5jo9aS1JB8uAw5rRcnM2QiTAVhQ after only ~66million attempts.

It operates off my usual virtual_wire development setup right now; I can feed it a starting public key, and the hash range to look for.  It will report back the private key offset when a match is found.

Current performance using one vanity core is ~40Kk/s.  I expect initial performance once the number of cores is cranked up to be about 400Kk/s on this devkit.  I haven't done any optimizations.  Power consumption is 300mW right now.

Here is a screenshot of my second session, where I was double checking the results of the first test.



Let me know if there's any interest in me releasing the source code.  On a cursory glance I didn't see any open source FPGA solutions for Bitcoin's ECDSA curve, nor RIPEMD-160.  It would be cool to see the ECDSA code rolled into an SoC like Milkymist, and act as a low-running-cost, high-performance Bitcoin node.

In the meantime, I'll probably concentrate on getting performance up and porting over to the X6500.

I started open development of FPGA mining designs in May 2011; BTC was about $5USD at the time.  The first commercial FPGA mining products first appeared on August 18th, 2011, and BTC was about $10USD then.

Food for thought: scrypt as it is used in litecoin is not a memory-hard algorithm.  Rather, it's an algorithm with a space-time trade-off skewed towards using more space, given the current relative costs of memory fetches versus computations.  You can implement litecoin's scrypt with only a little over 2 kilobits of memory, but it runs ~512 times slower.

It's likely that a performant implementation will use a sparse LUT to cut down on fetches.  For example, with a 512 element LUT (instead of 1024), the algorithm performs 50% less fetches, and requires only one extra salsa round 50% of the time.

200mhz is the current figure (without manual placement).

It's unlikely the rep meant 600/700mhz for the hashing designs; he probably meant that the fabric itself can run at 600/700mhz.  In other words, the registers and block ram will run at 700mhz, but any complex logic will run much slower.  For reference, the Kintex 7 fabric runs around 500mhz, but that doesn't mean a CLB based miner would run at 500mhz (more like 300).

Looking at just the LUT count, I would agree with the rep, and I imagine they did the same (look at the LUT count).  However, as Dexter770221 mentioned, performance could be much worse if their FPGAs are sparse in terms of carry chains.

At $3k per chip, I don't personally see a good performance/$ here.  It just sounds a lot like a Virtex/Stratix chip.

Running any high performance bitcoin mining operation will run into networking issues.  The traditional method of getting mining work to a machine is the getwork protocol, which will provide ~4 billion hashes worth of work per request. (Of course extensions to the getwork protocol improve this).  A single 3 module Avalon machine will churn through that work in ~0.07 seconds.  In other words, a single Avalon machine would need to make 13 getwork requests per second.  getwork requests are expensive, and thus put a large strain not only on the network connection, but also the server providing the work.  Also note that, on average, for every getwork request, there will be a corresponding submission of shares.

Extensions to the getwork protocol, getblocktemplate, or the stratum protocol can all be used to alleviate these problems and are mandatory for any modern mining setup for the reason illustrated above.

So, that covers the networking issues.  However, the source of your mining work must also be considered.  Hypothetically, if someone did have a 1TH/s mining farm, they would be foolish to mine at a pool with it.  The pools will not handle that load well, and will constantly fail to fulfill the needs of such a mining farm.  The better option would be mining solo by setting up your own private pool.  Second to that would be a local mining proxy that distributes the work load to multiple pools.

When bitcoins are sent to an address, they are sent using the standard pay-to-hash output script:


For the receiver to spend this output, they need to supply a scriptSig of:


And thus you see that the public key is revealed when the receiver spends the bitcoins.  Until such a time, the public key may remain unknown.