Posted on

Xiran’s Status Report for 10/30

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.

Posted on

Ali’s Status Report for 10/30

This was probably the most exciting week so far. I was able to get a demo working where a random string was sent to the FPGA via ethernet and then sent back to the FPGA. (I already shared a video of this working on Slack.) I spent most of the first two days getting it to work. The next task I worked on had 2 parts: 1) better understanding what the demo I synthesized actually did (I found the demo online), and 2) determining how we can output the data from the pre-built system.

Regarding the first task, I understand why almost all of the components are in the nios system. I’m still not fully sure the role the JTAG UART module plays, but I do mostly understand the c code, too. The demo I’m referencing is still this one.

The main issue with the ethernet demo is that it handles all of the ethernet payload generation from the c code, and it does not have external code interacting with the payload. So, my question was: is it possible to interface with the nios processor with external design, and how? If it’s not, then what? We previously found a Cornell Ethernet project which used EthMAC to interface with the ethernet port instead of using the Triple Speed Ethernet Core from Altera. They did this because the EthMAC core is open source, so it was easier to understand what it did unlike the heavily guarded Altera cores. While I was reading through their documentation, I noticed that they also used a Nios processor, and used an Avalon to External Bridge to send/receive data externally from/to the processor. (Avalon is the connection fabric which connects all of the different parts of the nios system together). I then found documentation on this bridge which pointed me to the following files: SOPC User Guide and Avalon Interface Specifications. I also found that you can import custom modules into the nios system. I’m not fully sure how this works, but it was just something that showed up.

My goals for this week is to bring Grace back into this conversation, and to 1) finish reading through these user guides to have a better idea of how we can export information, or import our design. I’m expecting to need to make a separate module which can communicate through the Avalon Bridge, and then send data to our DUT. Also 2) I am hoping to now connect our design to Ethernet. I think this might be a little ambitious, but I would really like to get this working.

I think it’s been difficult that Ethernet was stretched out by a lot, but because Xiran is doing a great job at picking up some of the tasks that Grace and I would’ve worked on, it is going okay.

Posted on

Team Status Report for 10/30

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.

Posted on

Grace’s Status Report for 10/30

This past week had substantial results for us as a group. In the beginning of the week, we were still hesitant that Ethernet could be configured correctly with the NIOS II processor. I started off the week investigating some of our risk mitigation strategies (as listed in the design report) incase we needed to shift toward a different communication protocol. However, by the middle of the week, Ali was able to load the NIOS II processor correctly. This shifted our focus to investigating the memory interface that the NIOS II works with. I began with reading through the DE2-115 FPGA manual and found that the board supports 2MB of SRAM, 128MB of SDRAM, and 8MB of Flash memory. Based off of the interfaces of each of these memory modules and descriptions of using each memory, SRAM was determined to be the easiest memory to use. Only 2 bytes of information can be read or written at the same time to SRAM and only a single type of transaction (read/write) can be done at a time. However, the memory does support a clock of up to 125 MHz, which means that we could read and write within one cycle on the FPGA by reading on the rising clock edge and writing on the falling clock edge of the FPGA’s 50 MHz clock. However, this method will have to be investigated more thoroughly.

I then continued to research more methods for reading and writing to SRAM within the SV program, which seems more difficult. I am still trying to find the correct way to interface with memory correctly in the program. I found this interesting tutorial, but it is interfacing with SDRAM. I was also reading through this message board to determine how the NIOS II can set memory in SRAM.

This upcoming week, Ali and I will need to investigate more about how to interact with the SRAM chip on the board and hopefully can interact with the memory through a SV program.

Posted on

Ali’s Status Report for 10/23

First I want to address the request for the protocol between the FPGA and the PC. This has not been determined yet because we are still trying to make sure we can actually send data between the devices. I would like to work on this once we a) decide to keep using Ethernet (see team report) and b) can get a simple demo working.

For 10/10-10/16, I spent most of my time working on 2 things. First, I worked on the design report, edited it, and made sure that the sections I was responsible where cohesive. The second major task I worked on toward the end of the week was trying to make a demo work. I found a demo online which walks the user through creating the soft processor and it included code which could be used to process the data. I had no issues following the steps to create the processor on my version of Quartus (a big bonus! and My quartus lets me use the NiosII/f processor which is also super nice). I got to the point where I was able to install eclipse, so I could use SBT for eclipse (it’s part of Quartus which is used to program/interact with the FPGA). However, I could not build the project because many header files were missing. I ultimately got to the point where I needed the winternl.h file, but it was missing on my computer, so I stopped and decided to pick that up this week.

For 10/17-10/23, I have been busy with my other classes because last week I neglected my other classes for capstone, but I found out that the winternl.h file is part of a few applications, and it seems like none of the programs I tried to install which might have had the header file, didn’t have it. However, I realized that some of the types/structs which were used in the one header file which needed winternl.h actually appeared in another file. So, I’m guessing that because the tutorial I’m following is a bit out dated, that windows 11 no longer uses that header file and the structs are distributed across several other header files. For the rest of this weekend, I will go down this rabbit hole hoping to resolve dependencies. Otherwise, we will need to figure out a solution where we are not relying on SBT to program the FPGA, but we’ll see.

After riskily editing some of the header files, I’m still hopeful that we can use ethernet or some other form of I/O on the FPGA, it’ll just be painful. I spent most of the past 2 weeks googling issues and trying to figure out how to resolve them.

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.