Topic: Official Open Source FPGA Bitcoin Miner (Last Update: April 14th, 2013) - page 2. (Read 432891 times)
August 29, 2013, 05:37:33 AM
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).
August 29, 2013, 04:07:09 AM
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?
August 29, 2013, 03:55:56 AM
Lookin' good; congrats! The average should crawl to 400 MH/s over time.
August 29, 2013, 03:36:45 AM
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?
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?
August 29, 2013, 03:26:38 AM
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?
August 29, 2013, 02:32:37 AM
Quote
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? August 29, 2013, 12:14:01 AM
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.
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.
August 28, 2013, 11:22:58 PM
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.
August 28, 2013, 10:03:37 PM
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.
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.
August 20, 2013, 11:25:45 AM
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
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
August 17, 2013, 06:06:53 AM
PS Did you go on the Arrow course to get hold of that board. At $99 it was an absolute bargain
Exactly.
August 17, 2013, 05:02:28 AM
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.
August 17, 2013, 03:18:23 AM
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.
August 16, 2013, 07:09:18 PM
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).
August 16, 2013, 06:51:20 PM
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.
August 16, 2013, 06:20:47 PM
Did the student project include networking SW for mining on the embedded ARM CPU?
They solo mined using bitcoind ...
Quote
Testing Bitcoind was a simple matter. We ran the daemon, waited for the sizable block chain to download and then used the line command to start Bitcoind’s built-in CPU mining software
...
The final component of our system is a small relay program to pass work from Bitcoind to the mining core through the driver, and return results
...
The final component of our system is a small relay program to pass work from Bitcoind to the mining core through the driver, and return results
As I said earlier, student project showing off the features of the zedboard. Not really relevant to actually using it for real mining.
PS Terasic/Arrow/Rocket's new SoCKit board looks to be a very interesting competitor to the zedboard. Altera Cyclone V 85kLE plus dual core A9. $249
August 16, 2013, 06:13:19 PM
Did the student project include networking SW for mining on the embedded ARM CPU?
July 29, 2013, 01:56:31 AM
High Level Synthesis? I had to look the acronym up, I rather liked Hysterical Laughter Syndrome myself
Yes. The code shown in the table uses C syntax. Not being a fan of C based synthesis I liked your definition better too
July 28, 2013, 09:38:53 AM
Seems like it was more an exercise in HLS rather than creating a more optimal implementation.
High Level Synthesis? I had to look the acronym up, I rather liked Hysterical Laughter Syndrome myself
I probably came over too critical. Its a student project after all, so I shouldn't be too hard on them. The entire issue of the magazine was pretty much devoted to the Zedboard (it is a Xlinx in house publication), and it takes more than just the mining core get get a working system running on one of those. Anyway I'm going to look up some more issues of the mag, should be some nice reading material to keep me occupied.
July 28, 2013, 09:25:43 AM
Seems like it was more an exercise in HLS rather than creating a more optimal implementation.
Jump to: