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.

Posted on

David’s Status Report for 3-26

In terms of the Raspberry Pi, we still need to consult somebody on how to set it up properly on CMU Secure, but currently, we can work on it at home with an ethernet connection. I have since created a module to create the miner and client to communicate with the mining pools. There is a slight oddity with how bytes and strings are dealt with with Python3, so the client is currently written for Python2 where there isn’t as much of a distinction between bytes and strings, which is easier to understand the data that is sent to the mining pool and the data that we get back from the pool. The mining pool in addition to giving work also gives the previous hash and changes to the difficulty. The last step now is to send the data and receive answers via the GPIO Pins. The decision tree has also been updated to include another attribute of volatility that is currently crudely calculated with an average threshold. Currently, I take the averages of the differences of the high and low prices and divide it by the average of the open and close prices. This in some sense gives a metric of how volatile it was from a generalized mean value. All of these mean values are averaged to get an overall threshold value that the get_data method will use to update the label generation. In addition, the decision tree inference currently conducts a majority vote at the node it traverses to, but the vote has now been changed such that it takes in external variables which currently include shares found and difficulty. Future work involves expanding all of these and especially on Sunday and Monday I want to make the modules to hook up the system so that we can push to have a prototype that doesn’t necessarily have to mine yet, but can at least communicate so that we can set up/hook up everything else during the week.

Posted on

Team Status Report for 3-26

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.

Posted on

William’s Status Report for 3-26

This week, I finished the second part of our testing regime by synthesizing every module through terminal as well as using Quartus. I added synthesize commands to our Makefile and updated the FPGA module code such that any unsynthesizable logic was replaced. In particular, the top module took the most time because I was accessing the GPIO pins as a 36 wire block. However, this was causing issues because I needed both input and output functionality within a block. I ended up separating the wires out and only using the five that I needed to implement SPI. In addition, I hardcoded a Bitcoin block header into the code for testing. For now, the FPGA will cycle through all nonces until it reaches one that hashes below the target. Because the block header is preset, the communication aspect of the FPGA modules were not able to be tested.

I am still on schedule because most testing was finished this week.The FPGA side of the communication with the Raspberry Pi is complete but I am waiting on the Raspberry Pi side to be finished.

Next week, I will switch to working on the Raspberry Pi software and making sure that it is able to send and receive data. After this is complete, I can finish the FPGA testing by having a block header be sent over, the FPGA hashes it, and sends the correct nonce back to the Raspberry Pi.

Posted on

Team Status Report for 3-19

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.

Posted on

David’s Status Report for 3-19

Since the last status report, many hours were put into the mining proxy that we will not get back. The original plan was to use the same getwork protocol that is used in the Open Source FPGA Miner and bridge the protocol connection with the stratum mining proxy. This path was filled with dependency issues and different work arounds since that miner is meant for Windows and relies on root command, something I don’t have control over on the ECE machines and limited by my own resources locally for tools and dependencies. Even when I got the mining proxy to finally run on the ECE machines, the miner wasn’t able to connect to the proxy, perhaps with some ip address issues, so instead of driving more dead hours into debugging this, we moved on. However, the ultimate reason we decided to no longer continue with this getwork bridging was because this was only going to solve the communication problem for Bitcoin. The same solution was not going to work with Etereum, or any other currency for that matter. Instead, I decided to directly communicate with the stratum protocol, something I guess could be argued that we did in the first place. We didn’t because nobody had experience with the stratum protocol or its parent protocol, JSON RPC. I was able to find some documentation about the protocol and some miner implementations that use the protocol. So at this point in time, we have a very basic communication protocol that can at least receive requests from the mining pool.

Aside from that, I also worked on the decision making process, constructing the decision tree and the scripts necessary to gather the data for training and inference. The decision tree is built upon the historical data we pull from the Binance API. I took the historical klines code from the webapp and pulled as much data as I could to create the training file. The data is formatted currently as price_change_btc, price_change_eth, coin. The coin is ultimately what the miner should have mined. This decision is currently crudely made saying that the miner should mine bitcoin if the price change for bitcoin is up and ethereum otherwise. The model is then used every 10 seconds for inference. Work to be done here is to add more attributes for the decision tree to split on, improve the label generation for training, and process the decision more to not output a coin specifically, but a spread of which coins to mine (probably with some mechanism to prevent it from always predicting the same spread).

Setting up the Raspberry Pi has proven to be a little more problematic than I would have hoped. Setting up the internet with my home wifi is worse than with CMU-DEVICE since there is at least some documentation about how to do it on CMU-DEVICE, my home wifi uses some third party that has no documentation. However, I did try to set it up on campus with the guide, but to no avail. I have another plan to set up the internet since William was able to ssh into the pi, but that will have to wait after the status report. Additionally for work for next week, I hope to finally create the modules to send data from the RPI to the FPGAs to finally start bridging between our different parts. I guess as an administrative thing, as a group we finished the design review document and we each also separately did our ethics assignment.

Some inferences after training:

Sample training data (Data Format):

Posted on

Lulu’s Status Report for 3-19

For this week I worked on the table that will display cryptocurrency information from the past 24 hours. In addition, the website will now refresh every minute to ensure the current prices are up to date. I tried deploying the website using the Amazon EC2 instance. The instance was setup successfully but I need the final GitHub repository link to deploy the app, which is not yet available because we are working on separate branches individually and haven’t merged into the master branch yet. In terms of schedule, I’m a little behind on the integration between FPGA and the web app. I still need to move the code for the web app from my local computer to the RPi and test the data transmission from the FPGA to the web app. Since we are prioritizing getting connected to the mining pool first, the work for the web app is pushed back a bit. In the meantime, I was working on the SPI send byte function that will take in a byte and turn it into bit format to transmit through  GPIO pins. I was also helping to get the historical data for the cryptocurrency and converting it into a format that will be easier to use for the decision tree that we implemented. For next week, I would like to have the FPGA send dummy data and have the web app display on the website to make sure I have the communication method set for these two components. I will also help with other components that we need to finish before the interim demo.

Posted on

William’s Status Report for 3-19

This week, I finalized a lot of the FPGA modules that will be performing the mining and the communication. I researched an efficient way to perform SHA-256 hashing online and used the Wikipedia article on it to create my own implementation.

I then tested it with a SystemVerilog testbench to ensure it worked properly. For Bitcoin mining specifically, it requires the hash output to be hashed a second time. Thus, I created a pipeline structure that allows for this second hash to be computed while the first SHA-256 module moves on to the next nonce. This was also tested with an individual testbench.

The mining controller is now able to calculate the hash target based on the input puzzle and perform a comparison to check that the hash output is valid. Once the hash is valid, the nonce used to generate this hash is saved. On the communication side of the project, I implemented the FPGA out, Raspberry Pi in, communication module that sends the correct nonce to the RPi through GPIO. It serializes the data and sends the packet along with a header. This was tested as well.

With my work this week and last week, I am now on schedule with my assigned tasks. I caught up on work and will continue to work on the testing portion of the project phase.

Now that all the modules have been implemented and tested through VCS simulation testbenches, I want to move on to the next part of testing with synthesis. Next week I will be doing bug fixing on the FPGA files so that all of them will be synthesizable. Along with this, I will load the final design onto an FPGA and test whether the system as a whole works.

Posted on

Team Status Report for 2-26

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.

Posted on

Lulu’s Status Report for 2-26

This week I kept working on the features for the website, specifically getting past data and plotting the trends for all the cryptocurrencies. I got the past data from the binance API and stored them using the pandas data frame. At first I tried to use matplotlib functions to plot the data and display it on the website, but I encountered many errors. In the end, I was able to plot the data using plotly functions instead. Right now the web app has candle charts and line charts displayed for bitcoin and ethereum, below are examples for each chart. Overall I’m on schedule for developing the web app, but since the RPI has not been delivered yet, I couldn’t work on tasks or testing related to the RPI for the past week. For now I will keep working on the web app and other parts of the project until the RPI comes, then I will switch to RPI related tasks. For next week, I will be working on the design review report and adding more features on the web app.

Posted on

William’s Status Report for 2-26

This week I created the framework for the SystemVerilog testbenches that I will use to test the communication modules. For the communication module, I hooked up the module ports in the testbench file and added randomized testing inputs as well. I haven’t run the test with VCS yet because we are still finalizing the bit widths of the module inputs. Additionally I also finalized the design for the communication module and added functionality that allows it to recreate the Bitcoin puzzle from a single bit data input. The top module containing the communications now has buffers that are able to store this puzzle and replace it with a new puzzle when needed. I anticipate being able to run this implementation along with the testbench next week. 

Next week, I will synthesize the design as well in order to fulfill the second part of our testing plan. The FPGAs have arrived already so I can load it onto the board to test with the switches. I am still on schedule to finish my portion of the code including the communication module next week. However, I placed an order for the Raspberry Pi about 1.5 weeks ago and still have not heard back. The software we need to test on the RPI is still in hiatus. I will speak with the course staff if I haven’t heard back by next week.

Posted on

David’s Status Report for 2-26

Last week, I encountered a blocker where I was unable to connect to mining pools because they no longer support HTTP and getwork, but instead use the stratum protocol. In working around this, I have decided to use a stratum mining proxy that will bridge the gap between the protocols. This was the result of first researching the deprecated getwork method and postulating how to request work from pools. After some literature review of another project using the same FPGA miner, I decided to use their solution to the same problem. The mining proxy is more generally for testing mining when using a computer as the middleman with a mining pool. However, we want to use a Raspberry Pi as that middle connection, so I also looked into multiple existing miners that either use FPGAs or CPUs so that I can use them to figure out how we want to communicate to mining pools. These include repositories of bfgminer, cpuminer-multi, and btcfpgaminer. For my task to create and test a module for the RPI to communicate with a mining pool, we are still waiting to receive our Raspberry Pi. I also have the task in figuring out web synthesis, but we have since decided to pass the configuration as an input to the FPGAs, so we don’t need to resynthesize anything. I worked on my slides for the design review presentation and provided a script to the presenter. I also began working on the design review report. I am now slightly behind on my task to simulate mining locally because I had only recently discovered the work around, but I have access to the mining proxy now, I just have to figure out either how to get Quartus on my mac or how to sudo on the 240 machines. In regards to other tasks, I am pretty much on track.

Posted on

David’s Status Report for 2-19

This week, I dabbled in many different aspects of our project that also happened to strike a good balance between solo work and team work. In our team sessions, the most important things that William and I did for our group was we fleshed out our communication protocol and choosing algorithm to an extent. We determined our packet structures and the different types of packets we would be sending. William and I also did some research on the differences between our requested Raspberry Pi 4 and the RockPi that Professor Tamal suggested we should take a look into. We ultimately decided to go with our original request and I put in another request for 5 more FPGA boards to make sure we can guarantee having enough boards for our final product. On the solo work side, we had two main large issues in figuring out how to maneuver around the Binance API and how the mining would actually take place, so I decided to research into both of these. For the Binance API, I read into their online documentation. For the mining, I tried to configure the open source fpga miner I found during research, but I kept running into various issues like trying to run windows commands on linux, quartus not working properly, different compiling issues, etc. I managed to work past all of these issues, but I ran into a different issue where that source code used a deprecated way of getting work, so I need to find an alternative to test or create my own before testing. Overall, I’d say I’m on track where I’m a little ahead on some tasks but behind on some other tasks. We also had a team meeting where William and I basically wrote the team status report and delegated slides for the upcoming Design Review presentation.

Posted on

Lulu’s Status Report for 2-19

For this week, I kept working on the web app, specifically I made the model that will store the user information and customizations that they wish to make on the FPGA. On the home page there’s now a form with five different mining ratios that the user can choose from. The data is then stored in the Profile model’s sub model Customize’s field ratio. In addition, I also researched the API, Binance, that will be use to display the current price and the trends of the cryptocurrencies. This week I managed to have the current prices of BTC and ETH display on the home page. I’m going to work on displaying the trends on home page next week. I also redesign the website a bit and added a gif to make it less bare, and I will look into displaying more stuff in the future.  In terms of schedule, I think I’m on track now that we pushed back the date for integrating with the raspberry pi. I will start working with the raspberry pi once it’s delivered.

Posted on

William’s Status Report for 2-19

As mentioned last week, I wanted to more fully flesh out the communication modules. I was able to accomplish this and catch up with my assigned tasks such that I am now on schedule to complete my portion of the work. This week I worked further on the top and communication SystemVerilog files. Seeing as our FPGAs arrived but the Raspberry Pi was still being delivered, I focused my attention on developing the FPGA files instead. I added combinational logic for both input communication and output communication to the FPGA. This controls whether the FPGA is receiving a parameter update packet or a crypto mining packet. 

The modules that I added are now capable of handling both MOSI and MISO communications. The specifications for the two were different so two modules were needed for both. It includes combinational logic to control which buffers to write to along with sequential logic that determines which state the module is currently in.

I also started working on the hashing controller for the FPGA. I researched the hashing algorithms for the cryptocurrencies we are planning on using and added module interfaces for those algorithms. I plan to decrease the wire sizes of the input puzzles in order to reduce the board area size taken by the controller.

I am on schedule to complete my tasks in time for testing before Spring Break. There is about one to two weeks of work left on the FPGA files before I will run them with a testbench through VCS simulation. Additionally, I plan to synthesize and test it on the board as well. In the next week, I plan to solidify some of the more subtle details of the code such as wire sizes and number of hashing modules in order for the code to be ready for testing. With the arrival of the Raspberry Pi next week, I will also pivot towards developing software code for the RPI.

Posted on

Team Status Report for 2-19

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.

Posted on

David’s Status Report for 2-12

This week was generally more heavily focused on researching both the hardware specifications of the board we wanted to use and researching the software connections between our modules. It is imperative that we perform sufficient research into this because our aim is to maintain a low hardware cost while achieving the same performance. Settling upon the DE0-CV boards, I successfully requested and picked up some of these boards and located an area in HH 1307 to store them after giving them a quick inventory check. After delegating tasks to the other members, I ended up with the task to figure out how to connect to the Bitcoin blockchain with the Raspberry Pi, to create skeletal modules to perform the communication, and to figure out how synthesis would operate. The  bulk  of my time was focused on figuring out the connection, so only barebone modules were created, but equipped with the knowledge of these connections, I hope to catch up in the next week and create a functional module to communicate with the blockchain via our Raspberry Pi and to outline how synthesis will work so my teammates and I can refer to it as we all collectively forge ahead.

Posted on

Lulu’s Status Report for 2-12

For this week, I started working on the web app. I created a base design for the website that will apply to the whole web app. I have the login and registration page working. I setup the home page but it’s still bare since I’m still  unsure what I want to put there yet.

In addition to setting up the website, I did a little bit of research on how to transfer data between raspberry pi and Django website. Apparently there’s a package named channels that can be used to achieve what we want.

Overall my progress is on schedule. For next week, I will be working on forms that will be used to customize the settings for the miners. If the raspberry pi is here, I would also like to work on integrating it with the web app.

Posted on

William’s Status Report for 2-12

This week, I worked on the communication modules that I was assigned on our Gantt chart. Specifically, this included the FPGA module for sending and receiving bytes and the Raspberry Pi software for sending and receiving bytes. In order to do this, I researched online to find existing RPI libraries that provide the user with GPIO control. Similarly, I researched ways to access the GPIO pins on the DE0-CV FPGA board. I created module headers for the FPGA top module and pseudocode for the communication module. On the RPI, I was undecided whether to use a C library or Python library so I created both files for now. Python had more developed libraries so I ended up adding pseudocode for that file instead.

https://github.com/williamzhao636/CryptoHash

I am behind progress on my schedule because the modules and code are still not fully designed. Without the physical boards with me, it was difficult to refer to the pin numbers and their locations on the board. Next week, I will need to have more progress on the code for sending and receiving bytes for both the RPI and the FPGA.

I hope to have the communication modules more fully fleshed out and a diagram showing the wires and pins between the two boards. This diagram will better outline how the communication will work and will help me with imagining which GPIO pins to use to connect multiple FPGA boards to one RPI.

Posted on

Team Status Report for 2-12

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: