Posted on

Grace’s Status Report for 11/20

This past week Ali and I researched more about serial communication and clock crossing protocols, as well as started implementing our own protocol. We started by using the structure given in the 18-240 serial lab and set up the receiving end of the protocol. Some of the week was spent debugging the receiving end using the sending protocol testbenches in the 240 lab (its in the 240 afs space under lab 5 if you want to see what it does). Once we felt that our receiving protocol was sturdy enough, we moved on to the transmitting protocol, which does the receiving protocol in reverse.

Given that our FPGA clock speed is much faster than the baud rate for serial communication, we decided to set the speed to 1/10th of the FPGA rate. This way, when performing clock crossing, we only have to wait for or hold values for 10 cycles, depending on sending/receiving.

We also spent time this week playing around with PuTTY. Connecting to the board using our laptops is relatively easy and we can send bytes directly by typing them into the terminal. Now, we need to create a program that can read data from a file and send it across using PuTTY.

In this next week, we will finish creating the transmitting SystemVerilog code, look into creating a program to send/receive on PuTTY, and work on the final presentation slides.

Posted on

Team Status Report for 11/20

The most significant risk in our project remains to be the communication protocol. After deciding to switch from using Ethernet to UART, Ali and Grace made good progress on implementing UART this week. The receive direction of the datapath is completed, while the transmit direction is in progress. This upcoming week, Ali and Grace will work on transmit, after which we will have a functional protocol, making our system flow complete.

Meanwhile, Xiran has been working on the GUI. The output GUI is complete, and she will work on the input GUI this coming week.

There have been no changes to our existing design or schedule.

Posted on

Xiran’s Status Report for 11/20

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!

Posted on

Ali’s Status Report for 11/20

I think Grace and I made a lot of progress this week. We also worked together on everything so it might sound redundant. Anyways, we modified the receive datapath, so that it works for our use case (removed error handling and enabled the data to be sampled). We also explored how to send data to the FPGA via serial communication, so we installed puTTY (a windows communication handler), and successfully sent data down the serial cable (we knew this because we saw the RX light flash). We also began implementing the transmit portion of serial communication. I’m hoping to work on the transmit datapath tomorrow.

This upcoming week, we will finish transmit, make a demo, and then deal with clock crossing (between the serial module and the DUT). We also need to solidify the script we’re using to send data from the PC to the FPGA. I think we will be able to get serial working, and it’ll be okay.

Posted on

Xiran’s Status Report for 11/13

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).

Posted on

Team Status Report for 11/13

Right now our biggest risk remains the communication protocol. Given the challenges we have experienced with using Ethernet, we have decided to switch gears from Ethernet to serial communication using UART. This will come with a performance drop, but it gives us much better chances of actually having a working product. This past week, Grace and Ali implemented half of the UART protocol and tested in simulation. They will continue implementing the protocol this upcoming week, with the goal of having a working protocol on the FPGA by Thanksgiving break.

Meanwhile, Xiran has begun working on the output GUI. We also have a new schedule made for the demos this past week, attached below for reference. Until Thanksgiving break, Grace and Ali will work on UART, while Xiran will work on the GUI. We will integrate and work on the report after.

Posted on

Ali’s Status Report for 11/13

This week was a very nice change of pace. The three of us talked on Monday, and we decided that it would be best to switch to serial UART for several reasons. 1) It is a better documented protocol 2) Prof. Nace has a lab where students do some UART communication 3) No Nios!!! 4) There are more examples of projects which use UART 5) We can interface with the serial port without using a socket — and can use something like PuTTY to send data (which should be easy).

I spent a lot of the earlier portion of this week looking through the lab handout that Prof. Nace sent me, and I also looked through different UART protocol documentation. Today, Grace and I implemented the lab that Prof. Nace has, and it worked! We did not synthesize because we aren’t sure if we have the needed to files to synthesize the sender board. We are currently waiting for a serial to USB cable to come in so we can easily send data from the PC. Hopefully, the cable comes this week, and we can interface with it this week. I think this will be a much better alternative than Ethernet. I think this week will be a bit hectic, but I finally have a lot of confidence in communication!

Posted on

Grace’s Status Report for 11/13

This week we decided to turn to serial communication in order to have a working data communication between the FPGA board and the PC. We are not completely abandoning ethernet, but want to have a working version first. In that vein, Ali and I were able to have access to 18-240’s serial communication lab from Bill Nace. This lab has one FPGA send bits serially to another FPGA. We had to wait for a serial cable in order to start implementing this lab (and then our actual protocol), so I spent the middle of the week researching more about serial communication, and in particular, UART. I took 18-349, so I am already pretty familiar with UART and USART. As long as we can ensure our timing is correct in translation between the baud rate on the PC and the clock frequency on the board, we shouldn’t have major issues implementing a basic serial protocol. A good, simple UART reference can be found here – it shows the basics for how UART works and the frames used in the most common protocols.

On Saturday, Ali and I spent the day in the lab implementing the serial lab and then started working on our own serial protocol. We are hoping to finish it up this week so that we can actually communicate with our DUT on the board.

This week, we plan to complete this protocol. The added bonus of UART is that it is well documented and a common protocol which should make it easier for us to implement.

Posted on

Team Status Report for 11/6

Our main risk is Ethernet communication again because we need to have both a laptop and the FPGA connected on the same socket. We’re going to see if Ali/Grace can get the socket code working on the lab machines this weekend. If not, they might switch to serial communication via JTAG UART. (This is currently the best option because we know that we can use the NIOS Processor now). There is also a chance that they can use the SD Card reader to send/receive the test cases/results. Ali asked Prof. Nace if he can share any information he has on the 18-240 lab which uses Serial Communication between FPGAs.

Also for the rest of the system, Xiran has made prototypes for all the components. She will be looking into how to make the components more user friendly in the next few weeks.

Posted on

Xiran’s Status Report for 11/6

This past week, I worked on the output end of our framework. I updated our golden model and DUT so that they now both read from a test case file and write cycle-by-cycle register dumps to output files. The output comparator that compares the two’s output files is also complete. Once again, the code can be found in our repo.

Save for communication between the PC and FPGA, our system flow is now complete! The user can create a test case using the test case generator, get the expected output from the golden model, get the DUT’s actual output from simulation (we can also synthesize the DUT but can’t talk to it yet), and compare outputs using the output comparator. I will be demoing these components.

I am on schedule. Starting next week, I will be exploring ways to make our UI more friendly. Also worthy of mentioning is that before the demo next week, I want to make a graph showing how simulation scales as test case size grows.