[ANN][BLC] Blakecoin Blake-256 for GPU/FPGA With Merged Mined Pools Stable Net

[kramble]

Thanks.  I'll tinker around to see what I can break :-)

Try setting the overclock parameter (not too high, no more than say 150MHz), and see what value gets read back. I'm somewhat bemused that its reporting a clock speed of 26MHz while the initial value is hard coded at 50Mhz (almost but not quite double). In binary that's 11010 as opposed to 110010 so its not obvious how these can be conflated.

I think the best approach to debugging this is to get the comms working reliably first (so if your python is up to it you could try writing and reading back the registers, see jtag_comm.v for details), then possibly swap out my serial bus optimizations for the earlier wide-bus version as this does not then rely on a comm_new_work strobe to initiate the hasher).

I can do some testing on my Lancelot, once I've worked out how to drive the jtag bus outwith of Impact.

[1714160210]

1714160210

[1714160210]

1714160210

[1714160210]

1714160210

[1714160210]

1714160210

[1714160210]

1714160210

[bronan]

which fpga are you using kramble ?

[kramble]

which fpga are you using kramble ?

Xilinx Spartan6 LX150, pretty ubiquitous for the bitcoin FPGA miners (with the exception of BFL who went for a locked-down Altera chip). I've just got the one Lancelot board myself, but it should be fairly easy to port to the other boards: Ztex, Cainsmore, Modminer (notwithstanding the hiccup we're currently having with the X6500).

[atavacron]

Thanks.  I'll tinker around to see what I can break :-)

Try setting the overclock parameter (not too high, no more than say 150MHz), and see what value gets read back. I'm somewhat bemused that its reporting a clock speed of 26MHz while the initial value is hard coded at 50Mhz (almost but not quite double). In binary that's 11010 as opposed to 110010 so its not obvious how these can be conflated.

I think the best approach to debugging this is to get the comms working reliably first (so if your python is up to it you could try writing and reading back the registers, see jtag_comm.v for details), then possibly swap out my serial bus optimizations for the earlier wide-bus version as this does not then rely on a comm_new_work strobe to initiate the hasher).

I can do some testing on my Lancelot, once I've worked out how to drive the jtag bus outwith of Impact.

My python fu isn't very good but since I like a challenge I'll see what I can do.

[kramble]

My python fu isn't very good but since I like a challenge I'll see what I can do.

Cheers, it can't be worse than mine (just mind those spaces/tabs, whoever had the bright idea that whitespace should be syntax deserves, well, something not nice ). See if you can work out if the data is getting into/out of the fpga OK. Also run it with the verbose flag and turn on all the debug stuff so you can see what its actually doing.

I'll put together a more robust build tomorrow that avoids all that messy clock-crossing and serial-shifting. Perhaps its just idle because I'm not handling the comm_new_work strobe properly. Shame there are no leds on that board we can flash to see what its getting up to 

[bronan]

Just for information 7970 at 900 mhz core and memory at 300 mhz does give 2.2 Gh on blakecoin

Intensity 7,  worksize 64

This card soon gets replaced by a R9 290X

[atavacron]

My python fu isn't very good but since I like a challenge I'll see what I can do.

Cheers, it can't be worse than mine (just mind those spaces/tabs, whoever had the bright idea that whitespace should be syntax deserves, well, something not nice ). See if you can work out if the data is getting into/out of the fpga OK. Also run it with the verbose flag and turn on all the debug stuff so you can see what its actually doing.

I'll put together a more robust build tomorrow that avoids all that messy clock-crossing and serial-shifting. Perhaps its just idle because I'm not handling the comm_new_work strobe properly. Shame there are no leds on that board we can flash to see what its getting up to 

There are three LEDs on the board, one at the power input and two at the far sides of the FPGAs with the label "Done".  At power on the two "Done" LEDs are off.  However, there turn on just after loading the bitstream.

[Vorksholk]

http://www.blakecoinmining.com/BlakecoinGUIMiner.zip <--- Compiled Binary
http://www.blakecoinmining.com/BlakecoinGUIMinerSource.zip <-- Source

Will put up more detailed information later.
Here's a screenshot:

[SpeedDemon13]

http://www.blakecoinmining.com/BlakecoinGUIMiner.zip <--- Compiled Binary
http://www.blakecoinmining.com/BlakecoinGUIMinerSource.zip <-- Source

Will put up more detailed information later.
Here's a screenshot:

What runs in the backend of the software: CGminer or Reaper? Will the final version have more stats to show?

[SpeedDemon13]

Nevermind, just checked it out, it's Reaper...lol

[Eli0t]

cuda miner would be nice...

[loveys]

need a pool

[Vorksholk]

need a pool

Pools are hopefully coming pretty soon

[mogrith]

Pool will be nice dif is rising. Which is good as it means lots of miners ( or at least lots of MH/s).

I'm happier getting 5 coins every hour than 50 coins every 10 hrs even if it the same amount over time.

[kramble]

There are three LEDs on the board, one at the power input and two at the far sides of the FPGAs with the label "Done".  At power on the two "Done" LEDs are off.  However, there turn on just after loading the bitstream.

Unfortunately DONE is a dedicated configuration pin, not user drivable, but it is useful as it tells us the bitstream has been successfully loaded. Here is the (simplified) schematic.

Just starting on the robustified version (I'll take out the results FIFO too as that's a black-box NGC file which could be an issue due to different versions of ISE). Should be done sometime later today.

[SpeedDemon13]

I have been working on and have finished the Blakecoin wallet and Cpu miner.

http://www.blakecoin.org

Released yesterday but due the site being down I was not able to post on here until now:
https://forum.litecoin.net/index.php/topic,6280.0.html

Forked from Bitcoin reference wallet 0.8.5

Blakecoin Wallet is on Github
https://github.com/BlueDragon747/Blakecoin

Blake-256(optimized) faster than Scrypt and faster than SHA-256 in Sphlib C code

The algorithm was written as a candidate for SHA-3, Based on round one candidate code from the Sphlib 2.1 library and reduced the round function to 8 rounds.

Tweaks:
Removed some of the double hashing from the wallet relating to proof of work, No changes to the wallet ecdsa public/private key function that has proven to be secure for Bitcoin.

Block reward is 25 coin + inflation (square root of (difficulty + block height))
No halfing of reward after x blocks
Cap in place to reduce the difficulty jumps upwards
Block target time is 3 minutes and retargets every hour
7 Billion coins
Block maturity 120

The Cpu miner is on Github
https://github.com/BlueDragon747/cpuminer

Benchmarks performance:

• 11000 khash/s on a Intel i7 2600k Cpu
• 3500 khash/s on a Intel Core2 E7300 Cpu
• 100 khash/s on Raspberry Pi Arm Cpu (thanks to kramble for testing)
• 14250 khash/s on a Intel Core i7 3930K (thanks to sgrunger for testing)
• 11200 khash/s on a AMD Phenom II X6 1090T (thanks to sgrunger for testing)
• 7022 khash/s on a Intel Core i7-920s (thanks to sgrunger for testing)
• 12000 khash/s on a Amd FX-8350 (thanks to Vorksholk for testing)
• 4000 khash/s on a AMD A10-5800k (thanks to reecelander for testing)
• 10600 khash/s on a Intel Core i7 3820 (thanks to ciklop1974 for testing)
• 8700 khash/s on a Intel Core i5 2500k (thanks to Vorksholk for testing)
• 10400 khash/s on a AMD FX-8150 (thanks to Aalesund for testing and finding the display bug)
• 3800 khash/s on a Intel T4500 (thanks to SpeedDemon13 for testing)

to benchmark
minerd --benchmark -a blake

Wallet Binaries:

Windows
http://blakecoin.org/Blakecoin-0.8.6-WIN.7z

Linux
http://blakecoin.org/Blakecoin-0.8.6-LIN.7z

Add the following nodes to your conf:
addnode=162.243.133.80
addnode=162.243.14.130
addnode=146.185.135.24
addnode=184.171.247.23 (thanks to Vorksholk)

CPU Miner Binaries:
Windows Intel compiled for core2+
http://blakecoin.org/Blakecoin_Minerd.7z

blakecoin.conf example:

listen=1
gen=0
rpcallowip=127.0.0.1
rpcuser=username
rpcpassword=password
rpcport=8772
server=1
daemon=1
addnode=162.243.133.80
addnode=162.243.14.130
addnode=146.185.135.24
addnode=184.171.247.23

you can set gen to 1 or use the command: setgenerate true if you wanted to use build in mining(bit slower than minerd)

minerd command example:

minerd -o 127.0.0.1:8772 -O username:password -a blake -q -s 2 --no-longpoll --no-stratum

Happy mining  

Update:
Thanks to the efforts of kramble, Blakecoin has been successfully ported to the FPGA (early development)

FPGA-Blakecoin-Miner by kramble
https://github.com/kramble/FPGA-Blakecoin-Miner

For information an FPGA is not a SHA-256d Asic it is a re-programmable hardware device e.g a software defined hardware device used for hardware development and high speed custom logic.

Thanks to the efforts of Vorksholk and smolen, Blakecoin has been successfully ported to Reaper with OpenCL on the GPU

http://blakecoinmining.com

Thanks to the efforts of melnikalex, Blakecoin has been successfully ported to cgminer with stratum and OpenCL on the GPU

cgminer for Blakecoin
http://blakecoin.org/cgminer-blake256.7z
cgminer for Blakecoin source code
http://blakecoin.org/cgminer-blake256-src.7z

I don't know if anyone has asked yet, but will you have a blockchain explorer soon? That would help markets to trust and accept the coin more.

[atavacron]

There are three LEDs on the board, one at the power input and two at the far sides of the FPGAs with the label "Done".  At power on the two "Done" LEDs are off.  However, there turn on just after loading the bitstream.

Unfortunately DONE is a dedicated configuration pin, not user drivable, but it is useful as it tells us the bitstream has been successfully loaded. Here is the (simplified) schematic.

Just starting on the robustified version (I'll take out the results FIFO too as that's a black-box NGC file which could be an issue due to different versions of ISE). Should be done sometime later today.

Ah, I see.  At least the LEDs are of some use.

I'll be AFK for some time at work.  I'll check back with you as soon as I return home.

[kramble]

I'll be AFK for some time at work.  I'll check back with you as soon as I return home.

New version is now up https://github.com/kramble/FPGA-Blakecoin-Miner/tree/master/experimental/X6500-Robust

Bitstreams (same code, just different initial DCM synthesis clock) ...

https://www.dropbox.com/s/58bkb5k4ts8k7j1/X6500-Robust-v02-fmax-100MHz.bit
https://www.dropbox.com/s/lygc90a0xz9el4q/X6500-Robust-v02-fmax-150MHz.bit

Try them both, its possible the faster one was causing problems before.

Since I removed the output FIFO I took the time to do some simulation of the jtag_comm, so hopefully this will work. If not then I'm going to have to do a build for the Lancelot and debug the JTAG I/O with that. I expect this will take some significant time.

[atavacron]

I'll be AFK for some time at work.  I'll check back with you as soon as I return home.

New version is now up https://github.com/kramble/FPGA-Blakecoin-Miner/tree/master/experimental/X6500-Robust

Bitstreams (same code, just different initial DCM synthesis clock) ...

https://www.dropbox.com/s/58bkb5k4ts8k7j1/X6500-Robust-v02-fmax-100MHz.bit
https://www.dropbox.com/s/lygc90a0xz9el4q/X6500-Robust-v02-fmax-150MHz.bit

Try them both, its possible the faster one was causing problems before.

Since I removed the output FIFO I took the time to do some simulation of the jtag_comm, so hopefully this will work. If not then I'm going to have to do a build for the Lancelot and debug the JTAG I/O with that. I expect this will take some significant time.

Well, it seems to be doing something interesting.  I've got rejects.

I loaded "X6500-Robust-v02-fmax-100MHz.bit" with x6500-miner and ran the miner.  Below is the a clip of the output prior to and including the program exit.

"X6500-Robust-v02-fmax-150MHz.bit" would load but sat idle when using the miner.

Code:

hash cbbc7c728d2c30660a37dae6e6363caa0cb3929466a327ceb3c811ac00000000
2013-10-29 00:10:27 | rejected 37c6d309
0 kH/s | 0/5/0 100.00%/0.00%midstatehex= 178f52078ab83a108e0303f153ac22018a9cb00fe3d7d48d12eb1aa8c2e99310
midstatehex= c555571b3acf3a6203b8ffabd6b7c195caf2e242888239e9f8fd51a0eb4b99de
0 kH/s | 0/5/0 100.00%/0.00%hrnonce= e0f3da0e
hash f2ccafb0ce960609f78b1d85966f1d0a922ac13d731e6d12b51a7cd600000000
2013-10-29 00:10:35 | rejected edaf3e0
0 kH/s | 0/6/0 100.00%/0.00%midstatehex= 8e90b7bf6520b2fb0ebef042aaffa274677b03ed17915a979822bbec663f52bf
midstatehex= 98c2d76b50e9d5ebefee845c66a606137a3d18f65684cbc1318c95e4b0ab2979
0 kH/s | 0/6/0 100.00%/0.00%hrnonce= 13c5b612
hash 779615cc24e81a7f836954f5bd5a45efe4efbe3a7a05bc0cac02099800000000
2013-10-29 00:10:58 | rejected 12b6c513
0 kH/s | 0/7/0 100.00%/0.00%midstatehex= bbd55aa308f3dd6f607aa8d4ec23948121395bab3f4b06c6ce484611f433d06b
midstatehex= 96b5c3359fc7b9f6498e670d31e0fdf3c1a3f2a2235cb210fbea27a7a2b64c48
0 kH/s | 0/7/0 100.00%/0.00%midstatehex= 0b67fbdf3761c5f5ca752ba1fd1abc7e549ac481c12c7607ea694448bd10554a
midstatehex= c498a5ff5d05af0ee06f62d9152887e936f78859d2e514108a7c444b7bab681b
2013-10-29 00:11:39 | Exiting...

Run Summary:                
-------------
Device: 0
Serial: A5VNUHQI
Number of FPGAs: 2
Running time: 5m26s
Getwork interval: 20 secs
FPGA 0:
  Accepted: 0
  Rejected: 3 (100.00%)
  Invalid: 0 (0.00%)
  Hashrate (all nonces): 39.45 MH/s
  Hashrate (valid nonces): 0 kH/s
  Hashrate (accepted shares): 0 kH/s
FPGA 1:
  Accepted: 0
  Rejected: 4 (100.00%)
  Invalid: 0 (0.00%)
  Hashrate (all nonces): 52.60 MH/s
  Hashrate (valid nonces): 0 kH/s
  Hashrate (accepted shares): 0 kH/s
Total hashrate for device: 92.05 MH/s / 0 kH/s / 0 kH/s

[kramble]

Well, it seems to be doing something interesting.  I've got rejects.

I loaded "X6500-Robust-v02-fmax-100MHz.bit" with x6500-miner and ran the miner.  Below is the a clip of the output prior to and including the program exit.

"X6500-Robust-v02-fmax-150MHz.bit" would load but sat idle when using the miner.

Great! Its working fine. The hashes are valid (eight trailing zeros, difficulty 1), so you just need to wait until it finds one that's less than the network difficulty and you've got yourself a block. In explaination, the fpga miner returns difficulty one hashes (just like in bitcoin). If you were mining against a pool these would all be credited as shares, but since you're solo mining they will (almost) all be rejected. However you will need to wait a long time for a block at those hash rates, eg ...
[6 accepted, 15215 failed] from my current log (been running around 24 hours).

You could try pushing up the clock rate using the --overclock argument, just increase it until you get a significant number of invalid hashes (anything that does NOT have eight trailing zeros), then back it off a bit. You can comment out the midstatehex print at line 358 of fpga.py if this is annoying (its just there for debugging.

It is rather strange than the 150MHz build does not work, as it should still boot up at 50MHz and the initial overclock should not affect the JTAG/DCM. Must be some weird failure mode. Anyway now we know the basic code works I'll do some more builds to add in the second core and the output FIFO. Then its just a matter of testing each variant to see what works and what doesn't. Should eventually get the hash rate up towards that goal of 800Mhash/sec for the pair of fpgas