Topic: Cyclone V now shipping! (Read 13976 times)

Not if the looping is free. If there are abundant local resources at a specific place because of chip layout constraints the penalty used for looping and memory would decrease up to the point where it would be more efficient. But to be honest I have no idea how this should be implemented and don't even know if it is at all possible with available tools.
Nevertheless I think it is worth a thought and if FPGAs prevail over a long period as the status quo something will come up. I am certain of that.

Another speculative note: the I/O ports of the FPGA might eventually be used to obtain additional routing, this would of course restrict the layout but it should be worth it for cases where a slow rate data stream would consume unnecessary resources if routed over wide distances.

I agree.  The only way it makes sense it to spread the risk around.  Problem is finding 10 people to invest $75K, or even 100 people to invest $7.5K and then wait at least 6 months before seeing any return on their investments.

I am curious to see what level of performance can be achieved and will see how many miners will fit on a Stratix IV/V myself soon and report back my findings.  I think others have tried with some Xilinx products, but until they have a hardcopy equivalent, those results are less interesting.


I'm surprised someone would even attempt to do that for something as (relatively) obscure as LargeCoin.

Nah, I cannot afford funding a Hardcopy device, and even if I barely could, I wouldn't invest all of my money into a Bitcoin miner. So many things can go wrong - difficulty can explode, the exchange rate can plummet, MtGox could be shut down by the Japanese government, etc. etc.

The LargeCoin folks up in Vancouver seem to be doing something like that, however.
Maybe even full-custom ASICs, judging from the low estimated power draw of their 20 GH/s box.

I still think the fastest you're going to get will be just a bit over the slow simulation based on my experience with the Cyclone II and Cyclone IV.

Dunno if you're interested, but if you'd like to get some idea for what's possible with Altera Hardcopy and you have modified the code to allow you to compile multiple instances of Makomk's code, you might try targeting a Stratix IV, EP4SGX530HH35 which is a prototype for the Hardcopy HC4GX25 ASIC (530K LEs).  You could also try targeting one of the bigger Stratix V devices as a prototype for the Hardcopy V ASICs (up to 930K LEs) -- but I can't seem to find on the Altera website a list detailing which Stratix V is a prototype for which Hardcopy V like I can for the Hardcopy IV series.  Don't bother trying unless you have at least 8GB RAM on the machine you're using as the bigger FPGAs really use up a lot of memory during compilations.

I'm guessing somewhere in the 2.4 GH/s range is possible with the Hardcopy IV, and considerably more with the Hardcopy V, although cooling the die may be challenging.

By my back-of-the-envelope calculations, it's going to take around $0.75 million in capital to launch such a project -- including the setup fees for the hardcopy ($200K), 500 ASICs ($500K), and a little more for the design and production of 500 basic mining boards.  In order to beat BFL in terms of MH/$, it would almost certainly need to use the Hardcopy V ASIC which would conservatively give over 2 MH/$ performance if the ASIC could be adequately cooled.  At today's difficulty/valuation levels, each one of those boards should be able to mine around 2 bitcoins per day, or $300/month, with a projected payback period of 5 months -- not bad.  Any fearless investors out there? 

So, can you make the latest code available somewhere?
I'm trying to instantiate two fully unrolled instances of your "slightly older code" on the Cyclone V GX 7 target architecture - so far, unsuccessfully.
Once instance is placed and routed just fine, and achieves 140 MH/s in the conservative "slow" simulation and a whopping 250 MH/s in the optimistic "fast" simulation.

110 MHz at 4 clock cycles per hash, actually. The design scales down reasonably well to smaller devices.

That's slightly older code. It's probably better than the newer versions with LOOP_LOG2=0 but it gives invalid results if you change it to anything else.

Yes, you can, and that would be a fallback strategy for the Cyclone V GX 7 in case one cannot fit two unrolled double-SHAs, however it'll hurt the $ per MH/s number.

I too looked over Wondermine's code and I am skeptical that it will challenge either the Ztex code or Makomk's modifications of Fpgaminer's code in terms of MH/s.  Still, having said that, I wish him good luck as if he does manage it, we'll all benefit and learn something in the process.

The inefficiencies of a rolled hasher are (usually) in area consumption, not in timing performance.

But to answer your question, yes you can clock different hashers at different speeds. Async FIFOs are used to cross the clock domains.

Unfortunately those numbers have nothing to do with a real working hasher, as a single hashing core needs 1/3  more LEs and i wonder if he gets the LE count back to the anounced 1250 LEs. In fact in another run i turned most area optimisations on and got only slightly better results. Besides that, his design has no communication module and the control logic seems incomplete to me as there is no logic to distribute the different nonces to the hashing cores.

Btw. as far i know the makomk design aims at the C7 grade device and it would worth a test what speed is possible with a C6 grade device. At least for the EP3C25 C7 grade device i got a bitstream reaching 117 MHz which should be sufficient to run an the aimed 120 MHz (=30 MHash).

Interesting.
So if you can fit one fully unrolled instance in a device so you can get 1 hash/clock and fit another half unrolled instance that gets 1 hash/2 clocks, the second one holds back the speed of the first one.
Would it be possible to clock the first at a speed a little faster than the second one? Or would this give difficulties to combine the 2 parts to have 1 output?

wondermine has released new code. Look yourself what he achieved:
https://bitcointalksearch.org/topic/m.844304

Impossible to say at this point, because
1) two instances don't even seem to fit
2) the difference between the slow estimate at 140 MH/s/instance and the fast estimate at 250 MH/s/instance is just too great.

The maximum seems to be 500 MH/s for two instances, but that's subject to too many assumptions to be realistic.
But then again, maybe wondermine comes up with a better implementation than fpgaminer.

so basically what would be the... rough estimation of performance in MH/s for a chip if you can get the 2 instances fully loaded into it?

As far as I understand, loops that are not 100% unrolled incur inefficiencies, as partial results have to be fed back in and there has to be logic (multiplexers) to do that, whereas data in a fully unrolled design just percolates from start to finish.

OK, after 15 1/2 hours Quartus failed to fit two instances of the double-SHA, albeit at the "optimize for speed" setting.
I have now restarted it with the "optimize for space" setting. The tension is almost unbearable...

Isn't the whole unrolling discussion really quite naive?

The optimal solution will be, depending on the layout of the chip, partly unrolled partly not, depending on which place inside the chip the operation takes place. It isn't really proficient to even talk about unrolling since depending on the amount of elements which can be used for memory, logic and routing a particular approach will be best.
Of course computing a solution which fits this paradigm would probably be too much, however if the tools permit programming the FPGA on a low level it should be at least possible to use close to 100% of all resources for something useful.

That has the potential to reduce the Fmax you can achieve, although if one fully unrolled miner uses only 40% of the device, the effect should be small.


LOOP_LOG2=0 is a fully unrolled miner -- 2 full SHA256 instances.  It achieves 1 clock cycle per bitcoin hash.  LOOP_LOG2=1 divides the work of each SHA-256 hasher in two so that they takes 2 clock cycles per bitcoin hash but use significantly fewer LEs.  You want to use LOOP_LOG2=0 whenever you can for best performance.


LOOP_LOG2 does not affect the number of SHA-256 instances.  There are always two of them.  It affects the amount of unrolling that is present in each of the SHA-256 instances.

LOOP_LOG2=0:  fully unrolled (2 fully unrolled SHA256 hasers)
LOOP_LOG2=1:  partially unrolled (2 clock cycles per output)
LOOP_LOG2=2:  partially unrolled (4 clock cycles per output)
etc.

Makes sense.  Who knows what form the I/O will take anyway until someone has designed/built some hardware around the Cyclone V.

You should be able to put two instances on the chip fairly easily either by creating a new top-level entity and instantiating two fpgaminer instances.  You'll probably have to parameterize the virtual_wire instance IDs in order to avoid collisions, but that may only be a problem at runtime so you might also be able to ignore it.

Your confusion may arise from some typos I made in the comments of my code awhile back. I apologize for that (and hope most of those typos have been fixed).

The LOOP_LOG2 parameter determines how many times the entire Bitcoin SHA-256 pipeline is folded in half. Each folding cuts performance in half, but also cuts resource consumption in half (1).

• LOOP_LOG2=0 -> Fully unrolled, one hash per clock cycle.
• LOOP_LOG2=1 -> Half unrolled, one hash per 2 clock cycles.
• LOOP_LOG2=2 -> Quarter unrolled, one hash per 4 clock cycles.
• ...etc...

Mmmkay, I was mentioning it mostly due to it having probably better timing, and use far less resources (those virtual_wires are nothing to sneeze at).

(1) It should be noted that LOOP_LOG2=0, fully unrolled, has special advantages over the other settings due to constant optimization, dropping the last three rounds, etc. So if you were to graph LOOP_LOG2 vs. area consumption it would be linear from 1 onward, but not from 0 to 1.

It never "failed" on the JTAG clock, because I never put a time constraint on the JTAG clock.
At 7.3 ns clock cycle, the design passes.
Fmax is quoted as 139 MHz and 141 MHz for Slow 0C and Slow 85C, respectively.
(Yes, for some reason the Cyclone V is expected to run slightly faster at a higher temperature.)

I have not tried to fit two instances of the miner yet.

If you have the time, please elucidate the difference between LOOP_LOG2=0 and LOOP_LOG2=1.
I can't wrap my head around that - both of them are supposed to be fully unrolled ?!?
Which one is the "preferred", "believed to be faster" setting?

(I do understand that a setting of 2 means that there is only one SHA-256 instance and its output has to be fed back in front.
No need to set LOOP_LOG2 to 2 or higher on the Cyclone V.)


Duly noted, but convenient I/O is not my main focus now - rather, I now want to focus on getting two instances fully placed and routed and timed.