Posted on

Team Status Report for 4-30

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.

Posted on

William’s Status Report for 4-30

This week I continued working on the Ethereum mining modules and almost have the cache and dataset generation complete. One issue I ran into was the FPGA not having enough memory to store the full 1GB dataset size. I am attempting to solve this problem by only storing the 16MB cache and generating dataset entries as needed. Although calculating dataset entries as we go along will take longer than pre-generating it, this seems to be the only solution as of now. I also researched more about ethash and the hashimoto algorithm that it uses. Although there are some speed optimizations that others use between a light hashimoto and a full hashimoto, we are limited by memory to only the light hashimoto. This version only uses the cache and not the dataset.

I am slightly behind on finishing the Ethereum implementation. I spent the past week having to help Lulu debug the Raspberry Pi communication while also generating configuration files for the team to test the GPIO sending and receiving. Although I anticipate being able to finish the Ethereum component on time, I am unable to fully test receiving puzzles and sending nonces without the Raspberry Pi communication up and running. That is still the biggest bottleneck of this project.

Next week we will be presenting our project at the Final Demo on Friday so I will have the Ethereum mining modules working as intended. If communication still does not work at that point, I will resort to running them on preset puzzles like I am doing for Bitcoin. The FPGA configuration switching will be operational with the decision tree portion of the project.

Posted on

David’s Status Report for 4-30

For the week, I had to present our final presentation. I worked on my portion of the slides, which included work left to be done and verification and testing. I asked my teammates to leave me some things to say so I could present their slides, but Lulu failed to include anything. Luckily, half of her slides were very similar to slides I had made for previous presentations so I was able to come up with things to say on the spot because she had not informed me that she left me with nothing. After seeing all of the interesting presentations that the other teams had put together, I focused in on continuing my testing of the system. I ran longer tests to get a better grasp of the true accuracy (however close I can understand of it) of the decision making process. I expanded my testing to include spreads of more than 2 FPGAs, including 6 boards and 10 boards, changing the scaling up process to 2-6-10 instead of 2-5-10. This made more sense as we can start from an equilibrium state regardless of the number of FPGAs. I also ran tests on the thresholds with which we decide to change configurations to better improve the overall robustness of the system. I came up with different ways to make the algorithm more robust to sudden volatility spikes that may change the configuration and make the FPGAs reset unnecessarily. I also made plans with the team to work on the poster, but Lulu remains inactive, so might have to work on that only with William. I also await Lulu’s response to my asking of her status update on the receiving code.

In terms of my schedule, I am on time. I conducted tests and will analyze my data with better numbers from lessons I learned during my own presentation. Since Lulu is unresponsive, I can only try to keep helping William with the Ethereum miner implementation.

We also have to begin writing the final report in addition to finishing the poster.

 

Number of Boards for each coin

Attaching a small sample of the many graphs I’ve generated and analyzed

Expected Revenue of switching after scaling up system
Posted on

Lulu’s Status Report for 4-23

For this week, I met up with a TA to discuss our issues in the communication modules between the Pi and the FPGA. The reasons we are dropping bits are mostly likely due to the fact that the clock is shorted and the FPGA is not sending on a frequency that the Pi can operates.  Right now the pi is the host, but the FPGA is sending the clock signal instead of the Pi. When using the SPI library, the Pi also sends in a clock signal, so our clock signal is shorted which affected the results when we are receiving signal from the FPGA. The TA suggested a solution which involves changes on the SPI code on the FPGA side. I already informed my teammates about the TA’s suggestion and we will see if we can work something out. In the mean time, I’m working on the presentation slides that are due on Sunday. In terms of schedule, I think I’m behind since I need to wait for the FPGA side’s SPI code to change to test my SPI code on the Pi. I will continue to work with my teammates to resolve this issue.

Posted on

William’s Status Report for 4-23

I continued to debug the Ethereum mining code along with the associated SystemVerilog communication modules. I looked into the source of the issues and found out that Ethereum requires a cache size of 32 MB along with an ever changing dataset size. The current dataset is about 2.78 GB which should fit on the SD cards that we bought. I am using this information to hash the Ethereum puzzle to compare against its target.

Another issue we ran into was getting the configuration switching time low enough to meet our requirement of 10 seconds. Quartus Programmer loads the boards sequentially even when given the command simultaneously so I researched using threads and other concurrency tools to lower our switching time. After talking with David, the solution we came up with was to change the way the cryptocurrency spread was updated to only change one board at a time.

I did more metric testing this week by getting the cell area, power, and hash rates of our system running with one mining module vs. multiple mining modules. I then used this data to calculate our expected returns. With this information, I plan to work on optimizing our design next week so that we are able to generate higher returns.

I am on track with my schedule but still running into issues with testing my part of the project with the Raspberry Pi portion. Lulu is working on getting the sending and receiving code to work so I am waiting for that to finish before I can fully test the communication modules of the FPGA.

Posted on

Team Status Report for 4-23

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.

Posted on

David’s Status Report for 4-23

For the week, I focused on the decision algorithm where I started to play around with the weights and seeing how they affected the decision making. This is where the bulk of my time lies. Different inputs have different weights in how they affect the spread. I also had to change our accuracy metric because the way we were measuring the accuracy was flawed. We were at first measuring the accuracy by considering the price changes and the price percent change. This was giving our predictor with accuracy ranging from 80-94%. We are now changing the accuracy rating where we scale up our mining rate and check the expected revenue from the mining pool. We also worked on the presentation that’s due Sunday. I worked on my slides and told the rest of the team to finish their slides by tonight so that we can meet tomorrow and have a meeting where we can prepare myself for the presentation next week. The ticker used for all the data was also reverted back. Using BUSD for the tickets didn’t fix the issue, instead the fix was to keep the client inside all of the api call helper functions so that it would pull the most recent data each call. 

In terms of my schedule, I think that I’m relatively on time, I’m just still waiting on receiving to work so that I can more accurately have testing metrics. It is hard to have accurate metrics to present, but we have relative numbers that we can extrapolate and present. 

I will continue to work with my teammates to implement Etereum and finish fixing receiving code. I know that Lulu has met with a TA regarding this issue and maybe has a workaround. Hopefully she can get this working soon.

Posted on

Team Status Report for 4-16

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.

Posted on

Lulu’s Status Report for 4-16

This week I kept working on the GPIO communication modules, specifically the receiving function. While I was debugging, I realized that the MISO pin on the pi that we are using to receive data from the FPGA is stuck at 0. Using the other pin, I was able to get the receiving function working.

In addition, I was able to set up the web app environment on the pi and the web app is now running on the pi. I also set up the web app so it can display the decision that our machine learning algorithm outputs and the profit we get from the FPGA miners. In terms of schedule I think I’m overall behind but caught up with my teammates. For next week, I would like to test the receiving function with the FPGAs and display the metrics on the web app if the project is done. I will also help with improving the decision algorithm if my parts get done early.

Posted on

David’s Status Report for 4-16

For the week, I focused on my parts in scaling the design up to support Ethereum mining. The communication packets are different and need to be stored differently, but everything should be working in that regard. There was an issue with the ETHUSDT ticker for the Binance API where the data was incorrect, the tickers have since been updated to use Binance’s own stablecoin as the second coin in the ticker pairing. This should be enough for longevity unless Binance decides to remove support for their own stablecoin. The historical data comes in through kline data and is processed as such, but inference was not happening with kline data, it has since been changed to use kline data. This allows the added metric of volume of transactions to be used in predicting. I have it set such that when outputting a spread, it will favor choosing the coin with more transaction volume.

In terms of my schedule, I think I’m still overall behind, but in pace with the progress that the rest of my team has made. Most of the work I have to do now has to deal with testing and metric evaluation, which is hard to do without the rest of the project done.

I will continue to work with my teammates to get their parts done. I know that receiving from the FPGAs is still a work in progress that is very important to the communication so I will focus my efforts to helping Lulu with that. I will also work on my own part, perhaps even trying different machine learning models if my team doesn’t require my help. This will also include finding more attributes to help prediction.

Posted on

William’s Status Report for 4-16

This week I implemented all the SystemVerilog code needed for Ethereum mining. This included the mining module, the FPGA module to accept Ethereum puzzles from the Raspberry Pi and the module to send completed Ethereum nonces to the Raspberry Pi. I also created testbenches for these modules in order to test their functionality through simulation. While the mining module still needs some debugging, the communication ones appear to be working as intended. In addition to this, I also synthesized this full design with Quartus onto an FPGA. The FPGA can take in a bitstream through the GPIO pins and store the puzzle in its internal memory. Once the mining modules find a correct nonce, it outputs this through the GPIO pins as a bitstream as well.

In terms of my schedule, I am a little behind on getting the Ethereum code working. The mining module is causing some issues that I still need to fix. I still have not been able to test the Bitcoin communication modules because the Raspberry Pi side of this is not working properly. Until this issue is resolved and that part of the project is functional, I will focus my attention on getting Ethereum working.

Next week I hope to test the Ethereum modules more rigorously on the FPGA. This includes connecting reset wires from the Raspberry Pi and testing configuration switching. I will also hook up LEDs to our breadboard as an interim way to test communication while the Raspberry Pi code is being worked on.

Posted on

Lulu’s Status Report for 4-10

For this week, I worked on debugging the GPIO’s sending and receiving functions. Sending is working, but receiving still needs some refinement. It needs to be on receiving mode whenever sending mode is off. In terms of schedule, I’m a little behind on the GPIO communication modules. I will consult with my teammates next week during our scheduled meeting to get the receiving function done ASAP. For next week, I would like to have the receiving function done and the web app displaying the current cryptocurrency that we are mining base on the ML algorithm as suggested by professor Kim.  During the interim demo, there was a bug with the graphs that I would like to resolve for next week.

Posted on

Team Status Report for 4-10

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.

Posted on

William’s Status Report for 4-10

This week I wrote code that gets information from the remote server and copies it to the VM that we are running the FPGA synthesis on. This code will read a file created by the decision tree that tells it which cryptocurrency to mine and eventually receive information on how much to mine as well. I tested the FPGA outputs on the breadboard since we were not able to test the Raspberry Pi receiving code. By using an LED and GPIO wires, I was able to see that the FPGA outputs the valid nonce once it mines it. 

The work that needs to be done to verify the FPGA communication is now falling behind schedule. While the mining portion of the project is close to completion, I am unable to test communication without the Raspberry Pi working as well. I will continue to press my teammates for updates to determine its status.

Next week I hope to have the communication portion between the FPGA and the Raspberry Pi complete. I want to test that the response headers and the puzzle information is being sent/stored correctly.

Posted on

David’s Status Report for 4-10

I have worked with my teammates to make sure that their modules were working as intended. With Lulu’s sending and receiving functions, I changed it to match the clock that the FPGAs run on so we sync up the communication. William and I debugged the sending part such that we currently have a sending function working and is received by the FPGAs. I have instructed her to finish up the receiving function, which should wait for the nonces from the FPGAs. William and I also found a way to get around the remote server idea by simplifying using github where we push and pull `mine.txt` regularly.

Aside from teamwork, I have found a way to get information from the Binance API that tells us the trade volume, which was one of the metrics Professor Kim recommended us to look into.

Posted on

Lulu’s Status Report for 4-2

For this week, I figured out how to setup the RPi using a monitor, which took a long time. I also spent many hours attempting to hook it up to the wifi and then finally proceeded to work on the code. I finished implementing the communication and was able to test the send byte function.

For the receiving function, since I can’t manually change the input pin, we still have to hook it up to the FPGA to see if it works.  In terms of schedule, I think I’m back on track. For next week, I will try to integrate this with the FPGA to debug any potential issues such as endianness, and the receiving function.

Posted on

David’s Status Report for 4/2

My focus for the week has been to figure out how exactly to link together all of my modules. Some components that I had were dependent on the Python version like using the Binance API or how the socket communication was configured. I resolved the version issues and changed the Miner so that it would connect to multiple mining pools at the same time. All information obtained from the mining pool is ready to be sent over, but I continue to wait for that part of the project to be completed. I have been able to link the decision process and communication with the mining pool together. There is a main miner object that connects to the different mining pools, currently 2 of them for different coins on different ports. Before this, it trains on the historical data to have its model ready for inference. After subscribing to the mining pools, it spawns jobs from their replies in threads so that the main thread can sleep every 10 seconds determining when to switch. Our way of switching has changed because of OS difficulties, so it currently outputs its prediction into a file to be transported to and fro remote servers. It waits for replies from the GPIO wires (waiting for this to be done) and sends this back to the mining pools.

I will continue to improve the decision process with suggestions from Professor Kim about using the number of transactions (trades) and integrating more real time data like number of shares found and difficulty. I will also try and see if I can find a way to funnel in the amount of money we get into the decision making process. I know the demo is coming up, so this may take a backseat as I try to help my other teammates to get back on track with what they’re doing, or perhaps figure out the details on the remote server communication.

Posted on

Team Status Report for 4/2

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. 

Posted on

William’s Status Report for 4-2

I was able to accomplish most of the FPGA system setup this week. Following the feedback from the meeting, I added support for configuration switching to the project. Now, when the decision tree decides to mine a particular coin, it sends a command and a section of code outputs a script to the command line. This script will execute and load a pre-saved configuration to the FPGA through Quartus Programmer. I tested this setup with an FPGA using multiple Bitcoin mining modules. I decided on using eight per FPGA through extensive testing to see the amount of area each design would take. I also tested a system with two FPGAs mining in parallel. Eventually we would like to scale this to five or ten but the design works well with two boards and I see no reason why it wouldn’t be able to scale.

Although the FPGA part of the project is almost complete, I am still unable to test communication with the Raspberry Pi because that component is still being worked on. All my tasks are on schedule except for testing this FPGA to Pi communication. I will keep checking in with the team to see what the status is and if I can take on more tasks.

Next week, I want to finalize the design for the second cryptocurrency that we are mining. I am hoping to have the hash algorithm, mining module, and nonce verification modules complete. I would also like to test this component both through simulation and synthesis with a multi-FPGA setup before the demo on Wednesday but I may only be able to do this on a one FPGA setup. The Quartus compilation time for the code is approaching 20 minutes which limits the degree of synthesis testing I can perform.