Flexible Channel Emulation Workflows on USRPs with MATLAB and Simulink
Guest bloggers:
Nadia Shivarova (Senior Wireless Application Engineer) & Neil MacEwen (Pricinpal Development Engineer)
Nadia Shivarova is a senior wireless specialist application engineer at MathWorks, working with customers in multiple industries to adopt the tools and accelerate their development. She specializes in modelling wireless standards, end-to-end systems and deployment to SDRs. She joined MathWorks in 2016 as a quality engineer as part of the HDL group, then transitioned to application engineering in 2020. Recent interests include 6G, NTN and AI for wireless. She holds an MEng in Electronic and Electrical Engineering from University of Strathclyde, Glasgow.
Neil MacEwen is a Principal Development Engineer at MathWorks specializing in wireless communications, Software-Defined Radio (SDR), and FPGA development. His work focuses on rapid prototyping of next-generation wireless, radar, and sensing systems using MATLAB, Simulink, and NI USRP hardware. He holds an MEng in Electronic and Electrical Engineering and a PhD in communication systems for wireless sensor networks from the University of Strathclyde.
Overview
In this post we walk through a Model-Based Design workflow for building wireless signal processing on the FPGA of an NI USRP radio with Wireless Testbench, using SISO terrestrial channel emulation as the example. We handle the scenario, waveforms and test vectors, the reference model, device control and analysis through MATLAB, and the HDL-compatible implementation and the move to fixed point through Simulink. The channel emulator is built from behavioural model to validated on hardware. It can be extended to MIMO, reconfigured for NTN, or leveraged for AI training data and low-PHY work in O-RAN architectures.
Introduction
Wireless research validation often requires more than simulation and more control than purely over-the-air (OTA) testing can provide. Teams want to define representative wireless scenarios, implement real-time signal processing on hardware, and validate the results against software references without rebuilding the workflow at each step.
That’s the gap the Wireless Testbench deployment workflow addresses. MATLAB stays the environment for scenarios, standard-compliant waveforms, reference behaviour, control and analysis. Simulink holds the HDL-compatible implementation, and synthesisable HDL is generated from it. The USRP brings FPGA processing and RF together on one platform. None of this is toy-scale: the same approach has been used for much larger designs, such as an NR 5G SIB1 receiver.
Channel emulation is a good test of the idea. Receiver behaviour, synchronisation, beamforming decisions, link adaptation and waveform robustness all depend on delay, multipath fading and UE mobility. An emulator in the live signal path gives you realistic conditions that are repeatable and can be reconfigured from MATLAB between runs.
Put that emulator on a USRP and you have a practical hardware-in-the-loop setup. You evaluate behaviour on real hardware under controlled conditions, not just offline. If you read the earlier post on the desktop simulation, SiL, PiL and HiL, this is HiL applied to wireless.
The example here is a terrestrial, multipath, ray-traced scenario. The workflow carries over to more channel paths, MIMO, NTN and controlled dataset generation for AI, which we come back to at the end.
Channel Emulation on NI USRP Radios
The example is in the Wireless Testbench documentation. It takes a multipath channel from a ray-traced scenario in MATLAB to an emulator running on the USRP FPGA, then checks the hardware against a software reference. Figure 1 is the map for the rest of this post.
Figure 1: Model-Based Design for USRP
- A MATLAB test bench that generates required path delays and gains based on a terrestrial ray tracing scenario.
- A fixed-point, HDL-compatible Simulink implementation of a multipath channel emulator device-under-test (DUT) implementing integer and fractional delays.
- Deployment of the design to a supported NI USRP FPGA using the Wireless Testbench deployment workflow.
- A host MATLAB I/Q streaming configuration and validation of the deployed design against a software golden reference
Workflow summary
The deployment flow has five stages, shown in Figure 2.
Figure 2: Wireless Testbench USRP deployment workflow
- Setup. Configure the environment, the toolchain and a saved radio configuration.
- Simulink model. Model the algorithm in MATLAB, then Simulink. Convert from floating to fixed point, and check functional behaviour and the AXI interfaces in simulation.
- IP core generation settings. Set the HDL code generation options, pick the USRP target and map the DUT’s AXI interfaces to the radio.
- Generate bitstream. Generate the HDL IP core, wrap it as an RFNoC block and let Vivado integrate the design and build the bitstream.
- Host interface script. Generate the MATLAB script that programs the radio, connects to the deployed design and controls it for HIL validation.
You can run all of this interactively from the HDL Code tab in Simulink (Figure 3). The tab is laid out in the same order as the workflow. You choose the output, prepare the settings and target interface, generate the IP core, build the bitstream, then generate the host interface script.
Figure 3: Simulink HDL Code toolstrip
For CI/CD, the same steps are available through a MATLAB API. That matters more than it sounds. Once the hardware build is a pipeline step, regressions in the FPGA design get caught the same way software ones do.
I won’t repeat the full procedure here, because the documentation covers it in better detail.
Channel Emulator HDL IP
Now for the detail. Figure 4 shows what actually runs on the radio.
Figure 4: Deployed channel emulator DUT
The host transmits a test signal out of DAC 0, which loops back over RF into ADC 0. The channel filter applies the multipath delays and gains, sends the result out of DAC 1, and it loops back into ADC 1 for capture. Delays and path gains stream in separately from MATLAB, so you can change the channel without rebuilding the bitstream. Because the signal passes through the radio’s real converters on both sides, the test covers more than the FPGA logic.
The channel itself comes from a terrestrial ray tracing scenario (Figure 5). comm.RayTracingChannel uses shooting and bouncing rays (SBR) over buildings from an OpenStreetMap file, and can account for building materials, antenna beamforming, reflections and diffraction. What we get out is a set of path delays and gains. This scenario produced 11 paths, set through MATLAB variables.
Figure 5: Terrestrial ray tracing scenario
The same scenario drives the golden reference: comm.ChannelFilter, a floating-point model of what the hardware should do. Because it exists before deployment, problems show up in simulation rather than on the bench, where they cost more to find.
The Simulink model shown in Figure 6 maps that behavior into an HDL-compatible, fixed-point arithmetic DUT implementation of a channel filter with AXI4 Stream interfaces and registers. The design uses highly optimized blocks for HDL code generation, such as reprogrammable discrete FIR filters, complex multiplications, and counters to implement streaming logic, per-path delay handling, complex gain application, and path combination. This makes the model suitable for FPGA targeting while preserving a clear connection to the original channel concept.
Figure 6 Channel emulator IP implementation model
The next step is to choose the USRP device to target, including FPGA rate and required streaming interfaces. This is shown in Figure 7. Finally we indicate which ports on the Simulink model correspond to which interfaces on the Target Interface.
Figure 7 Radio and DUT configuration parameters
From there it’s automated. The flow generates a device-agnostic HDL IP core, wraps it as an RFNoC block, and runs Vivado in a shell to integrate the design and produce the bitstream and auxiliary files. It can also generate the MATLAB host script, already populated with the functions to program the FPGA, stream data and update registers.
Validation
Validation happens at three levels: the functional correctness, the speed and area fit on the FPGA, and the behaviour on hardware.
Fixed point against floating point. Once the fixed-point model is built, compare its output with the floating-point MATLAB reference. That tells you whether the data types have enough precision, range and scaling. In this example the maximum error stays within a 1e-4 tolerance (Figure 8).
Figure 8 Validating quantization error between floating- and fixed-point models
Speed against area. Next comes iterating on the FPGA requirements. Pipelining raises the achievable clock rate but adds latency. Resource sharing saves area, also at the cost of latency. HDL Coder automates a lot of these optimisations. The full RFNoC design was synthesised for 200 MHz, and the table below shows the channel emulator IP on its own.
|
USRP Target
|
LUTs (%)
|
FFs (%)
|
BRAM (%)
|
DSP (%)
|
|
X310
|
5579 (2.19)
|
16363 (3.22)
|
51 (3.21)
|
364 (23.64)
|
|
X410
|
5661 (1.33)
|
16856 (1.98)
|
38 (1.78)
|
364 (8.52)
|
To enable scaling up to MIMO, this model allows DSP resource sharing to be set via a MATLAB variable. This would significantly reduce DSP resources at the expense of latency as the number of input and output channels grow and consume more resources.
Hardware against reference. With the IP running on the radio, you can drive it from MATLAB. You can stimulate the DUT from the radio front end, or stream complex I/Q straight from the host as AXI4-Stream over Ethernet. Code snippets on the host side look like this:
% Set up the radio and download the bitstream
device = usrp(radio);
programFPGA(device, …
“build_N320_HG/build-N320_HG/n3xx.bit”, …
“build_N320_HG/build/usrp_n320_fpga_HG.dts”);
describeFPGA(device, “wtChannelEmulatorSL_wthandoffinfo.mat”);
% Select physical antenna ports
device.TransmitAntennas = “RF0:TX/RX”;
device.CaptureAntennas = “RF0:RX2”;
% Initialise the FPGA and write the channel parameters
dut = fpga(device);
writePort(dut, “pathGains_data”, sl_in.PathGains(:,1));
writePort(dut, “delays_data”, delays);
% Set up the test vector
txData = int16(impulse * 2^15);
captureLen = impulseLen * 5;
% Transmit continuously into the FPGA
transmit(device, txData, “continuous”);
device(captureLen);
% Capture the DUT output back to the host for validation
[dataOut, numSamps] = capture(device, captureLen);
The same script captures the DUT output. That means two checks: the impulse response against the golden reference, and the frequency-selective behaviour against what the ray-traced scenario predicts (Figure 9).
Figure 9 Spectrum analyzer visualization of I/Q data
That closes the loop. The environment that defined the channel is the one that decides whether the hardware got it right.
Additional Use Cases
Although the current example is focused on a terrestrial multipath scenario, the workflow is relevant to several broader use cases.
SISO to MIMO Channel
The methodology is not limited to SISO. As the number of antennas and links grow, the design becomes more demanding in terms of interfaces, memory, and FPGA resources, but the same workflow applies. Simulink is able to handle data vectors creates a natural extension to a MIMO channel emulator. That makes the example a useful stepping stone toward MIMO and beamforming studies. For further up-scaling and synchronizing time and phase across multiple USRPs using the OctoClock, see Connect and Synchronize Multiple NI USRP Radios example.
NTN Research
This workflow is also extensible toward non-terrestrial network (NTN) scenarios. In these cases, Satellite Communications Toolbox can help derive orbit scenario parameters, such as doppler and latency. 5G Toolbox nrTDLChannel or nrCDLChannel 3GPP NTN profiles can configure the path gains and delays. For more information on NTN channel modeling, see Model NR NTN Channel.
AI Training Data
Channel emulation can also support AI and machine learning workflows. A controllable deployed setup can be used to generate labelled training and validation data under repeatable wireless conditions. By sweeping channel parameters deliberately, teams can create datasets with clearer provenance and more systematic scenario coverage than uncontrolled OTA capture alone. Explore the Capture and Label NR and LTE Signals for AI Training example to see how USRPs can be leveraged for this purpose.
O-RAN Research
Deploying processing to the USRP FPGA can help isolate low-PHY behavior from higher-layer or software-based processing. That makes the workflow relevant to O-RAN-style split experimentation, where lower-layer timing behavior may need to be studied independently of the rest of the stack. For more information, explore HDL OFDM Transmitter and Introduction to Custom OFDM on NI USRP Radio examples.
OAI Testbeds
The same channel emulation concept can fit into broader SDR and open testbed environments. In OpenAirInterface-style systems and related research setups, a controlled channel stage can complement higher-layer experimentation by adding repeatable wireless behavior to the overall platform.
Conclusion
This application note uses channel emulation to illustrate a broader MATLAB and Simulink Wireless Testbench workflow for NI USRP radios. The value of the workflow is not only that it can produce a flexible, working FPGA deployment, but also that it preserves continuity from scenario definition to deployed validation.
MATLAB supports the front end of the process through modeling, test vector waveforms, and golden references. Simulink provides the environment to design and test the HDL-compatible model. Deployment using Wireless Testbench in MATLAB provides the bridge to USRP hardware, host control and analysis layer for HIL validation.
Channel emulation is a strong example because it demonstrates how this workflow supports real-time HIL wireless experimentation while remaining repeatable, extensible, and practical for research and prototyping. It also provides a natural path toward related use cases such as MIMO studies, NTN parameterization, AI dataset generation, and low-PHY exploration in O-RAN research.
Appendix Tool Requirements
The exact deployment requirements depend on the target radio and build environment, but this workflow assumes the following components:
댓글
댓글을 남기려면 링크 를 클릭하여 MathWorks 계정에 로그인하거나 계정을 새로 만드십시오.