Author: xiranw

Yay! Last status report!

For the past two weeks, I worked on a few different tasks. During the week of Thanksgiving, I finished our input GUI (below is a screenshot). I also worked on the final presentation slides and practiced delivery, given that I was the presenter for our team this time. This past week, I practiced the presentation more and am beginning to work on integration. More specifically, I need to update the output comparator to accept a slightly different file format that Grace and Ali are working on sending from the FPGA.

I am on schedule. I’m at a point where I’m essentially done with all of my individual tasks for the semester. During this final stretch, I’ll work with my teammates on integration, more testing, plus the final deliverables.

To Tamal and Joel, thank you for your help throughout the semester 🙂 See you at our demo!

This past week, I finished implementing our output GUI. Below is a gif demonstrating the interface:

The user can upload the two output files (golden and actual) and see 1) graphed statistics about the test case and 2) which instruction, if any, failed plus the register dump comparison. We present these information in order to help the verification engineer better understand the tests being run and more quickly isolate bugs.

I am on schedule. Next week, I plan to implement the input GUI, which should be simpler since it involves less components, and also work on the final presentation slides. There are improvements I want to make to this output GUI (play around with layout and colors); I will come back to this at the end of the semester.

Happy early Thanksgiving!

This past week, I researched frameworks to use to improve our UI and began working on the output GUI.

For the first half of the week, I planned to make a python GUI that runs on the ece machines, but after I ran into many issues, I decided to make a web app instead. The first issue was that the library choices I have are quite limited (most libraries aren’t installed on these machines, and I don’t have permission to install anything). After I settled on Tkinter and Matplotlib, two libraries that are already installed, I ran into package dependency issues and bugs that have been fixed in newer releases, but not in the old release on those machines.

Getting even a simple plot to show proved to be difficult, so my plan switched to making a web app instead in the second half of the week. However, given that I do not have web app experiences, I want to use a web app builder to simplify the process. I discovered a web app builder called anvil, that allows me to make a UI by dragging and dropping components and code client and server side code in Python. I’ve since been playing around with this framework, and here’s what I’ve been able to get to work so far:

This is showing that the user can upload a test case file and get some graphed statistics about that test case.

I am on schedule. Next week, I will continue building this GUI. The goal is for the user to be able to upload relevant files and see more statistics about the test case as well as a failure analysis (what instruction, if any, failed, plus a table comparing the expected vs actual register dumps).

This past week, I worked on benchmarking our system and implementing the input side of our testing framework. Regarding benchmarking, since the DUT is now complete, I was able to measure how much time simulation takes with our DUT (instead of estimating simulation time like we did before).  Turns out, simulation is much slower than we anticipated: 20,000 instructions can take up to 3 seconds to simulate! This discovery has two important implications. First, it means we have more choices for our communication protocol. Performing the same calculations that we did in our Design Report (but using this new simulation speed) shows we can meet speedup with JTAG. Second, our use case is also strengthened; we now have numerical data proving that simulation really does not scale well as the design size grows.

In addition, I also made a prototype test case generator. It prompts users for customizations on the command line (e.g., test case size, instructions to test for) and generates a randomized test that adheres to their customizations. It’s not a very friendly UI, however, so if we have time, we’ll come back to this and use perhaps a Google Forms interface instead. Both benchmarking and test case generator code can be found in our repo.

I should mention I originally planned to work on the output end of our framework this past week, but I think it makes more sense to start with the input and go down our flow. The other deliverable was to synthesize the DUT, which we did without issues.

I am on schedule. Next week, I will move on to the output end of our framework. The goal is to create a barebones interface first, then improve on it.

Last week, I spent the vast majority of the week working on the Design Review Report. I wrote some sections from scratch in the Report, just like Grace and Ali did, but I was also the final editor for our Report. I went through multiple passes to change wording to make the report sound coherent and rearrange sections for a better flow.

All the time I spent on the Report put me behind schedule, because I was planning to work on the DUT last week. However, I was able to finish the DUT this week (code here). After finishing the DUT, I also took the tasks of creating a simple test case and performing some testing on the DUT, which were originally planned to be Grace’s and Ali’s tasks, but they are very busy with Ethernet work. I did find a bug in my code for the DUT that was actually a little bit subtle. When we later deliberately insert bugs into our DUT, I may insert this bug.

I am still a little bit behind our original schedule, but we will likely revamp this schedule next week if we decide to change our communication protocol (we will need tasks to be shifted around to accommodate the change). For now, I’m just trying to do as much work as possible that can be done in parallel to communication.

Next week, I will synthesize the DUT and start working on an output display to the user. It was mentioned in a previous meeting that having a GUI display for the demo would be nice, so I will start designing that.

This week, I implemented the golden model for our system. The code is in golden_model.c in our Github repo.

This C program reads an input test case file (containing instructions separated by end-of-line character) and computes the expected register values after each instruction. The program does not currently write the register dump to an output file, as we have not decided on the exact format of the output file yet, but I will add that once it’s been decided (this addition should not take long). I have also tested the golden model with different input files to verify its correctness.

My progress is on schedule. Next week, I expect to spend significant effort working on the design report. After that, I will start working on the SystemVerilog implementation of our DUT.