Hardware Layer of AtomMiner
As a physical interface to communicate between host PC and hardware miner, we’ve chosen well known serial interface in full-duplex mode since it was one of the easiest solutions to implement in both hardware and software parts of the project.
Basically, all the communications are done in the standard (for UART comm) mode: service commands and data blocks are being sent from the host PC over the serial cable to the hardware while miner responds back to the received commands and sends mining results back to the host. Not a rocket science, just a typical serial terminal with pre-defined commands. Below is the list of commands we use to control hardware:
| Name | Mnemonics | bytes | Notes | |
| 1 | host_break | 8’h31 | 1 | Global hardware reset |
| 2 | start | 8’h32 | 1 | Start mining |
| 3 | stop | 8’h34 | 1 | Stop mining |
| 4 | wr_block | 8’h38{byte[47:0]} | 49 | Writes midstate data, Table 6 |
| 5 | set_target | 8’h54{byte[23:0]} | 25 | Writes target, top 8byte numbers are zero, so they are not sent |
| 6 | set_nonce | 8’h4E{byte[3:0]} | 5 | |
| 7 | set_timestamp | 8’h57{byte[3:0]} | 5 | |
| 8 | set_clk | 8’h43 {byte} | 2 | Writes new frequency number and triggers set up new operation frequency |
| 9 | get_signature | 8’h49 | 1 | Hard returns ASCII signature current project version |
| 10 | read_ubuf | 8’h52 | 1 | Hard returns 48 bytes of uart_buf midstate data |
| 11 | get_status | 8’h53 | 1 | Returns 4 bytes Status register |
| 12 | get_current_nonce | 8’h6e | 1 | Returns 4 bytes of current nonce |
Table 1. AtomMiner Physical Commands
Sometimes it is necessary to identify in which state hardware is so we can make our decision if it is ready for the next chunk of data, or not. Status block is returned from AtomMiner in response to get_status command (0x53). Status register is described in the following table:
| bits | notes | |
| 1 | [7:0] | clk_h_frequency – current device frequency |
| 2 | 8 | start_stop bit 1 – start, calculations in progress 0 – stop, waiting start or new block |
| 3 | 9 | ready4hash bit 1 – midstate data and target are loaded 0 – waiting for load midstate data or target |
| 4 | 10 | hash completed bit 1 – hashing of the last block has been completed 0 – hardware is still working on the last data block |
| 5 | 11 | Busy 1 — device is busy seting up new clk_h frequency or processing other system commands. |
Table 2. AtomMiner Status Register
Here’s the typical workflow showing how to initialize device and actually start mining:
1) After power on hardware fires up at 25MHz for safety
2) Required set of commands to initialize hardware and setup work frequency. We recommend to execute this set of commands every time software and/or hardware was restarted since there’s no reliable way to identify power down on the hardware part.
— host_break;
— set_clk (for instance, 0x431A willl try to change hardware frequency to 50MHz)
— host_break;
— get_status (Status block should have requested frequency and busy bit is 0 if all previous operations were successfull)
3) Following commands: get_signature, read_ubuf, get_status, get_current_nonce – can be sent to the hardware at any time after initialization has completed successfully.
4) Next set of commands will transfer block data and start mining
— host_break;
— wr_block 8’h38{byte[47:0]};
— set_target 8’h54{byte[23:0]};
— get_status //optional if you want to verify ready4hash status bit
— start.
On success (solution found) hardware sends 8 bytes buffer back to the host: 4bytes of the GoldenNonce followed by 0x21212121 constant.
Failure to find successful solution within source data will return following constant in response buffer 0x7f7f7f7f7f7f7f7f, which technically means that hardware is ready for the next block of data to chew on.
5) set_clk command can only be sent to hardware while it is stopped (status[8] == 0)
— host_break;
— set_clk
— host_break;
— get_status //to verify new frequency has been setup correctly
