FPGA prototype boards are an important component of the hardware development process, and the progress of synthesizing a design, uploading it to the prototype, and validating its behavior has definitely become easier over time. Modern development environments from the major FPGA vendors make it easy to upload FPGA bitstreams to the board via a JTAG connection or via a USB JTAG adapter (often directly on the prototype board). Standard prototype boards also provide standard interface connectors that enable interaction with the hardware being validated.
So, what's the problem?
Despite how easy it is to connect to modern FPGA prototype boards, it is necessary to be close to and connected to them. Working on an FPGA prototype from the local coffee shop really just isn't a good option.
FPGAMgr
The goal of the FPGAMgr project (https://github.com/mballance/fpgamgr) is to change this. FPGAMgr enables access to an FPGA prototype board via the network -- be that the local network or the internet.
FPGAMgr was developed using the CycloneV-based SocKit prototype board (https://rocketboards.org/foswiki/Documentation/ArrowSoCKitEvaluationBoard), but I'm not aware of any obstacle to making it work with a different vendor's FPGA or different prototype board. FPGAMgr currently provides two key services for interacting with a FPGA prototype board:
- Programming the FPGA
- Sending data to and receiving data from I/O interfaces on the FPGA.
FPGAMgr Components
There are three components to FPGAMgr: The client, the server, and the board configuration.
The client is an API that provides functions for uploading a bitstream to the FPGA, as well as methods to exchange data with I/O interfaces on the FPGA. The server is device and environment agnostic code that processes messages. The board config consists of device- and environment-aware code that knows how to program the FPGA device and knows which I/O interfaces are available to FPGAMgr and how to interact with those interfaces.
FPGAMgr with SocKit
The CycloneV device was Altera's (now Intel's) first foray into pairing an ARM processor with an FPGA fabric. The Arrow SoCKit board (show below) provides an array of physical I/O interfaces connected to the CycloneV.
Example
I developed a very simple example design to use in testing out FPGAMgr. Much less involved that what I plan to test using FPGAMgr, but hopefully it illustrates the concept. I wanted to show that I could both program the device, and prove that I'd done so, over the network from my laptop. One of the simplest ways to do so is with a UART-based design that echos back the data it receives. The design looks a bit like this:
The UART is a basic UART from the OpenCores site with a Wishbone bus. The Responder is a custom state machine that initializes the UART, waits for a character to be received, then transmits it back. The count register keeps track of the number of characters received.
The test code that runs on the remote machine is shown (minus some argument-parsing code) below.
The code:
- Connects via the network to the FPGAMgr server
- Registers a sideband-channel interface for communicating with the UART
- Programs the FPGA with the simple design
- Sends and receives a series of messages from the UART within the design
Demo
The short video below shows the process of connecting to, programming, and interacting with the prototype board from the host workstation.
- The pane in the upper-left shows the prototype board via a camera pointed at the board.
- The pane in the lower-left is a login session running on the ARM processor on the SoCKit board.
- The right-hand pane shows the testbench C++ program running on my laptop.
The general demo process is as follows:
- I launch the FPGAMgr server specific to the Altera SoCKit in the lower left-hand pane
- I run the testbench program on my laptop that:
- Uploads the design image to the FPGA
- Connects to the UART I/O
- Sends a series of messages to the UART and receives them back
- You'll see the LEDs flashing on the prototype as the testbench program runs. The count displayed by the LEDs increments once for 16 characters received by the UART.
Conclusion
FPGAMgr makes it easy to access a prototype board across the network, enabling programming the FPGA and virtualized access to design I/O interfaces. What's present at the moment is proof of concept support for Altera/Intel devices and simple I/O interfaces.
Do you virtualize access to your FPGA prototype? What are your approaches and key requirements?
