Topic: Official Open Source FPGA Bitcoin Miner (Last Update: April 14th, 2013) - page 14. (Read 432918 times)

Sorry, I thought you were talking about scrolling down in the list of files. I got the file from the download section. Now I see what section you were talking about...

Error, error, error.....

There are a download section at http://www.ztex.de/btcminer. SCROLL DOWN.
Don't click on "Downloads" link at the left side menu bar, because it redirects you to SDK and Example downloads. It is an different downloads section.

Use this:
http://www.ztex.de/btcminer/ZtexBTCMiner-121126.tar.bz2

Which all contains memory tests etc.

Maybe try to scroll down:)

Download a source package, extract it, and you can find it in "fpga" subdirectory.

I'm not familiar with the site. All  can find is some firmware (mostlyJava) and the only HDL I can find is for memory tests etc. and some references to the Leon open source design. They seem to have lots of documentation so it's most likely hidden somewhere one the site.Anybody knows where?

http://www.ztex.de/btcminer/

Where is the ztex source? Is it in one of the project directories?

Separating clock will not help for you(i've tried on xc6slx150). The frequency is limited by carry chains, not by the clock network delays.
As i know, ztex design allows 190MHz generally(probably calculated by xilinx at 85 celsius) , but voltage/temperature derating allows to increase frequency.

I've tried to compile ztex's source, and xst reported 230 MHz maximal clock freq. . I made some modifications, so i hope it will reach 190MHz after par, because Xst reported 316.312MHz.

Nope..

The git repository contains several designs in the projects directory in addition to the main src directory.

Which of these contains the fastest hashing core?

It's possible check them all, but it would take some time to build almost 20 designs using either Quartus or ISE/Vivado.

Is this the Stratix V development kit?

It should build pretty much straight out of the box. But you need define you clock pin. You will probably have to modify main_pll.v in qmegawiz to match your external clock frequency (osc_clk) and target hash_clk.

But it appears that the Stratix V performance is below the Stratix IV, which I find a little odd.

Send me a shout on freenode irc "senseless".

I'll soon receive the board based on Altera Stratix V.
Any advice? ; )
Also, if you want to poke around with the board with me, VNC+Skype could be arranged.

Yes, I misremembered. There is a "Design Goal" for "Power Optimization" that invokes synthesis with "Optimization Goal" of "Area" and adds "Power Reduction" flag. It must have scrolled so many times on my terminal that I completely forgot about the top-level goal.

I haven't really tried anything on Kintex-7, but various Virtex-[456] that I had available. After what you've said about Vivado and Family-7 I'm getting motivated to upgrade my toyset.

FIFO's are usually implemented using embedded memory on the FPGA's. Even if you claim not being a FPGA designer/coder you think like one

But if you run your miner clock domain way above the fmax it will quite often work as most devices are usually faster than their marked speed grade. But when you get your next board/batch it might fail constantly since you got slower devices. Also you have to be careful so that timing errors in the faster clock domain will not propagate into the slower clock domains, e.g. the FIFO enqueue signal beeing stuck asserted due to a timing error etc. It can potentially be a lot worse than just a bad nonce.

This was the part of my concern. Getting that part to run at 500Mhz is a challenge, especially with multiple cores when utilization goes up


Yes. The CLB is pretty similar to the Spartan6, but it seems like the new switching matrix is quite effective when it comes to this type of logic/routing.

Altera Stratix-V does not seem to match this type of logic very well, at least with the current tools, as the Stratix-IV seem to outperform the Stratix-V. I don't understand why as the ALM does not seem to be radically different from the Stratix-IV.

Correct, something like that. I was thinking on-die memory segments could be used. But anything that would separate the hasher clock from the software communicator should be a good thing. I hadn't seen that code as I was working on the altera branches. They must be doing something right to achieve 200mh/s per chip on a spartan lx150 which in this thread (and on the hardware comparison page) topped out at 100mh/s on other boards (unless I missed some updates somewhere). The ztex design seems to be clocking 1 core at 200+mhz versus the other designs without hasher/controller separation clocking at 100mhz with 1 core. Would be amazing to double the clock rate of my altera chips from 220 to 440 w/ 3 cores!


What sort of pipelining would you recommend, I suppose 64 cycles per hash would be the smallest footprint and the highest clocked design? At some point routing issues will become a concern I guess I'll need to optimize the pipeline unrolling per chip. Pipelining would also allow for a greater use of available space (on an sasic at least). I would love to be able to better utilize all of the logic available on my chip (lacking 8% MLABs for a 4th fully unrolled core).

Thank you for sharing your idea, Senseless.  I love getting people engaged in this field of engineering.

Forgive me if I misunderstand your design, but I believe you have replicated what the current FPGA mining designs are already doing.  For example, on the X6500 board, the jtag_comm module communicates with the mining core in the rx_hash_clk clock domain, and communicates with the outside world in the jtag clock domain.  You can see the Asynchronous FIFO that shuttles golden nonces from rx_hash_clk clock to jtag clock here.

There is certainly work that could be done there, though.  JTAG is not a good communication method for this sort of task.  On the X6500 it was simply chosen to reduce cost and complexity.

In this case, the DSP48E1's are taking care of the heavy lifting; three and two-way 32-bit addition.  The rest of the fabric only needs to handle registers, routing signals, and the non-linear math.  Obviously the Kintex 7 fabric is capable of handling these frequencies for modest logic, otherwise the DSP's would be unusable in the first place

But, as I said before, I already did a rudimentary implementation of this design and synthesized/routed it.  Timing reported ~400MHz on the devkit.

Quartus, ISE, and Vivado all have options to target minimizing power.  I don't know how good they are at it; probably not very.

Actually, unrolled cores are very straight-forward designs.  The issue is that FPGA's are routing constrained, especially in the Spartan 6's, and the tools aren't designed to handle these sorts of long chains.  The Kintex 7 chips are much nicer with respect to routing resources and consistency.  Also, the newer Vivado Studio tool does a much better job than ISE in my experiences with it so far.  It's a shame Vivado does not support S6.

In my opinion, Avalon was smart in this regard and did it right.  Using lots of chips is a very good thing for these early mining ASIC's; I would not have recommended it any other way.  This is because there are rather large Minimum Order Quantities when producing ASIC's.  If you sell 1000 units, each with 4 chips, you aren't going to reach the necessary MOQ's, which are at least 50K chips.  Selling 1000 units, each with 240 chips, puts you in that beautiful quantity where the fabs and factories start giving you the time of day.  And the cost of everything else goes down.  In the long-run, yes, bigger chips are a better idea since they require less overall supporting circuitry and PCB space.

Slightly related:  I would not recommend fully unrolled cores for an ASIC design.  It will certainly result in higher performance per area due to optimizations unique to the unrolled designs, but it means higher failure rates and lower clock speeds due to intra-die variations.  Fully rolled cores that can be individually enabled and clocked (or clocked in regions) should give better yield and overclocking.

I like this idea.