Well, this is a bit earlier than I had wanted, but I will tweak and improve this as we go along.
...
Please feel free to give me feedback, suggestions, critiques, and of course to submit Pull requests.
...
June 2nd, 2011 - Flexible Unrolling Added
Thanks to the patch submitted by Udif, the code now supports a configurable amount of loop unrolling. The original design was fully unrolled, with 128 total round modules. By adjusting the CONFIG_LOOP_LOG2 Verilog define, you can choose to unroll to 64 round modules, 32, 16, 8, or 4. This makes the design smaller, at the equivalent cost of speed, which should allow it to run on many more FPGAs.
FPGAminer - I've been following this thread for ~2 weeks now and looking at your TCL code for your miner (mine.tcl), and I am still trying to figure out *exactly* what goes into the FPGAs for hashing, and what comes out to be submitted.
It looks like the following takes place:
1) get_work() and send the following to the FPGA:
1 a) MIDSTATE - all 256 bits
1 b) DATA - *ONLY* 256bits [256-511] (DATA string characters 128-191)
1 c) HASH1, TARGET, and the remaining 75% of DATA are discarded. (?!?!)
2) wait up to 20 seconds for a result - [wait_for_golden_ticket 20]
3) upon finding a "golden ticket", submit_work to the bitcoin client containing:
3 a) original DATA string[0-151], plus
3 b) "golden ticket" nonce string replacing DATA characters[152-159], plus
3 c) original DATA string[160-255]
... in essence, the original data string with the 20th 32-bit all-zero data block replaced with the golden nonce.
Side note: it appears that the 18th 32-bit block is Unix seconds - since 01/01/1970 00:00:00. Any other clues you can give about other fields?
Maybe a link to the getwork() definition of returned data?
My questions are the following:
A) When does the FPGA "learn" of the target value to beat ... or does it ever? (Hardcoded?)
B) SHA256 requires 512bit chunks of data to hash over. Is MIDSTATE really *right-in-the-middle* of a 64-round hash as opposed to just between 512bit chunks?
C) Exactly what gets hashed? It looks like the SHA256 engine is "primed" with MIDSTATE, and only gets 256bits of DATA to iterate with (ignoring the other 768bits of DATA).
D) If you only submit MIDSTATE and 256bits of DATA, how do we arrive at 128 round engines in the FPGA?
Any insight would be appreciated. Especially if an explanation points to a more in-depth description of the algorithm. (I've read every post here for ~2 weeks.) I've also refreshed my memory at
http://en.wikipedia.org/wiki/SHA-2BTW - Thanks for all of your work! GREAT JOB!
A) it does not learn anything it just matches h[7] == 0, like saying the first 32bit is zero.
b)the midstate is between 2 chunks. a block is 80 bytes long. and 512 bit is 64byte. acc. to
https://en.bitcoin.it/wiki/Protocol_specification#Block_Headers DATA[512:640] is 4 bytes of the rest of the merkelroot, timestamp, "bits", nonce. that means that the data is only 4*4=16bytes long, it should be 32bytes, it is then padded till it is 32 bytes long
C)the midstate is the state of the sha256 engine after the first block of 512bits, after then you hash up to 80 bytes(640bits).
D) there is 2 rounds of sha256, and one sha256 round is 64 rounds. 2*64=128rounds.
the way to calculate the hash of a block is: sha256(sha256(blockdata))
hope it explained it. feel free to drop some coins/cents at: 1EJXbMi5CjHeNmUQNpZgg72HWzEMX8tVja
Show Posts
