This example shows how to implement an LTE MIB recovery system on the Zynq radio platform that is partitioned across the ARM and the programmable logic (PL) fabric. The FPGA image generated is then used as the base for building an LTE cell scanner to detect LTE cell signals in the vicinity.
LTE HDL Toolbox
HDL Coder Support Package for Xilinx Zynq Platform
Embedded Coder Support Package for Xilinx Zynq Platform
Communications Toolbox Support Package for Xilinx Zynq-Based Radio (this support package)
Limitations: Due to limited hardware resources, this example does not support
ZedBoard and FMCOMMS2/3/4.
The LTE Cell Search and MIB Recovery HDL Example model is a hardware friendly model. You can use this model to detect the MIB information from synthesized data generated by the LTE Toolbox or captured off-the-air LTE waveforms. This example shows how to adapt the model to software-defined radio (SDR) hardware, and how to to prototype it on the Zynq platform. Firstly a system will be developed to receive MIB information at a single center frequency. Then the software interface model will be modified to allow real-time tuning of the center frequency to implement a cell scanner.
If you have not already done so, ensure you follow the hardware-software co-design setup instructions in the documentation.
The hardware generation model is used to develop the functionality that you wish to implement on the PL fabric. In this example, we implement a MIB recovery receiver based on the LTE Cell Search and MIB Recovery example. The following figure shows the hardware architecture diagram of the MIB Recovery example.
Hardware-software partitioning: In this example, the MIB recovery algorithm is implemented entirely in the PL, due to the high rate signal processing requirements of the design. The ARM is used to pull the information from the FPGA and send some useful information back to the host over a UDP link for display. The LTE_MIB_HDL subsystem contains the functionality to be implemented on the FPGA. Around this subsystem is the functionality that will eventually be implemented on the ARM processor on the Zynq hardware. The software provides two main functions: communication of the decoded MIB information back to the host for display, and start/reset control of the FPGA IP. In the hardware model, the communication back to the FPGA is replaced with a simple interface which displays the decoded information. The software can also control which input data to use: off-the-air or test data stored on the FPGA. To simulate software execution on hardware, the output data of the subsystem is downsampled by 1000.
The LTE MIB recovery subsystem is shown below.
In this subsystem, the HDL LTE MIB Recovery subsystem contains the cell search and MIB recovery algorithm as presented in the LTE Cell Search and MIB Recovery example.
In addition to the algorithm, the subsystem also provides functionality for integration with the Zynq hardware architecture.
At the input to the HDL LTE MIB Recovery subsystem, the StimulusSelector subsystem allows the input data to the MIB detection algorithm to switch between off-the-air or embedded test data. The embedded test waveform is pre-generated using LTE Toolbox and stored in a lookup table on the FPGA.
Next, some adjustments are made to the received data in the PrepInputs subsystem. The data from the AD9361 is a 12 bit number, sign extended to 16 bits. In order to use the full range the samples are scaled up to 16 bits. To take advantage of hardware resource sharing and simplify some of the architectures found in the receiver, the data rate into the system is configured to be higher than required. The input data rate is 61.44MHz, whereas the required maximum data rate is 30.72MHz. This difference translates to an overclocking factor of . Therefore, upon entering the detector, the data is immediately downsampled by a factor of 2. An FIR Decimation block is used to implement a lowpass decimation filter which captures the central part of the received LTE waveform and downsamples the data to 30.72MHz.
You can run this model to confirm its operation using the captured LTE waveforms in zynqRadioLTETransmitData.mat. The test waveforms used in the model are configured in the initialization script. As the model contains a large number of HDL-optimized blocks, requiring simulation using sample-based signals, the simulation runs very slowly. When a MIB is decoded, the MIB GUI will pop up with the decoded information.
You can set up the model with the following option:
externalDataSel: set to false to select internal test data, transmitted from a LUT. When false is selected, the start signal will also be driven internally, resetting the MIB recovery every 4s. Set to true to select the pre-captured off-the-air data stored in the test vectors.
Once you are satisfied with the simulation behavior of the hardware subsystem, you can start the process of generating the HDL IP Core, integrating it with the SDR reference design, and generating software for the ARM processor.
In preparation for targeting, you must set up the Xilinx tool chain by invoking
hdlsetuptoolpath. For example:
>> hdlsetuptoolpath('ToolName','Xilinx Vivado','ToolPath','C:\Xilinx\Vivado\2017.4\bin\vivado.bat');
Start the targeting workflow by right-clicking the LTE_MIB_HDL subsystem and selecting
HDL Code / HDL Workflow Advisor.
In Step 1.1, select
IP Core Generation workflow and the appropriate Zynq radio platform. Choose either
ADI RF SOM or
ZC706 and FMCOMMS2/3/4. Due to limited hardware resources, this example does not support
ZedBoard and FMCOMMS2/3/4.
In Step 1.2, select
Receive path reference design. You can leave the reference design parameters as the defaults.
Step 2 prepares the design for code generation by doing some design checks.
Step 3 performs the actual HDL code generation for the IP core.
Step 4 integrates the newly generated IP core into the larger Zynq SDR reference design, generates the bitstream, and helps you load it onto the board.
Execute each step in sequence to experience the full workflow. Alternatively, if you are already familiar with the workflow, right click Step 4.1 in the table of contents on the left hand side and select
Run to selected task. You can use the default settings in Steps 2 and 3.
In Step 4.2, the workflow generates a Zynq software generation interface model and a block library. Click the
Run this task button with the default settings.
Software Interface Library
The library contains the AXI Interface block generated from the LTE_MIB_HDL subsystem. The data ports present on the Receiver block represent the streaming data interface between the FPGA user logic and the ARM. If you use the library blocks in your downstream models, any updates to your HDL subsystem are automatically propagated to this library and to your software generation models. In this example, the hardware generation model did not contain SDR transmit or receive blocks, so the parameters on these blocks are populated with default values. When using the library blocks, you must configure the parameters correctly for your application.
Software Interface Model
You can use the generated software interface model as a starting point for full SW targeting to the Zynq: external mode simulation, processor-in-the-loop, and full deployment. Note that the generated model is overwritten each time you run Step 4.2. To further develop your software algorithm, save the model under a unique name. For a software interface model that shows how you can structure this model, see section Running the Software and Hardware on the Zynq board.
Use the rest of the workflow to generate a bitstream for the FPGA fabric and to download the bitstream to the board.
In Step 4.3, the Workflow Advisor generates a bitstream for the FPGA fabric. You can choose to execute this step in an external shell by ticking the selection
Run build process externally. This selection allows you to continue using MATLAB while the FPGA image is being built. The step requires a couple of minutes to complete after some basic project checks. When a green checkmark indicates that the step is complete, you must still wait until the external shell shows a successful bitstream build before moving on to the next step.
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.
Alternatively, if you want to load the bitstream outside Workflow Advisor, call the
>> dev = sdrdev('AD936x'); >> downloadImage(dev,'FPGAImage', ... 'hdl_prj\vivado_ip_prj\vivado_prj.runs\impl_1\system_top.bit') % Path to the generated bitstream
The following software interface model allows you to run the example system in
External mode or fully deployed.
The software interface model is configured to run on a timer interrupt. This means that the code generated from the Simulink model is executed on the ARM processor at a rate corresponding to the maximum rate in the software interface model. In this case, the model is configured to run at a rate of 1kHz, thus the AXI registers on the FPGA are read 1000 times per second.
For more information on setting up the software interface model, refer to workflow documentation.
You can detect an LTE MIB by choosing one these options:
Use the waveform embedded on the FPGA by setting the
externalDataSel input to 0.
Detect a live signal off-the-air by setting the
externalDataSel input to 1. This option requires the transmission center frequency of an LTE cell tower in your area. The default center frequency for this example is 806 MHz.
External mode allows you to control the configuration from the Simulink model. You can also fully deploy the design to run on the board, disconnected from Simulink. In the Simulink toolbar, click Deploy to Hardware.
The software algorithm is set up to reset the receiver on a timeout with default value 4000, which corresponds to 4 seconds. The same value is configured for the hardware start signal.
The ARM sends the decoded MIB information directly back to the host over the Ethernet link using the UDP send block. The UDP send block is configured using the default IP address of the host '192.168.3.1'. If you alter the IP addresses during the hardware setup process, you must supply that address instead. The following UDP receive model illustrates how to receive the decoded data, and displays the result.
When running successfully, you should notice that the information updates on the user interface on the host. The data received from the test waveform on the FPGA should result in received data as shown below.
The FPGA image generated for the MIB detector example can be re-used to scan across center frequencies and search for LTE cell towers in the local vicinity. The HW generation model used in this example already contains everything you need to implement this system, you only need to modify the SW interface model to update the center frequency over time and check for valid MIB signals.
The following software interface model is configured to implement a cell scanner, and allows you to run in
External mode or fully deployed.
The basic architecture of this SW interface model is very similar to the previous MIB detector example. The AXI interface block is used to read and write registers on the MIB detector IP core, and the ARM-FPGA interface block is used to configure the RF parameters. In this model, the center frequency is tuned in real-time from the software algorithm configured in the LTE Scan Controller block. To select the band of interest over which to scan, double click the LTE Scan Controller block and configure the parameters.
The LTE Scan Control block is a simple MATLAB state machine that programs the center frequency, gives the RF card time to settle and waits for valid MIB signals. The
numMIBRetries input allows you to choose how many times the MIB Detector algorithm will be restarted on each center frequency. The Concat and Send to Host block packages up the MIB information and associated data to be sent over UDP to the host. The current center frequency is also sent at regular intervals allowing the host display model to update its state periodically.
Open the LTE MIB Logger host model to view the decoded MIB information. This model implements a simple user interface to display the MIB information and currently scanning center frequency.
Some RF front-ends can have large frequency offsets which can make it hard to decode an LTE signal. The maximum offset that can be corrected is 7.5kHz. You can try the following techniques to identify a frequency offset.
If you have LTE Toolbox, you can run the LTE MIB Receiver script to look for LTE signals at chosen center frequencies. Edit the center frequency in the script to attempt to receive an LTE signal. The script will output the detected frequency offset on the command prompt.
You can add or subtract 3.75kHz from your chosen center frequency in the MIB Detector or Cell Scanner models. If your offset is greater than 7.5kHz, you can progressively try higher or lower frequencies.