Why Use a Network Interface to your FPGA

Most FPGA board’s come with some sort of interface port that you can use to interact with them. Digilent’s Nexys-Video, Arty and Basys-3 boards each have a UART connection that can be used to interact with the board–as do many of their other boards. As a result, the host side interaction can be done using an old fashioned serial port interface. The iCEstick also has a similar interface.

Xess’s XuLA2 board is a little bit different, in that it has a JTAG port that can be commanded from a small PIC over a USB port. However, if you use the JTAG USER command, this port can be turned into something that looks, feels, and acts like a serial port, with only a touch of libUSB work required. While I don’t have any Terasic boards¹, I’m sure you could use a similar approach to driving JTAG over USB.

Other boards, such as Digilent’s CMod-S6 or the ICO board, have a parallel type of interface. While this interface can be turned into a serial stream, and while I have done this for both interfaces, it takes a bit more work to get going than a plain serial port.

My point is twofold. First, all of these interfaces will require some work with the hardware to figure out how to how to send information to the interface, and how to receive data back from it. Second, reading and writing a character stream is the easiest paradigm to consider when interacting with such a port. In the case of a serial port, this may have the most O/S support, since reading from and writing to “/dev/ttyUSBx” is pretty easy. Other ports that aren’t of the serial port variety can still be made to look, feel, and act like a serial port even though the underlying transport itself is very different.

My recommendation, which we’ll discuss below, is that you interact with any character stream-type of interface over a TCP/IP link.

A Networked Interface

If this is your first FPGA project, you might look at what’s available to you and consider the simplest interface: from your CPU to the device, as in Fig 1.

Fig 1: Serial Port Controller

Your first task will be to figure out how to interact with your board. While proprietary developer software, with all the nice GUI’s that it comes with, may be the first solution you find, such software usually doesn’t have the flexibility you’ll need to to do your project. If your board has a serial port, then you have a generic port you can work with. If not, feel free to make something similar.

If your board does have a serial port, you may be able to interact with it using either a putty or minicom terminal. While this can be pretty fun, if you ever want to do anything requiring serious communication with your device (image processing, camera interaction, etc), then you’ll want a capability that goes beyond what these can provide. Indeed, even if you have another interface for handling image transmission, it will help to be able to get that interface going with a serial port, that you can use as a back up.

In particular, if you want to read scope information from a design, you are going to want to run some software to read this data out. While you might manage to do it by hand using a minicom terminal for a 64-element scope, but you could), doing it for a 2048 element scope (or more) really calls for a software solution. Seriously–let the computer do the hard work for you.

Other things you might wish to do with your board might include starting or stopping your on-board logic, reading state registers from the board, initially loading the memory of your FPGA board, debugging a soft-CPU implemented on your board, or even reading the results of an analog microphone.

All of these means of interacting with your board need some kind of software interface.

While all of this may be sound straight forward so far, the problem you will run into is simulation. Specifically, it’d be nice to be able to write our control programs once and have them work both when we are interacting with the hardware itself, as well as when we are interacting with the simulator.

We’ll create this approach by using TCP/IP, as in Fig 2 below.

Fig 2: A Network Based Controller

Lest you misunderstand the figure, the server need not be a separate computer. It’s just the other end of the TCP/IP interface. I often run both ends of this network link on the same computer. Further, if you bind the IP address to “localhost”, then your computer will not open up any external TCP/IP ports that might be visible to the big internet. On the other hand, I tend to run it wide open, so I can work on my laptop just as easily as on my desktop, and then I port at the firewall.

Somewhere about now I can also hear several students groaning. Debugging an FPGA is hard enough, and now I’m recommending that a network debugging port needs to be added to the FPGA?

Relax–it’s not that bad.

First, the networking debug capability isn’t something you’ll be graded on. Therefore I don’t think your instructor will have a problem if you use someone else’s capabilities, but feel free to check with him/her if you aren’t sure.

Second, the software you’ll need is all available under the GPL already. You don’t need to do much more. If you improve upon it, though, please be kind enough to the other poor souls out there to share your improvements. Further, if you wish to legally give me any of those improvements, I’ll be glad to share them with the rest of the world as well.

In general, three basic components are required in order to connect a serial port to a TCP/IP port, as shown in Fig 3.

Fig 3: Network S/W Components

1. You’ll need a piece of software to forward your physical serial port serial port onto a network port. You can find an example of that here. You’ll like this piece. It lets you watch what’s going over the interface, in case things aren’t working, and so you can debug that interface in the same window its running in.

   If you are using the parallel port of the ICO board, you can find an example of what it would take to make this interface work with wiringPi here.

2. You’ll also need a piece of software to connect your FPGA control software to. You can find that piece here. You might find right now that this is nothing more than a bare interface. Don’t worry, it’s the end we are going to connect our software controller to when we build it.

   If you don’t have this portion of your interface built yet, don’t worry. As long as you have the network forwarding piece. listed above, you can build use telnet. As in, telnet localhost <portnum>. This will replace your need for putty or minicom—although if you stick around, we’ll create a command line approach to interfacing with your board.

3. The third piece of software you will need, assuming you can interact with your device over a serial port, you can find as part of the wbuart32 package here. This piece turns the simulation end of the TCP/IP port into a serial interface that you can process on your simulated board.

   If you have an ICO board with a parallel interface, you can find an equivalent software component here. In this case, while this software provides the same capability, it does it in a different fashion. You can look within it to see some of the details.

We’ll discuss how all of these pieces work later and in detail. For now, just know that the software is available for you to do this should you have a serial port-type of interface to your board.

What does this infrastructure allow you to do? Why is it to your advantage? It allows you to test your control software in such a manner that the control software might never know whether the other end of the link is an FPGA, as in Fig 2. above, or a simulator–as in Fig 4 below.

Fig 4: Network Based Simulation

If you can control your simulator over the network, and not know the difference, then you know your control programs and your simulator work.

That’s where we are headed.

Next Time

We’ll come back to these software pieces later to describe how they work in detail.

For now, we’re going to continue focusing on what it takes to get an initial debugging interface up and running. We can debug more complicated interfaces from there if we need to.

If you’ve never tried using a networking debug interface before, think about it. As we go over the pieces, give them a try. My bet is that once you find your first bug using Verilator and GTKWave that you’ll become a quick believer in this method.

---

Footnotes: