Category: Team Status Reports

The biggest concern is still regarding communication, but we are now a bit more concerned about the timing. The fastest baud rate Ali and Grace’s computer can handle is 512,000 bits/second which doesn’t scale for larger instruction quantities. Additionally, the library they are using is relatively slow to read data from the serial cable. They are thinking of switching to using a raspberry pi to handle sending data to the FPGA because it should be able to send data at a faster rate, and it might be easier to use a linux operating system rather than a windows operating system for communication. Ali picked up the Pi on Friday, and has an SD card coming today. She and Grace will be playing around with it later this week to see if they can increase speeds.

Arguably, we’re very happy that UART is basically working — especially compared to all of the issues with Ethernet.

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.

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.

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.

This week we made significant improvement in our communication protocol. Ali was able to finally load the NIOS II processor on the FPGA board successfully and do an Ethernet echo. We also learned that we can use the NIOS II/f (fast) instead of the NIOS II/e (economy) due to the fact that our DUT takes up less than 1% of the LUTs on the FPGA and the /f takes up only 8% of the LUTs on the board. This is promising because it would allow for much larger designs than our own to be tested on the board with the same processor.

Right now, we are still figuring out how to interface with the memory (SRAM) on the board. We need to be able to read/write from 1) the NIOS II to SRAM, and 2) the SV DUT to SRAM. We have been doing research into how to accomplish these tasks and want to implement a simple memory echo program using a SV design in the next week.

[For last week’s report, see the post for 10/16.]

Throughout this past week, we started to consider using some of our risk mitigation protocols given that sadly, our communication is still not working. Ali has been working very tirelessly for the past few weeks to get the NOIS II processor to synthesize on the board, but to simply place it on the board has proven to be challenging due to issues with the provided files. We are still looking into seeing if this is feasible, but we also want to be prepared if it isn’t.

Therefore, we are considering 1) using JTAG for communication and 2) placing all of the input/output files in memory on the board. In the Design Review Report, we outlined both of these approaches as backups in case we cannot get Ethernet to work.

We have not fully decided to abandon Ethernet. Based on progress this weekend, the team will meet Sunday night to discuss next steps. We expect debating what decision to make to be the focus of our Monday meeting with Tamal and Joel as well.

This week we got a little behind schedule due to the Design Review Report. We spent much more time than expected on the Report, leaving some of our other tasks unfinished.

The biggest risk we currently have to our project is the communication protocol. Ali and Grace are trying to implement Ethernet by first getting one of the NOIS II demos working. However, this has proven to be a large hassle given the different amounts of Quartus errors and version issues. We are hoping to get the demo to run this week and then edit the existing code for the demo to do a simple echo test. Editing the code should not be too much of an issue, but we are unsure how many other unexpected errors will we get in actually running it.

In the case that this protocol is unable to be created, we are planning on resorting to USB or JTAG since their interfaces are much easier to deal with. We also, as mentioned in our design report, have been looking into placing all of our inputs and outputs directly into memory bypassing the need for a communication protocol. However, this will require much changes to our system, so we are not looking at that as our first backup.

We’ve also moved back the development of the DUT to focus on the report.

There were no design changes or new risks to our project. However, we would like to note some schedule changes. (The updated schedule is provided below).

This week, Grace and Ali fell a little behind schedule due to waiting for the Ethernet dongle to arrive and lack of time to sync up after Wednesday. In the meantime, they focused on finding more resources and examples of people using the Nios II processor. Due to this setback, we are extending the tasks related to the communication protocol by a week. Next week, the goal for Grace and Ali is to complete a fairly simple test to verify 1) the Nios II processor is functional and 2) we can make use of it to send data back and forth.

Xiran’s work is on-time, with no adjustments to her schedule. To keep the ball rolling on the project, she will begin working on the DUT by herself next week. We may adjust the schedule for the DUT because it was originally planned to be a group effort.

 

The most significant risk that could jeopardize the success of the project is still in the communication protocol. Last Sunday, we made the decision to use Ethernet for communication. This week, while waiting for the Ethernet cable to arrive, Grace and Ali prepped by spending considerable time researching the protocol, including how the 88E1111 Marvell PHY Chip is connected to the board and its Ethernet ports. Next week, Grace and Ali will implement the protocol. We also plan to try out USB demos in the case of running into unresolvable issues with Ethernet.

The risk of the design not fitting on the board is also being managed. The finalized DUT ISA is intentionally small to mitigate this risk. In addition, we are looking into how much space the NIOS II processor takes up on the FPGA, so we can get a concrete number of how much is left for the DUT.

As for changes to our project, we worked on strengthening our project motivation and the requirements based on Proposal Presentation feedback. Instead of motivating solely with runtime gains, we will also highlight, in the future, how the FPGA approach allows the design to be tested in actual silicon instead of only in software. We also added a requirement of being able to support test cases of size 1 ~ 20k instructions, as a quantitative measure of what we can support was missing in the Proposal.

We do note that some of Grace’s and Ali’s work with Ethernet have been delayed due to waiting for equipment, but work will pick up next week. We may update the schedule next week depending on progress, but at the present, there are no changes.

The biggest risk for our project remains to be the communication latency between the FPGA and the computer. This week, each of us researched one of three communication protocols under consideration (JTAG, USB, Ethernet). Tomorrow, we will meet to discuss choosing a protocol. Work on implementing the protocol will begin next week.

Another point of concern brought up during our Proposal Presentation is whether the size of our DUT will fit onto the FPGA. Work on designing the DUT ISA will also begin next week, and taking into account this feedback, we are considering limiting the design to an ALU. This will allow us to mitigate this risk.

There have been no changes to the requirements or the schedule.