Given the tiny returns from mining on the Nano, my opinion was that its not worth risking the boards at the higher speeds. I'm happy with my current setup (as described above) as nothing is getting above 60C, but its your call on your own stuff.

RegardsMark

I've tryed to fit a 2 loop with a 32 hasher, this could be fit in a DE0 Nano, after some auto magic Quartus Area optimization, but with a far less fmax (120Mhz).That s fit with only few 1xx lut free

Unfortunatly i mess up the things, as trying to convert things to two loop i break something in the cnt or feedback ...

I've tryed to fit a 2 loop with a 32 hasher, this could be fit in a DE0 Nano, after some auto magic Quartus Area optimization, but with a far less fmax (120Mhz).That s fit with only few 1xx lut free

Unfortunatly i mess up the things, as trying to convert things to two loop i break something in the cnt or feedback ...

I was not able to get the LOOP_LOG2=2 code to fit myself but makomk achieved 27.5MH/s on a Nano (https://bitcointalk.org/index.php?topic=74749.msg847182#msg847182 (EDIT updated to a better link)), so I guess that with some expert tweaking it does indeed work. I decided to go a different route and try to fit 22 hashers (which nicely gives 66 stages in three rounds, so just discarding the last two to give the 64 needed) using a variant of sha256_transform from makomk's github (since the makomk branch in the official distribution does not work unless LOOP_LOG2=1). It did take a fair bit of tinkering in the simulator to get the timing right (and I ended up discarding makomk's pipelining of the K values since it was too confusing, so there is an opportunity for some further gain by putting it back in).

Interestingly this 66 round core generalized quite well as I was able to use it on a EP4CE10 as 6 rounds of 11 hashers and on an LX9 as 11 rounds of 6 hashers (rather disappointing utilization, but I'm even more of a novice at Xilinx ISE as I am at Quartus). Anyway this was just playing around for the sake of it rather than a serious attempt to build a miner on these devices, though I did construct one of each using TQFP devices built on breakout adapter's, which are currently hashing away at the majestic rates of 12.7MH/s 11.7MH/s (140MHz) and 5MH/s (110MHz) respectively.

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 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 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

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.

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

RegardsMark

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!!

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.

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%

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.

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%

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?

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.