-
Notifications
You must be signed in to change notification settings - Fork 550
Specification: Components, Interfaces, and Protocols [WIP]
This is a Work-in-Progress attempt at defining a useful specification for Bitcoin FPGA Miners. Some of it consists of mere guidelines, while other parts should be very useful in easy and consistent interface between many different Bitcoin FPGA Miner implementations.
Outlined here are the major Components involved in a Bitcoin FPGA Miner design; the Interfaces between those Components; and the Protocols and behavior of communication across those Interfaces.
###Terms/Abstract Concepts###
- Raw - The raw data needed by SHA-256 to produce a Hash. 512-bits of data, and 256-bits of state.
- Hash - The result of a Bitcoin hash: sha256(sha256(data)).
- Work - A unit of Bitcoin work, consisting of 96-bits of data and 256-bits of midstate.
- Share - Work + 32-bit nonce that results in a Hash <= Difficulty1 (first 32-bits of Hash are 0).
- Abstract Interface - This type of interface should be consistent, and change as little as possible between specification revisions; allows for interchanging of the communicating modules.
- Flexible Interface - This type of interface is specific to the modules using it, and is not usually well defined or consistent.
##Components## ###Slave Mining Core (Slave)### The Slave Mining Core implements a single mining core, typically accepting Raw inputs and producing a resulting Hash every X number of cycles.
###Master Mining Core (Master)### The Master Mining Core is master over one or more Slaves. Typically it is processing one Work at a time, starting with nonce=0 and working all the way to nonce=2^32-1 before loading in new Work. Typically, to handle multiple Slaves, it assigns a sequential ID to all the Slaves and uses a Slave's ID as the LSB of nonce. This reduces the nonce's bit-width, accounting for the increased number of Hashes produced per X cycles.
The Master returns Shares.
###Logical Communication Module (Comm)### The Logical Communication Module maintains local Work queues and Share queues and controls one Master.
###Physical Communication Module (PHY)### The Physical Communication Module manages communication between Comm and a physical communication interface. Examples of physical communication interfaces: UART, SPI, JTAG, Memory Mapped, String&Cup, and ShoutingNeighborsModulation.
###External Controller (Controller)### The External Controller could be a PC, embedded CPU, micro-controller, etc. It generates Work, processes Shares, etc, usually communicating with a pool or bitcoind.
##Interfaces## ###Slave### Flexible Interface - This interface will be specific to the type of Slave and Master. Usually it just amounts to the Master providing the Slave with Raw and getting back Hashes.
module Slave (
input clk,
input [511:0] rx_data,
input [255:0] rx_state,
input [255:0] tx_hash
);
###Master### Abstract Interface - The Master's external interface is a passive one, meaning that the Comm will take a mostly active role in the relationship.
module Master (
input clk,
input work_reset, new_work_available,
output work_read,
input [96+256-1:0] new_work,
output new_share_available,
input share_read,
output [96+256+32-1:0] new_share,
output [31:0] current_nonce,
output idle
);
###Comm### Abstract Interface - The Comm's external interface is a memory map. There is currently no interrupt functionality defined, although that may be appropriate.
module Comm (
input comm_clk,
input [7:0] addr,
input [31:0] data,
input we,
output [31:0] q
);
##Protocols and Behavior##
###Master###
(1) The internal hashing clock and communications clock are both provided by clk for simplicity.
(2) When Master needs new Work it may use the Work present on new_work if new_work_available is HIGH and work_read is LOW. The cycle following Work being read from new_work, Master should drive work_read HIGH for at least one cycle.
(3) new_work may not be changed while new_work_available is HIGH or work_read is HIGH.
(4) If new_work_available is LOW and new Work is needed, the Master should go into an idle state if possible. Idle state should be a low-power state.
(5) If work_reset is HIGH, Master should immediately grab new Work from new_work: see (2) and (4).
(6) The Master may be forced into idle (if that mode is available) by holding new_work_available LOW and work_reset LOW [7: Shouldn't this be HIGH?].
(7) If the Master is in an idle state, idle should be driven HIGH; otherwise LOW.
(8) new_share may be read externally if new_share_available is HIGH and share_read is LOW. share_read should be driven HIGH for at least one cycle following the reading of new_share.
(9) new_share may not be changed while new_share_available is HIGH or share_read is HIGH.
(10) current_nonce is the nonce the Master is currently processing. This is used externally to measure hashrate and possibly need for new work. It may be a few cycles delayed, as long as it is accurate enough for the aforementioned uses.
The Master is likely to maintain an internal Share queue, to account for delays in communication, and multiple Slaves. On average, only one Share is likely to be found within a given Work, with an acceptable variance of 3 or 4. Therefore this queue may be kept small, on the order of 3 or 4 items. If the queue does get full, Master should attempt to flush the oldest Share in favor of new Shares.
###Comm###
Comm presents a Memory Mapped external interface, with some Action-on-Write behavior. comm_clk may be slow; slower than the clk provided to Master. Below are the specified registers:
Interface Version 0x0100 Firmware Version 0x0100
--------------------------------------------------------------------------------
Reg 0 | Version - Read
--------------------------------------------------------------------------------
0-15 | Interface Version | A 16-bit version indicating the version of the
| interface provided by Comm. This can allow external
| software to determine the meaning of all the
| registers across several revisions of this
| specification.
16-31 | Firmware Version | The firmware version of the Comm. This allows
| external software to determine all the
| functionality provided by the Comm, version
| specific bugs/nuances, etc.
--------------------------------------------------------------------------------
Reg 1 | ID - Read
--------------------------------------------------------------------------------
0 | String | A single bit string indicator. If this is 1, then
| the ID is actually a string. See below.
1-31 | Numerical ID | ID code for the Comm, if String is 0.
24-31 | Char | If String is 1, then Char can be read multiple
| times to read a sequential UTF-8 string. The
| string data is read 8-bits at a time from Char.
| The string is repeated over and over, allowing for
| U+0000 to be used as a start and stop, in case the
| current state of _ID_ is not known.
--------------------------------------------------------------------------------
Reg 2 | Queue Sizes - Read/Write
--------------------------------------------------------------------------------
0-7 | Max Work Queue | The maximum size of the work queue.
8-15 | Max Share Queue | The maximum size of the share queue.
16-23 | Works in Queue | How many Works are in queue. Writing 0 will clear
| the work queue.
24-31 | Shares in Queue | How many Shares are in queue. Writing 0 will clear
| the share queue.
--------------------------------------------------------------------------------
Reg 3 | Current Nonce - Read
--------------------------------------------------------------------------------
0-31 | Current Nonce | The nonce the mining core is currently processing.
--------------------------------------------------------------------------------
Reg 4 | Miner Status - Read/Write
--------------------------------------------------------------------------------
0 | Not Idle | Whether the mining core is idle or not. 1 for not
| idle. Writing a 0 will force the mining core to go
| idle.
--------------------------------------------------------------------------------
Reg 5 | Work/Share Control - Read/Write
--------------------------------------------------------------------------------
0 | Can Read Work | 1 if Comm is ready to read new work.
1 | Can Write Share | 1 if Comm is ready to write a new share.
2 | Read Work | Write 1 to instruct the Comm to read new work from
| the Work Scratch Pad.
3 | Write Share | Write 1 to instruct the Comm to write a new share
| to the Share Scratch Pad.
If Can Write Share is 0, Comm will not write a new Share when requested.
Flushing any of the queues will invalidate this register, so read it back after
flushing any queue.
--------------------------------------------------------------------------------
Reg 208-239 | Work Scratch Pad - Read/Write
--------------------------------------------------------------------------------
Write Work here first, before telling the Comm to read it. This should also be
readable (reading back what was written). Work is written Little-Endian,
96-bits of data first, followed by 256-bits of midstate.
This scratch pad is 1024-bits to future-proof it, allowing for communication of
extra data like pre-computed Ws and states.
--------------------------------------------------------------------------------
Reg 240-255 | Share Scratch Pad - Read/Write
--------------------------------------------------------------------------------
After requesting a share, it can be read from here. Little-Endian. 96-bits of
data, 32-bits of nonce, 256-bits of midstate.