Category: Team Status Reports

The accuracy measures that we had in our presentation was made for 2 boards, which included all of the graphs and other metrics. The accuracy metrics have been updated to include different number of boards and more ways to try to improve the robustness of the switching algorithm. The algorithms tested are for favoring equal split, linear peak, exponential peak, and equal splits. Accuracy number for this will continue to be analyzed to confirm the best state that our choosing algorithm can be in.

Another risk in our project lies in the memory limitations of the FPGAs when mining Ethereum. Ethash is a memory hard hashing algorithm which means that it was designed to prevent ASICs and other specialized hardware from gaining an advantage over GPUs and other systems. Thus, the limited memory space on the FPGAs make it difficult to efficiently mine Ethereum. Although there does exist ASICs that mine Ethereum today, these boards are more expensive and more complex than the systems that we can create on the DE0-CV FPGA board. To mitigate this risk, we will attempt to only store the 16MB Ethereum cache and if this also does not work, we will create multiple smaller scale caches that provide the same functionality.

The accuracy measure for the entire system has been changed. Initially, the accuracy measure was how often the predictor was predicting to mine the coin that had the higher price change. The accuracy now is measured based on switching and scaling up the system. The profitability metric is conducted based on the expected revenue the mining pool will generate based on the hash rate that our system provides. The largest risk that lies with this change is that the mining pool data for revenue is technically given in 24 hour increments which is a much coarser granularity than the switching time that we are using for our system. This will be risk mitigated by keeping track of the different price points and using Gaussian noise to extrapolate the expected revenue. We can then create an expected revenue for what we would believe to be an ideal switching, with and without the 10 second switching.

This week we continued to troubleshoot the issues surrounding the Raspberry Pi sending and receiving code. This still remains the greatest source of risk for the project. While we were able to send a one clock pulse to reset the FPGAs, more intricate communication such as cryptocurrency puzzles or nonces are unable to be sent. The receiving part of the code was also problematic where it was able to detect steady high signals but was less keen on receiving actual data with the same 50 MHz clock that the FPGAs run on. There is an added complexity with driving the same bus with different signals, which may cause some data corruption if we don’t manage it. There are limited alternatives to our current method of communication if we cannot get it functional. Part of our team will research communication through JTAG as a backup plan in case we do not sort out our issues. This would require a redesign of the way the Raspberry Pi is currently connected to the FPGAs so JTAG is an option only if we cannot get GPIO to work.

For the project as a whole, we have began to add all of the necessary modules for Ethereum support including data structures, communications, and mining modules.

Following the demo, we have put together most of the system. The largest part missing is the receiving code that the Raspberry Pi runs to accept nonces from the FPGA. Lulu is responsible for this, but we will try to assist her in finishing this part as much as we can while we work on our own parts. We now have access to information about the trading volume so we can make our decision on that as well.

While SHA-256 is a well known hashing algorithm with plenty of documentation online on how to implement it in SystemVerilog, our other cryptocurrency choice, Ethereum, uses Keccak-256 which is less well-documented. There is a risk that we will have to pivot to using another cryptocurrency or devote more time into implementing Keccak-256 which takes time away from other aspects of the project. The Bitcoin miner which uses SHA-256 is close to completion but the Ethereum one is still being tested and debugged. If we cannot get it to work, we will try to find existing publicly available hardware implementations of Keccak-256 or choose a different cryptocurrency with a different hash algorithm.

The largest change in plans has to deal with configuration switching on the FPGAs. We can change the synthesized design on the boards via command line with Quartus Programmer, but Quartus only runs on x86 processors and the Raspberry Pi has an ARM processor. This means that the Raspberry Pi will not be able to tell the FPGAs to switch from one cryptocurrency to another. Our current solution to mitigate this risk is to upload a configuration file to a remote server accessible by both the Raspberry Pi and code running locally on one of our laptops. Using this, we can parse the remote file to reconfigure the FPGA boards. The design for this new solution has incurred an additional cost in the purchase of a ten-to-one USB hub so that all of the boards can be reconfigured from a central location. 

The decision making process and the code that talks to the mining pool is largely complete. The decision tree can be heavily improved, but that will be put on the back burner for a little bit so that the entire project can come to life in time for the demo.

The most significant risk lies in the GPIO communication where we continue to wait on progress there. 

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.

The hashing rate of the FPGA can be increased by having a greater number of hashing modules. However, with each Bitcoin module taking up a cell area of ~13,000 units, we are limited by the number of logic elements on the FPGA. If this is a problem for reaching our target hash rate of 5Mh/s, we will need to optimize the hashing module further. There are additional pipelining techniques that we can use to cut down on the idle time of the hashing module. Additionally, some parts of the block header are being hashed without any modifications. We can eliminate more than a billion redundant hashes by caching this somewhere.

Communication method between FPGA and the web application has not been set and tested yet. For the mitigation plan, we will have the FPGAs send over dummy data to the web app and the web app will then display the data on the website to make sure the communication protocol between these two components are set.

The accuracy of the decision tree is not very high on preliminary tests, but this is with the framework of only 2 attributes both stemming from price changes in the past 10 seconds. The tree was also trained to be rather shallow with the hyperparameter being relatively low. This is only a short term risk and should be bettered later on when we introduce more attributes and deepen the tree to improve inference accuracy.

Caching part of the block header hash will affect how the Raspberry Pi communicates with the FPGA. If we decide to implement this change, it wouldn’t make sense for the Raspberry Pi to send the full 80 byte block header. Instead, out communication protocol will have to be changed to send a 256 bit hash followed by the remaining 36 bytes of the block header. Implementing this change will cut down on our communication costs and allow the system to scale better.

We will no longer be using the stratum mining proxy in tandem with the getwork function to communicate with the bitcoin blockchain, instead we have directly migrated to communicating with mining pools with the stratum protocol. This should make communication more streamlined and understandable while also widening the pool of currencies that we can mine. This does create a overhead where we have to understand the protocol to use it, but we have examples from other available miners to base our implementation off of.

The unavailability of our Raspberry Pi continues to plague us. We have received our Pi Wedge, but we continue to not hear back about the Raspberry Pi. In an attempt to mitigate this risk, we are trying to enter into the Hackberry Pi hackathon in an attempt to get a RPI from that. The largest blocker in testing mining locally has largely been solved through the discovery of a stratum mining proxy that can effectively bridge the HTTP and stratum protocols for mining. Now, to create our RPI communication protocol with mining pools, we just need to research how other established miners such as cpuminer-multi and bfgminer connect to pools. The only potential risk here is that the stratum mining proxy does require sudo access so the computers in the lab room may not suffice.

We continue to work on the FPGA modules controlling both the communication and hashing. The communication part of the system is now able to store the input Bitcoin/Ethereum puzzles and replace them with new puzzles if needed. These puzzles are recreated on the FPGA through a single bitstream sent by the Raspberry Pi. One of the risks in this method is that a cryptocurrency with a large puzzle size may take up too much hardware area on our FPGA. This would limit the amount of area available for hashing. We are researching ways to cut down on the puzzle input size and only send the necessary information.

Our most significant risks as of now consist of the probability of dropping packets during our communication protocols. The packets that we send are carefully crafted to contain information that the hashing modules will need so we need to make sure that the packets won’t get dropped or corrupted. This might become more of a problem when we start to scale up our design to more FPGA boards because our current plan includes using a breadboard and the Pi Wedge to bridge the connections between the GPIO pins between the Raspberry Pi and the FPGAs. By including checksums or other types of CRCs, we can diminish the effects of dropped bits by detecting them before computation. However, the inclusion of CRCs will eat into our communication budget and is not a solution for the RPI to breadboard interconnect.Through further research, we are examining whether the plans we have in place are feasible. If communication bandwidth proves to be an issue, we have a contingency plan to increase the number of bits sent by our SPI protocol from one to eight. This should reduce any bottlenecks caused by communication.

We didn’t make any changes to the requirements this week. The specifications we laid out in the proposal are still the guiding principles of the project. This week, we as a team fleshed out more about the communication protocol and how we plan on performing the choosing algorithm. On the communication side of things, we fleshed out what our data packets would look like and what the different fields inside of the packets would contain. We also discussed the possibility of packets dropping and discussed sending ACK packets that would help network traffic confirmation. In regards to the choosing algorithm, we want to generate a bunch of hashing modules and have a select line input to decide what the hashing modules will compute.

The progress of the project is going well with a large portion of the research completed and some implementation occurring already. We still need further concrete details on how each hashing algorithm will be translated into SystemVerilog. With the delivery of the Raspberry Pi and Pi Wedge next week and the inventory of FPGAs already in hand, we anticipate being able to perform testing in the weeks to come. Because of this setback, we also have to push back our planned parallel testing of our modules. The expected completion dates for that will be pushed back accordingly with the arrival of our Pi components.

A major part of our project is the Raspberry Pi since it will serve as our mode of communication between the FPGAs, the webapp and the cryptocurrency blockchain networks. Seeing as how it is such an integral part of our design, we wanted to spend extra time and pay closer attention to the specifications before locking in our decision. However, this poses a sticky situation where the Raspberry Pi we want is not readily available in the 18500 inventory as the FPGAs were and the Raspberry Pi is also out of stock online. We are in the process of looking into other Raspberry Pis in the meanwhile.

We haven’t made any changes to the requirements of the system. The specifications may have to change depending on the Raspberry Pi that we can get ahold of. We have successfully allocated at least 5 FPGAs and will look to scale up in the further weeks.

We pushed back completion of the communication modules because we misjudged the total amount of time it would take, especially because we had to deconstruct our tasks into tasks that took less than a week. The schedule also changed because we were unable to acquire a Raspberry Pi to perform testing on. This is a central component of the system and will take longer than we initially estimated. Further progress on these tasks is now estimated to be made on February 18.

Working components on web app: