bfgminer/FPGA-README

This README contains extended details about FPGA mining with cgminer


Bitforce

--bfl-range         Use nonce range on bitforce devices if supported

This option is only for bitforce devices. Earlier devices such as the single
did not have any way of doing small amounts of work which meant that a lot of
work could be lost across block changes. Some of the "minirigs" have support
for doing this, so less work is lost across a longpoll. However, it comes at
a cost of 1% in overall hashrate so this feature is disabled by default. It
is only recommended you enable this if you are mining with a minirig on
p2pool.

BFGMiner also bundles a bitforce-firmware-flash utility on Linux. Using this,
you can change the bitstream firmware on BitFORCE Singles. It is untested with
other devices. Use at your own risk! Windows users may use Butterfly Labs
EasyMiner to change firmware.

To compile:
 make bitforce-firmware-flash
To flash your BFL, specify the BFL port and the flash file e.g.:
 sudo ./bitforce-firmware-flash /dev/ttyUSB0 alphaminer_832.bfl
It takes a bit under 3 minutes to flash a BFL and shows a progress % counter
Once it completes, you may also need to wait about 15 seconds,
then power the BFL off and on again

If you get an error at the end of the BFL flash process stating:
 "Error reading response from ZBX"
it may have worked successfully anyway.
Test mining on it to be sure if it worked or not.

You need to give cgminer about 10 minutes mining with the BFL to be sure of
the MH/s value reported with the changed firmware - and the MH/s reported
will be less than the firmware speed since you lose work on every block change.


Icarus

There are two hidden options in cgminer when Icarus support is compiled in:

--icarus-options <arg> Set specific FPGA board configurations - one set of values for all or comma separated
           baud:work_division:fpga_count:quirks

           baud           The Serial/USB baud rate - 115200 or 57600 only - default 115200
           work_division  The fraction of work divided up for each FPGA chip - 1, 2, 4 or 8
                          e.g. 2 means each FPGA does half the nonce range - default 2
           fpga_count     The actual number of FPGA working - this would normally be the same
                          as work_division - range is from 1 up to 'work_division'
                          It defaults to the value of work_division - or 2 if you don't specify
                          work_division
           quirks         List of quirks to enable and disable (after a minus sign):
                            r  Reopen device regularly to workaround buggy Icarus USB chipset
                               (enabled by default)

If you define fewer comma seperated values than Icarus devices, the last values will be used
for all extra devices

An example would be: --icarus-options 57600:2:1:-r
This would mean: use 57600 baud, the FPGA board divides the work in half however
only 1 FPGA actually runs on the board, and don't reopen the device (e.g. like
an early CM1 Icarus copy bitstream)

--icarus-timing <arg> Set how the Icarus timing is calculated - one setting/value for all or comma separated
           default[=N]   Use the default Icarus hash time (2.6316ns)
           short         Calculate the hash time and stop adjusting it at ~315 difficulty 1 shares (~1hr)
           long          Re-calculate the hash time continuously
           value[=N]     Specify the hash time in nanoseconds (e.g. 2.6316) and abort time (e.g. 2.6316=80)

If you define fewer comma seperated values than Icarus devices, the last values will be used
for all extra devices

Icarus timing is required for devices that do not exactly match a default Icarus Rev3 in
processing speed
If you have an Icarus Rev3 you should not normally need to use --icarus-timing since the
default values will maximise the MH/s and display it correctly

Icarus timing is used to determine the number of hashes that have been checked when it aborts
a nonce range (including on a LongPoll)
It is also used to determine the elapsed time when it should abort a nonce range to avoid
letting the Icarus go idle, but also to safely maximise that time

'short' or 'long' mode should only be used on a computer that has enough CPU available to run
cgminer without any CPU delays (an active desktop or swapping computer would not be stable enough)
Any CPU delays while calculating the hash time will affect the result
'short' mode only requires the computer to be stable until it has completed ~315 difficulty 1 shares
'long' mode requires it to always be stable to ensure accuracy, however, over time it continually
corrects itself

When in 'short' or 'long' mode, it will report the hash time value each time it is re-calculated
In 'short' or 'long' mode, the scan abort time starts at 5 seconds and uses the default 2.6316ns
scan hash time, for the first 5 nonce's or one minute (whichever is longer)

In 'default' or 'value' mode the 'constants' are calculated once at the start, based on the default
value or the value specified
The optional additional =N specifies to set the default abort at N 1/10ths of a second, not the
calculated value, which is 112 for 2.6316ns

To determine the hash time value for a non Icarus Rev3 device or an Icarus Rev3 with a different
bitstream to the default one, use 'long' mode and give it at least a few hundred shares, or use
'short' mode and take note of the final hash time value (Hs) calculated
You can also use the RPC API 'stats' command to see the current hash time (Hs) at any time

The Icarus code currently only works with an FPGA device that supports the same commands as
Icarus Rev3 requires and also is less than ~840MH/s and greater than 2MH/s
If an FPGA device does hash faster than ~840MH/s it should work correctly if you supply the
correct hash time nanoseconds value

The timing code itself will affect the Icarus performance since it increases the delay after
work is completed or aborted until it starts again
The increase is, however, extremely small and the actual increase is reported with the
RPC API 'stats' command (a very slow CPU will make it more noticeable)
Using the 'short' mode will remove this delay after 'short' mode completes
The delay doesn't affect the calculation of the correct hash time