Bitcoin Forum
October 18, 2018, 12:46:25 PM *
News: Make sure you are not using versions of Bitcoin Core other than 0.17.0 [Torrent], 0.16.3, 0.15.2, or 0.14.3. More info.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Detailed FPGA Mining Software Operation.  (Read 1928 times)
Ltcfaucet
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
March 29, 2013, 10:50:44 PM
 #1

I would like to know more about the workings of the Open-Source-FPGA-Bitcoin-Miner.

https://github.com/progranism/Open-Source-FPGA-Bitcoin-Miner

If someone would like to answer my questions and help me out that would be awesome.

I have two X6500s and I would like to streamline the code and make it more efficient. (If possible.)

I some what need someone to hold my hand as I don't want to break anything, haha.

Any help would be greatly appreciated.

Thanks.

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1539866785
Hero Member
*
Offline Offline

Posts: 1539866785

View Profile Personal Message (Offline)

Ignore
1539866785
Reply with quote  #2

1539866785
Report to moderator
1539866785
Hero Member
*
Offline Offline

Posts: 1539866785

View Profile Personal Message (Offline)

Ignore
1539866785
Reply with quote  #2

1539866785
Report to moderator
1539866785
Hero Member
*
Offline Offline

Posts: 1539866785

View Profile Personal Message (Offline)

Ignore
1539866785
Reply with quote  #2

1539866785
Report to moderator
fpgaminer
Hero Member
*****
Offline Offline

Activity: 560
Merit: 500



View Profile WWW
March 30, 2013, 09:13:29 AM
 #2

Feel free to ask your questions and I will answer as best I can when I have time to do so.

Quote
I have two X6500s and I would like to streamline the code and make it more efficient. (If possible.)
The code that compiles at 200MHz is about as close to efficient as you'll get without doing manual placement.

Ltcfaucet
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
March 31, 2013, 04:32:18 AM
 #3

Feel free to ask your questions and I will answer as best I can when I have time to do so.

Quote
I have two X6500s and I would like to streamline the code and make it more efficient. (If possible.)
The code that compiles at 200MHz is about as close to efficient as you'll get without doing manual placement.

What do you mean by manual placement?

fpgaminer
Hero Member
*****
Offline Offline

Activity: 560
Merit: 500



View Profile WWW
March 31, 2013, 11:44:29 AM
 #4

Quote
What do you mean by manual placement?
Picking where all the logic goes in the FPGA yourself, instead of letting the Place and Route tools do it.  It's incredibly tedious and not very well supported/documented.

Ltcfaucet
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
April 01, 2013, 03:30:30 AM
 #5

On another post you said the altsource_probe width is 511 bits.

Could another 128 bits be added as a buffer for the next nonce?

What are the 384 bits for prior to the nonce and buffer?

Sorry for asking so many newb questions I am very interested in learning more about FPGAs.

Thanks for your time.
fpgaminer
Hero Member
*****
Offline Offline

Activity: 560
Merit: 500



View Profile WWW
April 01, 2013, 07:15:08 AM
 #6

I will start by saying that altsource_probe is not an efficient way to communicate with the FPGA, so there is little practical point in optimizing its usage.  I occasionally use altsource_probe in my work because it is simple to use and quick to get working.

Quote
Could another 128 bits be added as a buffer for the next nonce?
I don't quite understand this question.  There are two sets of altsource_probes in the Altera targetted designs.  midstate_vw_blk and data2_vw_blk provide the input the mining core needs to mine.  golden_nonce_vw provide a means for the mining core to report any gloden nonces it has found (nonces which result in a share that can be submitted to a mining pool).

The way that code is designed (specifically, this code), is that any found golden nonces are written to (and thus overwrite) the golden_nonce register.  When the host computer reads the golden_nonce_vw_blk altsource_probe, it's just reading the golden_nonce register.  There's no buffering or anything.  So in the current design, there's no way to buffer results.  Like I mentioned at the beginning of this post, this isn't meant to be efficient; just quick and simple.

Quote
What are the 384 bits for prior to the nonce and buffer?
Are you referring to this line?  Remember, all a miner is really doing is SHA-256 hashing a block header.  SHA-256 requires that the input data be padded out to a multiple of 512-bits.  On that line, the 384-bits are the padding that gets added to the block header.  They are constant, no matter what block header is being hashed, because all block headers are (currently) the same size.

Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!