FPGA mining

From DigiByte Wiki
Revision as of 19:42, 19 July 2019 by Dgb chilling (Talk | contribs) (Added autocompiler error)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Introduction

FPGA mining for Odocrypt is far more efficient than CPU-mining. A single Cyclone V FPGA is around 1000-1500X more powerful than a normal desktop CPU (Depending on the CPU that you're comparing against).

FPGA's are also incredibly energy efficient compared to the likes of a GPU. Where a GTX1070 might consume ~180W (Not allowing for underclocking etc), a consumer-grade FPGA will use around 8W. This means that once a user has purchased a FPGA up-front, the on-going costs are negligible compared with a GPU.

FPGA's are also multi-purpose, bringing in the possibility for users who have existing hardware to mine DigiByte, or to use that same hardware to also mine other non-Odocrypt algorithms. They are far more flexible than an ASIC in that respect. Because FPGAs are reprogrammable, in the event that an ASIC were developed for Odocrypt (Though the advantage of doing-so over an FPGA would arguably be minimal and pointless), the algorithm could be modified easily enough to render the ASICs obsolete similar to what XMR does with CryptoNight, and requiring minimal adjustment of FPGA's.

The up-front cost is also a significant factor, as FPGAs are an "off the shelf" piece of hardware compared to an ASIC, they're far less likely to have an extreme vendor-tax on them as we have seen throughout 2015-2019 specifically with ASIC mining equipment.

All of this combined makes a FPGA-based algorithm a strong arrow in the quiver of DigiByte, both as another non-ASIC hashing algorithm that will aid in the security of the network, but also in the decentralization of mining thanks to the borderline commodity nature of FPGAs.

Getting ready for mining

These instructions presume you are running Linux natively, though you should also be able to run it through WSL on Windows 10.

Don't plug your FPGA in just yet, you'll be instructed to do-so later. When you do, you only need the power and the USB cable connected to your PC.

There are going to be a few software components that you need to be aware of:

  • Quartus Prime, this is required to run your FPGA miner
  • Autocompiler, this re-creates the software your FPGA uses every 10 days based on the new seed
  • FPGA mining controller, one for each FPGA you have
  • Mining Pool, optional, in case you are wanting to solo-mine
  • DigiByte Core, optional, if you're wanting to solo-mine. Can be pointed at any wallet otherwise.

This guide presumes you will be solo-mining and is currently written with testnet in-mind so you can test your setup prior to the mainnet cutover to Odocrypt.

 

Quartus Prime

Quartus Prime is required to both compile and run this miner. You'll want to do this part from a GUI due to the way the Intel website works. You can do this on a PC and SCP the files across to your FPGA host if you're using a VM / headless server, or, if you've simply installed the likes of Ubuntu then you can do it directly.

You can download the FPGA software from https://fpgasoftware.intel.com/ where you will need to sign up for a free Intel account.

For the Intel Cyclone V GX Starter Kit and DE10-Nano Kit you want to install the Lite version Quartus Prime 18.1, this version is free, and supports the Cyclone V chip family.

Choose Linux OS, and then choose Direct Download. You then want to go to "Individual files" and download two files, the "Quartus Prime (includes Nios II EDS)" and "Cyclone V device support".

Once downloaded, in the terminal run:

cd ~/Downloads
chmod +x QuartusLiteSetup-18.1.0.625-linux.run
./QuartusLiteSetup-18.1.0.625-linux.run

Follow the instructions to finish the installation

Other prerequisites

Once you have Quartus Prime, you're going to want to clone the Odocrypt miner repository. Fire up a terminal and run the following to install git, python, and then clone the odo-miner source code:

sudo apt-get install git python python-pip
git clone https://github.com/DigiByte-Core/odo-miner.git

You'll also want a few python modules:

pip install base58 requests

 

 

Profile setup

You'll want to edit ~/.profile and add the following line to the bottom:

export QUARTUSPATH="/home/digibyte/intelFPGA_lite/18.1/quartus/bin"

Naturally you'll need to update the username / path there depending on where you've extracted it. Put it in there though to keep life simple.

It should look like this:

export QSYS_ROOTDIR="/home/digibyte/intelFPGA_lite/18.1/quartus/sopc_builder/bin"
export QUARTUSPATH="/home/digibyte/intelFPGA_lite/18.1/quartus/bin/"

You can either log out of your X session, or you can run the following command in the terminal session:

source ~/.profile

Device setup

Normally only root can access the FPGA hardware, but running things as root is just bad practice, so we want to allow your user-account to access the hardware.

cd ~/odo-miner
sed -i s/1000/$(whoami)/ 99-altera.rules

This is going to edit the altera rules file with your username, to allow your user access Now we need to put it into the udev rules:

sudo cp 99-altera.rules /etc/udev/rules.d/
sudo udevadm control --reload

Connecting your hardware

Congratulations, you can now connect your hardware!

Simply take the USB cable and connect it to your PC. If there are multiple USB ports, use the "USB Blaster" port, and then power-on the device.

You can run the following, to check and ensure the FPGA has been detected by your operating system:

lsusb | grep Altera

You can also then ensure that the miner is functioning correctly by running:

$QUARTUSPATH/jtagconfig

You should see the results return similar to the following: https://i.imgur.com/DS3GQsR.png

If it complains of issues with the JTAG chain, see the FAQ below.

 


Mining

You are now ready to begin mining. We're going to want several terminals open, and, DigiByte Core 7.17.2

If you do not currently have DigiByte Core installed, you can do-so with:

wget -c https://github.com/digibyte/digibyte/releases/download/v7.17.2/digibyte-7.17.2-x86_64-linux-gnu.tar.gz -O - | tar xz

It is up to you if you want to use digibyted or digibyte-qt, either will work fine. You should not need to make any changes to digibyte.conf, however as we are mining on testnet at present you should either launch with:

./digibyte-7.17.2/bin/digibyte-qt -testnet -server

or add

testnet=1
server=1

to ~/.digibyte/digibyte.conf

NOTE: You should not need to add any other RPC allow etc to your conf file, as the pool will find the local digibyte cookie and use that

In your terminal #1 we will start up the Autocompiler:

cd ~/odo-miner/src/

Then run:

./autocompile.sh --testnet cyclone_v_gx_starter_kit de10_nano

This will automatically create the files needed to program both the Cyclone V GX Starter Kit, as well as the DE10 Nano. If you only use one, you can safely drop the other.

NOTE: If you are restarting this during the 10-day epoch for any reason, this may show no additional output to begin with, as the Autocompiler doesn't need to adjust the files it has already created.

Next you will want to start up the Mining Pool. In terminal #2, run the following:

cd ~/odo-miner/src/pool/solo

You can now launch the pool software by running:

python pool.py --testnet sju95DMmdu8uyUiGxZRJrG8Cs9y8jfKCbS

NOTE: You can replace sju95DMmdu8uyUiGxZRJrG8Cs9y8jfKCbS with your own address, but be sure to have a testnet address as they are not compatible with mainnet

Last of all your FPGA Mining Controller, you'll need one terminal for each piece of hardware you have attached.

Run:

cd ~/odo-miner/src/miner

You need to do this so that you are in the same location as the mine.tcl file

You can then launch the miner with:

$QUARTUSPATH/quartus_stp -t mine.tcl

If you have multiple FPGAs attached, it will prompt you to specify which one. You can do-so as follows:

$QUARTUSPATH/quartus_stp -t mine.tcl "USB-Blaster [1-7]"

Do this for each, adjusting the USB Hub ID that it is connected to.

You should see a confirmation alert "Programming successful", followed by "Mining fpga found". If you have, congratulations, you are now solo-mining. https://i.imgur.com/rlAbpb1.png

Note:If you encounter an error: "Inconsistency detected by ld.so: dl-close.c: 811: _dl_close: Assertion `map->l_init_called' failed!" see the Troubleshooting section below.

Depending on the number of FPGAs you have, vs the network hashrate etc, you will eventually find a block and be rewarded with DigiByte for doing-so (The block reward is 688 DigiByte on mainnet at the time of writing).


Stratum Implementation

There is an additional parameter odokey is required from a pool, which shows current epoch and required for a correct share calculation at miner side.

To keep standard stratum implementation compatible with existent mining software, this is additional JSON key out of standard params list.

JSON pretty print of mining.notify

{
 "params": [
   "5cf1....1d9a",
   "f696....defd",
   "0100....2508",
   "0a20....0000",
   [],
   "20000e02",
   "1c5024dd",
   "5cf2a6dd",
   false
 ],
 "odokey": 1559347200,
 "id": null,
 "method": "mining.notify"
}

In case you are not able to to modify stratum message or you are not pool owner, you may callculate odokey at miner side from nTime

uint32_t OdoKey(uint32_t nTime) {       
       uint32_t nOdoShapechangeInterval = 10*24*60*60;   // 10 days
// OR  uint32_t nOdoShapechangeInterval =  1*24*60*60;   // 1 day, testnet
       return nTime - nTime % nOdoShapechangeInterval;
}

Using odokey param is the most preferred way to go.

In this case miner do not need to care about current Odo period length at a pool side and miner do not care what is testnet or mainnet.

But anyway miner still need to select correct pre-compiled bitstream image for a received odokey or generate it on-the-fly immediately as soon as new odokey received from a pool.


Troubleshooting / FAQ

How do I know when the Change of Epoch has occurred?

You'll see the following in your console output:

Info: Results for last epoch:
Info: accepted: 22
Info: [2019-04-19 12:00:01] Programming DE-SoC [1-6] with ../projects/de10_nano/output_files/miner_1555632000.sof
Info: [2019-04-19 12:00:14] Programming successful.
Info: Mining fpga found: DE-SoC [1-6] @2: 5CSEBA6(.|ES)/5CSEMA6/.. (0x02D020DD)

This indicates that this particular FPGA has found 22 blocks, and been successfully reprogrammed. The reprogramming took a total of 13 seconds.

ERROR: An internal Tcl interpreter error occurred

If you get the error: https://i.imgur.com/FbPaJcl.png

If you scroll up it likely began with: Error: [Datestamp] Unrecoverable checkcksum failure

You can simply press the up key in your terminal to re-run the last command and it should continue to mine immediately. This appears to happen more-so on the Cyclone V Starter Kits, the cause of which is currently uncertain.

Warning: result inconclusive

This is fine, it means the miner submitted results to the pool which were deemed valid, however by the time your pool tried to claim the block it had already been mined by another algo with a higher amount of work.

If you go into your Transactions list on your DigiByte Core wallet (if running digibyte-qt) then you will also see a transaction with a block reward with a "?" next to it, which says "Generated but not accepted".

Error: Lost connection to pool

Please check that the pool software is still running and that it is connected to your DigiByte Core

Unable to read device chain - JTAG chain broken

If you get this error when running

$QUARTUSPATH/jtagconfig

You should simply power off your Cyclone V Starter Kit. Give it 2 seconds. Power it on and try running it again. There seems to be an issue with initializing the FPGA specific to that hardware, the root cause of which is uncertain, but power-cycling it resolves this issue. Sometimes it has taken me 3-4 power-cycles to get this resolved, but that's all that's been needed to connect to it successfully

If you have installed Quartus on your Ubuntu Linux, then the error could have been caused by missing the 32 Bit version of libudev. To fix this, you have to download libudev1:i368 and create a symbolic link

$ sudo apt-get install libudev1:i386
$ sudo ln -sf /lib/x86_64-linux-gnu/libudev.so.1 /lib/x86_64-linux-gnu/libudev.so.0

Warning: Command `read_probe_data -instance_index 3 -value_in_hex` failed:

This usually occurs when the unit has overheated. You should be able to restart the mining controller and start again immediately by pushing up on the terminal and re-running the mine command. You might also want to look at cooling the FPGA down through the use of a fan or similar.

Error: Inconsistency detected by ld.so: dl-close.c: 811: _dl_close: Assertion `map->l_init_called' failed!

This error may be seen when trying to program the FPGA. The problem appears to be some kind of incompatibility with libboost_system.so. Quartus supplies and indeed requires v1.59.0, while your system may have a diferent version. It turns out that the Quartus commandline tools refer to plain libboost_system.so file, which is in fact a sym-link to libboost_system.so.1.59.0. Meanwhile, the GUI tools explicitly require the latter. The easiest fix seems to be to simply remove the symlink, such that the Quartus command-line tools would use the system lib (found by ld-linux.so, in the normal fashion):

$ cd ~/intelFPGA_lite/18.1/quartus/linux64/
$ rm -f libboost_system.so

Autocompiler won't start, keeps looping

If you get the following error:

Error (20004): Your design targets the device family "Cyclone V". The specified family is not a valid device family, is not installed, or is not supported in this version of the Quartus Prime software. If you restored a project from an archived version, your project was successfully restored, but you still must specify or install a supported device family.

This is because you downloaded Quartus Lite but did not have the Cyclone V support in the same directory when you ran through the installation. Re-download it as-per the instructions, then re-run the Quartus setup.