Cheers! Couldn't have said it better myself.  

Actually I'm pretty much finished with crypto on FPGA now. It is just not worth the investment of my time (and the frustration, see what Blue said about ISE). I did have a look at a couple of other algos (groestl, keccak) and got initial, rather poorly performing, builds working, but the GPUs perform far better. The only advantage for FPGA is power consumption.

As for X11/X13, I reckon it can be done on a LX150, but only via a soft-CPU optimized for hashing. A huge amount of work for a very poorly performing hasher. So I'm not going there.

Anyway, best of luck rupy.

The HW errors are reported on the raw diff=1 shares, but since the pool (currently) accepts at diff=32, it's not quite as bad as it looks. You should be aiming for a HW error rate of a few percent of the diff=1 share rate, so anything less than the accept rate at diff=32 is probably OK (as usual, it's the hash rate reported by the pool that really matters). So you may be able to bump up the clock a little from 175MHz. I was easily achieving 200MHz, though since you've got an early board, it may perform a little worse than the later ones. Good luck

It's useful to set up a failover pool (just add --failover-only and the second pool login credentials). I actually failover to solo mining so that I pick up the occasional pristine block.


Umm, I think that was just about it. I'm not actually doing very much with FPGA at the moment (especially the LX150 which is a right PITA to work with). Just waiting to come up with some cool idea to get stuck into (crypto-mining is pretty much dead on FPGA now, blake is just about the only algo that's worth mining with).

I updated the WU in my previous post to 5.6 per device (60 * 2 * clock * 1000000) / 2^32 ) so you should be seeing around 20 or so for the CM1 board. The pool will tell you the actual rate (should be around 1600MHash/s at 200MHz).

Aww, shucks I'm just an amateur, I learned on Bitcoin https://bitcointalk.org/index.php?topic=9047.0

That said, from my bookmarks

http://www.fpga4fun.com/
http://svenand.blogdrive.com/
http://www.asic-world.com/verilog/veritut.html
http://excamera.com/sphinx/fpga-vhdl-verilog.html#main
http://www.joelw.id.au/FPGA/CheapFPGADevelopmentBoards
http://opencores.org/or1k/Main_Page
http://www.rcis.aist.go.jp/special/SASEBO/SHA3-en.html (the inspiration for the blakecoin miner)
http://cryptography.gmu.edu/athena/index.php?id=source_codes (other crypto algos)

and I'll add some more once I've gone through them properly (apologies Blue if this is off topic).

Yep, that looks good. As long as all four devices are giving accepted hashes at the right sort of rate (WU around 5.6 per fpga 13 I think off the top of my head, I run my lancelot in background I don't see the interactive display, I'll need to check back through the thread to see what others are getting with the CM1). If you run it with the --verbose switch you'll see the difficulty=1 shares being reported in the log (the pool accepts at diff=32 so most of them will be above-targets, but it will show that it's working).

Use "--icarus-timing 1.0=20" instead of long as this gives better control of the work (20 is one work refresh every 2 seconds). You don't want the nonce wrapping and the devices going idle (yellow led).

I think the problem with the early boards was that only three of the four fpgas would work reliably (the clock signal was poorly routed and picked up noise), so you may still be mostly OK.


It's a long time ago since I worked with this, and the board's since been returned to BlueDragon so I don't think I'm going to be able to help much, but here goes anyway (from memory)...

Spiprog.exe is in http://www.enterpoint.co.uk/cairnsmore/CAIRNSMORE1_CONTROLLER_SHARING_V1_5.zip and you'll need to copy hashvoodoo_controller_25.bit into the same folder (get it from https://github.com/downloads/pmumby/hashvoodoo-fpga-bitcoin-miner/hashvoodoo_release_09_23_2012.zip), then open a DOS command prompt and navigate down to the right place (shift-rightclick on the folder then open command prompt is a useful shortcut under more recent versions of windows).

As for mining, best to post your cgminer command string (and config file if you're using one). You need to use my custom version from https://github.com/kramble/FPGA-Blakecoin-Miner/tree/master/cgminer/cgminer-3.1.1 (and I assume you're running on windows?). Run it with the -T and -D switches and redirect the output to a log file with 2>log.txt then post that up.

There is not much I can add to what has been said by BlueDragon and sidgrip. Just be sure to load the hashvoodo firmware via spiprog (or impact) before flashing the blake bitstream. I'll add those notes to the CM1 github README as it's a bit terse at the moment. EDIT: OK, that's done. Let me know if I can improve it or if there are any errors.

I didn't find the CM1 to be very reliable (at least the one I was testing on, borrowed from BlueDragon) as it kept dropping off the USB every few hours, needing a complete power cycle (including disconnecting and reconnecting the USB cable) to reset it. While the CM1 appears to be of really good build quality, there were some design issues with the USB, the clock distribution and the broken serial chaining of the FPGA devices. Later devices were apparently slightly better (serial number 0051 onwards, see here), but I don't know if Enterpoint ever got it properly up to production quality (and I'm not reading all the way through that thread to find out). There is also some useful background information on the Hashvoodo thread.

I'm not a github expert either, am using windows client myself. BlueDragon may be able to help though. Or just put a note in the README (most users don't bother with the daemon I expect).

All donations are gratefully received. Might as well use eKramgtvXd45wgW3HYNCtUyPm5uqTXzHyz (eating my own dogfood   )

Vanitygen for electron

Continuing from the blakecoin thread ...


I've tested this using the electrond daemon on unbuntu 12.04 (not tested sending any coin yet I have tasted my own dogfood and it's yummy ELT to eKram and eKram to eCoin)

You need to start with my hacked version of vanitygen from https://github.com/kramble/FPGA-Blakecoin-Miner/tree/master/vanitygen

You will need to compile it yourself (works ok on raspi and ubuntu, not tested on windows), but first edit two files:
util.c line 129, change if (blake_flag == 26) to if (1)
vanitygen.c line 397, change if (addrtype == 26) to if (1)
make vanitygen (OK on ubuntu, but raspi needs the top line of Makefile editing to remove -march=native)

Now run it
./vanitygen -F compressed -X 92 eCoin

And annoyingly, it works fine on raspi but takes a while to get going on ubuntu. Perhaps because I ran it in a VM?

As a side issue, you need to make a couple of changes in your git repo to fix the daemon build
mkdir src/obj
chmod +x src/leveldb/build_detect_platform

Yes, that's a perfectly good way of generating keys, with the proviso that this can all be done on an off-net system, or even a ubuntu live-cd (it just needs to be online for a short period to run the apt-get's for the wallet dependencies, and I'm not sure even this step is needed as the runtime versions may already be present in the base distribution so you just need a precompiled wallet). Note that blakecoin-qt (or blakecoind which is easier to use for this purpose) does not need to be online in order to generate addresses, so everything can be done totally sterile (you just have to hope the NSA haven't compromised the RNG [/paranoia]).

Taking it one step further, all you need to generate a private key is a cryptographically secure random number generator (even a set of dice will do the job). Once you have the 256 bit / 32 byte private key it is a straightforward process to derive the address. Take a look at this script which demonstrates the steps (it actually implements a blakecoin brain wallet, but can be trivially tweaked to accept the private key instead). Props to JackJack for the heavy lifting (it's based on his pywallet).

One thing that I have done myself is to use bitaddress.org (downloaded from github onto a usb-stick, then loaded onto an offline system, I use puppylinux on an ancient PC) which can generate addresses in bulk to a csv file. Ignore the bitcoin addresses and just use the private key values. Feed these into a variant of the above python script that reads private keys from a file and writes out the privkey + blake address. Note that the Wallet Import Format for the blake private key is not compatible with bitcoin WIF private keys, just like the addresses it needs a blake hash checksum, though we can trivially work around this in python by simply ignoring the checksum when reading the bitcoin WIF privkey (see WIFpriv2addr in the script above).

OK, it should just work using ./vanitygen -F compressed -X 92 pattern (using my hacked version at https://github.com/kramble/FPGA-Blakecoin-Miner/tree/master/vanitygen) EDIT: No it won't work as is, since the blake checksum is only applied to -X 26. You'll need to change util.c (see the previous commit for the file), around line 129. EDIT2: Also vanitygen.c line 397 may need changing. So I've got three variants of the code to check, need to compile an electron wallet first (2 hour job on raspi, quicker on ubuntu, once I sort out a VM for it). EDIT3: That took longer than I expected. Yes, both changes are needed, I'll take this onto your thread now as it's OT here.

Give it a try (check if the electron wallet will import the private key, and that the resulting address is the same as the one generated). Also try sending some coin to the addresss, then import the private key (into an empty wallet) and try spending the coin.

Mogrith: Doing a paper wallet (like bitaddress.org) is beyond my skill set, but a competent web/javascript developer should be able to do it easily. It just needs a javascript version of blake256, 8 round variant (which is the slightly tricky bit) to do the custom checksum.

It's getting late here, so I'll go look at this tomorrow (it's a while since I worked on this and I'm a bit rusty).

Anyway, Blake addresses are the same as Bitcoin, except with a different network byte. That much is the same as any other alt-coin, and if that was all then the standard vanitygen could generate the addresses.

Two differences: blake uses the blake8 hash to generate the address checksum (last few characters) instead of sha256, and we need to use the compressed address (the standard vanitygen only creates uncompressed).

I'll need to look at what electron does.

Yep, gotcha. I was being a bit nannyish I suppose. ZiG's comment was very helpful though, thanks!

Did you see the chip input clock speed in the datasheet, 12MHz. I think we were assuming 32MHz from the Blizzard schematics, and you were talking about using 42.2 MHz in this post. This probably needs a rethink if the blizzard schematic was a typo. The next step up from 115200 baud is 153600, which is a 33% increase, so a 16MHz crystal should do it (but will need a recompile of the windows executable, and I think won't work on linux).

You do risk destroying the chips if you overvolt them. I don't know the absolute limits for the 55nm process (google has not been very helpful so far). Even if they work at a given voltage, the devices may degrade and die at some later time.

Yes, pad_bypass switches the internal hash clock source between the PLL output and the bpclk input pad. Eyeballing the layout masks on the schematic, it looks like these pads are unrouted, but it may be possible to make connection with them (depending on your SMT rework skills).

The problem with the PLL is telling it what multiply/divide ratio to use. Divide seems to be 8, but the configuration field only goes up to 255 so we are limited to 255/8 * 12MHz = 382.5MHz maximum. Unless there is some undocumented way of changing the divide ratio or supplying a higher multiplier (seems unlikely, but then there are those TEST pins; but even if it is possible, it's not going to be practical with the existing boards). I was hoping there might be something in the command protocol to allow a higher clock multiplier than 255 to be specified, but that's rather grasping at straws.

Great, that's (almost) exactly what we were looking for (a little extra detail on TESTMODE/EN and MODESEL would have been nice, but I won't quibble).

One slight confusion is the 12MHz clock input, whereas the Blizzard schematic shows Y1 as 32M (though the X32A schematic shows 12M so perhaps that's a typo). It would be useful to measure the clock speed at the oscillator via a scope just to confirm this.

So it looks like we could bypass the clock input and clock directly via BPCLK while still retaining the 12MHz baud clock. The spec only says 200MHz though, which is a lot slower than I'd like, but perhaps this is just being conservative.

It still might be better to replace the 12MHz crystal with a slightly faster one and just up the baud rate in the driver to match, as pushing a 400MHz raw clock onto the chip seems unlikely to work very well.

That is exactly the behavior I'd expect if clock code 255 (383MHz) is simply being ignored by the ASIC (as in the verilog I linked a couple of posts above).

I suppose Windows ought to work something like
--set zus@\\.\COM4:ignore_golden_nonce=1
or
--set zus@//./COM4:ignore_golden_nonce=1

(One of my pet niggles about DOS/windows is it's use of the wrong slash for paths, unix came first, why not follow the standards Microsoft, oh, it's because you want to do it differently just because you can. Then oops, you just broke character escaping in C, shells, etc etc </rant>)

Do you use it like this?

It depends on whether they treat 255 as a valid clock speed (my FPGA code does not, see here). I'm curious about whether it works too!


In the UK I use Farnell. No delivery charge for any size order (pretty insane really, I once ordered a single device in a 144 pin TQFP package and it came packed in a 60 chip carrier array in a huge box, must have cost them more to send it than the chip was worth!).