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: