In this series:

Post-installation validation

We covered the installation process for the Advanced Development Platform (ADP) in the last blog post of this series. In this post, we continue to explore Nutaq's hardware and software by looking at a demo application and the Nutaq Model-Based Design Kit (MBDK). We then validate the software installation by running the demo.

The demo requires a Perseus advanced mezzanine card (AMC), an ADAC250 FGPA mezzanine card (FMC), a laptop computer running Matlab and Simulink, a signal generator, an oscilloscope, and the required interconnect cables. The ADP demo can be used to test the hardware or as a template when starting a new application.

The reference design for our system (Perseus with ADAC250 FMC), by default, provides four different functional options:

  •  Pass-through mode
  •  Record mode
  •  Playback mode
  •  Direct digital synthesizer (DDS) sine wave generation mode

The different modes can be selected from a terminal window opened when the user runs the compiled executable file. The FPGA logic is generated and uploaded to the system prior to running the demo executable. Details about the Simulink model representing the logic are given in the next section.

Here's what the system does when the user selects one of the above options (see Figure 7 for a diagram of the model):

Pass-Through Mode

In pass-through mode, when a generated signal is sent to the analog-to-digital converter (ADC), it passes through the FPGA without undergoing any processing and without being saved in memory. The signal is sent directly to an oscilloscope. Figure 1: Pass-through mode

Figure 1: Pass-through mode

Record mode

In the record mode, the signal is recorded to RAM on the Perseus board. It is then sent from the memory to the host computer. To do this, a channel must be instantiated in order to enable the data to be transferred over Ethernet. The core responsible for handling FPGA to host PC data transfers via Ethernet is called RTDEx (real-time data exchange). The RTDEx logic can be programmed on the FPGA by compiling and uploading a bitstream using the Simulink-based tools provided with the MBDK package.  

Figure 2: Record mode

Figure 2: Record mode

Playback mode

In the playback mode, the data is sent through an RTDEx Ethernet channel from the host PC to the FPGA. The FPGA-side RTDEx module then recuperates the data and sends it to the digital to analog converter (DAC). The data can then be played onto the oscilloscope.

Figure 3: Playback mode

Figure 3: Playback mode

DDS sine wave generation mode

In the last mode, a DDS is used to generate a sine wave that is sent directly to the oscilloscope. The system in this mode can be viewed as a signal generator. The parameters of the DDS can be set by using a custom register. Custom registers will be described in the next section.

Figure 4: DDS mode

Figure 4: DDS mode

Running the demo

We successfully ran the demo by following the procedure described in the ADP documentation. We selected record mode and set the clock to 30 MHz. We can observe in Figure 5 that the signal was sampled correctly. The fundamental frequency is the sampled clock signal.

Figure 5: The sampled signal (left) and the frequency spectrum of the sampled signal (right)

Figure 5: The sampled signal (left) and the frequency spectrum of the sampled signal (right)

First steps with the MBDK

The MBDK is a package of Simulink tools for creating an FPGA program without hand-coding it in a hardware description language (HDL). When the model is ready, a bitstream file can be generated directly from Simulink and is uploaded to the FPGA using a JTAG pod and a program such as Xilinx iMPACT. The program does not have to be loaded in the FPGA each time the system starts, as it can be saved to the Perseus' flash memory and be loaded automatically at the boot time. Additionally, you can use a command line interface (CLI) tool to upload a bitstream into the flash memory by providing its path on the host PC. The procedure is very straightforward. The normal workflow when using MBDK is the following:

  • Conception of a model to be implemented in the FPGA 
  • Simulation of the model using only the PC 
  • Modifications to the model if needed, along with additional simulations 
  • Generation of the bitstream and upload to the FPGA 
  • Testing and validation of the complete system

Figure 6: The MBDK/BSDK flow

Figure 6 : The MBDK/BSDK flow

Nutaq's MBDK complements Xilinx System Generator by providing System Generator blocks that interface with Nutaq hardware. Blocks are available for all Nutaq FMCs and for communication between the host PC and FPGA-based systems.

When using the MBDK, the user builds his or her system by using Xilinx System Generator blocks (shown in blue in figure 7) and Nutaq blocks (shown in green in Figure 7). When finished, the user generates a bitstream by clicking the Generate icon. Simple models may run immediately after these steps are completed. More complex models may require a C program to execute the operation from the host PC connected to the FPGA-based system via the Nutaq External API (EAPI).

Figure 7 : MBDK model used to generate the record/playback demo

Figure 7 : MBDK model used to generate the record/playback demo

Values can be read from or written to the custom registers (CR). This lets the user interact with the FPGA from the host PC while it is running and set up different parameters. In the example of the record/playback demo (Figure 7), I outlined a custom register usage in red. On the left, the input and reading of the custom register is implemented. On the right, the value entered in the custom register is sent to a multiplexer that enables the selection of one of the described working modes: pass-through, record, playback and DDS. When the user sets the custom register value using either the CLI or an application that uses the Nutaq API, the FPGA logic behaves accordingly. It is possible for the user to create a custom register that controls the functions in his or her design.

Additionally, various functions can be passed to the FPGA via the EAPI library. These functions can be called by the user in C programs and are passed to the Central Command Engine (CCE). The CLI itself is an example of a program that uses the EAPI to communicate with the system via the CCE. The following diagram illustrates how communication through Ethernet is achieved in order to pass commands to the CCE, which then translates it into actions on the FPGA side.

 Figure 8: Communication between the host PC and the FPGA via the CCE

Figure 8: Communication between the host PC and the FPGA via the CCE

The program uses API functions to execute commands on the FPGA side. For example, memory can be read and data can be passed to the system's RAM. API and CCE interaction is also used to initialize the Ethernet or PCIe link.

In this blog, we explained the record/playback demo that we ran on the Perseus-ADAC250 system to validate that everything worked properly. In this series' next blog post, we will begin the design of our system, as described in the first post.