Author: gfieni

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.