and he may have edited his last post but you can read what hes saying in this post about the LVDS clock source.
Ok, quick update. Unfortunately my last build once again (sigh...) had a bug in the new LVDS clocking. (literally oversight on my part, I put a FALSE where it should have been TRUE for LVDS signal termination... DOH!) anyway, that resulted in continuing stability issues, and caused my latest week long marathon build to be a waste of time... Grumble...
Anyway, this has prompted me to apply another round of code fixes. And I think this one should wrap it up. I've fixed the couple minor bugs that existed, so those problems should be solved. AND I've applied several new fixes as well. Including backporting ALL (that I could find) of makomk's shortfin fixes into the HashVoodoo core now. (With the exception of the DCM watchdog, because it was just to fix the failing DCM, but with the LVDS clock signalling there actually is no DCM at all, so nothing to slap a watchdog on lol).
Anyway, this one has several new fixes, and all of makomk's improvements. Plus I've fixed the nonce range problem (which will cause wrong hashrate to report, and wierd U numbers and such) the chips *should* (provided I didn't bork something up again) hash a full nonce range per chip.
So anyway, just posting this up, these changes are already committed, and pushed up to the github, so they are there for everyone to see
And I'm doing a first round build on it now.
Also, I should have a new controller coming very soon (as in within the next day or two) to match this build, which will provide the following improvements/fixes:
- Should solve jtag instability and usb flashing capabilities, meaning people without jtag cables *should* be able to install it (but need to confirm this first for safety)
- It now supports dynamic clocking, it will be crude at this point, but it will allow 2 dip switches to be used to select from 4 different hashing clock rates (while leaving the communications clocks alone to keep stable baud rate)
- 180Mhz
- 190Mhz
- 200Mhz
- 210Mhz
This way with a given board, you can tune it within that range to find the optimal hashing rate without having to reflash various bitstreams (easy overclocking)
I'm building the bitstreams to close timing to 180Mhz now, so that lowest one will be the "100% in spec", but typically the chips can easily reach a bit beyond their spec (much like CPUs, they are graded in batches based on quality, and some chips may overclock better than others). In some cases I get lucky and exceed timing. So for example, if I'm shooting for 180Mhz, and manages to close timing, that means that no path within the FPGA will exceed a delay of 5.555ns, but if I manage to close timing with 0.55ns of slack, that means that it's actually only got 5ns of delay, which means it's technically fully "in-spec" for 200Mhz clock. And if I exceed timing by a full 1ns, then we're super lucky, and that means it's in-spec for a 219Mhz clock. Now that doesn't take into account power draw of all the components in the chip, noise at those frequencies, and thermal stability. But it means the more "in-spec" we are, the more "universally stable" it should be at a given clock. So the new overclocking options (however crude for now) should help people dial in what's "best" for their given board.
Down the road this will become an auto-tuned thing in software based on invalid rates to find the optimal share yield per second per chip. (yes technically we can tune each chip independently)
Anyway, just a quick update. I'll post more once I've been able to test it.
Oh and also my new board arrived, so I now have both my #0001 serial number board, and a newer #04xx (can't remember exact number) board, so this lets me test and validate on "both sides of the coin".
