changes to bitburner driver for bitburner fury boards

[someone42]

Justification of the changes:

• Bitburner boards do not contain a real USB-to-serial chip, so the send delays are unnecessary and will limit the hashrate of large and/or powerful stacks.
• The valid range for core voltage and number of miners was widened to accommodate Bitfury-based boards.

[someone42]

There appears to be an issue with removing the send delays. When running dissimilarly-sized stacks on the same cgminer instance, the effective hashrates "lock" together.

[kanoi]

Since you wrote the Firmware - I'm not sure why you changed the mV limit to 1500?
I set it to 1400 due to that's what was said the firmware limit was.
If some changes are for the BitFury version of the board, then they need to be done differently - i.e. a separate IDENT (not BTB) and separate code to work with it. Probably even a separate driver since they are very different in chip and performance

[someone42]

The idea with the mV limit is that the BitFury version subtracts 300 mV off the specified core voltage. So the range is actually 700 mV to 1200 mV. This was done so that the Avalon default of 1200 mV corresponds to the BitFury default of 900 mV.

Despite the differences between the Avalon and BitFury chips, the fundamentals are the same: midstate and data in, nonces out. Thus the BitBurner firmware and cgminer driver can be readily adapted to BitFury chips. As much as I would like to develop and test a new cgminer driver (one that avoids the "quirks" of the Avalon driver), there isn't enough time for that now.

[roybadami]

How does this new code deal with the 300mV offset in the firmware? It seems to want a voltage setting between 700mV and 1100mV, but AIUI the firmware subtracts 300mV?

Or am I missing something? Are there going to be some versions of the firmware in the field that subtract 300mV and others that don't? (Which sounds like a recipe for disaster).

EDIT: Ah, maybe the new firmware is different in this respect, and it is safe because the new boards will not be recognized by the old driver?

[roybadami]

Also, I'm confused - is the absolute limit 1100mV or 1200mV? Your original commit increased BITBURNER_MAX_COREMV from 1400 to 1500 to allow a max core voltage in the Fury boards of 1200mV. The intent of your later commit seems to be to revert the maximum to 1100mV. Was 1200mV a mistake then? Is the correct limit for the production units indeed 1100mV?

[someone42]

Yes, the 1200 mV was a mistake. I asked burnin what the limit should be and he suggested 1.1 or 1.2 V. So I made it 1200 mV just to cover both possibilities. However, the production units ended up having their resistor divider values set such that the maximum is 1.1 V.

As for the subtracting 300 mV thing, only boards which identify as "BTB" will do that. If a board identifies as "BBF" (the distinction is done using a different USB iProduct string), the firmware does not subtract off 300 mV. To further avoid confusion, BTB boards use --bitburner-voltage and BBF boards use --bitburner-fury-voltage. Accidentally using an incorrect one will have no effect.

So:

• BTB firmware: use --bitburner-voltage and compensate for 300 mV
• BBF firmware: use --bitburner-fury-voltage and do not compensate.

[ckolivas]

We've just been auditing this code and were about to pull it and test it but it unfortunately does not apply cleanly to git master. Can you rebase it please?

[roybadami]

@someone42: With the old (i.e. current) firmware, what is communicated over the CAN-BUS? Is it the true voltage (after subtraction of 300mV)? I'm just trying to understand what would happen to voltage setting if a stack had mixed firmware versions.