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

[themike5000]

I adapted the "program-fpga-board.bat" program to load "OrphanGland's" .sof file for the stratix 4 boards onto my fpga (my chip is the 230, his is the 530).  Then I changed the minc.tcl file to point towards my device.  I run the program and this is what spits out:



What am I supposed to see?
(I put in my slush credentials into the file as well)

[1713963536]

1713963536

[1713963536]

1713963536

[1713963536]

1713963536

[1713963536]

1713963536

[1713963536]

1713963536

[TheSeven]

Sounds like either the FPGA design has a bug that makes it calculate garbage, or the nonce offset value on the client side doesn't fit.

[comboy]

To me, themike5000's output looks good, I have very similar one.

I was just wondering, how can I list devices name to know what to put into mine.tcl? I see "hardware_name" in Quartus so that's not a problem, but I don't know where can I check "device_name". The first part in the device name seems to be models that Quartus are asking me too choose between when plugging the device, but what is this 0x020F70DD? I thought maybe checksum but it doesn't seem to fit. Is there any way I can list all devices in a format that I'll be able to use in this param?

[lame.duck]

If i remember correctly, pro programming script has some provisions to detect what  Jtag-adapter an which device on each adaper are connected. Eventually i added some output lines or just commented them out (don't remember exactly). But you can also use the scheme give in the mine.tcl script (even i failed to do so manually) when copying it did work.
Eventually we could  trying to find a canonical naming scheme for the bitstreams so the software could select from the jtag-id.

[themike5000]

To me, themike5000's output looks good, I have very similar one.

I was just wondering, how can I list devices name to know what to put into mine.tcl? I see "hardware_name" in Quartus so that's not a problem, but I don't know where can I check "device_name". The first part in the device name seems to be models that Quartus are asking me too choose between when plugging the device, but what is this 0x020F70DD? I thought maybe checksum but it doesn't seem to fit. Is there any way I can list all devices in a format that I'll be able to use in this param?

Run the programfpga.bat file. It will find any attached devices and list them in that format.

I'm going to try to run it for a bit longer and see if slush recognizes my output as work.

[LazarusLong]

"result: false" looks like the share was not accepted.
Accepted shares normally should have a result "true" in the JSON response

[themike5000]

"result: false" looks like the share was not accepted.
Accepted shares normally should have a result "true" in the JSON response

It seems like its working.  I have it working for bitcoins.lc because it tells me the hashrate of the workers (any other way to do this in the software?).  It leveled out a around 300Mhash/second.  That seems odd because its running on two cores and should be at 220 clock rate (see picture)



Any way to find a more accurate hashrate output than relying on bitcoins.lc to calculate for me?  Am I running at 150 or 220?  I'm confused...

[lame.duck]

Any way to find a more accurate hashrate output than relying on bitcoins.lc to calculate for me?  Am I running at 150 or 220?  I'm confused...

You are running @220MHz and with a lully unrolled design you should have a hashrate of 220 MHash/s

[themike5000]

Any way to find a more accurate hashrate output than relying on bitcoins.lc to calculate for me?  Am I running at 150 or 220?  I'm confused...

You are running @220MHz and with a lully unrolled design you should have a hashrate of 220 MHash/s

220MHash/s on each core though, right?

[lame.duck]

yes, on each core.

[OrphanedGland]

440MH/s is the raw underlying hash rate for your configuration, but you need to consider delays associated with presenting the golden nonce, getting new data from the pool etc.  You would never be able to achieve 440MH/s in practice.

[comboy]

To me, themike5000's output looks good, I have very similar one.

I was just wondering, how can I list devices name to know what to put into mine.tcl? I see "hardware_name" in Quartus so that's not a problem, but I don't know where can I check "device_name". The first part in the device name seems to be models that Quartus are asking me too choose between when plugging the device, but what is this 0x020F70DD? I thought maybe checksum but it doesn't seem to fit. Is there any way I can list all devices in a format that I'll be able to use in this param?

Run the programfpga.bat file. It will find any attached devices and list them in that format.

I'm on linux, but yes, I found what I needed there, thanks.

[lame.duck]

440MH/s is the raw underlying hash rate for your configuration, but you need to consider delays associated with presenting the golden nonce, getting new data from the pool etc.  You would never be able to achieve 440MH/s in practice.

Well, there would be some sort of FIFO @ the input that holds the next workload. Since with high hashing speed the performance loss will rise there could be some demand for such a solution.

[themike5000]

My linear tech chips are running very hot, especially the one circled.  Two of them are too hot to touch for longer than a second or two.  Should I try to cool it off?

The hottest one is a Linear LTM4601V.

[makomk]

My linear tech chips are running very hot, especially the one circled.  Two of them are too hot to touch for longer than a second or two.  Should I try to cool it off?

The hottest one is a Linear LTM4601V.

Hmmmm. The data sheet for that chip suggests that maximum safe case temperature is 100 degrees centrigrade and that it should probably be able to operate without forced cooling or a heatsink across the full rated amperage range at typical room temperatures, so I don't know... check the temperature and see, or just point a fan across it?

[TheSeven]

440MH/s is the raw underlying hash rate for your configuration, but you need to consider delays associated with presenting the golden nonce, getting new data from the pool etc.  You would never be able to achieve 440MH/s in practice.

Actually making that run at 100% efficiency is fairly trivial, and my Xilinx design is already doing it. Just upload the next work when the old one is like 80% processed, and while you upload it, the FPGA will continue to old one, and still report shares if it found them during the upload.

440MH/s? What kind of badass FPGA is that?

[themike5000]

440MH/s is the raw underlying hash rate for your configuration, but you need to consider delays associated with presenting the golden nonce, getting new data from the pool etc.  You would never be able to achieve 440MH/s in practice.

Actually making that run at 100% efficiency is fairly trivial, and my Xilinx design is already doing it. Just upload the next work when the old one is like 80% processed, and while you upload it, the FPGA will continue to old one, and still report shares if it found them during the upload.

440MH/s? What kind of badass FPGA is that?

Can that be implemented into "FPGA Miner"'s program?  I suck at coding and would screw it up.  (I'm learning bit by bit...)

Its a Stratix IV dev board -- the GX230KF40C2 chip.  Hoping for a Stratix V board within the year... Yeah -- its not cost effective (got the Stratix IV at discount for $2k), but it is pretty slick.  I'm going to try to push it to 260MHz and 2 cores.  But yeah, wasting most of my time talking to the server and asking for blocks is killing me more than anything else.

You know of a better way to track ACTUAL mhash/sec so we can see where we need to tweak?

[TheSeven]

440MH/s is the raw underlying hash rate for your configuration, but you need to consider delays associated with presenting the golden nonce, getting new data from the pool etc.  You would never be able to achieve 440MH/s in practice.

Actually making that run at 100% efficiency is fairly trivial, and my Xilinx design is already doing it. Just upload the next work when the old one is like 80% processed, and while you upload it, the FPGA will continue to old one, and still report shares if it found them during the upload.

440MH/s? What kind of badass FPGA is that?

Can that be implemented into "FPGA Miner"'s program?  I suck at coding and would screw it up.  (I'm learning bit by bit...)

I would guess yes, but I'm not at all familar with all this Tcl and Altera stuff.

Its a Stratix IV dev board -- the GX230KF40C2 chip.  Hoping for a Stratix V board within the year... Yeah -- its not cost effective (got the Stratix IV at discount for $2k), but it is pretty slick.  I'm going to try to push it to 260MHz and 2 cores.  But yeah, wasting most of my time talking to the server and asking for blocks is killing me more than anything else.

Way better than mine! It costs $2k as well but only runs 1 fully-unrolled miner at 120MHz (XC5VLX110T-1)

You know of a better way to track ACTUAL mhash/sec so we can see where we need to tweak?

By calculating it, like you already did: 220MHz * 2 fully unrolled miners = 440MH/s. That's the truth. Everything else is just estimates based on the number of shares submitted, which is subject to variance/luck.

Is the FPGA wrapping around on the keyspace while it's being fed new data? If yes, you'd need to take that into account as well, by measuring the time between the work uploads.

If you care to either rewrite your FPGA design to communicate via a serial port or to write a python interface module for your FPGA's JTAG, you could use my improved python mining code, which should be able to handle 440MH/s at 100% efficiency easily.

[themike5000]

Is the FPGA wrapping around on the keyspace while it's being fed new data? If yes, you'd need to take that into account as well, by measuring the time between the work uploads.

If you care to either rewrite your FPGA design to communicate via a serial port or to write a python interface module for your FPGA's JTAG, you could use my improved python mining code, which should be able to handle 440MH/s at 100% efficiency easily.

I'm not really qualified to do that.  I'm barely able to hang on reading instructions and switching out one or two settings.  I'm at the whims of the rest of you here, until i get a little more experience under my belt.  :-p

[TheSeven]

Is the FPGA wrapping around on the keyspace while it's being fed new data? If yes, you'd need to take that into account as well, by measuring the time between the work uploads.

If you care to either rewrite your FPGA design to communicate via a serial port or to write a python interface module for your FPGA's JTAG, you could use my improved python mining code, which should be able to handle 440MH/s at 100% efficiency easily.

I'm not really qualified to do that.  I'm barely able to hang on reading instructions and switching out one or two settings.  I'm at the whims of the rest of you here, until i get a little more experience under my belt.  :-p

Which version of the FPGA design are you using?
Does your board have a serial port?
I might be able to whip up something...