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

Average of 670Mh/s based on my submissions over the last 1240 share submissions. Thanks again, the TCL was definitely the problem.

I started compiling a stratix V with 4 cores to see what the fmax would be.

Fmax was 147mhz. There were some routing issues and it had to add in some delays to fit 4 cores. There also seemed to be some weird clocking things going on in the stratix v with some sort of fractional clock. I'm not sure what that was all about, probably some sort of EP5 specific features that will improve performance if the design takes advantage of them.

If not, you could probably squeeze in an extra half-core, though it would make apportioning work a bit trickier.

Mark

Thank you, I was even showing duplicate submissions on the pool. I set it to 3 and now i'm pushing 600MH/s submission rate!

Now if I can just find 8% more resources so I can add in 1 more core I'll meet BFL single original specs!

Are you still using the original mine.tcl script? This does getwork at a fixed rate (every 20 secs, unless a share is submitted in the meantime), but at 660MH/s (which 3 cores at 220MHz should be doing), the nonce will wrap every 6 seconds, so you end up duplicating work and get a reduced actual throughput. Just a thought.

Mark

They work together dividing work between N cores instead of each core doing its own work.

It holds the nonce value in a variable(?) and then rotates that and provides work to each core. I think it might be a bit more efficient if each core was given a nonce range and then does its own internal flipping but would require a larger footprint. It's definitely not doing 1 hash per clock per core. I think the cores just get hung up waiting for data. It seems like it's doing 1 hash per 2 clocks (Maybe it takes a full clock just to get the data to the core). My hash rate has slipped down to 325-350 with good streaks pushing that up to 400+ and the actual hashing value should be closer to 700mh/s. Hash rate is based on submitted shares since the firmware doesnt have any way to stat the internal hashing frequency.

I've got 2-3 compiles going at any given time atm (takes like 2 hrs to compile). I'll try it out on a Stratix V when I can.

Cool. Do the three cores act like individual workers, or do they work together? Did you ever try to run your design with a Stratix-V target to see what fmax you would get?

I was able to increase the fmax on my chip for the Stratix IV OrphanGland code from 107 to 221 by removing all of the quasi-piplining code from the top and the associated files from the project. I now have 3 cores hashing @ 220mhz (450MH/s) on my EP4SGX230. It's still no where near as efficient as the makomk-mod code. Going to try to implement makomk's hashing core under the orphangland top.

Also, on a side note. I talked with Luke-Jr and he said he'd be willing to build a driver (bfgminer already has a jtag driver) if someone were to send him a board. I was thinking of just sending him some coinage so he can buy a DE0-Nano (which should be sufficient to get communication with the firmware running). He said it would be able to take a look in 1-2 weeks.

That makes sense.

As I understand it, fpgaminer doesn't care about the target difficulty and always treats it as 1, so showed lots of rejects when you were solo mining. There's no problem with this, because that just means you haven't found a block yet. When one is accepted is when you should be interested, because you just earned 25 BTC! If you don't want to see the rejects because they bother you, recode the host software (tcl?) to request the real target and make sure any hashes received from the FPGA meet that target. The FPGA will always return shares that meet the target of 1, which you can just ignore or count to make sure the FPGA is still hashing properly.

You're doing a simulation on the netlist after synthesis. This is very slow and is probably not what you want.

Yes, a pretty plain indirect addressing unit which can address multiple instances was what I was thinking.


True, even though I haven't really sat down to study the different ASIC offerings which are available yet.

You could just use different ident strings for the second instance eg STA1/DAT1/GNO1/NON1 and STA2/DAT2/GNO2/NON2
(they seem to need to be 4 chars not longer), then duplicate the jtag driver code to direct the work alternately between them.

At a very long shot you might even try just running two instances of the mine.tcl scripts (in separate directories due to dependancies) and just change the idents accordingly. I don't know if this is supported by the quartus_stp driver, but I have had some success with this approach on another project.

[EDIT]
Actually, thinking about this, its a pretty crude approach. It would be better to rewrite fpgaminer_top so as to apportion work between multiple hashers, and queue the results for transmission back via a single channel. Rather beyond my skills I'm afraid. I'll also note that the quartus_stp JTAG driver is not entirely reliable. I've had the mine.tcl script drop out with errors on extended runs (this is partly why I went the route of a custom serial interface to my raspberry pi host).

[EDIT2]
Then again it would be ridiculously easy just to push the same midstate_buf and data_buf into two or more sha256_transform units and just use different nonce values (eg for four instances just hardwire the top two bits of the nonce and count over a 30 bit range). Then just load golden_nonce based on whichever unit matches. Voila. You'd probably also need to reduce the getwork from every 20 seconds to something a bit faster in order to avoid wrapping and duplicating work. Longpoll would be nice too.

[EDIT3]
This is roughly what I had in mind https://github.com/kramble/DE0-Nano-BitCoin-Miner/blob/master/Misc/quad_fpgaminer_top.v
... just as a discussion point. I can't vouch for it working and it needs optimization, but I have given it a quick trip through the simulator (just tested one of the cores). I also found LX150_makomk_dualcore in the fpgaminer distribution which may be worth a look.

Anyway, with the rate that ASIC's are coming on stream and pushing up the difficulty, I doubt if anyone is going to do any further work on the fpgaminer code.

Mark

If a custom driver for cgminer were devised for this firmware should be possible to check for multiple instances per fpga and multiple fpga per jtag. As I mentioned before I'm willing to put up some coinage for a driver bounty. 4x 233mhz w/ cgminer sounds nice.

I tried to build an image with two instances of fpgaminer_top but it did not change anything. Seems like the tcl scripts can only handle a single GNON/NONC interface. So I guess the answer is no here as well.

The problem appears to be related to my local bitcoind. Now with btcguild.com as upstream I'm at least getting:


Thank you for the suggestion.

Sorry for the delay, I had to reinstall python on my laptop to run the check script (seems my windows 8 upgrade broke it).

Yes, I can confirm that 1a3b4de4 is a valid nonce for that block (difficulty 1 hash), so the problem looks to be with your bitcoind configuration rather than the fpga. Unfortunately I can't help with that.

Best of luck
Mark

Yes, I think that is likely. Just to eliminate this, why not just set up an account on btcguild (it only takes a moment) and try it on there?

I know almost nothing about the getwork protocol, but comparing your sample, the target value 0000000000000000000000000000000000000000000000fa7503000000000000 looks suspicious. I'm pretty sure the fpgaminer is hard coded to search for difficulty 1 shares. For instance my script logs target values of ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000 from btcguild getwork requests.

I'll have a poke around in my stuff and see if I can confirm the sample hash you've given. Be right back.

Regards
Mark

The FPGA seem to be running. The problem appears to be related to upstream json communication. I'm a bitcoin newbie so it's a little hard to tell if the transactions are correct. I've included some puts statements and here is what I observe:


The problem might also be related to the configuration of my bitcoind on localhost.

Looks to me that the pool is rejecting ALL of your shares! So either the fpga is producing garbage, or your submission to the pool is not working.

However the actual hash rate (102.75MH/s) matches the expected rate of 100MH/s pretty closely, so the device would seem to be hashing properly. Assuming you're using the official fpgaminer code (linked on the first page of this thread), I can offer the comment that its not entirely bug free. It has several variants and some are better than others. From the hash rate it looks like you're running the fully unrolled version which I can't (I've only got a 22kLE part), but I did come across a very similar problem caused by GOLDEN_NONCE_OFFSET being off by one for the particular LOG_LOOP2 value I was using  (so the submitted nonce was consistently wrong, even though the hash had been correctly calculated). The mine.tcl script does not check the result before submitting it to the pool. So one thing to try is to add some logging to the script and then manually check the hash values to see if they are correct. Or maybe just try a different pool (the default btcguild configuration works fine for me, albeit with my own account details).

Mark

There's a note in the mine.tcl:


So I guess the answer to multiple FPGA's is no...