This is machine translation

Translated by Microsoft
Mouseover text to see original. Click the button below to return to the English version of the page.

Note: This page has been translated by MathWorks. Click here to see
To view all translated materials including this page, select Country from the country navigator on the bottom of this page.

Hardware-Software Co-Design Workflow

This guide helps you to deploy partitioned hardware-software (HW/SW) co-design implementations of SDR algorithms for USRP®[1] embedded series radio hardware.

You can use Simulink® to design, simulate, and verify your application, and to perform what-if scenarios to optimize performance. Then you can decide which system elements to implement on the programmable logic, and which system elements run on the ARM® processor.

Using this workflow, you can automatically generate HDL code for the programmable logic using HDL Coder™, and generate C code for the ARM processor using Embedded Coder®. Finally, you can implement the design on the radio hardware.

This workflow uses the Target a QPSK Transmitter and Receiver to a USRP® E310 using HW/SW Co-Design Workflow example as a reference design.

Step 1. Verify Radio Hardware Connection

  1. Follow the instructions in Installation for Hardware-Software Co-Design. Make sure that all support packages and third-party tools required by the HW/SW co-design workflow are installed and configured.

  2. Create a radio object by using the sdrdev function.

    radio = sdrdev('E310');
  3. Before you can use the HW/SW co-design workflow, the host computer must be communicating with the radio hardware. Verify host-radio communication by calling the testConnection function on the radio object. This function queries the device and returns either success or failure.

    testConnection(radio);

Step 2. Set Up Third-Party Tools

Set up your system environment to access Xilinx® Vivado® from MATLAB®. The hdlsetuptoolpath function adds the required folders to the MATLAB search path, using the Xilinx installation folder that you specify.

For example:

  • In Windows®:

    hdlsetuptoolpath('ToolName','Xilinx Vivado','ToolPath', ...
                    'C:\Xilinx\Vivado\2018.2\bin\vivado.bat')

  • In Linux®:

    hdlsetuptoolpath('ToolName','Xilinx Vivado','ToolPath', ...
                     '/opt/Xilinx/Vivado/2018.2/bin')

Step 3. Create Algorithm and Partition the Design

When partitioning an SDR algorithm, use the ARM processor for slower-rate control functionality, and use the FPGA fabric for high-rate signal processing. Group the blocks you want to implement on programmable logic into an atomic subsystem. This subsystem is the boundary of your hardware-software partition. The blocks inside this subsystem are implemented on programmable logic, and the blocks outside this subsystem are used to verify its operation. The blocks around the subsystem can contain the algorithm that you eventually implement on the ARM processor.

For example, in Target a QPSK Transmitter and Receiver to a USRP® E310 using HW/SW Co-Design Workflow, the QPSK transmit-and-receive physical layer front ends are implemented on the programmable logic. These layers include high-rate operations such as gain control, filtering, and frequency compensation. The data encoding and decoding are lower rate and are implemented on the ARM processor, which outputs the decoded message to a console window.

The workflow has specific requirements for the boundary between the hardware and software. The following diagram shows the data and valid user logic inputs and outputs for a single-channel transmit-and-receive reference design. Multiple-channel reference designs contain multiple sets of I and Q data lines. Transmit-only or receive-only reference designs contain only transmit or receive signals.

Guidelines

  • Each data input or output must be 16 bits. Complex inputs and outputs are not supported at the ports of the HDL subsystem. Therefore, real and imaginary signals must be modeled at the subsystem boundaries.

  • The diagram shows only single-channel inputs and outputs. You can also choose multiple channels. In USRP® E310, you can use up to two channels. Each channel consists of a real and an imaginary part.

  • Model all the ports for a given reference design, even when the ports are not used.

  • The data inputs and outputs to the subsystem are modeled using separate data and valid signals. In Simulink, the data and valid lines must be driven at the same sample rate. Therefore, the input and output clock rates of the subsystem must be equal.

  • Clock the data and valid signals at the fastest rate of the HDL subsystem. When the Tx-baseband-valid signal is de-asserted, the last sample value is held.

  • AXI4-Lite register ports can be clocked at arbitrary rates.

Step 4. Generate HDL IP Core Using HDL Workflow Advisor

HDL IP core generation enables you to generate a shareable and reusable IP core module from a Simulink model automatically. The generated IP core connects to an embedded processor, such as the ARM processor on the radio hardware. HDL Coder generates HDL code from the Simulink blocks. It also generates HDL code for the AXI interface logic connecting the IP core to the embedded processor. By using an SDR reference design, you can create an IP core that integrates into the radio hardware. Using this core, you can configure the RF card and send and receive data.

After you are satisfied with the simulation behavior of the hardware subsystem, generate the HDL IP core and integrate it with the SDR reference design.

A. Start HDL Workflow Advisor

Right-click the subsystem and select HDL Code > HDL Workflow Advisor.

B. Select Workflow and Synthesis Tool

At Workflow Advisor Step 1.1, select IP Core Generation for the Target workflow. Then select E310 for the Target platform.

Finally, select Xilinx Vivado as the Synthesis tool.

Click Run This Task.

C. Select and Configure Reference Design

  1. At Workflow Advisor Step 1.2, select the reference design for your system:

    • Receive path

    • Transmit path

    • Receive and transmit path

    Verify that the Channel mapping and DUT Synthesis Frequency (MHz) meet the requirements for your design. You can check the sample times for your model by selecting Display > Sample Time > Sample Time Legend. Your DUT synthesis frequency must be equal or greater than the highest sampling frequency within the HDL subsystem.

    Click Run This Task.

  2. At Workflow Advisor Step 1.3, set the target interface and verify that Processor/FPGA synchronization is set to Free running. Then map your user logic to the reference design. When mapping the RF channels, each I and Q component refers to a 16-bit port on the user logic. The number defines the channel designation. For example, Rx data I1 In [0:15] maps to the real part of the receiver for channel 1 on the RF card. The following diagram shows the target platform interfaces for the QPSK transmit-and-receive reference design with two AXI4-Lite registers.

    Click Run This Task. Check for warnings in the log text area at the bottom of the Workflow Advisor and make the required changes before proceeding.

D. Run Design Checks

Workflow Advisor Step 2 prepares the design for generation by performing design checks. Click Run This Task.

E. Generate HDL IP Core

Workflow Advisor Step 3 performs the HDL code generation for the IP core. Click Run This Task.

Step 5. Integrate IP Core into Xilinx Vivado Project

Workflow Advisor Step 4.1 integrates the IP core into the SDR reference design and generates a Vivado project. Click Run This Task.

Step 6. Generate Software Interface Model and Library

Workflow Advisor Step 4.2 generates a Zynq® software interface model and a software interface library. The library contains the blocks that you use to generate your own software interface model. The software interface model outlines how to create a user application model and guides you in specifying the sampling rates for the receiver. Click Run This Task.

Software Interface Library

The library contains the AXI Interface block generated from the subsystem in the QPSK example. The block exposes only the AXI-lite control ports and not the data ports. The data ports are present on the Receiver and Transmitter blocks. These blocks represent the data interface between the fabric HDL user logic and the ARM. They contain the means to configure the RF chip. If you use the library blocks in your downstream models, updates that you make to your HDL subsystem propagate to this library automatically. Then, when you run through the workflow, the updates propagate to your software generation models. When using the library blocks, make sure that you configure the parameters as required by your application.

Generated Transmitter.  The generated transmitter block contains radio transmitter properties and a timeout value for frame transfer completion. The default timeout is 1 seconds.

In addition to the common radio properties and timeout, the generated transmitter block contains an option to buffer data for continuous transmission. Selecting this option causes the model to buffer two full frames of data before transmission starts, enabling more robust performance of continuously streaming data .

Generated Receiver.  The generated receiver block contains radio receiver properties and a timeout value for frame transfer completion. The default timeout is 1 s.

Software Interface Model

You can use the generated software interface model as a starting point for full software targeting to the Zynq, including external mode simulation, processor-in-the-loop, and full deployment. This model is overwritten each time you run Step 4.2. Save this model under a unique name and develop your software algorithm in your saved model.

The model shows the generated software interface model from the QPSK example.

Step 7. Generate FPGA Bitstream and Program Zynq Hardware

  1. Generate the bitstream

    Workflow Advisor Step 4.3 generates a bitstream for the FPGA fabric.

    To keep using MATLAB while the FPGA image builds, select Run build process externally to generate the bitstream in an external shell. The step completes in several minutes, after basic project checks have been performed and the step is marked with a green check mark. Before continuing, verify in the Command Window that the Vivado bitstream built without printing an error.

  2. Program the Zynq hardware.

    Workflow Advisor Step 4.4 downloads the bitstream onto the device.

    Before continuing with this step, call the zynq function with the following syntax to make sure that MATLAB is set up with the correct physical IP address of the radio hardware.

    devzynq = zynq('linux','192.168.3.2','root','root','/tmp');
    
    By default, the physical IP address of the radio hardware is 192.168.3.2. If you alter the radio hardware IP address during the hardware setup process, you must supply that address instead.

    In Workflow Advisor Step 4.4, you have three options to download the bitstream.

    • With Download, the bitstream is persistent across power cycles (recommended).

    • With JTAG, the bitstream is not persistent across power cycles

    Alternatively, if you want to load the bitstream outside Workflow Advisor, call the downloadImage function.

    radio = sdrdev('E310');
    downloadImage(radio,'FPGAImage',...
       'hdl_prj\vivado_ip_prj\vivado_prj.runs\impl_1\system_wrapper.bit')

    This function call renames the generated system_wrapper.bit file to system.bit and downloads the file over an Ethernet connection to the radio hardware. This bitstream is persistent across power cycles.

Step 8. Configure Software Interface Model

To configure the software interface model, set up parameters according to the application you are modeling.

The following procedure shows how to configure one specific application. If your application requires different settings, see Guidelines for Configuring the Software Interface Model.

  1. Configure the QPSK transmit-and-receive model to run with a Base rate trigger setting of Transmitter interrupt.

    Set the Hardware board parameter to Xilinx Zynq Based Radio Board Target

  2. In the Transmitter block, select Buffer data for continuous transmission. This setting causes the model to buffer two frames of data before starting transmission. Because the model runs from a transmitter interrupt, the timeout value does nothing.

  3. Configure the width of the input vector (the transmit frame size) to a value that meets your application requirements.

  4. Because the model runs from the transmitter interrupt, terminate the transmit overflow port.

  5. Connect the underflow port to a Stop Simulation block. An underflow implies an interruption in the data being sent, which is an error in a continuously streaming example.

  6. To cause the model to ignore the first two frames, add a Step source and a logical AND block.

    Set the Step block sample time to a value that matches the frame period. Set the Step block output to a value that starts at 0 and changes to 1 at N times the frame period.

    You ignore the first two frames because the transmitter does not start until the model has buffered the first two frames. As a result, these frames underflow.

  7. In the Receiver block, set the Samples per frame parameter to a value that meets your application requirements, for example DataFrameLength/2. Then set the Receive timeout (s) parameter to a value that is small relative to the frame rate, for example 200e-6.

  8. To qualify valid data that enters the receiver model, connect the data valid port to an enabled subsystem.

  9. Connect the overflow port of the Receiver block to a Stop Simulation block. Overflow implies an interruption in the data being sent, which is an error in a continuously streaming example.

Step 9. Run on ARM Processor Using External Mode

You can use external mode in Simulink to monitor and tune the algorithm you develop when it runs on the hardware. First your algorithm is deployed to the ARM processor in the Zynq board. Then it is linked with the Simulink model on the host computer through the Ethernet connection. The main role of the Simulink model is to tune and monitor the algorithm running on the hardware. Because the ARM processor is connected to the HDL IP core through the AXI interface, you can use external mode to tune and monitor the hardware.

To run the algorithm in external mode:

  1. Right click the generated model, and select Model Configuration Parameters.

  2. On the Commonly Used Parameters pane, select Solver, set Stop Time to inf, and click OK.

  3. From the model menu, select Simulation > Mode > External.

  4. Before running the model, call the zynq function with the following syntax to make sure that MATLAB is set up with the correct physical IP address of the radio hardware.

    devzynq = zynq('linux','192.168.3.2','root','root','/tmp');
    
    By default, the physical IP address of the radio hardware is 192.168.3.2. If you alter the radio hardware IP address during the hardware setup process, you must supply that address instead.

  5. On the model toolstrip, click Run. Embedded Coder builds the model, downloads the ARM executable to the Zynq hardware, executes it, and connects the model to the executable running on the Zynq hardware.

    Note

    When you run the model in single-channel mode, the number of samples must be even.

  6. Change tunable parameters on the model. Confirm that the resulting behavior meets your requirements.

  7. Click Stop on the model. The system command window closes.

Step 10. Deploy Executable to Hardware

You can fully deploy the design to run on the board, even after you disconnect it from Simulink. In the Simulink toolbar, make sure that the model is in normal execution mode and click Deploy to hardware. In this mode, while the model is running, you cannot interact with Simulink to tune parameters and display data.

See Also

Functions

Related Examples

More About


[1] USRP, USRP2, UHD, and Ettus Research are trademarks of National Instruments Corp.