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

[Khertan]

two loop instead of 3 will increase design of 33 percen t, That's Incredible and Awesome boost ... Witch will give to my de0 nano 10mh/s instead of 6.66mh/s (at 40mhz to not fry it). that's amazing !!!


:p of course that's more for fun and to learn

[kramble]

two loop instead of 3 will increase design of 33 percen t, That's Incredible and Awesome boost ... Witch will give to my de0 nano 10mh/s instead of 6.66mh/s (at 40mhz to not fry it). that's amazing !!!

I concluded that the power consumption is pretty much proportional to the hash rate. So for example 10MHash/sec will consume the same power (and get just as hot) whether running at 50MHz or using half the resources at 100Mhz (to a first approximation anyway as faster clock should be slightly less efficient).

I've gone back to look at makomk's code (he's uploaded something recently to http://www.makomk.com/gitweb/?p=Open-Source-FPGA-Bitcoin-Miner.git;a=tree;h=refs/heads/de0-nano-usb;hb=de0-nano-usb ), so I thought I'd give it a try (swapping out his usb interface for my serial code), its still compiling after 2 hours (only just failing to route at the last attempt, just one signal short!) It will be interesting to see how fast it will run (assuming it does finish compiling!)

[fpgaminer]

I'd like to ask what optimization options need to use to achieve > 190MHz clock speed? please help me, thanks very much.

The project won't "just compile" and achieve >190MHz.  Getting timing that high requires using Xilinx's SmartXplorer to brute force it.

[Khertan]

two loop instead of 3 will increase design of 33 percen t, That's Incredible and Awesome boost ... Witch will give to my de0 nano 10mh/s instead of 6.66mh/s (at 40mhz to not fry it). that's amazing !!!

I concluded that the power consumption is pretty much proportional to the hash rate. So for example 10MHash/sec will consume the same power (and get just as hot) whether running at 50MHz or using half the resources at 100Mhz (to a first approximation anyway as faster clock should be slightly less efficient).

I've gone back to look at makomk's code (he's uploaded something recently to http://www.makomk.com/gitweb/?p=Open-Source-FPGA-Bitcoin-Miner.git;a=tree;h=refs/heads/de0-nano-usb;hb=de0-nano-usb ), so I thought I'd give it a try (swapping out his usb interface for my serial code), its still compiling after 2 hours (only just failing to route at the last attempt, just one signal short!) It will be interesting to see how fast it will run (assuming it does finish compiling!)

PowerPlay estimate less power usage to use two loop at 40mhz than 3 at 50mhz. and i think you will not be able to get more than 100mhz with two loop.

I use very aggressive fitter settings, effort multiplier of 40, that's 2hours of fitting

[xbaby]

I'd like to ask what optimization options need to use to achieve > 190MHz clock speed? please help me, thanks very much.

The project won't "just compile" and achieve >190MHz.  Getting timing that high requires using Xilinx's SmartXplorer to brute force it.

Thanks for you hint. I've already tried SmartXplorer with default 7 built-in strategies, but can't achieve above 160MHz result. so, you mean I should use the cost table method to brute force it? thanks.

[kramble]

I use very aggressive fitter settings, effort multiplier of 40, that's 2hours of fitting

Thanks for the tip, I've been using the default settings so far but I'll give the more aggressive ones a try.

Makomk's code did eventually compile (for 120MHz clock) and gave a fmax of 123MHz at 85C. This should be giving 30MHash/s, though I'm not convinced I'm seeing that in practice. Possibly the fpga is running a bit too hot, though I'm not seeing any bad hashes. I'll have to run it a bit longer to be certain.

[EDIT] Its actually working perfectly. I cranked it up to 140MHz and it seems quite stable, pushing out 35MHash/sec! Not bad at all for a DE0-Nano. Cheers makomk  

Regards
Mark

[fpgaminer]

Thanks for you hint. I've already tried SmartXplorer with default 7 built-in strategies, but can't achieve above 160MHz result. so, you mean I should use the cost table method to brute force it? thanks.

Yup.  For reference, the released bitstreams took days/weeks to compile.

[iidx]

Thanks for you hint. I've already tried SmartXplorer with default 7 built-in strategies, but can't achieve above 160MHz result. so, you mean I should use the cost table method to brute force it? thanks.

Yup.  For reference, the released bitstreams took days/weeks to compile.

xbaby,

You can also try to floorplan the DSP48s if you want to cut your runtime.  To get the boards I have with V6 130Ts to run at 300 MHz, I had to constrain each of the DSP48s, otherwise there was no chance.  This was based on the original verilog port, but I'm sure the problem with no pre-placement is the same.

[AJRGale]

I use very aggressive fitter settings, effort multiplier of 40, that's 2hours of fitting

Thanks for the tip, I've been using the default settings so far but I'll give the more aggressive ones a try.

Makomk's code did eventually compile (for 120MHz clock) and gave a fmax of 123MHz at 85C. This should be giving 30MHash/s, though I'm not convinced I'm seeing that in practice. Possibly the fpga is running a bit too hot, though I'm not seeing any bad hashes. I'll have to run it a bit longer to be certain.

[EDIT] Its actually working perfectly. I cranked it up to 140MHz and it seems quite stable, pushing out 35MHash/sec! Not bad at all for a DE0-Nano. Cheers makomk 

Regards
Mark

wow, now im in, 35MH/s = $5 a month... at max of 5W? now if i was going to replace my setup now thats pulling 200W, i need 100 of these, and that beating my 190MH/s setup! (35 x 100 = 3500MH/s!!) and thats just the DE0-nanos!!

now, wheres my $10,000...

[kramble]

wow, now im in, 35MH/s = $5 a month... at max of 5W? now if i was going to replace my setup now thats pulling 200W, i need 100 of these, and that beating my 190MH/s setup! (35 x 100 = 3500MH/s!!) and thats just the DE0-nanos!!

now, wheres my $10,000...

Yes, quite! In the 6 months I've been tinkering I've mined the glorious sum of 0.4BTC. I was sort of hoping to get up to a whole bitcoin eventually (I rather fancied one of those shiny physical coins as a keepsake), but that now seems rather forlorn.

Still, I already had the kit, which (as I explained way back up the thread), I obtained in a fit of enthusiasm for rekindling the electronics hobbyist days of my youth, and all I've invested is my time (of which I have a lot spare at the moment), and a little electricity. It was fun though, so no regrets.

Anyway, this is rather derailing fpgaminer's thread with my chattering, so I'll shut up now.

TTFN
Mark

[xbaby]

Thanks for you hint. I've already tried SmartXplorer with default 7 built-in strategies, but can't achieve above 160MHz result. so, you mean I should use the cost table method to brute force it? thanks.

Yup.  For reference, the released bitstreams took days/weeks to compile.

xbaby,

You can also try to floorplan the DSP48s if you want to cut your runtime.  To get the boards I have with V6 130Ts to run at 300 MHz, I had to constrain each of the DSP48s, otherwise there was no chance.  This was based on the original verilog port, but I'm sure the problem with no pre-placement is the same.

Hi, thanks for your tips. I'm compiling the "X6000_ztex_comm4" project, which doesn't use any DSP48 block as I know. I also successfully compiled the same project on V6 130T device (with minor fix for MMCM, FIFO, JTAG core), just achieve at most 300MHz, same as yours, but no DSP48s. the compile time of V6 device is much less than spartan6 LX150. I guess the long-route resources of virtex6 make the difference.

next, I want to try difference implement options to go higher target, such as 350MHz.

BTW the power estimation given by ISE of V6 130T @ 300MHz is about 10W. below is the resource usage:

Code:

Device Utilization Summary:

Slice Logic Utilization:
  Number of Slice Registers:                85,173 out of 160,000   53%
    Number used as Flip Flops:              85,172
    Number used as Latches:                      1
    Number used as Latch-thrus:                  0
    Number used as AND/OR logics:                0
  Number of Slice LUTs:                     57,385 out of  80,000   71%
    Number used as logic:                   34,910 out of  80,000   43%
      Number using O6 output only:          14,978
      Number using O5 output only:             539
      Number using O5 and O6:               19,393
      Number used as ROM:                        0
    Number used as Memory:                   9,759 out of  27,840   35%
      Number used as Dual Port RAM:              0
      Number used as Single Port RAM:            0
      Number used as Shift Register:         9,759
        Number using O6 output only:         9,759
        Number using O5 output only:             0
        Number using O5 and O6:                  0
    Number used exclusively as route-thrus: 12,716
      Number with same-slice register load: 12,452
      Number with same-slice carry load:       264
      Number with other load:                    0

Slice Logic Distribution:
  Number of occupied Slices:                15,859 out of  20,000   79%
  Number of LUT Flip Flop pairs used:       62,383
    Number with an unused Flip Flop:         1,382 out of  62,383    2%
    Number with an unused LUT:               4,998 out of  62,383    8%
    Number of fully used LUT-FF pairs:      56,003 out of  62,383   89%
    Number of slice register sites lost
      to control set restrictions:               0 out of 160,000    0%

[iidx]

That's really interesting, I am not familiar with the ztex projects (they don't compile in my preferred synthesis tool, synplify pro).  I would not have expected it to run on the V6 with that usage @ 300 MHz without additional pipelining.  Maybe I'll take a look at that project and see what the big difference is.

I used the old veriliog port to get to 300 MHz on mine (adding DSPs and pipelining), but the power usage is around 7W due to the use of the DSPs.

IIDX

Thanks for you hint. I've already tried SmartXplorer with default 7 built-in strategies, but can't achieve above 160MHz result. so, you mean I should use the cost table method to brute force it? thanks.

Yup.  For reference, the released bitstreams took days/weeks to compile.

xbaby,

You can also try to floorplan the DSP48s if you want to cut your runtime.  To get the boards I have with V6 130Ts to run at 300 MHz, I had to constrain each of the DSP48s, otherwise there was no chance.  This was based on the original verilog port, but I'm sure the problem with no pre-placement is the same.

Hi, thanks for your tips. I'm compiling the "X6000_ztex_comm4" project, which doesn't use any DSP48 block as I know. I also successfully compiled the same project on V6 130T device (with minor fix for MMCM, FIFO, JTAG core), just achieve at most 300MHz, same as yours, but no DSP48s. the compile time of V6 device is much less than spartan6 LX150. I guess the long-route resources of virtex6 make the difference.

next, I want to try difference implement options to go higher target, such as 350MHz.

BTW the power estimation given by ISE of V6 130T @ 300MHz is about 10W. below is the resource usage:

Code:

Device Utilization Summary:

Slice Logic Utilization:
  Number of Slice Registers:                85,173 out of 160,000   53%
    Number used as Flip Flops:              85,172
    Number used as Latches:                      1
    Number used as Latch-thrus:                  0
    Number used as AND/OR logics:                0
  Number of Slice LUTs:                     57,385 out of  80,000   71%
    Number used as logic:                   34,910 out of  80,000   43%
      Number using O6 output only:          14,978
      Number using O5 output only:             539
      Number using O5 and O6:               19,393
      Number used as ROM:                        0
    Number used as Memory:                   9,759 out of  27,840   35%
      Number used as Dual Port RAM:              0
      Number used as Single Port RAM:            0
      Number used as Shift Register:         9,759
        Number using O6 output only:         9,759
        Number using O5 output only:             0
        Number using O5 and O6:                  0
    Number used exclusively as route-thrus: 12,716
      Number with same-slice register load: 12,452
      Number with same-slice carry load:       264
      Number with other load:                    0

Slice Logic Distribution:
  Number of occupied Slices:                15,859 out of  20,000   79%
  Number of LUT Flip Flop pairs used:       62,383
    Number with an unused Flip Flop:         1,382 out of  62,383    2%
    Number with an unused LUT:               4,998 out of  62,383    8%
    Number of fully used LUT-FF pairs:      56,003 out of  62,383   89%
    Number of slice register sites lost
      to control set restrictions:               0 out of 160,000    0%

[iidx]

Oh, what speed grade did you use for the V6?  All my boards with 130s and 240s (ml605) are -1, so if you used -3 that could explain the big difference in the quality of the results.

[xbaby]

Oh, what speed grade did you use for the V6?  All my boards with 130s and 240s (ml605) are -1, so if you used -3 that could explain the big difference in the quality of the results.

my board have 2 pcs 130T devices. the speed grade is -2I. so your design with DSP48s really have some speed and power usage advantage. BTW, can your design be synthesized on XST?

[iidx]

Possibly, but I used some compiler directives to force SRLs and registers in certain situations so the design would fit.  In XST it infers too many of register or SRL to properly fit, so some manual instantiation might be required.

I'm still surprised that the Ztex project would hit 300 Mhz without extra pipeline stages.  I think that it might be better to add DSPs to that project instead?

[xbaby]

the 300MHz result was just compiled with no timing error. in next few days, I'll program it on board to see if it could really run perfectly.

[senseless]

I've been asked a few times about a mining script for the current KC705 firmware.  I wrote a plugin for Modular Python Bitcoin Miner.  Here's the message I sent to someone about it:

I uploaded the custom MBPM module, which is compatible with the current KC705 mining code, here:
https://mega.co.nz/#!Oh5HTDRB!C0RLYW4yZN8gbg38FfgLpzmKFcseOql3Xx1i_gXTfdM

You'll want to download a copy of MPBM's testing branch.  Then extract the above archive into
Code:
modules/fpgamining
such that you end up with:

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

Once you start MPBM, you can now add a KC705 Worker by openning up the MPBM web-interface (http://127.0.0.1:8832) and clicking the "Workers" button on the left.  On Windows, I ran MPBM under Cygwin, and the "Port" ended up being /dev/com2 for me.  The Baudrate is 115200.

~fpgaminer

I haven't had a chance to clean it up and put it on the repo yet.

Have you tested the code on windows? Having a hell of a time trying to get mining. Tried as best I could without knowing python to get it running without much success. First was getting a ton of indentation errors. PyWin editor was telling me 1/2 the code was not idented properly. Think I fixed those successfully; now getting the following errors. Any idea?

I was thinking it was a result of my python setup in windows [since another user was able to get it running under linux on the VC707]. Tried 3.3 and 3.2 with same errors on both.

Code:

2013-05-11 00:10:32.222	[100]	KC705: 	Traceback (most recent call last):
  File "c:\FPGA Work\Scripts\mpm\modules\fpgamining\kc705_uart\kc705uartworker.py", line 201, in main
    self._sendjob(job)
  File "c:\FPGA Work\Scripts\mpm\modules\fpgamining\kc705_uart\kc705uartworker.py", line 391, in _sendjob
    self.handle.write(job.data[64:76].encode('hex') + job.midstate.encode('hex') + "\n")
AttributeError: 'bytes' object has no attribute 'encode'

2013-05-11 00:10:32.223	[100]	KC705: 	Traceback (most recent call last):
  File "c:\FPGA Work\Scripts\mpm\modules\fpgamining\kc705_uart\kc705uartworker.py", line 323, in _listener
    data_buffer += self.handle.read(9)
TypeError: Can't convert 'bytes' object to str implicitly

When running the code default without changing any of the indentations I get:

Code:

2013-05-11 00:41:46.872	[300]	Core: 	Could not load module fpgamining.kc705_uart: Traceback (most recent call last):
  File "c:\FPGA Work\Scripts\mpm\core\core.py", line 108, in __init__
    module = getattr(__import__("modules.%s" % maintainer, globals(), locals(), [module], 0), module)
  File "c:\FPGA Work\Scripts\mpm\modules\fpgamining\kc705_uart\__init__.py", line 1, in <module>
    from .kc705uartworker import KC705UARTWorker
  File "c:\FPGA Work\Scripts\mpm\modules\fpgamining\kc705_uart\kc705uartworker.py", line 324
    if '\n' not in data_buffer: continue
                                       ^
TabError: inconsistent use of tabs and spaces in indentation

[fpgaminer]

Have you tested the code on windows? Having a hell of a time trying to get mining.

Weird.  I have tested it on Cygwin, using Python 2.7.  Maybe Python 3 doesn't like the code?

[senseless]

Have you tested the code on windows? Having a hell of a time trying to get mining.

Weird.  I have tested it on Cygwin, using Python 2.7.  Maybe Python 3 doesn't like the code?

Working perfectly under cygwin with py 2.7, thank you.

[fizzisist]

There are a few tabs mixed in there. That should cause problems on some systems: lines 324, 331, 333, 334, 338. The 'bytes' issues are definitely due to using python3: http://docs.python.org/3.0/whatsnew/3.0.html#text-vs-data-instead-of-unicode-vs-8-bit

Should be easy enough to fix that up, though. Throw the code up on github and I'm sure someone will do it.