Compiling for different board

[mlo0352]

Hey, does anybody know of a way I can get this to compile to a Cyclone II EP2C35F672C6N? I have been trying for a while, now, and when I try to compile after opening the .qpf in Quartus and changing the device to mine, I get this error:

Error (272006): MGL_INTERNAL_ERROR: Port object altpll|clk of width 5 is being assigned the port altpll|stratixii_pll inst pll1|clk of width 3 which is illegal, as port widths dont match nor are multiples. CAUSE : The port widths are mismatched in the mentioned assignment. The port widths of the connected ports should match or the LHS port width should be a multiple of the RHS port width. ACTION : Check the port widths of the connected ports. Logical operation results in a port width equal to the larger of the two ports and concatenation results in a port width equal to the sum of the individual port widths. Double check for such cases.

(yeah...it's long)

There's also these two warnings:

Warning (10230): Verilog HDL assignment warning at ltcminer.v(83): truncated value with size 32 to match size of target (4) Warning (10230): Verilog HDL assignment warning at ltcminer.v(124): truncated value with size 32 to match size of target (2)

I don't have much experience compiling for other boards, admittedly. If nobody knows the specific answer, I would super super appreciate either some help, some tips, or a kick in the right direction.

I'm doing this in Linux, by the way.

THANK YOU.

[kramble]

I'll get onto this tomorrow (getting late here UK time). Probably just a matter of rewriting the PLL to the Cyclone II spec (or you could try using the megawizard to create the PLL from scratch).

The truncation warnings are just due to lazy coding when implementing counters. Just ignore them for now as there is no consequence (I'll fix them eventually ... you should see the warnings on the LX150 port, more than 100!).

PS WELCOME ABOARD !! This is a fun ride :-)

[mlo0352]

Thanks! That sounds good.

I was wondering why the hashing rates were so much lower (from the other conversations I've seen you have with people who've put this on other boards) compared to the bitcoin rates of ~109 MHashes/s on similar hardware. Is that because of the different hashing algorithm?

Thanks for the response! I'm super excited to start working on this. I have some cool ideas and am excited to get working!

[BlueDragon747]

Hi,

well its not similar hardware that they get the 109MH/s from, it is large cyclone iV or large spartan-6 fpga's or better hardware and it is a entirely different algorithm bitcoin vs litecoin.

for example the DE0-Nano cyclone Iv (22k LE) board only get about 30MH/s on bitcoin and on litecoin it gets about 2.1kH/s, no idea what it would get on a cyclone II but the smaller and older the chip the less the algorithm is unrolled and the slower it gets, totally unrolled bitcoin sha256 on a DE2-115 = the magic 109MH/s but on litecoin that drops to 31kH/s or less.

see here: https://forum.litecoin.net/index.php/topic,5162.0.html

also you can generate your own definitions files for that board in a few minutes, if you have some example code that works on your board check that for these details or create a new empty project for that board/chip and compare the outputs of the files to see difference, qpf, qsf, sdc, pll files are the main ones that will need changing, first 3 will be created by a new project and can then be adapted with the board specific details and the main_pll.v can be generated using the clock wizard, hope that helps.

to avoid disappointment please don't get your hopes up to high that chip is quite small and old compared with what we are using and we are not getting mega fast hash rate with ours, its more of a learning project as you can learn a lot about both sha256 and salsa algorithms and how it work in fpga's

Best Regards BlueDragon747

[kramble]

Sorry, I haven't managed to make time to look at this yet (got my nose stuck into debugging a FSM and I need to focus on that until I've got it working ... I don't find multitasking easy). If you're familiar with quartus then the megawizard may help (at least you can see what changes to make to the pll code to get it working with cyclone 2).

Re the hash rates, its just a far more complicated algorithm ... and this post is just crossing with bluedragon's so I'd best push comment before I lose it (he's done a better job of explaining it than I have).

[mlo0352]

Thanks guys. Okay, so yeah, I mostly am just trying to learn how to compile for other boards. I've taken some computer architecture classes and I'm trying to expand my knowledge, and this just happens to be the board I have immediate access to.

So:

1. I have the source files and everything.
2. I create a new Quartus project with my board specified, and I include all of the .v files that are available here [should this include the altera_pll, altera_ram, altera_virtual_wire ?]
3. ???
4. PROFIT

I've not had to do any custom compilation because I've relied on scripts to do this in my classes. Sooooo I'm kinda dumb. But I can learn fast...hopefully! :)

Thank you!

[BlueDragon747]

Hi,

altera_pll should be recreated with clock wizard and leave out the test_ltcminer.v and in the .qsf file you will need to put the port pins in, led's, clock pins etc.

best to have a look at the project you have working even if they are generated or find some projects that will work with that exact board else you need to troll though the datasheet, most important one is going to be clock pin and then your tx/rx.

should look something like this (from de0-nano qsf file): set_location_assignment PIN_R8 -to osc_clk set_location_assignment PIN_A15 -to LEDS_out[0] Edit: note that these will be different on your board/chip but the DE0-Nano is a good reference

"4. PROFIT" lol maybe after the next ice age ;)

Good Luck

[kramble]

You won't be able to build the project as it stands due to insufficient RAM ...

; Flow Status ; Flow Failed - Fri Aug 30 20:52:22 2013 ; ; Quartus II Version ; 10.1 Build 153 11/29/2010 SJ Web Edition ; ; Revision Name ; ltcminer ; ; Top-level Entity Name ; ltcminer ; ; Family ; Cyclone II ; ; Device ; EP2C35F672C6 ; ; Timing Models ; Final ; ; Total logic elements ; 18,391 / 33,216 ( 55 % ) ; ; Total combinational functions ; 15,222 / 33,216 ( 46 % ) ; ; Dedicated logic registers ; 9,740 / 33,216 ( 29 % ) ; ; Total registers ; 9740 ; ; Total pins ; 9 / 475 ( 2 % ) ; ; Total virtual pins ; 0 ; ; Total memory bits ; 524,288 / 483,840 ( 108 % ) ; ; Embedded Multiplier 9-bit elements ; 0 / 70 ( 0 % ) ; ; Total PLLs ; 1 / 4 ( 25 % ) ;

However by using a quarter-sized scratchpad, it ought to fit. Unfortunately I haven't implemented this feature yet ... over to you :-)

This is what I did to get it to compile ...

Start a new project (we will just use this to build the components, so call it dummy or something) Choose your device EP2C35F672C6 Don't add any source files Run Tools/Megawizard Create new custom megafunction I/O Pll Call it main_pll.v Freq 50MHz Next Untick areset and locked Next Set multiply=25 div=50 (it will actually use 1 and 2) Finish

We also need to do the ram ...

Tools/Megawizard Create new custom megafunction Memory/Ram/1-port ram.v q bus 256 bits, 512 words next untick register q port finish

Close the project.

Edit the main_pll.v and make the following changes ...

module main_pll # (parameter SPEED_MHZ = 25) (

altpll_component.clk0_divide_by = 50, altpll_component.clk0_multiply_by = SPEED_MHZ,

Edit ram.v and make the following changes ...

module ram # ( parameter ADDRBITS=10 ) ( input [ADDRBITS-1:0] address; altsyncram_component.numwords_a = 2 << (ADDRBITS-1), altsyncram_component.widthad_a = ADDRBITS,

Now in your downloaded copy of the github Copy the folder DE0-Nano as EP2C35F672C6 Copy main_pll.v and ram.v into the new folder Edit ltcminer.qsf and change ... set_global_assignment -name FAMILY "Cyclone II" set_global_assignment -name DEVICE EP2C35F672C6 set_global_assignment -name VERILOG_FILE "ram.v" instead of "../source/altera_ram.v" set_global_assignment -name VERILOG_FILE "main_pll.v" instead of "../source/main_pll.v" You will also need to setup your pins, probably best to copy from a working/demo project. Double click on ltcminer.qpf - it should open OK and should compile but give the failure message I included above.

Alternatively instead of modifying the DE0-Nano project, create one from scratch and just add in the neccessary files and ...

set_global_assignment -name VERILOG_MACRO "HALFRAM=1"

Sorry it won't build, but if I can help in any other way, just ask.

[mlo0352]

Thank you for checking on that. Surprisingly enough, I just found a DE2-115 board in my lab. Same model that your code is designed for. So it seems like I'm in luck!

So I have been trying to just get it all working.

I compiled the whole thing, got the SOF, used the In-System Memory Content Editor to copy it onto the board [side-note: how does one apply the SOF in a non-volatile way?], and have it plugged into my computer (obviously).

So the board has been programmed. Now. I can't see the board using cgminer-fpgaonly (sees usb devices, no suitable miners). I saw you had some scripts included. So I try to run them in Quartus [quartus_sh -t mine.tcl ]. Then I get this error:

--- FPGA Mining Tcl Script ---

Looking for and preparing FPGAs...

---

ERROR: Quartus II Tcl command "get_hardware_names" belongs to the "::quartus::external_memif_toolkit" package which is currently not loaded. Please type "load_package external_memif_toolkit" to load the package before using this command.

So, I figure I can include that in the file by placing load_package external_memif_toolkit before the package requires. That just causes more errors.

I guess what I'm saying is:

[kramble]

You're doing pretty well so far!

Yeah, I forgot to include quite a lot of background info which came from the original bitcoin fpgaminer project (its well worth taking a look at). I'm not sure what you need to do to fix your quartus installation (have a word with your lab tutors), but you will definitely need quartus-stp. My board is a DE0-Nano (quite a bit smaller then the DE2-115, though I am told it works fine on this board), and I just installed the full Quartus suite (version 10, since that was what came on the DVD-Rom) If you can use your own laptop, just download and install the latest version.

Assuming you're running windows you just need to cd to scripts and run program.bat to upload the SOF file (no need to mess with the Quartus GUI tools). Then you run mine.bat to start the miner (you also need to rename config-example.tcl to config.tcl and set your pool credentials in there). On linux I guess you just run the quartus-stp commands directly from the shell (just one-liners, see the .bat files for info).

cgminer won't work as the litcoin fpga needs the full 128 byte block header, not the midstate/data that bitcoin uses. I don't think it will talk directly to a DE2 board either.

PS There should be some info on flashing the non-volatile configuration roms in the DE2 user manual. Its done from within the Quartus programmer GUI, but I would not recommend it if this is lab gear, best to leave it alone and upload as you need to.

[mlo0352]

Well, the lab is Linux, but I'm fairly certain I have all of those. I ran all sorts of various quartus_xx things to try to get things working...but I suppose I could look into getting it on a personal computer. If that's not possible, I'll try your other suggestion.

As for using a mining program directly, is it possible to use any existing programs as far as you know?

Also, one thing I've been wondering from the beginning (and would probably be more clear once I got an actual board working) is: how much data transfer is there back and forth between the board? Where does the check for the valid hash happen? Is it FPGA-side or PC-side?

Thanks for the quick response!

[kramble]

None of the existing programs support litecoin FPGA (this is bleeding edge!). The tcl scripts are fairly reliable though, if used with a local stratum proxy server (just get it working on getwork first before trying this).

Data transfer is minimal. 128 bytes every couple of seconds, even less for the nonces coming back. The hash check is on the fpga, and is sent directly to the mining pool which ill accept or reject as it sees fit (the stratum proxy is a little more intelligent and checks the hash before submitting it) ... actually, strike that as its for the serial comms version (ltcminer.py in the LX150 directory). The quartus TCL scripts rattle the JTAG bus continually to sample the current nonce and golden_nonce registers, probably around 1000 times per second. But that's just because it was the way the bitcoin miner did it, the actual data requirements are very light as I said earlier.

Response is quick 'cos I'm currently online :-) Running UK time though, and I do have to sleep occasionally.

[mlo0352]

So I was wondering though, is there any reason for using the JTAG as opposed to putting in some USB device logic into the chip? Is it just for simplicity's sake? As far as I know, JTAG isn't commonly used for non-debug data transfer.

Once again, thanks for the quick responses. On Sep 5, 2013 2:13 PM, "kramble" notifications@github.com wrote:

None of the existing programs support litecoin FPGA (this is bleeding edge!). The tcl scripts are fairly reliable though, if used with a local stratum proxy server (just get it working on getwork first before trying this).

Data transfer is minimal. 128 bytes every couple of seconds, even less for the nonces coming back. The hash check is on the fpga, and is sent directly to the mining pool which ill accept or reject as it sees fit (the stratum proxy is a little more intelligent and checks the hash before submitting it) ... actually, strike that as its for the serial comms version (ltcminer.py in the LX150 directory). The quartus TCL scripts rattle the JTAG bus continually to sample the current nonce and golden_nonce registers, probably around 1000 times per second. But that's just because it was the way the bitcoin miner did it, the actual data requirements are very light as I said earlier.

Response is quick 'cos I'm currently online :-) Running UK time though, and I do have to sleep occasionally.

— Reply to this email directly or view it on GitHubhttps://github.com/kramble/FPGA-Litecoin-Miner/issues/5#issuecomment-23889453 .

[BlueDragon747]

you can use Serial, USB or JTAG for communication with your software not many using USB (e.g not many examples to base your work on) most are using Serial then JTAG, best to check out the forums, the reason for JTAG comes from the Open-Source-FPGA-Bitcoin-Miner project

the altera dev boards have a funky inbuilt programmer and the hack is to get JTAG though the onboard chips without adding extras, I am sure this was a quick hack but still useful

I use Serial and add a cheap cp2102 adapter on some spare io pins to get my comms to the software as it the easiest to do and lots of examples to base my code on.

Edit: to be honest with you I would start with the fpga bitcoin project as there are quite a few examples with that board you found in the lab and get that nailed with a few different comms examples. https://bitcointalk.org/index.php?topic=9047.0

by jumping straight into this project you are jumping in the deep end first ;)

[kramble]

As Blue said, its just developers working with what was to hand. The Altera boards often only have the jtag (usb-blaster), so that's what got used. Some of the xilinx dev boards have usb serial, so that got used. Then when the commercial fpga mining boards came out (mostly based on xilinx LX150, with the exception of ButterflyLabs), the Icarus/Lancelot used a usb-serial chip, while ztex and modminer went for an onboard MCU approach to talk to the usb.

And I'll agree that getting to grips with the bitcoin miner is probably easier (there is a whole lot more written in the forums support-wise, though its gone very quiet now that bitcoin difficulty has gone stratospheric).

[mlo0352]

So it boils down to it mostly being a convenient hack, that's cool. I'm wondering if this would work with a larger number of boards like how the Bitcoin boards do with USB. If you could daisy-chain the JTAGs to get a nice cluster going. It'd be limited by size, but it could work, right?

Yeah, it's a shame about Bitcoin. How long do you think Litecoin has until there's that sort of change in difficulty? Or do you think the nature of it will keep that from happening?

On Thu, Sep 12, 2013 at 5:01 PM, kramble notifications@github.com wrote:

As Blue said, its just developers working with what was to hand. The Altera boards often only have the jtag (usb-blaster), so that's what got used. Some of the xilinx dev boards have usb serial, so that got used. Then when the commercial fpga mining boards came out (mostly based on xilinx LX150, with the exception of ButterflyLabs), the Icarus/Lancelot used a usb-serial chip, while ztex and modminer went for an onboard MCU approach to talk to the usb.

And I'll agree that getting to grips with the bitcoin miner is probably easier (there is a whole lot more written in the forums support-wise, though its gone very quiet now that bitcoin difficulty has gone stratospheric).

— Reply to this email directly or view it on GitHubhttps://github.com/kramble/FPGA-Litecoin-Miner/issues/5#issuecomment-24355620 .

[vpereira]

if you are using linux, I can give you some tips: if you want to test it using JTAG, you must buy a USB Blaster cable.. the cheap one, that you can find on ebay for $5 doesn't play well with Linux.. I had to buy a real altera cable (actually a Terasic, and yes, it costs 50 bucks)

about the daisy chain, yes maybe its possible, but maybe you can just change the mine.tcl to actually share the job between the found fpgas (the script is able already to find N fpgas, so you should be able to push job to both at same time).. i have it in my TODO list, but because now I'm fighting against ztex boards, xilinx crap ISE and etc.. I'm not able to do it.

[kramble]

The altera jtag drivers support multiple devices on multiple boards. The scripts would need modifying though (some comments on one of the other threads here EDIT: by vpereira as above). Performance would be an issue as its really only meant for debugging, not for production use. You'd be better off just daisy chaining the boards (no need for adapters, though you might want to use opto-isolators if you're worried about having all your eggs in one long chain). Then either use jtag or a rs232 adapter as suggested by Blue) I did some work on this in my DE0-Nano github, but only ever chained a couple of boards (bit of a mixed bag of two DE0-Nano's and a pair of homebrew boards, one each altera and xilinx).

On the difficulty, there was a big spike a week or so back, probably a huge GPU farm switching from bitcoin to litecoin, but I don't see it going stratospheric. ASIC's just won't give the huge performance leap for scrypt that they did on sha256d. Not impossible, but performance will not be that much above the current GPU level.

[BlueDragon747]

The change to alt coins has already happened with the migration of GPU miners from Bitcoin to Litecoin and others.

28th February 2013 the Litecoin difficulty was 16 today it is 846 so there is already a huge jump in difficulty on the network which I am sure will increase over time, also quite a few alt coins about that use scrypt so they are here to stay but only time will tell ;)

charts: http://ltc.block-explorer.com/charts

only thing that would effect the increase in difficulty is if a fundamental flaw in the algorithm (which might just get patched) or some sort of mass loss in confidence or just an alternative coin algorithm that takes away the hashing power of the network, your guess is as good as mine :)

[kramble]

Blue, I think you must have missed the thread on that huge GPU farm, difficulty is currently 1128 (I happen to have it up as I'm testing my dynamic DCM_CLKGEN code ... its working great! Makes it so much easier to tweak the clock speed)

Last Time Difficulty PPS Rate Shares Rewards 2013-09-12 21:32 UTC 1128.62544992 0.000000648950 4,804 0.003117555800 LTC 2013-09-08 15:05 UTC 938.98343044 0.000000780016 190 0.000148203040 LTC 2013-09-05 18:24 UTC 1102.31480110 0.000000664440 3,958 0.002629853520 LTC 2013-08-31 10:59 UTC 934.76573625 0.000000783535 800 0.000626828000 LTC 2013-08-29 20:02 UTC 969.43922696 0.000000755511 3,844 0.002904184284 LTC

diff's been bouncing up and down as that farm went on and offline, and, umm, yeah, fpga litecoin mining is not very profitable.

[mlo0352]

So is it [fpga mining] not profitable because we haven't gotten it tight enough to fit loads of cores per board, or is it because the market got saturated with a player that's too big compared to the average miner?

On Thu, Sep 12, 2013 at 5:41 PM, kramble notifications@github.com wrote:

Blue, I think you must have missed the thread on that huge GPU farm, difficulty is currently 1128 (I happen to have it up as I'm testing my dynamic DCM_CLKGEN code ... its working great! Makes it so much easier to tweak the clock speed)

Last Time Difficulty PPS Rate Shares Rewards 2013-09-12 21:32 UTC 1128.62544992 0.000000648950 4,804 0.003117555800 LTC 2013-09-08 15:05 UTC 938.98343044 0.000000780016 190 0.000148203040 LTC 2013-09-05 18:24 UTC 1102.31480110 0.000000664440 3,958 0.002629853520 LTC 2013-08-31 10:59 UTC 934.76573625 0.000000783535 800 0.000626828000 LTC 2013-08-29 20:02 UTC 969.43922696 0.000000755511 3,844 0.002904184284 LTC

diff's been bouncing up and down as that farm went on and offline, and, umm, yeah, fpga litecoin mining is not very profitable.

— Reply to this email directly or view it on GitHubhttps://github.com/kramble/FPGA-Litecoin-Miner/issues/5#issuecomment-24358308 .

[BlueDragon747]

lol I get flu for 1 week and it jumps again 848 ->1128 ^^

Good news about dcm_clkgen :D

fpga are not super cheap and the project is still in early days, and gpu farms and bot nets are a threat ;0

the biggest bonus to fpga's is that they are power efficent.

[kramble]

FPGA will never be profitable for litecoin. The on-chip BRAM is just too small, and once you get into adding external SDRAM (on custom built boards), you're just replicating what GPUs are already doing very well at. This project is more about finding a use for old bitcoin mining kit rather than creating new gear. Still Jasinlee has a project on these lines, and good luck to him, he may prove me wrong.

I'll get the DCM_CLKGEN code up tomorrow (its hot off the keyboard, I only started it this morning). Just got lucky I think as its a bit on the tricksy side.

[mlo0352]

Wouldn't GPU farms ramp up the difficulty to where only FPGA/ASIC solutions would/could be profitable? I mean once the designs have been tweaked.

I guess there's nothing to be done about botnets considering their masters don't need to worry about hardware costs or mining difficulty. On Sep 12, 2013 5:48 PM, "BlueDragon747" notifications@github.com wrote:

lol I get flu for 1 week and it jumps again 848 ->1128 ^^

Good news about dcm_clkgen :D

fpga are not super cheap and the project is still in early days, and gpu farms and bot nets are a threat profit ;0

— Reply to this email directly or view it on GitHubhttps://github.com/kramble/FPGA-Litecoin-Miner/issues/5#issuecomment-24358684 .

[kramble]

Yeah, the FPGA has the advantage electricity-consumption wise. There really is only a fixed pot of LTC to be mined per day, so when the GPU farms come over, we have the same race to the bottom as bitcoin (but without the disruptive change that ASICs made). As I've been nagging on bitcointalk, its gold-rush territory out there, and only the shovel sellers are going to make any money.

Anyway, this is getting somewhat off-topic for this thread (really ought to take it to the litecoin forum), and its getting on for my bedtime. Lots to do tomorrow, got to prep LX150-EIGHT-B for release, though performance-wise its rather disappointing, Onwards to the -C methinks.

[mlo0352]

Here are the different ways I've tried to get some mining to work:

1. Just running it normally (I know, you said this won't work)
2. Running a stratum proxy: I'm not quite sure how this works. How would the proxy know which actual server to connect to? From what I can tell, I'm not doing it correctly, that's for sure. Going to the address (localhost:8332) does get me JSON info containing hashes and things, but apparently it's not getting to the mining script. It says it's missing a key. (I unplugged everything last night or I'd take a quick screenshot this morning, still can if you don't know what I'm talking about...here's the proxy:
3. Try mining with a non-stratum server: set url "www.weloveltc.com:420"
4. By the way, I think I will write up a nice Tutorial on getting all this stuff configured so noobs like myself won't have trouble with it. :)

[vpereira]

hi, the option to talk direct with servers with getwork support is the easiest one. to use a proxy, you give as parameter your pool information - just check before which port your server uses - like:

python mining_proxy.py -pa scrypt -o stratum.foo.org:3333 

(it will be listening in localhost:8332)

and in your config.tcl you add your worker information like

set url "http://localhost:8332"
set userpass "user.1:x"

now you can start the miner and it should be working.

[mlo0352]

The issue was that I was using Windows and obviously didn't even consider trying command line arguments...

The server I'm trying to use is stratum+tcp://us3.wemineltc.com:3333

Doing a quick check shows:

usage: mining_proxy_1.2.0.exe [-h] [-o HOST] [-p PORT] [-sh STRATUM_HOST] [-sp
                          STRATUM_PORT] [-oh GETWORK_HOST] [-gp
                          GETWORK_PORT] [-nm] [-rt] [--blocknotify
                          BLOCKNOTIFY_CMD] [--socks PROXY] [--tor] [-t]
                          [-v]

So then I tried: C:\Users\mlo0352\Desktop\mining\scripts>mining_proxy_1.2.0.exe - sh stratum+tcp://us3.wemineltc.com:3333

Annnnnd it worked...oops. I forget that Windows isn't inadequate when it comes to running things. Lesson learned.

[kramble]

Its always a good idea to have a look through the README's, and also the program messages. The answer to your first question is right there in the screenshot ... it was connecting to pool.itzod.ru ... and if you don't have an account there, its not going to work! . Since you're a linux guy I'm surprised you didn't run the proxy on a linux host (it doesn't need to be on the same box!)

Anyway, good to know its working. The getwork protocol is easier to get up and running with, but it does give more network errors and is pretty much depreciated (the pools that do still support it don't pay it enough attention as nobody much uses it any more)