Topic: [ANN][BLC] Blakecoin Blake-256 for GPU/FPGA With Merged Mined Pools Stable Net - page 122. (Read 409641 times)

Where did you get PyUSB for python 2.7? As I mentioned many posts ago there was no PyUSB for 2.7 that I could find, only for 2.6. Have you tried installing python 2.6 and pyusb for 2.6? I know the readme states python 2.7, but 2.6 is what worked for me. Is the windows 7 you are using 32 bit?

http://bleyer.org/pyusb/


I left X6500-Robust-v05-2core-100MHz-fmax-103MHz.bit running overnight. Initial clock 120 max clock 150. Results in 500-630MHs pool side.

That's because I doubled the default clock from 50MHz to 100MHz. You should really be using the --overclock parameter of mine.py to set the clock speed. Give 120 a try, that should be OK. I suggest gradually increasing it until you start getting HW errors then back it off slightly. You'll need to rely on the pool stats for rejects as the hash error reporting is currently disabled in mine.py (you can turn it back on for characterization if you want).

I've not made much progress on a faster build, but I've seen that I need to add some TIG constraints which should help. Won't get much done today though as family are visiting and my build machine will probably be commandeered for gaming

Python 2.7 32 bit on win7 with Python 2.7 PyUSB-1.6

Same error in ft232r.py
line 22 (first line of code)
import d2xx

Works like a charm, now getting double previous hash rate.

Thank you!

Dual core version https://www.dropbox.com/s/yai3qyklwqy0tny/X6500-Robust-v05-2core-100MHz-fmax-103MHz.bit

It initializes to 100MHz but should overclock up to perhaps 120 or 130MHz.

I did try for faster but the first couple of attempts were failures, so I backtracked to 100MHz. Frustrating business, but it's early days yet.

Running this bitstream now. Clock readback issue has been fixed.

I've got a new test bitstream https://www.dropbox.com/s/fkakrtrn0r02wac/X6500-Robust-v05-1core-100MHz-fmax-118MHz.bit

It's just one core with an initial clock of 100MHz so it should be giving around 200MH/s total for the board. I expect it should overclock up to around 150Mhz. The purpose of this bitstream is just to check that the clock speed readback has been fixed, and that I haven't broken anything, so it will be useful if you could try it out. The 2 core version will take a lot longer to build (and optimizing it for best speed takes an eternity). Anyway, let's see if this works.


Yep, sounds likely. Unfortunately I'm not at all familiar with the stratum code (I just copied kr105's cgminer mods into my fpga version), so I can't offer any help there. Ideally we'd get a driver written for cgminer (there is one already in bfgminer that could be used as a basis), but it's a bit beyond my C programming skill level.

It was above 500MHs for quite a while, only after a long period of time unattended did it drop to these low rates. I seem to be the only one currently using MPBM for this so I would not worry much about it. I am content using mine.py.

TheSevens mods to fix a divide by zero error with stratum and eloipool worked fine. I was able to merge them in. The stratum server always rejects shares though, "unknown work". Must be related to the merkle hash.

Strange. I'd expect around 500MHs for that clock speed. Maybe it's just ramped the clock up too far and you're getting bad hashes (HW errors in cgminer terminology). I'll see if I can work out what MPBM is doing with the clock, but I need to finish my current work on simulations first (almost done, then I'll put on a quick single core build for functional verification).

Yes, hashvoodoo_controller_25.bit. I have no idea why we would get such vastly different results

After an overnight run my x6500 with X6500-Robust-v04-2core-fmax-100MHz.bit, running on MPBM, initial clock 100 max clock 135, MPBM shows an effective hashrate of 272MHs. I left this bitstream going since it seemed to provide a higher hashrate than the 125MHz static clock bitstream. I am now leaving X6500-StaticClock-v01-2core-125MHz.bit for an extended period of time to see where it's hashrate ends up.

You will also have to change the merkle hash as blake uses a single sha256 rather than the double sha256 used in bitcoin. The stratum code is missing in my fork (I only modified the master branch for blake, while stratum is in testing), but it's at around lines 131-132 in TheSeven's original repo. Though it's not quite that simple as the double hash is still used in some places! See cgminer diff. The gen_hash() function was changed to a single hash, but the double hash is still used at line 5487. I'm not quite sure how this will need to be implemented in stratumworksource.py, but I thought you'd want the heads-up.

Further to my last post about the clock speed issues. As understand the problem, it only affects the readback of the clock speed from the FPGA (the clock is always successfully changed). For clock speeds between 64-191MHz the value read is 0xFFFFFFFF, while it should be correct for <64MHz and >191MHz. What is happening is that only 6 bits are shifted into the JTAG user register when setting the address for read, this shifts out the lower 6 bits of the previous clock value, and the remaining bits are all-zero for speeds <64MHz, but at 64MHz a 1 remains in the LSB, which toggles the checksum value (really just a parity bit) and the command is ignored. At 128MHz we get 10 which is also gives an invalid checksum, and only at 192MHz do we get 11 which is valid. I don't know if this is the behavior for the official bitcoin bitstream, but this behavior is in the source code on fpgaminer's github (it may be that the bug is fixed in the official bitstream but did not get published on github).

Anyway I'll do the fix and get a new bitstream built. The fix is trivial, but testing it in simulation is going to be a pain so I'll do the bitstream build in parallel to the simulation and it may well be ready before I've even got the simulation working 

same bitstream CM1-hv-v04a-175MHz-ucf-150-fmax-161.bit

did you use the hashvoodoo on the controller?

Yes I am using all 4 chips. Which bitstream do you use at 1.5GHs? Clock rates show roughly 200MHz per chip. I take it the bitstream you are using gives 2 MHs per 1 MHz? I wonder why mine doesn't

are you sure its all programmed and you are using all 4 chips seems lower than default 

here is my command for cm1 at ~1.5Gh/s on pool

cgminer --disable-gpu --icarus-timing 2.45 -S \\.\COM28 -S \\.\COM29 -S \\.\COM30 -S \\.\COM31 --url stratum+tcp://ny1.blakecoin.com:3334 --userpass Username.Worker:WorkerPass --cainsmore-clock 200,200,190,180

What settings are needed to achieve these stated hashrates?

With --cainsmore-clock 200 and CM1-hv-v04a-175MHz-ucf-150-fmax-161.bit I see ~750MHs pool side.

At first I just thought cgminer was reporting the hashrate /2. But ny1.blakecoin.com shows the same numbers.

Any help is appreciated, thanks in advance.

SPREAD THE WORD: Fri 2/21/14 starting at 6pm EST 0% BUY FEE and 0.15% SELL FEE

Which is exactly 0xFFFFFFFF, which makes some sense. The JTAG code is quite horrible for me to understand (both the python, and to a lesser extent the verilog). There may be something strange going on (there is a checksum bit which looks suspicious as the change from 63 to 64 is just at a binary turnover). Perhaps I broke something in the original blake port from the bitcoin code? I'll have a look. Thanks.

Got it (I think), the python code and verilog are almost, but not quite, talking the same protocol. It's the checksum that's the issue (but only affected by the higher bits of the clock speed), so it makes sense now. The python has been written to the spec (described in the comments at the start of the jtag_comm.v verilog), but the verilog does not actually implement this correctly (the read address checksum should be differently calculated to the write address+data checksum). So it's fixable (if a bit tricky to simulate).

I believe this:
2014-02-20 15:27:15.972   [100]   X6500 board AH01A6C3 FPGA1:    Setting clock speed failed!
2014-02-20 15:27:16.182   [300]   X6500 board AH01A6C3 FPGA0:    Running at 4294967295.000000 MH/s

means that self.stats.speed == 4294967295.000000

?

OK, the MPBM code is doing this

So after a failure to set the speed, we have self.stats.speed != speed, so self.stats.speed is probably garbage which may be the reason for the bad stats. It would be useful to know what the actual value of self.stats.speed is as I still don't understand how this can fail (I'm gazing at the verilog, and it just seems impossible to not read back the same value as it wrote).

Anyway, its the actual pool speed that matters (for valid shares). At some frequency the device is going to start to giving invalid shares. I expect its going to be around the 500MHash/sec range (for the variable clock speed bitstream).


No problem. This is quite a difficult one to get working blind, so it will be good to make some progress. It was rather left in limbo back at the end of October as I moved on to do the ztex and CM1 ports, which is why the hash rate is so slow compared to those ports (it should be able to get 800MHash/sec from each board). If you're happy to test, then I'm happy to supply bitstreams. It will be quite a slow process though (probably be a couple of days). I'll PM you when I've got something.