Posted on

Xiran’s Status Report for 10/23

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.

Posted on

Team Status Report for 10/23

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

Posted on

Grace’s Status Report for 10/23

[For two weeks ago, see my post for 10/16.]

This past week, I focused on the Ethics assignment and considering a risk mitigation protocol. The Ethics assignment didn’t take up too much of my time, but I was unable to spend much time on our project due to limitations by other class work. Ali focused on getting the NOIS II processor to work on the board, but given how much difficulty we have faced in performing this task, I started to look into other options to create our project.

We are considering placing all of our inputs/outputs to the DUT directly on the board in memory so that we don’t have to use a communication protocol at all. We think that this will be feasible given the amount of memory on the board, but still need to investigate further before we proceed. Doing this method will also allow us to use the Cyclone V board instead, which is faster.

This next week will be a big decision week for us because we want to be confident in the method we are using by the end of the week. We will be meeting a lot to determine which is the best path forward for our project.

Posted on

Team Status Report for 10/16

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.

Posted on

Grace’s Status Report for 10/16

This week I spent a large amount of my time working on the design report. The first few days of the week I spent writing about half of the report in order for Xiran to be able to edit it later. While I was able to draw from our slides, much of the work for the report was expanding on the details mentioned in the presentation. I also looked through the feedback given to us from both the students and the instructors to ensure that their concerns were addressed in the report. I also made some final revisions on the report before we turned it in.

Ali and I also worked on getting the NOIS II ethernet demo working. We ran into a lot of issues this week in trying to run the demo. Firstly, the different versions of Quartus that we have on the lab computers versus the Quartus Lite that Ali has on her laptop have caused some discrepancies between the program we are trying to setup. I think that we are close to being able to run the demo on the board. However, this has been a much more laborious process than expected and unforeseen setbacks could keep popping up. Our hope is that once we get the demo to run, we can modify the code from the demo to do what we need.

Given this difficulty, we also have been investigating other methods for getting our input and output to and from the board in case we need to abandon the ethernet protocol. We have about 2MB of memory on the DE2-115 FPGA board, which we are looking into using to preload our inputs to the program.

This upcoming week, I will also be working on the Ethics assignment and adding an Ethics section to our design report for the final.

Posted on

Team Status Report for 10/9

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.

Updated schedule

 

Posted on

Grace’s Status Report for 10/9

This week Ali and I again focused on understanding the NOIS II processor on the FPGA boards. Unfortunately, we were halted from initiating some of our work due to delays in having access to equipment we needed in order to run some of the demos. However, once we were able to connect to the board using Ethernet, we worked through some of the demos that come with the DE2-115 FPGA board. We were unable to run the demo we wanted to run because we need an internet gateway, which we do not have and do not want to buy since we won’t need it for our project. However, even without being able to actually run the demo, we were able to see how the NOIS II actually is implemented on the board and how to access its own command line. We also investigated more about how Quartus interfaces with the NOIS II, something that we will need to continue to look into this upcoming week.

I also spent some time at the beginning of the week preparing for the design presentation, since I was our group’s presenter. On Sunday night, I did a few dry runs and really tried to prepare a good narrative for our project. Xiran and Ali were kind enough to watch and give me some very valuable feedback.

I also started working on the design report at the end of the week. I’m planning on spending most of the early part of this week focusing on the design report.

Other than the design report, Ali and I plan on actually running the NOIS II processor on our board this week to create a communication protocol. We will most likely need more time than expected to finish this task.

Posted on

Ali’s Status Report for 10/9

This week Grace and I worked on understanding how to actually work with the Nios II Processor a bit. Because we were waiting to receive the USB-ethernet dongle, so we could more easily work with the ethernet ports, we were set back from originally working together Monday evening. On Wednesday, Grace and I sat down to try to follow the basic ethernet web-server demo that comes with the board. Unfortunately, we were 1) missing a gateway (which we didn’t realize we needed for the demo), and 2) missing a file which we think we needed to run the demo. However, we did play around with the Nios II SOPC builder a bit more this week, so we/I have a better understanding of how the processor actually works and how to build it. I also looked into the Nios II terminal which we can use to send data to the board via the ethernet connection. We have to do a little bit more research to understand if there is a way we can interface with the terminal, but at the very least, we know that we should be able to execute some sort of script that can execute the code within a test. Additionally, I spent a decent portion of time trying to reinstall quartus on my laptop, so that I can play around with ethernet from my computer. (It turns out that since Altera does not sign their drivers, and I have windows 11, it was difficult to figure out how to get around that issue)

I was hoping we would be able to run an actual test this week using the ethernet cable, but we spent a lot of time still digging up papers and resources to better understand how we will interface with it. I found a paper which interfaces ethernet (via the Nios II processor) with other code, so I feel like I have a better understanding of how we can utilize the processor and utilize our DUT at the same time. I think Grace and I are a little more behind than we wanted to be, but we’re aiming to spend a lot of time together Monday evening/maybe Wednesday figuring out a large portion of the ethernet and getting a simple test working. Next week, I’m planning on spending a lot of time making sure we can get ethernet working and helping out with the design report.

Posted on

Xiran’s Status Report for 10/9

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.

 

Posted on

Xiran’s Status Report for 10/2

This week, I transitioned from working on the communication portion of our project to working on the DUT. Namely, I finalized our ISA and designed the datapath for our DUT.

Designing the ISA involved several decisions: deciding 1) the number of bits, 2) the instruction format, and 3) the instructions themselves. For 1), I settled on 16 bits because it allows us to lesson the communication cost of the system, while still keeping the number large enough that it doesn’t become a toy example. For 2), I used the simplest scheme I could think of in the interest of making our instruction decoder simple, as is typical in a RISC architecture. For 3), I examined ISAs I have studied (x86, ARM, RISC-V) and chose 16 arithmetic/logical instructions that are in most ISAs, as these are the crucial ones.

Summary of our ISA

I also designed the datapath for our DUT: a single-cycle microarchitecture implementing this ISA. There aren’t many design decisions involved here. I simply chose the most simple datapath with my computer architecture knowledge.

DUT datapath block diagram

In addition to these individual tasks, I also worked on benchmarking simulation speed and the design review slides.

It should be noted that my action items did change this week from what I had planned. I originally planned to start working on the golden model this week, but given that it would be nice to have a concrete diagram of the DUT for the design review, I prefeteched the task of designing the datapath. However, I am still on track to meeting my deliverables. Next week, I will work on and finish the golden model.