The overall design remains constant, but the attributes and inputs to the decision tree continue to be changed. The communication between the RPI and mining pool seems to have been isolated and the link in the spotlight now is between the RPI and the FPGAs. We will begin to link up the entire system to test the communication modules to make sure that everything is ready to be hooked up. The largest risk here is just in the modules not working as intended and the management of the risk is exactly as we’re doing, preparing the system and testing it to make sure that it works before moving on.
We had planned on having the FPGA send the number of hashes it completed to the Raspberry Pi in order to get an accurate picture of what the system hash rate is. However, this component is at risk because the timing of when to send this information is still up in the air. We want to minimize all communication with the Raspberry Pi to critical information only. This way, the system is able to scale up to 10+ FPGAs. We intend to mitigate this risk by having the Raspberry Pi calculate this hash rate instead of it being transmitted. Each FPGA has a unique ID and each hashing module on the FPGA has a set numerical bound from which it iterates through nonces. We intend to write software that takes the correct nonce, deduces the bounds that this nonce is in, and calculates the number of hashes the system ran through to reach this nonce.