Author: wzhao3

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.