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

Grace’s Status Report for 11/6

This past week Ali and I focused on getting Ethernet up and running. We were able to actually run the ethernet demo for the DE2-115 board, but the demo requires two cables (and we only had one). Therefore, we know how to run things using the NIOS, but we don’t believe that this is exactly what we will need for our project. Instead of sending data through the processor, I think we will need to send data through sockets that are connected on the processor and the PC. Ali has been looking into this method to see how to set it up using the NIOS. We should be able to do it pretty easily if the software tools on the lab machines allow us to run certain tasks.

This week was also spent prepping for the demo. We are hoping to have communication working in order to show it during our demo. Note, this is not the communication for the whole project, but a basic message sent back and forth to showcase functionality.

This upcoming week will be spent focusing on the demo and getting communication to work.

Posted on

Ali’s Status Report for 11/6

On Wednesday, Grace and I tried to adapt the demo to work for our FPGA with 1 ethernet cable. We succeeded, but with a caveat. We realized that the demo sends data down 1 ethernet cable, and then it bounces back on the other ethernet cable (originally, the demo used 2 ethernet cables). Additionally, when we type into the NIOS Console, we are actually sending commands from the processor (which makes sense), so when we were inputting a string to send, it was just us telling the processor what to transmit. This meant that we were not sending the FPGA data as we thought we were doing. I quickly searched how we can send data to the FPGA via ethernet using C, and it looks like we’ll need to use sockets. Sockets enable both devices to communicate with each other via a port. According to the Intel Forums, we should be able to use the Web Server Demo (a demo file from Quartus II) and the Simple Socket Server code (part of Eclipse SBT) to create a socket server. My plan for later tonight/tomorrow is to try to run this on the lab machines (unfortunately, I cannot install Quartus II on my computer, so I’m hoping to play around with it on the lab machines and then recreate it on Quartus Prime Lite which I have).

If this does not work, we will probably switch to JTAG UART using a serial cable. This would also be beneficial because Professor Nace runs a lab in 18-240 where 2 FPGAs communicate with each other via a serial cable. The backup plan is probably to have the processor handle reading and writing to the testcase/results file. We could then find a way to transmit that file to the PC (either using an SD card or maybe sending it back to the computer using JTAG). NOTE: If we decided to use UART, we would probably need yet another adapter to connect USB to Serial communication. (Sadly, JTAG UART is 9600 bits/sec). Also, I think it is still known that Ethernet/communication is behind. I’ll probably post a comment on this post today or tomorrow with the outcome of being in lab.

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.