Author: alhoffma

The most important update from the past 2 weeks is that UART works!! We can successfully send the FPGA 60,000 bytes of data in a row (and it can be sent back correctly!). Grace and I are very close to finishing our end of communication (as in, we need to handle some file I/O to be able to read the test vectors and then write the results from the FPGA to a results file). We’ve planned out this code but haven’t written it yet for 2 main reasons: first, my laptop died when we were writing code and I forgot my charger, second, I’ve been studying for a final on Tuesday. Regardless, we’re very confident that everything will come together pretty easily.

We’ve found out that the maximum baud rate when sending from my computer and Grace’s computer is 512,000 bits/second. This means that for 20,000 instructions, we have roughly 2x speedup, but it’s not very scalable. Additionally, when doing some testing, I found that with the code I’m using to send and receive serial data, it takes a relatively long time to read the data that is sent back to the PC. We have a few ways of addressing this: first, we can try running the sending/receiving portions of the code in different threads. We are also hoping to try using a raspberry pi which can 1) theoretically allow us to send data at a faster rate, and 2) use a different library to send/receive serial data which can reduce some of these latencies.

I think Grace and I made a lot of progress this week. We also worked together on everything so it might sound redundant. Anyways, we modified the receive datapath, so that it works for our use case (removed error handling and enabled the data to be sampled). We also explored how to send data to the FPGA via serial communication, so we installed puTTY (a windows communication handler), and successfully sent data down the serial cable (we knew this because we saw the RX light flash). We also began implementing the transmit portion of serial communication. I’m hoping to work on the transmit datapath tomorrow.

This upcoming week, we will finish transmit, make a demo, and then deal with clock crossing (between the serial module and the DUT). We also need to solidify the script we’re using to send data from the PC to the FPGA. I think we will be able to get serial working, and it’ll be okay.

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!

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.

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.

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.

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.