very low hashrate

[xiwan]

My board is de2-115, and I transmitted the generated sof to my board. However, the ltminer run good, but the the hashrate is only about 1.44kH/s, which was far from your previous guess (8kH/s). Even worse part was that the pool didn't display my worker's hashrate. This is so wearied. Was my hashrate invalid? why not rejected?

Please help me through this problem, and thanks in advance.

[kramble]

If you're using https://github.com/kramble/FPGA-Litecoin-Miner/tree/master/DE2-115-Single then that hash rate is to be expected. Its just a single core implementation of a very early version of the architecture. I didn't test it myself as I don't have the de2-115 board, so congratulations on getting it to work.

Have a look at https://github.com/kramble/FPGA-Litecoin-Miner/tree/master/experimental/DE2-115-SLOWSIXTEEN which is a more recent version. Again it is untested by myself, but has been reported to work (but only when adapted to a SoCKit device).

Good luck.

[xiwan]

Thanks buddy. But you still not explain why the pool not accept my worker's hashrate?
I will try the new version and give you feedback.
Thanks very much!

[kramble]

The pool problem could have many causes. The tcl mining scripts for the altera devices use the getwork protocol which is no longer supported by many pools. The workaround is to use a stratum proxy server, though this also has some bugs. There is some information on setting this up in the README files.

The first step to debugging this is to check that you are successfully receiving work from the pool. Also check your user name, worker name and password carefully as some pool software (eg MPOS) will supply work to an invalid username, but fail to credit any shares submitted.

I'm not going to be able to devote much time to helping you as this project is no longer a priority (it's just not worth mining scrypt coins on FPGA, the returns are tiny), but I'm happy that you found it interesting.

[xiwan]

As you mentioned the new version only adapted to sockit, my board (cyclone vi) didn't fit for the design. The reality was frustrating . However, I found some intereting in this project. In order to change the code to adapt my current board, there are two ways in front of me: 1. modify the single version; 2 modify the slow16; do you have any guidance for me to have a quick beginning?

BTW, you are nice guy:)

[kramble]

I was a little surprised it did not fit a DE2-115 as I did a test compilation a while back on the EP4CE115F29C7 which only took up 51kLE of the 115k available. I didn't do the full synthesis though, there was no point as I don't have the board, I just wanted to confirm the experimental/DE2-115-SLOWSIXTEEN code would compile (it needed a small tweak from the LX150 version as Quartus did not like one of the if statements). But I've taken another look at the device spec, and it looks like it has insufficient RAM for the 4MBit required (it only has 3.8MBit). You could try building it with just 2MBit of RAM. It's been quite a while since I worked on the code, but I think you can just change line 54 of ltcminer.v to read ...
parameter ADDRBITS = 11 - clog2(LOCAL_MINERS);

Alternatively, as you say, you could adapt the earlier single threaded code and employ up to three independent cores (or six if you employ the interpolated HALFRAM core). Use DE2-155-Single project, then it's just a matter of changing the LOCAL_MINERS parameter in ltcminer.v to specify the number of cores, and uncommenting `define HALFRAM in hashcore.v if you want to enable the interpolated version (it uses half the ram, so you can fit 6 or possibly 7 cores).

Good luck with it, and thanks for the kind words.