Topic: Detailed FPGA Mining Software Operation. (Read 2022 times)

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.

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.

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.

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.

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.

What do you mean by manual placement?

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

The code that compiles at 200MHz is about as close to efficient as you'll get without doing manual placement.

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.