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

[atavacron]

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  

Awesome!!!

I'll be available most of the day (EST) if you want me to test further changes.

[kramble]

Awesome!!!
I'll be available most of the day (EST) if you want me to test further changes.

I'm currently building a 2 core version, but it can take several hours (the xilinx tools are a real PITA, place & route is pretty much a lottery as to how well it proceeds). I'll let you know when the first one is done (its just a slow 60MHz build for now as that gives the best chance of a quick result).

In the meantime you could give the overclocking a try, it will be useful to see how fast it will clock. Then just let it hash, perhaps you'll get a block (though at the current 7k difficulty that may take a while) 

[atavacron]

Awesome!!!
I'll be available most of the day (EST) if you want me to test further changes.

I'm currently building a 2 core version, but it can take several hours (the xilinx tools are a real PITA, place & route is pretty much a lottery as to how well it proceeds). I'll let you know when the first one is done (its just a slow 60MHz build for now as that gives the best chance of a quick result).

In the meantime you could give the overclocking a try, it will be useful to see how fast it will clock. Then just let it hash, perhaps you'll get a block (though at the current 7k difficulty that may take a while) 

OK.  I'm running overclock'd right now.

Wow, 7k diff. 

[kramble]

OK.  I'm running overclock'd right now.

Wow, 7k diff. 

Cheers. The new build is done (sometimes it can go quickly) ...

https://www.dropbox.com/s/77wg1smijyfpvx3/X6500-Robust-v03-2core-fmax-60MHz.bit

The timing report gives 71MHz as max speed, so in practice you may get 90-100MHz out of it (still well below the 200MHz for my current lancelot build, but its still somewhere around 400Mhash/s for the pair of devices). Just going to start off a 100Mhz build now (this will probably take much longer as its well above the 71MHz initial max, perhaps I'll just do a 80Mhz one first).

Let me know if the new build works (I may well have introduced some bugs with the multicore port).

[atavacron]

OK.  I'm running overclock'd right now.

Wow, 7k diff. 

Cheers. The new build is done (sometimes it can go quickly) ...

https://www.dropbox.com/s/77wg1smijyfpvx3/X6500-Robust-v03-2core-fmax-60MHz.bit

The timing report gives 71MHz as max speed, so in practice you may get 90-100MHz out of it (still well below the 200MHz for my current lancelot build, but its still somewhere around 400Mhash/s for the pair of devices). Just going to start off a 100Mhz build now (this will probably take much longer as its well above the 71MHz initial max, perhaps I'll just do a 80Mhz one first).

Let me know if the new build works (I may well have introduced some bugs with the multicore port).

Got it.  Testing now.

[atavacron]

OK.  I'm running overclock'd right now.

Wow, 7k diff.  

Cheers. The new build is done (sometimes it can go quickly) ...

https://www.dropbox.com/s/77wg1smijyfpvx3/X6500-Robust-v03-2core-fmax-60MHz.bit

The timing report gives 71MHz as max speed, so in practice you may get 90-100MHz out of it (still well below the 200MHz for my current lancelot build, but its still somewhere around 400Mhash/s for the pair of devices). Just going to start off a 100Mhz build now (this will probably take much longer as its well above the 71MHz initial max, perhaps I'll just do a 80Mhz one first).

Let me know if the new build works (I may well have introduced some bugs with the multicore port).

Darn.  The new build doesn't seem to work...the FPGAs think that they are running @ 1073741823MHz.  I also tried forcing the overclock to 60MHz but it didn't change anything.

Code:

python mine.py -d 1 -u 127.0.0.1:8772 -w <username:password> --verbose
2013-10-29 10:22:33 | Device 1 opened (A5VNV3JE)
2013-10-29 10:22:33 | Discovering FPGA 0...
2013-10-29 10:22:34 | 0: Waking up...
2013-10-29 10:22:34 | Found 1 device:                            
2013-10-29 10:22:34 |  FPGA0: Spartan 6 LX150 - Firmware: rev 4, build 2
2013-10-29 10:22:34 | Discovering FPGA 1...
2013-10-29 10:22:34 | 1: Waking up...
2013-10-29 10:22:34 | Found 1 device:                           
2013-10-29 10:22:34 |  FPGA1: Spartan 6 LX150 - Firmware: rev 4, build 2
2013-10-29 10:22:34 | Connected to 2 FPGAs
2013-10-29 10:22:34 | FPGA 0 is running at 1073741823MHz
2013-10-29 10:22:34 | FPGA 1 is running at 1073741823MHz
2013-10-29 10:22:34 | Connecting to server...
2013-10-29 10:22:34 | Connected to server                       
2013-10-29 10:22:34 | 0: Clearing queue...                      
2013-10-29 10:22:38 | Exiting...                                  
Run Summary:                                                    
-------------
Device: 1
Serial: A5VNV3JE
Number of FPGAs: 2
Running time: 4s
Getwork interval: 20 secs
FPGA 0:
  Accepted: 0
  Rejected: 0 (0.00%)
  Invalid: 0 (0.00%)
  Hashrate (all nonces): 0 kH/s
  Hashrate (valid nonces): 0 kH/s
  Hashrate (accepted shares): 0 kH/s
FPGA 1:
  Accepted: 0
  Rejected: 0 (0.00%)
  Invalid: 0 (0.00%)
  Hashrate (all nonces): 0 kH/s
  Hashrate (valid nonces): 0 kH/s
  Hashrate (accepted shares): 0 kH/s
Total hashrate for device: 0 kH/s / 0 kH/s / 0 kH/s

[kramble]

Darn.  The new build doesn't seem to work...the FPGAs think that they are running @ 1073741823MHz.  I also tried forcing the overclock to 60MHz but it didn't change anything.

Darn indeed. 1073741823 is 3FFFFFFF so I'm guessing that the problem is in the JTAG interface (just like the 150MHz version that was reporting 26MHz for the clock frequency instead of 50Mhz). It would be useful to know if the "working" build is reporting the correct clock frequency on readback (and what the max working freq is). I'll do that 100Mhz build anyway as it may be some weird effect of the initial DCM clock which is breaking it so it may just work.

So it looks like I'm going to have to debug the JTAG on my lancelot after all. That's going to be quite challenging (I'll need to swap out the ft232 driver and write a custom one to drive the Xilinx platform cable, luckily its a parallel port so no reverse engineering needed). This is going to take all week I expect. In the meantime I'll tinker with the code a bit more if you don't mind doing an occasional test run.

[atavacron]

Darn.  The new build doesn't seem to work...the FPGAs think that they are running @ 1073741823MHz.  I also tried forcing the overclock to 60MHz but it didn't change anything.

Darn indeed. 1073741823 is 3FFFFFFF so I'm guessing that the problem is in the JTAG interface (just like the 150MHz version that was reporting 26MHz for the clock frequency instead of 50Mhz). It would be useful to know if the "working" build is reporting the correct clock frequency on readback (and what the max working freq is). I'll do that 100Mhz build anyway as it may be some weird effect of the initial DCM clock which is breaking it so it may just work.

So it looks like I'm going to have to debug the JTAG on my lancelot after all. That's going to be quite challenging (I'll need to swap out the ft232 driver and write a custom one to drive the Xilinx platform cable, luckily its a parallel port so no reverse engineering needed). This is going to take all week I expect. In the meantime I'll tinker with the code a bit more if you don't mind doing an occasional test run.

Sure.

It looks like the max freq using "X6500-Robust-v02-fmax-100MHz.bit" is 63MHz.  If I try 64MHz the reported freq is 4294967295MHz and the miner sits idle.


63MHz

Code:

python mine.py -d 0 -u 127.0.0.1:8772 -w <username:password> --verbose --overclock 63

2013-10-29 10:52:02 | Device 0 opened (A5VNUHQI)
2013-10-29 10:52:02 | Discovering FPGA 0...
2013-10-29 10:52:03 | 0: Waking up...
2013-10-29 10:52:03 | Found 1 device:                            
2013-10-29 10:52:03 |  FPGA0: Spartan 6 LX150 - Firmware: rev 4, build 2
2013-10-29 10:52:03 | Discovering FPGA 1...
2013-10-29 10:52:03 | 1: Waking up...
2013-10-29 10:52:03 | Found 1 device:                           
2013-10-29 10:52:03 |  FPGA1: Spartan 6 LX150 - Firmware: rev 4, build 2
2013-10-29 10:52:03 | Connected to 2 FPGAs
2013-10-29 10:52:03 | FPGA 0 is running at 63MHz
2013-10-29 10:52:03 | FPGA 1 is running at 63MHz
2013-10-29 10:52:03 | Connecting to server...
2013-10-29 10:52:03 | Connected to server                       
2013-10-29 10:52:03 | 0: Clearing queue...                      
2013-10-29 10:52:03 | 0: Queue cleared                          
2013-10-29 10:52:03 | 1: Clearing queue...                      
2013-10-29 10:52:03 | 1: Queue cleared                          
2013-10-29 10:52:03 | 0: Loading new job...                     
2013-10-29 10:52:03 | 0: Writing job...                         
0 kH/s | 0: 0/0/0 0.0%/0.0% | 1: 0/0/0 0.0%/0.0% | 0s | A5VNUHQImidstatehex= 85ec95d2225efa11ba88549c5ffe00f6997452c7ba5e754fd7aab0e4219f0555
2013-10-29 10:52:03 | 0: Job data loaded in 0.033 seconds       
2013-10-29 10:52:03 | 1: Loading new job...                     
2013-10-29 10:52:03 | 1: Writing job...                         
0 kH/s | 0: 0/0/0 0.0%/0.0% | 1: 0/0/0 0.0%/0.0% | 0s | A5VNUHQImidstatehex= 0e7414abac0cc8a9cbeb1eb17a70fb26d1858f2672fcdd427425e605f6106445
2013-10-29 10:52:03 | 1: Job data loaded in 0.034 seconds       
2013-10-29 10:52:04 | 1: Golden nonce found                     
0 kH/s | 0: 0/0/0 0.0%/0.0% | 1: 0/0/0 0.0%/0.0% | 0s | A5VNUHQIhrnonce= 0ae22a02
hash 2e26b4505f64b31fc7ed5cf8dec4d7d69f615d8a712758e79bb3db6600000000
2013-10-29 10:52:04 | 1: rejected 22ae20a                       
2013-10-29 10:52:04 | Exiting...                                    

64MHz

Code:

python mine.py -d 0 -u 127.0.0.1:8772 -w <username:password> --verbose --overclock 64

2013-10-29 10:53:19 | Device 0 opened (A5VNUHQI)
2013-10-29 10:53:19 | Discovering FPGA 0...
2013-10-29 10:53:19 | 0: Waking up...
2013-10-29 10:53:20 | Found 1 device:                            
2013-10-29 10:53:20 |  FPGA0: Spartan 6 LX150 - Firmware: rev 4, build 2
2013-10-29 10:53:20 | Discovering FPGA 1...
2013-10-29 10:53:20 | 1: Waking up...
2013-10-29 10:53:20 | Found 1 device:                           
2013-10-29 10:53:20 |  FPGA1: Spartan 6 LX150 - Firmware: rev 4, build 2
2013-10-29 10:53:20 | Connected to 2 FPGAs
2013-10-29 10:53:20 | FPGA 0 is running at 4294967295MHz
2013-10-29 10:53:20 | FPGA 1 is running at 4294967295MHz
2013-10-29 10:53:20 | Connecting to server...
2013-10-29 10:53:20 | Connected to server                       
2013-10-29 10:53:20 | 0: Clearing queue...                      
2013-10-29 10:53:20 | 0: Queue cleared                          
2013-10-29 10:53:20 | 1: Clearing queue...                      
2013-10-29 10:53:20 | 1: Queue cleared                          
2013-10-29 10:53:20 | 0: Loading new job...                     
2013-10-29 10:53:20 | 0: Writing job...                         
0 kH/s | 0: 0/0/0 0.0%/0.0% | 1: 0/0/0 0.0%/0.0% | 0s | A5VNUHQImidstatehex= f9983e6cb09838fafe641039c362c67c99975071a4d9ea0d941677b882ff8510
2013-10-29 10:53:20 | 0: Job data loaded in 0.032 seconds       
2013-10-29 10:53:20 | 1: Loading new job...                     
2013-10-29 10:53:20 | 1: Writing job...                         
0 kH/s | 0: 0/0/0 0.0%/0.0% | 1: 0/0/0 0.0%/0.0% | 0s | A5VNUHQImidstatehex= 0e84ed3510722967eb1ffbef4935355cb1c23b8c1d228cea803b807db04d04b3
2013-10-29 10:53:20 | 1: Job data loaded in 0.033 seconds       
2013-10-29 10:53:21 | Exiting...                                  

[kramble]

It looks like the max freq using "X6500-Robust-v02-fmax-100MHz.bit" is 63MHz.  If I try 64MHz the reported freq is 4294967295MHz and the miner sits idle.

OK, thanks for that. Definitely very strange. Seems setting the DCM hash_clk too fast is breaking the JTAG comms, but they should be completely independent. And 64MHz is not that fast at all, so I doubt if its a PSU issue. Some thinking is needed.

PS. Looking again at the jtag_comm code, I don't much like the fact that jt_clk is not driven from a dedicated clock buffer, and the use of the (buffered) 100MHz osc clock directly to drive dcm_progclk is also possibly suspect. I'll have a go at changing these to see if it helps.

[kramble]

Atavacron

Two more bitstreams, the 100Mhz build of the previous ...

https://www.dropbox.com/s/vrt69kzgboqf6nn/X6500-Robust-v03-2core-fmax-100MHz.bit

And one where I've added a clock buffer to the jtag clock (hopefully without breaking it) ...

https://www.dropbox.com/s/aalxmdbumare7ez/X6500-Robust-v04-2core-fmax-100MHz.bit

Both claim a fmax of 103Mhz, though perhaps I need to add some explicit constraints for hash_clk and jt_tck.

Fingers crossed, see what you make of them.

Mark

[atavacron]

Atavacron

Two more bitstreams, the 100Mhz build of the previous ...

https://www.dropbox.com/s/vrt69kzgboqf6nn/X6500-Robust-v03-2core-fmax-100MHz.bit

And one where I've added a clock buffer to the jtag clock (hopefully without breaking it) ...

https://www.dropbox.com/s/aalxmdbumare7ez/X6500-Robust-v04-2core-fmax-100MHz.bit

Both claim a fmax of 103Mhz, though perhaps I need to add some explicit constraints for hash_clk and jt_tck.

Fingers crossed, see what you make of them.

Mark

Got 'em.  Testin' time 

[atavacron]

Atavacron

Two more bitstreams, the 100Mhz build of the previous ...

https://www.dropbox.com/s/vrt69kzgboqf6nn/X6500-Robust-v03-2core-fmax-100MHz.bit

And one where I've added a clock buffer to the jtag clock (hopefully without breaking it) ...

https://www.dropbox.com/s/aalxmdbumare7ez/X6500-Robust-v04-2core-fmax-100MHz.bit

Both claim a fmax of 103Mhz, though perhaps I need to add some explicit constraints for hash_clk and jt_tck.

Fingers crossed, see what you make of them.

Mark

Robust-v03, no go.  Loads but sits idle.

Robust-v04, runs.  Loads and runs at 50MHz per core; overclockable to 63MHz; rejects shown.  Above 63MHz, reports 4294967295MHz.

[kramble]

Robust-v03, no go.  Loads but sits idle.

Robust-v04, runs.  Loads and runs at 50MHz per core; overclockable to 63MHz; rejects shown.  Above 63MHz, reports 4294967295MHz.

Great, thanks. Well at least its some progress and we've got a working dual core now. 63Mhz should give 126Mhash/s per fpga and 252MH/s for the board, which is roughly three shares per minute or 211 per hour. Might give you around one block per day.

I can't think how to progress this further without some hands on debugging, so I think I'll call it a day there and I'll get started afresh tomorrow on my lancelot board. It'll probably take a few days to get into a position where I can make some more progress.

Thanks for all the help.
Mark

[atavacron]

Robust-v03, no go.  Loads but sits idle.

Robust-v04, runs.  Loads and runs at 50MHz per core; overclockable to 63MHz; rejects shown.  Above 63MHz, reports 4294967295MHz.

Great, thanks. Well at least its some progress and we've got a working dual core now. 63Mhz should give 126Mhash/s per fpga and 252MH/s for the board, which is roughly three shares per minute or 211 per hour. Might give you around one block per day.

I can't think how to progress this further without some hands on debugging, so I think I'll call it a day there and I'll get started afresh tomorrow on my lancelot board. It'll probably take a few days to get into a position where I can make some more progress.

Thanks for all the help.
Mark

Thanks Kramble.  I'll let it run and see if it hits a block.

[cinnamon_carter]

question for developer:
if coin supply is 7 billion , 3 minute blocks , ect it seems to me Blake Coin is going to be churning out coins for a long , long time. I looked at your source and cannot tell if the extra award is calculated in this. Thought i saw max size 50 i guess if difficulty gets really large over time.
Is the difficulty subsidy counted in the 7 billion ?
Even if it is I think Blake Coin may be one of the coins with the longest ever production cycle?
(of course SIC simple inflation coin the Russian coin is designed to run forever)
Still that is a lot of coins for a long time.
I am curious why you decided on these amounts & long time span?
Not criticizing your work just curious the logic behind this?

[BlueDragon747]

question for developer:
if coin supply is 7 billion , 3 minute blocks , ect it seems to me Blake Coin is going to be churning out coins for a long , long time. I looked at your source and cannot tell if the extra award is calculated in this. Thought i saw max size 50 i guess if difficulty gets really large over time.
Is the difficulty subsidy counted in the 7 billion ?
Even if it is I think Blake Coin may be one of the coins with the longest ever production cycle?
(of course SIC simple inflation coin the Russian coin is designed to run forever)
Still that is a lot of coins for a long time.
I am curious why you decided on these amounts & long time span?
Not criticizing your work just curious the logic behind this?

long life cycle sounds great I do want to be able to mine Blakecoin for many many years to come don't you?

7 billion is coin Max, this includes block reward and inflation, I did not see any reason to have a low coin max and artificially create rarity it does not make sense to me  

I picked 7 as it is both a symbol of luck and a prime number  

should not be any cap on reward for Blakecoin, the idea was to create a steady coin supply that did not cut reward for miner over time and to use a fast hash function that would work on CPU/GPU/FPGA without being SHA-256 Asic compatible e.g a new main algorithm

SIC,QRK,YAK do at least try to do something different but the main thing I did not like was that they use a type of waterfall hashing from one algorithm to another which is artificially slow and would not fit in an FPGA and I was working with scrypt in FPGA with kramble's Litecoin miner but due to scrypt's linear function it was clear to me that it could never really take full advantage of the FPGA compared with the speeds of the GPU's.

I have also been working on a free to play 3D MMO framework with another developer since 2011 and thought it would be a good idea if we could use mining a coin within the game while the user was playing, "paid to pay/earn while you play" type of thing but after some research it was clear that the difficulty of Bitcoin was to high and it was not possible to merge mine scrypt based coins.

what was needed was a fast lightweight hash function that did not use too much memory and after some research the candidates where Blake-256, BMW-256, Blake2s all of which are very fast and have as much if not more security than SHA-256.

Blake-256 won for me as it is easy to work with lots of examples on CPU/GPU/FPGA and once I had done a reduced round variant was almost as fast as Blake2s and faster than BMW-256  

Hence Blakecoin was born  

atm still working on the pool stuff am rewriting the block submission function as it has bugs  

once the pool stuff is done I will be working on the blockchain explorer and a merged coin but a kickstarter/crowd funding for the first game title is due for xmas so need some time to work on that as well, it will be the post apocalyptic FPS MMO think Mad Max, Fallout, Diablo.

I feel that Blakecoin has a really good chance at becoming the second largest cryptographic coin for CPU/GPU/FPGA in the world but it might be a little unrealistic to think that it can surpass Bitcoin in the near future but who knows maybe 10 years from now Blakecoin will be number one      

Hope that answers your questions of why Blakecoin exists and what its future is with some background on the design decisions    
  

[boymok]

stuck at block 11765, no new blocks on network for more than 30 minutes, any idea why?

[BlueDragon747]

stuck at block 11765, no new blocks on network for more than 30 minutes, any idea why?

11771 here so try a restart of the wallet?

if you are mining on the same machine try to reduce the intensity as it maybe taking cpu time away from the wallet

[boymok]

stuck at block 11765, no new blocks on network for more than 30 minutes, any idea why?

11771 here so try a restart of the wallet?

if you are mining on the same machine try to reduce the intensity as it maybe taking cpu time away from the wallet

Im mining on the same machine with cgminer, i will lower the intensity , thanks!

[bronan]

I stopped mining after 2 days not find a block with 2 x 7970 burning around 520 watts at .32 Kw/h
Just is too much for a coin with 0 value for me.