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

[kingcoin]

OK. Thanks. So they just wrote a small driver then. Did anybody port bfgminer or similar to Zync or Altera SoC? I know it has been done for the RPi, but it would be fun to try to use the low latency FPGA fabric to ARM interconnect.

I guess it should be easy enough (having absolutely no experience with the FPGA/SoC combination myself so just guessing), its just linux running on ARM. The difficult part is the drivers since much of the peripherals will be implemented in or via the FPGA, but there must be demo code written.

Fun to use the low latency path, irrelevant to mining though (my "low latency" path from my RPi to my DE0-Nano runs at 4800 baud! I get the occasional collision (I've got four devices sharing the same serial port wire-or style), but hardly enough to worry about).

That's right. A miner is not very sensitive to bandwidth or latency. It's more for the fun part of learning more about the ARM subsystem as I have an Altera SoC board. But I've been playing mostly with the FPGA fabric part. The only software that I've done on it has been limited to flashing the LED's connected to the FPGA fabric, but at least my Linux based cross compilation is working as I'm not a big fan of Eclipse.

It's been a while since I looked at the RTL code and the TCL scripts, but I seem to remember that the work/nonce exchange was single threaded so that after you have read the nonce you will then read the next work (correct me if I'm wrong). Hence, the latency to fetch the next work will cause your hash core to be idle until it's received by the hash core. It's minimal and the software latency it probably larger, so it's better to solve the problem at the architecture level and make sure you pre-fetch work into a buffer so you can simply switch a mux or enable a register to get the next work and start the next iteration.

[kramble]

It's been a while since I looked at the RTL code and the TCL scripts, but I seem to remember that the work/nonce exchange was single threaded so that after you have read the nonce you will then read the next work (correct me if I'm wrong). Hence, the latency to fetch the next work will cause your hash core to be idle until it's received by the hash core. It's minimal and the software latency it probably larger, so it's better to solve the problem at the architecture level and make sure you pre-fetch work into a buffer so you can simply switch a mux or enable a register to get the next work and start the next iteration.

Yeah, I found that mistake fairly early on. My mining driver (written in my very idiosyncratic style of C, professional coders look away now), holds a stack of the three most recent getworks and compares the received nonces against each of them to check for valid hashes. Its surprisingly common to find a golden nonce that does not match the current work, but does match the previous one. But then my serial interface runs at 4800 baud so its probably much less common at 115200 baud (the reason I run so slow is that I used an opto-coupler to interface my RPi to DE0-Nano, just to be safe, and my first bash at the circuit was pretty slow, but it worked so I've never bothered to improve on it   )

What's worse is that ngzhang's icarus code (see his github) actually puts the mining core to sleep once its found a nonce. This is insane. You only do that if you found a block not a share. So all those icarus/lancelots and clones are running with non-optimal firmware.

PS Did you go on the Arrow course to get hold of that board. At $99 it was an absolute bargain, I wish I'd found out about it earlier (like in time to book on one), though I guess they would not be local enough to me (UK) to be practicable.

[kingcoin]

PS Did you go on the Arrow course to get hold of that board. At $99 it was an absolute bargain

Exactly.

[BlueDragon747]

Hi Guys,

just wanted to say thank you for hard work everyone has put into this project and the forks especially:-

fpgaminer
kramble  
progranism
teknohog
makomk
pmumby

and anyone else who has contributed to the code/projects

without you guys I would have not taken to fpga anywhere near as fast, in the near future I hope to be able to contribute by porting in the bitfury code to the Lancelot dev board which I currently have building @ 270MHz per core but I only have a test case working atm so work in progress

Thanks also go out to bitfury for releasing his source code for spartan-6 

I have also done the basic built of kramble litecoin fpga icarus project which is reports to have a max 194MHz but have only tried to add more local miner cores per fpga 2 > 8 with halfram but it is having more trouble routing atm so more work in progress

Best Regards
BlueDragon747

[hyphenx]

Hi,

I just received my Kintex 7 Evaluation board, having a play around, I believe I managed to flash the KC705 project to the board. However I am unsure how to connect this with CGMiner or any other mining software.
Could anyone please provide some assistance?

Thanks.

[fpgaminer]

I just received my Kintex 7 Evaluation board, having a play around, I believe I managed to flash the KC705 project to the board. However I am unsure how to connect this with CGMiner or any other mining software.

First thing you'll want to do is make sure the KC705's UART-USB is connected to your computer.  Open its com port, 115200 baud, and make sure you see hex values being dumped out at a regular interval (4 seconds).  Those are temperature readings coming from the firmware.

Once that's good, you can get a modified MPBM up and running to mine using the KC705.  goxed made a quick checklist to follow.

Yeah, it's not well documented; sorry about that.

without you guys I would have not taken to fpga anywhere near as fast

You are most welcome, BlueDragon747.  I am glad to see that the project has helped you taste the wonders of FPGA development

On a related note, I've been tossing around the idea of buying a DE0-Nano board for myself, and developing a well documented subset of the code, and tutorial around it.  The tutorial would be aimed at teaching the basics of the Bitcoin mining algorithm, and implementation on FPGAs.  Since the DE0-Nano is cheap, I think it would make a great starter project for anyone new to FPGAs.

I've been tossing the idea around, because profitable FPGA based mining is more-or-less dead.  But I would like this project to remain a healthy source of knowledge and inspiration for others.

[hyphenx]

thanks, hopefully in time I will be able to make my own contributions to the project.
Turns out I hadn't programmed it, but I've got it programmed now
Just need to get this python sorted out and hopefully I will have it hashing away

EDIT: Copied files to

modules/fpgamining/kc705_uart/__init__.py
modules/fpgamining/kc705_uart/kc705uartworker.py

Ran MPBM using python (not entirely sure with using cygwin, but downloading atm). The web interface opens ok however I cannot see KC705 in the list of workers.
Tried changing from COM2 to COM1, can see hex values when I open COM1 in putty.

[fpgaminer]

The web interface opens ok however I cannot see KC705 in the list of workers.

It won't be automatically detected; did you add a worker instance for the KC705 using the web ui?

[kramble]

On a related note, I've been tossing around the idea of buying a DE0-Nano board for myself, and developing a well documented subset of the code, and tutorial around it.  The tutorial would be aimed at teaching the basics of the Bitcoin mining algorithm, and implementation on FPGAs.  Since the DE0-Nano is cheap, I think it would make a great starter project for anyone new to FPGAs.

Its a very nice introductory board, but watch the regulator chip temperatures if you run the clock speed up. They can run hot even when powered by USB (nominally 500mA, but it will try to draw more, the blue led goes dim which is a good indicator of this). If you attach an external power supply they can get very hot. There is thermal shutdown (at 175C die temp!!), but you really do not want to push them this far (see my conversation with hardcore-fs way up thread).

PS You may want to amend the pool details in the default mining config file. Eleuthria is about to turn off the getwork server on BTCGuild. Perhaps add a note on using a stratum proxy server?

[hyphenx]

By gosh, I think I done it.
Once python was running in cygwin it seemed to recognise the KC705 worker module.
Installed pyserial the same way and away she goes.
https://i.imgur.com/yeJRkMV.jpg
Average is at about 220 now. How's it look?

[fpgaminer]

Lookin' good; congrats!  The average should crawl to 400 MH/s over time.

[hyphenx]

Thanks! I'm up to 305 now. At what point will the fan turn on? Or is it something I should add into the code?

[fpgaminer]

If I recall correctly, the fan on my KC705 was always running.  Perhaps yours isn't connected properly, a jumper is set incorrectly, or ... something else (I vaguely recall the FPGA being able to control it, but my firmware doesn't touch the fan).

[hyphenx]

I'll have to grab my multimeter and see. Is 400Mh/s really the fastest this can pull? I saw a post from goxed somewhere stating 1Gh/s. Other documentation suggests 825Mh/s.
Is this set by the hashing clock multiplier clk_out1?

EDIT: Fan hadn't been connected correctly by the factory
EDIT2: This thing is so much fun!!!! Testing different config's now to see how much I can hash.

[curseddagger]

I'm just getting into bitcoin mining for fun and have a Xilinx KC705 FPGA dev board at my disposal. I currently have it running at 400MH/s with the open source bitcoin mining software. I have seen on this forum a few people have it running at 600MH/s and so i'm wondering where i can find a bitfile or project to get it running at that speed.

[goxed]

I'm just getting into bitcoin mining for fun and have a Xilinx KC705 FPGA dev board at my disposal. I currently have it running at 400MH/s with the open source bitcoin mining software. I have seen on this forum a few people have it running at 600MH/s and so i'm wondering where i can find a bitfile or project to get it running at that speed.

https://mega.co.nz/#!bFwDib6S!UphPVlo-qi0qKViE8Kcr9hs-FjJBZaDocTlifIGl8D8

[curseddagger]

https://mega.co.nz/#!bFwDib6S!UphPVlo-qi0qKViE8Kcr9hs-FjJBZaDocTlifIGl8D8

Thanks Goxed!!

Do you have any idea what was changed in the project to get it to build and meet timing?

Cheers again!

[hyphenx]

https://mega.co.nz/#!bFwDib6S!UphPVlo-qi0qKViE8Kcr9hs-FjJBZaDocTlifIGl8D8

Thanks Goxed!!

Do you have any idea what was changed in the project to get it to build and meet timing?

Cheers again!

Not sure about everyone else, but I was able to achieve this by increasing the clock speed.

[curseddagger]

Not sure about everyone else, but I was able to achieve this by increasing the clock speed.

If i download the fresh project from github and open it, change the clock to 600 and build, it fails timing by heaps.

[hyphenx]

What's your effective MH's with a fresh project?