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

Or does it simply mean that it did not find a solution before somebody else, which is the most natural case. The output shown initially in this thread is winning, but this could be due to that it's located on some test net. Is that the case?

The pin location and io specification for the clock pin should be correct. I have a signaltap instance and some other logic in there which I observe is operating correctly off the same clock. I will try to disable the signaltap part in case it causes problems for the jtag hub...

But what does the 100% reject ratio actually mean? Is it described somewhere? If not I'll have to peek more into the logic and scripts....

Check to make sure your I/O is setup correctly. I had a wide variety of problems until i used the 50mhz GPIO clock on my board with 2.5v I/O.

I'm not sure if the miner will handle multiple cards or fpga on the same chain. I had to disable my CPLD to get it to function correctly. I was thinking of trying to put a driver hack together to handle the opensource fpga miner firmware on jtag for cgminer. But it'll likely take me forever. I'd be willing to put some coins toward a bounty for getting a jtag driver in cgminer for this firmware.

I just gave this miner I try and run into a couple questions:

1) What is the _rejected_ message and 100% rejection related to?


2) Will the TCL script handle multiple instances of the miner within a single FPGA?

3) Will the TCL script handle multiple FPGA's connected through the same JTAG chain

4) Will the TCL script handle multiple FPGA's connected through multiple JTAG chains, i.e. multiple USB blasters

The board I have is the DK-DEV-4SGX230N. It's got a place for the LCD I just don't have one.

Thanks for your assistance. I think i'm just going to find some 3rd party temperature monitoring do-hickey. The FPGA currently has a heat sink but no fan. I'll need to get around to adding a fan (and probably replacing the heat sink) at some point today.

Was able to get orphanedgland going stable @ 100mhz w/ 3 cores. (300mh/s). The FPGA's heatsink doesn't even go above room temperature (though I did now add a fan). The fMax of the orphaned gland code is 107mhz. Not sure if I should go about trying to get 3-4x makomk-mod's hashers running together or try to improve the fmax of the orphanedgland code.

Ah, obviously not the board I found via google http://www.buyaltera.com/scripts/partsearch.dll?Detail&name=544-2592-ND
so I'm talking out of my a** here. Shame as it looks to have a nice heatsink and fan to help with the cooling.

You won't damage the clock source, but as I said you may burn the chip! Quartus does have some options to estimate power dissipation, but you'll need to plug in the correct cooling parameters for the board, and anyway I'm getting out of my depth here as I've only played with a smallish cyclone device, and not the monster you've got your hands on
Even so, I can hazard a guess ... given that my one-sixth core on cyclone iv at 170MHz was dissipating around 2 watts, so for a full core you'd be looking at around 15 watts at 200MHz (possibly a bit less if the stratix is using a more advanced silicon process), which is going to need some serious cooling. Does the board have any temperature monitoring at all? Or can you attach a temperature probe to the heatsink? (I'm using one of those internal/external thermometers, though you have to be careful to insulate the metal probe so it won't short out anything) You'll need to keep the heatsink below around 60C to ensure a safe junction temperature, though for the exact calculation you need to know the actual power dissipation and junction-to-case thermal resistance of the package.

Anyway, as I said, I'm out of my depth here, sorry.
Mark

That makes 2 of us. I got the board off ebay. But that's not to say that it was cheap. Was still more expensive than other commonly available boards/fpga miners. If I got this thing running months ago when I bought it would've paid for itself by now. But at an electric cost of 35$ per year I should still be able to make it pay for itself over the next 2 years.

My main concern is that I would somehow damage my clock source by running the multiplier to high (if that is even possible). But it sounds like there shouldn't be any issues as long as I keep my temps under control. Unfortunately I don't have the LCD

I'm certainly not an expert on these things, but as this thread is something of a backwater, I'll make a few comments while we wait for the real experts to show up.

The PLL multiplier/divider is not a significant issue here as you should be able to achieve 200MHz quite satisfactorily and I guess 233MHz is just multilpy 14 divide 3 (refer to the altpll documentation).

The main issue is power dissipation as a fully unrolled core is going to run quite hot at these clock speeds, and yes, you could destroy the device. Given the expense of these devices (I just looked up the cost of the dev kits ... $3000 or $5000!!), you're taking quite a risk here.

You may want to take it slowly and step up the clock speed in increments. Looking at the DK-SI-4SGX230N data sheet there seems to be an option to display the junction temperature on LCD, but I guess this is going to need to be compiled into the design first.

Anyway as I said, I'm not the expert here, but I just wanted to raise a caution.

Mark

Finally got around to fiddling with my FPGA and getting it working. I'm running a stratix iv 230.

Was able to get a single fully unrolled core of the makomk-mod running. Started at 50mhz then went up to 100mhz then to 200mhz. I haven't really load tested it (just long enough to submit a couple shares then I kill the TCL miner). Now that I have it working, I'm concerned that I might burn up my chip. I was wondering what the implications of using a 50mhz clock source with a clock multiplier of 4 to obtain 200mhz were? In my timequest timing analsys it says my fmax is 233mhz for the pll driving the mining core. Is it safe to try to push 233mhz on a 50mhz clock source?  I don't quite understand how the clock source works in relation to the multiplier, divider, etc if anyone would be kind enough to share. My chip should be fully capable of those speeds; but my only other clock sources i'm not quite sure how to access as of yet. They're clock sources that are supposed to be used for driving 10gigabit ethernet among other on-board things (100,125,150,156mhz clock sources).

Oh ... if i start modelsim from quartus i got the error i posted in previous post, if i create the project manually like you explain it, that s works... )

Thanks a lot ! I ll now be able to play a bit more with the code

Just to make sure we're on the same page, I just did the following ...

BTW I'm using windows 8 (its an upgrade from windows vista, quartus/modelsim were actually installed on vista prior to the upgrade and survived the process, albeit with a rather strange but minor windowing display bug that just affects quartus).

Modelsim ALTERA starter edition version 6.6c / Quartus II version 10.1 web edition (installed from DE0-Nano CDROM).

Downloaded the Zip version from https://github.com/kramble/DE0-Nano-BitCoin-Miner
Unzipped it using 7-zip to C:\Users\Boss\Downloads\DE0-Nano-BitCoin-Miner-master\DE0-Nano-BitCoin-Miner-master
(sorry about the double nesting, 7zip just does that by default)
Started modelsim
Pressed Jumpstart on the Welcome screen, then "Create a Project"
Called it hashers22 and for the project location I browsed to
C:/Users/Boss/Downloads/DE0-Nano-BitCoin-Miner-master/DE0-Nano-BitCoin-Miner-master/Hashers22
At the add items dialog, press "Add existing file", then press browse (it opens the above folder)
Select (ctrl-click) ONLY fpgaminer_top.v, sha256_transform.v, sha-256-functions.v, test_fpgaminer_top.v
Close the dialogs.
In the project screen, right click on fpgaminer_top.v, compile, compile properties, in the dialog press Macro...
then enter SIM value 1 and close the dialogs
Press the "Compile All" button in the toolbar ... all 4 should compile successfully
Press the "Simulate"  button in the toolbar, expand the work folder and select test_fpgaminer_top
Assuming it loads OK, click on uut to expand the objects pane
Click on Simulate menu, Runtime options, Radix and select hexadecimal
Change the run length from 100ps to 100ns
Step the simulation 17 times (to 1700ns) and golden_nonce should change to 1afda099

That just worked for me, so possibly you're using a newer version of Modelsim and it just does not like the code? Then again its possible that I may just have fiddled with the modelsim configuration at some point when I was originally trying to get it working.

Perhaps one the the real experts could chip in to help out?

Regards
Mark

Hi Khertan

Unfortunately I'm not much of an expert in modelsim, so I'm probably not going to be of much help here.

The Modelsim version I used was the one than came on the CDROM with the DE0-Nano vis Modelsim ALTERA starter edition version 6.6c and Quartus II version 10.1 web edition.

I didn't really do much in the way of simulation as the original fpgaminer code worked fine, and my mod's were mostly just hacking around at the top level (though I did use it to debug my 22 hasher mod).

The only thing I can think of is the need to define the macro SIM (I just set it = 1) in the compile properties of fpgaminer_top.v so as to disable the virtual_wire probes (I'm assuming you're simulating the JTAG version, though I also did this for the serial version). This would certainly affect uut.data_buf, but I just tried deleting the macro and I got the error "Instantiation of 'virtual_wire' failed. The design unit was not found." rather than your "inconsistent with 'net' object".

But I didn't include virtual_wire.v in the modelsim project (its not needed for the simulation, and does not work anyway ... I just added it in, it compiles but simulating gives "Instantiation of 'altsource_probe' failed. The design unit was not found.").
Ah, memory is just coming back, I now recall that at this point I realised that I needed to define the SIM macro, and removed the virtual_wire.v module from the simulation.

Anyway, I'm probably not helping much here. It may be worth you going back to the original fpgaminer code (from the github link on the first page of this thread) and get that working first in the simulator, then see what differences my code introduces.

Regards
Mark

Look like i need to understand a bit more the complex modelsim ide

I got some error that should not happen ...
This or another usage of 'uut.data_buf' inconsistent with 'net' object.
#         Region: /test_fpgaminer_top


I probably miss something, any advices ?

Oh ... didn't notice your answer, thx a lot.

I'll not put clock too high, as i ll not put an other regulated power, this is more an exercice for trying to optimize things for fun
For the moment i ll just play with the simulator until the device will be delivered (bought but not yet received)

EDIT :

While trying to simulate i got an error :

# ** Error: (vsim-3033) fpgaminer_6_1200mv_85c_slow.vo(759): Instantiation of 'dffeas' failed. The design unit was not found.
#         Region: /test_fpgaminer_top/uut

Maybe you can point me what i miss ...
Thx

EDIT: was not in cycloneive_ver lib but altera

I've just now created a github account https://github.com/kramble/DE0-Nano-BitCoin-Miner and put up my 22 hasher mod of Makomk's code, plus the code for my raspberry pi mining host (warning, its pretty crude). Github's new to me, so I hope I've got it right (I based it on a bunch of stuff I mailed to another bitcointalk user, so the README is a bit out of date). Its probably worth noting the parameter SPEED_MHZ which sets the PLL osc speed, though confusingly in units of 10MHz (sorry), eg SPEED_MHZ=4 runs at 40MHz (I've kept it slow in the published code for safety's sake).

I've moved on from this now (it was fun, but not really worth spending any more time on), though I will note that I was able to reliably clock it up to a maximum of 170MHz (28.3MH/s), using an external 1.2V core supply as documented by Makomk at http://www.makomk.com/2011/10/06/de0-nano-power-efficiency-mod (though my version was somewhat of a kludge as I ran the external supply in parallel with the onboard regulators, and overvolted the supply slightly to 1.3V to ensure the onboard reg was overdriven ... not pretty, but it seemed happy about it).

Best of luck, and take care with the regulator temperatures (and USB supply current) if you crank the clock rate up.
Mark

I'm interested, indeed. Did you share somewhere your modifications ?
I'm currently trying to optimizing things (virtually, didn't have device yet).

Yes i know useless, that s most for fun as i bought a de0-nano for testing something else but once tested, i ll playing to try to run a miner on it ...

Total Logic Elements : 22,320 / 22,320 ( 100 % ) :p

Why not just use the arduino itself? store in EEPROM:
http://arduino.cc/en/Reference/EEPROM

Or just put an SD card on to the Arduino:
https://www.sparkfun.com/products/9802

both of which are much cheaper than FPGA. The cheapest is to print out a physical address and send it to your piece of paper.
https://en.bitcoin.it/wiki/Paper_wallet

http://print.printcoins.com/ (source code is on the site if you don't trust it)

I just wanted to through this idea out there, sorry if this thread is considered dead or not it has been quite a few days. I was kind of curious if it would be possible to implement an FPGA as a sort of hardware wallet that could be interfaced with an Ethernet adapter (say for arduino). Just kind of a thought I guess, some sort of stand alone, networked FPGA system that would hold onto your bitcoins and not rely on the computer (which can be more easily breached). I guess I'm thinking of something like a piggy bank for bit coins.

A (probably) final update on my experiences with the DE0-Nano, in case anyone out there is interested.

Using Makomk's code (from his github rather than the fpgaminer code), plus some modifications of my own to pack 22 of the sha256_digester's onto the EP4CE22, I've got a single core generating a full bitcoin hash every 6 clock cycles. I've been running this at 140MHz for a couple of days now which I reckon is 23.3MH/s (it averages 20 shares per hour which I reckon is about right, though if anyone wants to correct me on this then please feel free to do so). Its drawing 1.35 amps from an external 3.3V PSU, and the onboard regulators get pretty hot (I'm fan cooling the board). Not that I'd recommend this to anyone as its really pushing the envelope on the DE0-Nano board and may well fry it eventually.

This is probably as far as I'm going to go with this as to clock it any faster will need modifications to the power supply (as Makmok has documented on his web site) since the onboard regulators are only rated at 1.5A (and that's pretty optimistic as they need some serious additional cooling to get anywhere near that).

I'm running a pair of these boards on btcguild which claims to be earning me 0.00659245 BTC per day, not a lot I know, and probably barely covering my power costs (two times 4.5 Watts, plus another say 2 Watts for the raspberry pi host, plus whatever the mains PSU's are dissipating in heat), but I may as well have the boards do something vaguely useful while I think of something else to use them for, and its "free" bitcoins anyway (even if I am just converting joules into coins). I wonder what I can spend them on?

Many thanks to all who have contributed to this project, as its kept me well entertained for the last few months (I saw a quote somewhere saying you can lose 3 months of your life to FPGA's, so it seems like an appropriate point to bow out).

Regards
Mark

Just to be clear, using the midstate in mining is not deprecated, receiving the midstate from getwork is.

You need code running on a host computer that interfaces with your device anyway.  This code can just generate the midstate itself.  For an example, check out cgminer.c:calc_midstate().

In fact, once you have your bitstream, the easiest thing to do would be to make a driver for cgminer that interfaces with your device.  Check out driver-ztex.c and driver-modminer.c in cgminer for for examples.