Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for latest ZTEX firmware. #15

Open
wants to merge 3 commits into
base: testing
Choose a base branch
from
Open

Add support for latest ZTEX firmware. #15

wants to merge 3 commits into from

Conversation

dpifke
Copy link
Contributor

@dpifke dpifke commented Jun 21, 2012

After applying these changes, I can succesfully mine on both my 1.15x
and my 1.15y boards. The latter currently only uses a single FPGA;
I'm currently working on a (much more invasive) patch to use all four
chips, to be applied on top of these (fairly safe) changes.

This adds support for a newer version of the ZTEX firmware, including
the version supported on the 1.15y quad miner.
In a future commit, I will be adding support for mining using all of
the FPGAs on a ZTEX 1.15y.  For now, we simply detect the presence
of multiple FPGAs and log a message indicating that mining will only
take place on the currently-selected chip.
With the previous value of 100ms, I was seeing the occasional
communication timeout talking to my ZTEX boards.  Looking at the ZTEX
SDK, it uses a value of 1000ms.  This commit changes MPBM to use the
same value.
@ghost ghost assigned TheSeven Jun 21, 2012
@TheSeven
Copy link
Owner

I'm not sure what to do about this.
Do you have a clue what exactly those values in the nonce reading result mean, i.e. how this maps to FPGAs, iterations, or whatever?
Once this is figured out, it should be fairly straightforward to extend this to multiple FPGAs. The FTDIJTAG module will probably be a good template for this.

@dpifke
Copy link
Contributor Author

dpifke commented Jun 21, 2012

It was written to match the behavior of the current BTCMiner.java code. Without these changes I couldn't mine at all using my MPBM and my 1.15y. Since applying the changes, I've been able to do so successfully, albeit using only the first FPGA.

I believe the intent of the extra nonce stuff is to support bitstreams which have more than one hasher working in parallel. Rather than pipeline everything so you get 1 hash per clock, it's possible to design code that performs X hashes per Y clocks. I'm not aware of any publicly-released bitstreams that do this, but I've played with this technique and it makes the place-and-route a lot easier.

Agree that the multiple FPGA stuff should be straightforward; my intent was to push one piece at a time for ease of testing and merging.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants