Category: Grace’s Status Reports

Thanksgiving week, Ali and I continued our work on serial communication using UART. We changed our code from using the standard of 1 byte per packet to sending or receiving three packets in a row. Even though we only need to send 16 bits to the FPGA and receive 20 bits, we have to roundup to the next largest byte for padding. Therefore, each time we send or receive, we need three bytes. We were able to make this successfully send and started setting up the code to connect to the DUT that Xiran made.

This past week we continued setting up integration. We also tried a couple of different methods to increase speed and checked to see if using a different laptop would allow us to send at a higher rate. However, unfortunately, we couldn’t seem to go faster. Then we looked into other methods to send our UART protocol and decided to look into using a raspberry pi. We are hoping to setup using the pi this upcoming week.

I also plan to spend time this week working on our final report and video. Additionally, I want to plan out exactly what we show in our demo and poster.

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.

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.

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.

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.

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

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.

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.

This week Ali and I focused on researching and testing different communication methods on the FPGA. We are already familiar with JTAG protocol methods, so we decided to focus on USB and Ethernet. I found that there are a bunch of demos already made specifically for the DE2-115 FPGA board that we will be using that implement different features of the board. One such test utilizes USB while another uses Ethernet. We were not able to actually run these demos together this week since we were waiting for the right cables to be ordered by the department. The demos are in chapter 6 in the manual (https://www.intel.com/content/dam/www/programmable/us/en/portal/dsn/42/doc-us-dsnbk-42-1404062209-de2-115-user-manual.pdf).

We also investigated how to use the triple speed Ethernet on the DE2-115 boards. I found that we will need to instantiate the NIOS II (a softcore microprocessor) on the board (using LUTs), which will connect to the 88E1111 Marvell PHY Chip on the board. I started looking through the documentation and short usage video chips on the NIOS II processor using their developer support tools (https://www.intel.com/content/www/us/en/programmable/documentation/lro1419794938488.html#mwh1416946569962). Unless we are willing to buy the license for the others, we will need to use the lowest performance NIOS II processor (version NIOS II/e).

I also worked a lot on the design slides for the next week’s presentations and did some practice runs as I will be the presenter for our group.

Additionally, our entire group worked together to determine which speeds we will need to meet for our project to meet its performance requirements. We ran some simulation tests and determined that we will need to use gigabit ethernet to achieve the necessary speeds.

Next week, Ali and I plan to run some of the demos and look through the code in the demos to see how they configure the NIOS II processor.

This week I focused on researching different communication protocols to be used for communicating between the PC and the FPGA board. I mainly researched Ethernet methods, but also looked at some USB ideas from my teammates. By comparing other thesis or final design projects from other universities, I found that there are methods for performing the tasks we need, but while Ethernet is very fast for performance metrics (can support 10Mbps, 100Mbps, and 1000Mbps), it is very difficult to implement in the DE2-115 Altera boards we are using (https://etd.ohiolink.edu/apexprod/rws_etd/send_file/send?accession=dayton1448287709&disposition=inline).
I discovered that one of the more challenging aspects of creating these protocols on this board is correctly using the NIOS II soft microprocessor. Both Xiran and I have embedded experience, so I am hopeful that by digging through the handbook for the NIOS II we will be able to effectively use it (https://www.intel.com/content/www/us/en/programmable/documentation/lro1419794938488.html#mwh1416946569962). We are also planning on reaching out to Bill Nace to see if he has any experience with NIOS II on these specific boards.
This upcoming week we want to test different protocols (if possible) using basic “ping” style tests. I found that the DE2-115 boards have demos in their manual kits that use both USB and Ethernet protocols. We are hoping to try to use those this week to learn how the built in tools work. I am currently on schedule for my deliverables. We are planning on meeting this week as a team to decide which method to use in our project.