I did not look at the code but maybe you can clarify to me how this particular approach scales; As mentioned, it scales linearly, but only in integer multiples. So an 80K device can get 80MH/s. A 160K device can get 160MH/s. A 240K device can get 240MH/s. But no in-between. At least, not without a different design. Note that, the design in the repo is not optimized and so uses something like 90K LEs. An optimized design fitting into at least 80K will be released once I've finished it. Correct. The EP4SGX230 flavor would get at least 160MH/s. The EP4SGX530 would get at least 480 MH/s. I say "at least" because as far as I understand the Stratix series of devices have better timing than the Cyclone series, and so will support a much faster clock. If they are, for example, twice as fast then you can expect 960MH/s out of the EP4SGX530. However, I don't know for sure what clock rate they can achieve with the mining core. In the FPGA though, you have to implement something to comunicate with bitcoind and, if using multiple devices, communicate with each one of them, right? The FPGA requires a controller, and so is really just a dumb processor like the GPU. It performs the hashing algorithm, and that's about it. Like a GPU, there is a small memory space inside the FPGA that a controller must write the work to (through some external interface like SPI), and a memory space where results (valid hashes) must be read from. The controller gives the FPGA a 256-bit Midstate, and 512-bit Data (which are acquired through a getwork request from bitcoind or a mining pool). The FPGA then proceeds to process all 2^32 variations and return any nonces that result in a valid hash. In that sense, it's exactly like a GPU where you give it data, and tell it to run 2^32 instances of the kernel. The controller can be anything. A microcontroller like an Arduino, a microprocessor like an ARM, or even an entire PC like the one you're reading this post on  How would one scale this to multiple FPGAs? Some communication between devices would be needed, or will there be a full TCPIP stack communitcation with bitcoin on each one? As said there are many approaches. One approach is to have the controller make a getwork request for each FPGA, so each FPGA gets its own data to work on and cycle through 2^32 times. This has the benefit of scaling easily, and not requiring traces on the board between the FPGAs (which would need to support high frequency data transfers). The FPGAs can just be put on a single bus, like I2C or SPI, and controlled by a single microcontroller or microprocessor (possibly embedded in one of the FPGAs). |
|
|
|
|
Are you part of a pool? Some pools send their payouts with the block that gets generated, so it shows up in everyone's client as Generated.
|
|
|
|
Yeah you can get some cheap FPGA boards no problem. Terasic sells the DE0-Nano board for $79USD, or $59 if you're a student. That's for a 22K LUT device, which is pretty darn good for the price! I'd respect you if you got 1 MH/s out of it. You can get 1 MH/s out of it no problem. |
|
|
|
A Spartan 3E 250K has 5508 logic cells. If I understand correctly, this is not enough for a design that needs 90K LUTs, though I'm still learning about all of this. I'll try to put my serial design online as well. That fits into 3K or 4K I think, although it's obviously much slower (64 cycles per hash). It's a nice toy for people to play with if they have smaller boards. |
|
|
|
First off, many, many thanks to the person who made a donation while I was asleep. I'm assuming it was because of this project? Either way, you have my gratitude! It makes me feel that my efforts on this project are appreciated.  just a optimision, from a noob: kokjo, thank you for your suggestion! I appreciate all feedback on this project. is it possible in sha256_transform.v to remove the generate loop, and replace it with some sort of pipelining instead That is indeed what the Verilog compiler does with a generate loop. It unfolds the loop, replicating the logic. So that sha256_transform module actually contains 64 instances of sha256_digester. btw is it transmiting all the hash, if it is, wouldnt it be better to transmit a signal if the H was 0? Hello ktion23. Thank you for your feedback and interest! It only transmits hashes where H is 0. In fpgaminer_top, this is the code that accomplishes that: is_golden_ticket <= hash2[255:224] == 32'h00000000;
old_golden_ticket <= is_golden_ticket;
if(is_golden_ticket && !old_golden_ticket)
begin
golden_nonce <= nonce;
end
Speaking of which, I need to clean that up a little bit. old_golden_ticket isn't necessary at all. I'll go do that now ... EDIT: On a more personal note, this past week has been pretty rough. Some bad mojo going around the company I work for, which is always stressful. But seeing this interest in the project, feedback, and that donation this morning have made be feel a lot better. So ... simply, thank you! |
|
|
|
Maybe this will get someone closer to a full implementation. A full implementation exists: http://forum.bitcoin.org/index.php?topic=9047.0https://github.com/progranism/Open-Source-FPGA-Bitcoin-MinerIt's fully functional, ready to go. There's even a binary release, which is pretty easy to use. I wrote scripts to program and control the board, so you don't even need to know how an FPGA works to use this. I guess it doesn't meet the bounty, though  Because of this Either of the above devices must cost no more than $0.60 USD per megahash per second that they provide, and must consume no more than 0.3 watts per megahash. It easily meets the Watts per MH/s requirement. I measured 8Watts at the wall for the 50 MH/s design and that's with a dev kit! But it obviously doesn't even come close to the $0.60 USD per MH/s requirement. But I will continue to work and improve on it. The $0.60 USD requirement is insane, but so am I! |
|
|
|
Do you have any data from Altera's tool chain on what % of the hardware units you used? (perhaps it could fit into a smaller device?) This version uses ~90K LUTs. I have a more optimized version in the works (<80K LUTs), but it's still being tested and tweaked. |
|
|
|
The Open Source FPGA Bitcoin Minerhttps://github.com/fpgaminer/Open-Source-FPGA-Bitcoin-MinerKintex 7 K325T Maximum Performance: 400 MH/sCyclone 4 C75 Maximum Performance: 109 MH/sSpartan-6 LX150 Maximum Performance: 100 MH/sList of FPGA Performance per device and configurationNote: The included configuration (for Cyclone 4), and source code, downclocks the chip to 50MH/s. 109MH/s requires cooling, and I didn't want to release something that would burn up your valuable chips.This includes a pre-synthesized configuration file, ready to be loaded onto a DE2-115. The README.md includes easy instructions on how to load that into your FPGA and get up and running. Please feel free to give me feedback, suggestions, critiques, and of course to submit Pull requests.  Compatible Board (and only purchase currently required): Terasic DE2-115 Development BoardNote: This is not the only supported FPGA board, but it is the only board with mining binaries and instructions currently available. The software can be manually compiled for many different chips (Altera and Xilinx) and boards. More pre-built binaries and instructions will be made available as time allows.News and UpdatesJune 2nd, 2011 - Flexible Unrolling AddedThanks to the patch submitted by Udif, the code now supports a configurable amount of loop unrolling. The original design was fully unrolled, with 128 total round modules. By adjusting the CONFIG_LOOP_LOG2 Verilog define, you can choose to unroll to 64 round modules, 32, 16, 8, or 4. This makes the design smaller, at the equivalent cost of speed, which should allow it to run on many more FPGAs. If you're interested in trying the code on a smaller FPGA, open the projects/DE2_115_Unoptimized_Pipelined project in Quartus. Then go to Assignments->Settings->Analysis & Synthesis Settings->Verilog HDL Input. You should see a CONFIG_LOOP_LOG2 macro setting, which you can set from 0 to 5. 0 gives full unrolling (largest, fastest), and 5 gives the smallest design. You will also need to go to Assignments->Device and choose your FPGA, and set the correct clock pin in Assignments->Pin Planner. Then just compile and program! June 12th, 2011 - Xilinx and VHDL Ports AddedWith many thanks to TheSeven and teknohog, their code has been added to the public repo. TheSeven did a re-implementation in VHDL, with support for Xilinx and ISE. teknohog did a straight port of the Verilog code to simply support Xilinx and ISE. Both include Python miner control scripts, and serial port communication with the FPGA board. I made little to no modification to their code for this first commit. If you appreciate their hard work on this Open Source project, please send them your thanks and donations! TheSeven: 14Jc8vWq1mPv7vWnP5VquZZgpLEtzW2vja teknohog: 1HkL2iLLQe3KJuNCgKPc8ViZs83NJyyQDM July 17th, 2011 - Code Updates and Minor Cleanupteknohog's Xilinx Verilog port on the public repo has been updated. teknohog's serial modifications to makomk's code have been added as a separate project. OrphanedGland's port to Stratix devices, using VHDL, has been merged into the public repo. To top it all off, I updated the project's main README.md file, to prominently include a list of contributors and their donation addresses, because they deserve recognition for their hard work. I will modify the first post in this thread to include the same list As it wasn't mentioned before on the first post, I am mentioning here that makomk made improvements to my base Verilog code. These changes improved both the overall performance of the design, and its area consumption, allowing the design to fit on a smaller, cheaper EP4CE75 chip. Great work makomk! August 8th, 2011 - Spartan-6 Code Added and Working, Altera Mining Script UpdatedThanks to the efforts of makomk, the Spartan-6 series of chips are now supported, and achieve the highest performance per $ of any chip. Code has been verified working on my LX150 development kit, and can achieve up to 100MH/s of performance. The Altera Tcl Mining Script has just received a massive update. No more need to edit mine.tcl to hack in your FPGA's hardware and device names; mine.tcl will automatically detect mining FPGAs connected to the system. Pool information has been moved to a config.tcl file for easy editing. No more dependency on TclCurl, so the script should be Linux friendly now. And best of all, the console output has been cleaned up to look like poclbm.  April 14th, 2013 - Kintex-7 Code Added and Working, Using The New DSP48E1 DesignI 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. ContributorsThese fellows have contributed to this Open Source project in various ways, and deserve recognition. If you appreciate their hard work on this Open Source project, please send them your thanks and donations! Not listed in any particular order.teknohog - 1HkL2iLLQe3KJuNCgKPc8ViZs83NJyyQDM OrphanedGland - 1PioyqqFWXbKryxysGqoq5XAu9MTRANCEP udifTheSeven - 14Jc8vWq1mPv7vWnP5VquZZgpLEtzW2vja makomk - 15XX7BhQcZFUg47S4VKyiLygPTHTs9234J newMeat1 - 1LbqTCA1cnpbbdKbXzZZfHYMe7teiczQc2 NOTE: If you've contributed to the project, and are not listed here, or your donation address is not listed, please contact me. I do my best to keep track of everyone, but I'm only human.-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 May 19th, 2011 First official release of the Open Source FPGA Bitcoin Miner. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) iQIcBAEBAgAGBQJN1dF/AAoJEFFoGj2A5YKRl/IP/2pMRqNZ0R+Z5WTG/v9DyafJ YChUTSW8Tc1su99hJWe4pXtVH3p/zsn6spy73DaTeGjHvjxlDAuRU/qq3ax5RdGG e5DsUb9fRFVnkpFDjIqsHQLAeQxwgRC28JsFNXP0ow986wwnZwRIBMx6xykVUYIx /ImV4Y/vbc92nMclsItuF2NCFtYcravbP6NsbYuhMGORIqTkTNUuczP2weRw9C9H 10ThsCpfDD2OgNrL3kDy2SSlOkMekpTTlkin5P2ax6vZUE/2o3ZaZW9ORGLYnM85 8VX2NfyKwstvIrPoyHuYAxQYyFB8FLDoyqbkBSdxR/xlv8lR1i9OzCfeEmXQGbOr yUk96JIoQIZ9TDuVlpMtIv7lYudiMLQ/6cgc1BrHoCiyotNDdI3zFAVsMZe7iTk0 zFHu1dbK3I8IzE+U8U5YLIBQZKALAdQ8yv+1ZytcJOOOdbNv8t20epmh01LxeHRw 1Mqmhxt7Nj+Dx+0UgYPH+05FshREYxS9nI0CPF0e3Bvae+0Dre++qxWITWkfHUtP 9hWVn55GvJyLotQOesFHhCy1TrL43VNw/3+fh1H2crbQ2GY0d+j0Fo4V1srEQFY2 nJAjw4c5mRH+MoFcvtts/Cj4xAeIdLTJ66j61unBhmV4EjlJd6NNdhx299CaIrSr UcXsHTrfpCUvNdQOChB/ =HGQa -----END PGP SIGNATURE-----
|
|
|
|
So true, i guess the problem is, 1 i don't have enough cash to buy a decent fpga, 2 i would struggle to set it up, but your right perhaps someone will be kind enough to produce a step by step guide on how to build one. If you buy a Cyclone 4 dev kit right now ($600USD), I can give you software to have it up and mining with just a few clicks. Seriously. The only reason I haven't made that software public is because I don't think anyone is crazy enough to spend $600 for a measly 50 or 80 MH/s |
|
|
|
Yes, I got the one from Avnet. The Xilinx Spartan-6 LX150T-3 has a PCI-e connector, does that mean it has to be mounted in a computer for comms and power? It's just a comm link, like the 20 some odd other interfaces on the bloody thing It has its own power supply and can run just fine without a computer. Having read through the post concerning bitcoin mining with fpgas here I wonder whether the DSP48A1 slice in the newer Spartan-6 can be put to good use, since it has a nice adder. Oh hey, I forgot about those! Thank you for reminding me  Yeah, I have an old Spartan-3E as well, and it indeed only has multipliers But now that I have my LX150 I will certainly give these shiny new DSP48A1 slices a try. I'm skimming the datasheet now, but from a first glance it looks like it only handles 18-bits. Two will have to be strung together to achieve 32-bit. That means 90 "free" adds on the LX150. Not much, but anything is helpful. Do you have plans to release it? Yes |
|
|
|
yeah well we just get the fpga to manage the arrays Neat idea! An FPGA driven board, with PCI-e controllers and an ARM core in the FPGA. You could then run ribbon cable to quite a number of video cards, depending on how many PCI-e cores fit into the FPGA. Luckily we only need PCI-e 1x, which seems do-able with an FPGA. My back of the napkins calculations couldn't justify the price, though. Perhaps for large mining farms. The majority of GPU mining cost comes from the cards and PSUs. Such a solution would only cut out the motherboard, CPU, and RAM, which really aren't that much. Not to mention how difficult it would be to get fglrx drivers running on such a stripped down system. What we really need to do is buy the GPU processors in bulk directly from AMD and build massive GPU array boards EDIT: FPGAMiner, what else would explain the difficulty jump? Personally, I don't find the difficulty jump surprising. But to answer your question, it was the recent spikes in the market price, compounded by the naturally growing number of miners. Newcomers see the market skyrocketing like that and they all start firing up the machines they have lying around. We've gotten lots of new traffic over the past week or two from Slashdot, Reddit, and I think an article or two. I know I just brought on an extra 3GH/s online this past week or so. Also take a look at how many posts we have about people trying to get their new rigs up and running, or looking to buy one. To be honest, the difficulty increase isn't that bad. It's quite appropriate for the market price, which jumped from ~$3-$4 all the way up to $10 not too long ago. Regardless of the difficulty increase I'm going to break-even on my hardware in a timely fashion just as I had hoped. Probably before schedule! EDIT2: Almost forgot! The phatk kernel was released shortly after the difficulty jump before last (jump to 157K). This increased everyone's performance by 10MH/s or so. That was about a 3% increase for most people, which most certainly contributed to this larger difficulty increase. |
|
|
|
It won't let me withdraw anything. I click withdraw and it just goes back to the homepage without sending anything (I checked my wallet, and it also continues to list the balance). er no currently it is 589.64331461 Oops! Guess my client was a little out of date. It was 290 a few days ago Those were happy times ... Actually 589 still isn't that bad either. |
|
|
|
whats the namecoin difficulty looking like these days It's currently 290. I solo mined on my old nVidia (50MH/s) and got 3 blocks overnight.  |
|
|
|
I think someone has succeeded in fpga/asic bitcoin flooding That seems to be a common misconception present in this thread. FPGAs aren't powerful. They're actually quite inefficient and slow Read ArtForz's posts for a good breakdown and debunking. Someone with free access to a huge stack of FPGAs isn't any better off than someone who has free access to a huge array of GPUs, as far as hashing power is concerned. As for an ASIC, I highly doubt anyone is foolish enough to drop >$1,000,000 of their own cash to have developed one. Also, it takes a long time from start to finish. Bitcoins weren't all that popular a year ago. They still aren't (outside of our little bubble). Suppose someone was foolish enough to do so. Well, sucks for them. Good luck getting $1,000,000 out of the Bitcoin market right now. The only feasible profit would be from selling them and spreading the risk to the customers. I post occasional updates on my progress with FPGA mining in this thread. If I succeed in making FPGA mining feasible, I fully intend to release a product. I also still have on my TODO list the release of an FPGA Mining Reference Design, open-source. I hope this helps clear out the mis-information and fear. As always, I am happy to answer questions about my project, FPGA mining, and FPGAs in general. It's an exciting topic for me and I hope my knowledge can be of some use to the community. |
|
|
|
It has been a little while since I submitted an update on my progress, so here we go. Area Improvement: <80K LUTs for 80MH/sI recently did another round of area optimization on one of my designs. As I suspected, it now successfully fits on a Cyclone3 C80 device. This is the 80MH/s design, so it achieves the theoretical 1MH/s = 1K LUT numbers that I had on the back of my napkin. The next step is to synthesize for a Cyclone4 C75 device, which might be a very tight fit. The Cyclone 4s are a bit cheaper and use slightly less power. Also, if it does fit into 75K LUTs, then it is likely that two of the same design will fit into a C150. That would achieve a total of 160MHash/s. New Parts Coming InI have a Xilinx Spartan-6 LX150T-3 development board coming in soon. My goal here is to achieve 160MHash/s on this single chip. Estimates predict that it will be possible, but may be very difficult. We shall see. Goals: Achieve 160MHash/s on a Spartan-6 LX150-3, which is a sub-$200 chip. That's $1.25USD per MH/s. The average cost of a complete GPU mining rig is $1 USD per MH/s. This goal would bring me very close to achieving GPU parity, and it most certainly will continue to exceed GPUs in power and temperature performance. I also ordered an Ethernet module and hope to use it to make the FPGA miner completely independent. Plug and profit! Power Consumption MeasuredI now have a Kill-a-Watt, which measures the amount of electricity drawn "at the wall" by any device. Using this, I measured the "at the wall" power consumption of my Cyclone-4 50MHash/s design. It was 8Watts. Quite impressive, considering that this is for the entire development kit and power inefficiency of the power supplies. Also, the Cyclone-4 required no cooling. No fan, no heat sink. It chugged along happily. Unlike my noisy mining rigs... |
|
|
|
Thank you for sharing this! I'm gonna poke at it later today and see if I can get it working  Just got my little multitail setup working last night, so this will be another nice improvement. |
|
|
|
I wanted a way to monitor my miners, even when mining solo. So I did this:  Courtesy of a small phoenix modification, SSH, and multitail. Now I can monitor every single miner and keep tabs on them. I also have a script that dumps all the GPU temperatures, so I can check that regularly. Hooray for Linux! |
|
|
|
Very nice! |
|
|
|
I have Sapphire Radeon 5850's from TigerDirect. Three to a rig. See my post here.They are right next to each other, as you propose, and after tweaking the setup they run just fine, <70C. To summarize here: Move the PSU away from the cards if you have a case that puts them close. If you're caseless, well, no worries! Use some non-conductive material to spread the cards apart at the back (behind the fan, making sure not to block the fan!). This will allow more air to flow into the middle card(s). Folded paper, cardboard, or plastic. Drop the memory clock to 300MHz or lower. If you have a case, make sure to put some fans on the side panel blowing on the cards. EDIT: I've tested 850/285 on one rig and she runs fine. In fact, that's on the rig that isn't even setup correctly (PSU is too close and no spacers on the cards). |
|
|
|
|
I am very interested in this! Haven't had the time to play with it yet, but I appreciate your work! *HIGH FIVE*
|
|
|
|
|
Show Posts
