Prepare Hardware Model for Deployment

R2026b

To deploy an SDR algorithm on an NI™ USRP™ radio, prepare a Simulink® model that meets the hardware constraints described in this topic. For the full workflow, see Target NI USRP Radios Workflow.

Preparing a model for deployment requires a configured development environment and a connected radio. To prepare your Simulink model:

  1. Determine the capabilities of your radio device, such as the number of channels and the supported baseband sample rates. For details, see Determine Radio Device Capabilities.

  2. Implement your algorithm using blocks that support HDL code generation. For more information, see Basic Guidelines for Modeling HDL Algorithm in Simulink (HDL Coder).

  3. To model the boundary of the user logic, use the guidelines in Configure Hardware Interfaces.

Determine Radio Device Capabilities

Before you start implementing your model, consider the constraints of your hardware. This table details the capabilities of supported NI USRP radios. The radio can transmit and receive at a sample rate equal to the maximum supported master clock rate (MCR) of the radio divided by a supported interpolation or decimation factor.

Radio DeviceSupported MCRsSupported Interpolation or Decimation FactorsNumber of ChannelsSupported Center FrequenciesSupported Channel GainsPL DDR Buffer Size and Connections*

USRP E320 (since R2025a)

  • Using one transmit channel, one receive channel, or both:

    • 40.00 MHz

    • 50.00 MHz

    • 61.44 MHz

  • Using two transmit or receive channels:

    • 20.00 MHz

    • 25.00 MHz

    • 30.72 MHz

  • 1, 2, or 3

  • Even integer in the range 4 to 256

  • Multiple of 4 in the range 256 to 512

  • Multiple of 8 in the range 512 to 1008

2†

70 MHz to 6 GHz

Transmit: 0 dB to 89.8 dB

Receive: 0 dB to 76 dB

2 GB (229 samples)

2 connections

USRP N310

  • 122.88 MHz

  • 125 MHz

  • 153.6 MHz

  • 1, 2, or 3

  • Even integer in the range 4 to 256

  • Multiple of 4 in the range 256 to 512

  • Multiple of 8 in the range 512 to 1016

4

1 MHz to 6 GHz

Note: Only two independent center frequencies can be set, with two channels sharing the same center frequency

Transmit: 0 dB to 65 dB

Receive: 0 dB to 75 dB

2 GB (229 samples)

4 connections

USRP N320

USRP N321

  • 200 MHz

  • 245.76 MHz

  • 250 MHz

  • 1, 2, or 3

  • Even integer in the range 4 to 256

  • Multiple of 4 in the range 256 to 512

  • Multiple of 8 in the range 512 to 1016

21 MHz to 6 GHz0 dB to 60 dB

2 GB (229 samples)

4 connections

USRP X310 + UBX 160

  • 184.32 MHz

  • 200 MHz

  • Integer in the range 1 to 128

  • Even integer in the range 128 to 256

  • Multiple of 4 in the range 256 to 512

  • Multiple of 8 in the range 512 to 1016

210 MHz to 6 GHz0 dB to 31.5 dB

1 GB (228 samples)

2 connections

USRP X310 + OBX 160 (since R2026b)

  • 184.32 MHz

  • 200 MHz

  • Integer in the range 1 to 128

  • Even integer in the range 128 to 256

  • Multiple of 4 in the range 256 to 512

  • Multiple of 8 in the range 512 to 1016

210 MHz to 8.4 GHz0 dB to 31.5 dB

1 GB (228 samples)

2 connections

USRP X310 + TwinRX (since R2026a)

200 MHz

  • Integer in the range 1 to 128

  • Even integer in the range 128 to 256

  • Multiple of 4 in the range 256 to 512

  • Multiple of 8 in the range 512 to 1016

4 (receive only)10 MHz to 6 GHz0 dB to 93 dB

1 GB (228 samples)

2 connections

USRP X410

  • 245.76 MHz

  • 250 MHz

  • 1, 2, or 3

  • Even integer in the range 4 to 256

  • Multiple of 4 in the range 256 to 512

  • Multiple of 8 in the range 512 to 1016

41 MHz to 8 GHz0 dB to 60 dB

4 GB (230 samples)

4 connections

* The PL DDR buffer connections are shared between streaming interfaces mapped to PL DDR Buffer in the Map Target Interfaces step and any CaptureAntennas or TransmitAntennas specified on the usrp System object™.

† Supported TX/RX configurations on a USRP E320 radio are 1-by-0, 0-by-1, 1-by-1, and 2-by-2. To use a 1-by-2 or 2-by-1 TX/RX configuration, implement a dummy transmit or receive channel in your model.

Configure Hardware Interfaces

Your design under test (DUT) communicates with other subsystems on the radio through hardware interfaces. You can include three types of interface in your DUT:

  • Register interfaces — Read and write scalar control values in the DUT from MATLAB®.

  • Radio streaming interfaces — Stream IQ data between the DUT and the radio front end for over-the-air transmission or reception.

  • Host streaming interfaces — Stream data between the DUT and the host computer, either directly or through the PL DDR buffer.

After you configure your interfaces, map them to the reference design in the Map Target Interfaces step. To interact with these interfaces from MATLAB after deployment, see Run and Verify Hardware Implementation.

Register Interface Guidelines

Use register interfaces to access control registers in your DUT.

  • Use scalar ports only.

  • Use any real data type up to 32-bits.

When you deploy your design to your radio, you can read and write registers using the readPort and writePort functions.

Choose Streaming Interface

The streaming interfaces available on NI USRP radios serve different use cases. Use this table to determine which streaming interface to include in your model before you begin implementing your DUT.

Interface PathUse WhenConstraints
DUT to RadioThe DUT generates or processes IQ data for over-the-air transmission.

  • The data type must be a complex signed 16-bit data type. For example, int16.

  • The DUT must respect ready_in backpressure

Radio to DUTThe DUT processes IQ data received from the air in real time.

  • The data type must be a complex signed 16-bit data type. For example, int16.

  • To avoid stream buffer overflow, the DUT must consume data at or above the sample rate

DUT to Host (direct)The DUT sends processed data to the host at a rate the host can sustain.

  • If the DUT sends data faster than the network throughput and readPort call frequency allow, internal buffers can overflow

DUT to Host (PL DDR buffer)The DUT produces data faster than the host can process, or you need to guarantee no samples are dropped.
Host to DUT (direct)The host sends data to the DUT synchronously.

  • If the DUT does not assert ready_out, the writePort function times out

  • If the network throughput and writePort call frequency do not keep up with the DUT consumption rate, underflows occur

Host to DUT (PL DDR buffer)The DUT consumes data from a pre-loaded PL DDR buffer.

  • The number of PL DDR buffer connections depends on the radio device (for details, see Determine Radio Device Capabilities).

  • The writeMode argument of the addRFNoCStreamInterface function controls whether the buffer streams data to the DUT repeatedly or once.

  • The PL DDR buffer can sustain full device rate and respects backpressure from the DUT without causing overflow.

Streaming Interface Guidelines

These requirements apply to all streaming interfaces in your DUT:

  • Use sample-based processing.

  • Use scalar ports at the top-level DUT boundary.

  • Use blocks that support HDL code generation. For supported blocks, see Basic Guidelines for Modeling HDL Algorithm in Simulink (HDL Coder).

  • Model each streaming interface using the AXI-Stream protocol signals described in the per-direction sections below.

The following sections describe the shared AXI-Stream protocol, buffering concepts, and signal-level implementation for each streaming direction.

AXI-Stream Protocol

Include the following signals for each streaming data interface:

  • Ready — A flag that is asserted when data is ready to be received.

  • Data — A 32-bit bus that carries data between subsystems.

  • Valid — A flag that is asserted when the data is valid.

  • Last — A flag that is asserted for the duration of the last sample in a data packet.

Optionally, you can also include these signals:

  • EOB (end of burst) — A flag that is asserted for the duration of the last data packet in a burst of data packets.

  • Timestamp — A 64-bit signal that contains the time of the first data sample in the packet.

  • HasTime — A flag that is asserted when a valid timestamp signal is present.

Backpressure is sink driven. The sink is the downstream block that consumes the data. The sink asserts the Ready signal to indicate it can accept data. Data is transferred only when both the Valid and Ready signals are asserted.

The timing diagram shows an example of these signals with a data packet length of 4 samples and a burst length of 3 packets. Samples transfer only when the receiving block asserts the Ready signal.

For more information, see:

Stream Buffer Size and Frame Size

Two independent settings control data transfer size and buffering at different points in the streaming data path:

  • Stream buffer size — An FPGA-side endpoint buffer, used for flow control. You set this value in the interface mapping table during the Map Target Interfaces step. The default is the maximum possible buffer size, which is 32768 samples. The buffer size must be a power of two for optimal use of the FPGA RAM resources.

  • Frame size — The number of samples per host-side readPort or writePort operation. You set this value in the generated setup script using the FrameSize argument of the addRFNoCStreamInterface function.

The generated setup script sets the frame size to 1e5 samples by default. Set this value based on how much data the host processes per call. For example, if your DUT outputs 2048-sample FFT frames and you want to read 1000 frames per readPort call, set FrameSize to 2048e3. For an example, see Introduction to Streaming Interfaces on NI USRP Radio.

Stream Data Between DUT and Radio

These interfaces carry IQ data between the DUT and the radio front end for over-the-air transmission and reception. Both directions use the AXI-Stream protocol with complex signed 16-bit data.

DUT to Radio

To implement this interface in your Simulink model:

  • Set the output port data type to int16 or any signed 16-bit fixed-point data type. The data must be complex (IQ).

  • Gate valid_out with the ready_in signal. Only assert valid_out and send data when ready_in is high. If the DUT sends data when ready_in is de-asserted, the radio drops the samples.

    • The radio asserts ready_in when it can accept a sample. The radio consumes data at the sample rate. To set this rate, use the Sample Rate parameter in the Configure HDL Code Generation Settings step of the workflow, or the SampleRate property on the usrp System object. For more information, see DUT Clock Frequency and Sample Rate.

    • Send a sample every time ready_in is asserted to avoid underflow at the transmitter. The DUT can produce data at any rate up to the DUT clock frequency.

  • Count output samples and assert last_out on the final sample of each packet to define the packet boundary. The recommended packet size is 256 samples.

  • Group packets into bursts of contiguous IQ data. Assert EOB_out for the duration of the last packet in each burst. When both last_out and EOB_out are high, the radio transmits the final packet and ends the over-the-air transmission. For continuous transmission, do not assert EOB_out.

  • To schedule a transmission, assert HasTime_out and drive timestamp_out with a 64-bit unsigned integer on the first packet of the burst. The timestamp represents the radio time in MCR clock cycles. If you do not explicitly set the radio time using the setTimeNextPPS function, this value is the number of MCR clock cycles since you called setup on the usrp System object. The radio acknowledges a timestamp only on the first packet of a burst. For more information about the call sequence, see Object Functions.

Note

Add a register interface to your DUT that controls an output-enable signal. This register allows the host to disable DUT output before releasing the radio, which prevents a 30-second stream flush timeout. Without this register, the DUT continues asserting valid_out during shutdown and the stream buffer must drain completely before the system can release.

For an example of a transmit streaming pipeline that handles packetization and backpressure buffering, see Tone Transmitter on NI USRP Radio.

Radio to DUT

To implement this interface in your Simulink model:

  • Set the input port data type to int16 or any signed 16-bit fixed-point data type. The radio streams complex IQ data to the DUT.

  • Assert ready_out when the DUT can accept a sample. The radio sends one IQ sample each time ready_out is high.

    • Assert ready_out at a rate at least equal to the baseband sample rate to prevent the stream buffer from overflowing. If the buffer overflows, the radio ends the current stream. To restart, call the usrp System object as a function, for example:

      device(numSamples)

    • The maximum rate at which the DUT can request samples is the DUT clock frequency. For more information, see DUT Clock Frequency and Sample Rate.

  • The radio sends IQ samples in packets sized according to the SamplesPerPacket property on the usrp System object. The recommended packet size is 256 samples. The radio asserts the last_in flag on the final sample of each packet.

  • The radio groups packets into bursts. The burst length equals the number of packets required to deliver the requested data. The radio asserts the EOB_in flag for the duration of the last packet in a burst.

  • The radio drives HasTime_in and timestamp_in on each packet. The timestamp is a 64-bit unsigned integer representing the radio time in MCR clock cycles. If you do not explicitly set the radio time using the setTimeNextPPS function, this value is the number of MCR clock cycles since you called setup on the usrp System object. For more information about the call sequence, see Object Functions.

Note

If your design uses multiple receive antennas, samples from different antennas do not arrive at the DUT simultaneously. Buffer samples from each antenna until valid data arrives on all channels before processing. For an example of how to synchronize data streams from multiple antennas, see Spectrum Visualization on NI USRP Radio.

Stream Data Between DUT and Host

These interfaces transfer data between the DUT and the host running MATLAB. You can connect directly or route through the PL DDR buffer. Direct connections offer lower latency but require the host to keep pace with the DUT. PL DDR buffered connections decouple DUT timing from host processing, which reduces the risk of dropped samples and underflows. If the DUT writes data faster than the host reads it, the PL DDR buffer can overflow.

DUT to Host (Direct)

To implement this interface in your Simulink model:

  • Set the output port data type to any complex data type up to 16 bits or real data type up to 32 bits. Data travels in a 32-bit bus.

  • Gate valid_out with the ready_in signal. Only assert valid_out and send data when ready_in is high.

    • The host asserts ready_in after it connects to the radio by calling setup on the usrp System object. For more information about the call sequence, see Object Functions.

    • The host buffers received data in RAM and reads it using the readPort function. If the DUT sends data faster than the host reads it, internal buffers can overflow. The overflow output argument indicates this condition. If overflows occur, reduce the DUT send rate or use the PL DDR buffer.

  • Count output samples and assert last_out on the final sample of each packet. The recommended packet size is 256 samples.

  • Group packets into bursts of contiguous data. Assert EOB_out on the last packet of each burst.

DUT to Host (PL DDR Buffer)

To implement this interface in your Simulink model:

  • Set the output port data type to any complex data type up to 16 bits or real data type up to 32 bits. Data travels in a 32-bit bus.

  • Gate valid_out with the ready_in signal. Only assert valid_out and send data when ready_in is high.

    • After the host connects to the radio by calling setup on the usrp System object, the PL DDR buffer asserts ready_in at the MCR. For example, on a USRP N310 radio with a 25 MS/s baseband sample rate, the MCR is 125 MHz and the buffer asserts ready_in at 125 MHz.

    • The PL DDR buffer de-asserts ready_in when the buffer is full or while the host reads data using the readPort function. After a read operation, the buffer flushes and is ready to receive data again.

  • The host reads data from the buffer using the readPort function with no dropped samples or overflow.

  • Count output samples and assert last_out on the final sample of each packet. The recommended packet size is 256 samples.

  • Group packets into bursts of contiguous data. Assert EOB_out on the last packet of each burst.

Host to DUT (Direct)

To implement this interface in your Simulink model:

  • Set the input port data type to any complex data type up to 16 bits or real data type up to 32 bits. The host streams data in a 32-bit bus.

  • Assert ready_out when the DUT can accept a sample. The host sends one sample each time ready_out is high during a writePort operation.

    • If the DUT does not assert ready_out, the writePort function times out.

    • If the DUT expects continuous data and the host does not call writePort frequently enough to keep up with the DUT consumption rate, underflows occur. To receive data asynchronously and avoid underflows, use the PL DDR buffer.

  • The host sends data in packets. The last_in flag is asserted on the final sample of each packet. The host does not send an end-of-burst signal.

Host to DUT (PL DDR Buffer)

To implement this interface in your Simulink model:

  • Set the input port data type to any complex data type up to 16 bits or real data type up to 32 bits. The PL DDR buffer streams data in a 32-bit bus.

  • Assert ready_out when the DUT can accept a sample. The PL DDR buffer sends one sample each time ready_out is high. This path eliminates dropped samples and underflows.

  • The host writes data to the PL DDR buffer using the writePort function. The writeMode argument controls delivery:

    • 'Once' — The buffer sends all data to the DUT once, then stops.

    • 'Continuous' — The buffer sends data to the DUT repeatedly until the host starts a new writePort operation, or calls release or reset on the usrp System object.

  • The PL DDR buffer sends data in packets. The last_in flag is asserted on the final sample of each packet. The EOB_in flag is asserted for the duration of the last packet in a burst.

See Also

| | | |

Topics