MATLAB Examples

LTE MIB Recovery Using Analog Devices AD9361/AD9364

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.

Required products:

  • Simulink
  • Communications System Toolbox
  • LTE System Toolbox
  • LTE-HDL Toolbox
  • HDL Coder
  • HDL Coder Support Package for Xilinx Zynq-7000 Platform
  • Embedded Coder
  • Simulink Coder
  • Embedded Coder Support Package for Xilinx Zynq-7000 Platform
  • Communications System 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.

Contents

Introduction

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 System Toolbox or captured off the air LTE waveforms. For a shorter introduction to this example, you can also read the overview example. This example shows how to adapt the model to a software-defined radio (SDR) hardware, and how to to prototype it on the Zynq platform.

Setup

If you have not already done so, run through the guided setup wizard portion of the Embedded Coder Support Package for Xilinx Zynq-7000 Platform and Communications System Toolbox Support Package for Xilinx Zynq-Based Radio (this support package). You might have already completed these steps when you installed the support packages. To run them again, on the MATLAB Home tab, in the Environment section of the Toolstrip, click Add-Ons > Manage Add-Ons. Locate Embedded Coder Support Package for Xilinx Zynq-7000 Platform, or Communications System Toolbox Support Package for Xilinx Zynq-Based Radio and click Setup.

For more information, see the instructions in the documentation. Ensure you have set up the Xilinx SDK toolchain using the Zynq Embedded Coder support package setup wizard.

Hardware Generation Model

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.

Open the model.

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 parse the MIB data 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 LTEMIBRecovery_FPGA subsystem contains the cell search and MIB recovery algorithm as presented in the LTE Cell Search and MIB Recovery example.

In addition to the functionality of the algorithm, the subsystem also provides functionality for integratation with the Zynq hardware architecture.

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. In order to take advantage of hardware resource sharing to 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 $N = 2$. 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.

At the input to the LTEMIBRecovery_FPGA 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 System Toolbox and stored in a lookup table on the FPGA.

At the output of the LTEMIBRecovery_FPGA subsystem, the Registers subsystem packages the decoded data for reading from the ARM processor. The output of the LTEMIBRecovery_FPGA subsystem is converted from the sample control bus format to a standard data/valid format, and the decoded MIB information signals are latched for reading from the ARM. The MIB information symbols from a single decoded MIB are held until the processor resets them.

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 initialisation script. As the model contains a large number of HDL-optimized blocks, requiring simulation using sample-based signals, the simulation runs very slowly.

You can set up the model with the following options:

  • externalDataSel: set to false to select internal test data, transmitted from a LUT. Set to true to select the pre-captured off-the-air data stored in the test vectors.
  • externalStartSel: set to false to select an internal start pulse with a period of 4s. Set to true to select a start pulse driven from the software algorithm.
  • freqCompOn: Set to true to enable frequency compensation. Set to false to disable frequency compensation.
  • noOfMIBTrials: Select the number of times the MIB decoder will try to decode MIB for each detected PSS.

IP Core Generation Workflow

Once you are satisfied with the simulation behaviour 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:\Vivado\2016.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. Ensure that the Channel Mapping parameter is set to 1, and that the DUT Synthesis Frequency is set to a reasonable number given the baseband sampling rate of the system. In this example, the sample rate is 61.44 MHz, so the maximum synthesis frequency of 61.44 MHz is required.

  • In Step 1.3, the interface table can be used to map the DUT signals to the interface signals available in the reference design. In this example, we only use a single channel, so the channel 1 connections and AXI register interfaces should be configured as shown in the two images below.

  • 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 or 3.

Software Generation Model and Block Library

  • 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/Transmitter blocks represent the 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 not populated. When using the library blocks, you must configure the parameters correctly for your application.

Software Interface Model

You can use the 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.

Bitstream Generation and Loading

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.

In the Workflow Advisor, you have three options to download the bitstream. * With Download, the bitstream is persistent across power cycles (recommended). * With JTAG or Ethernet, the bitstream is not persistent across power cycles

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

>> dev = sdrdev('ADI RF SOM'); >> downloadImage(dev,'FPGAImage',...
     'hdl_prj\vivado_ip_prj\vivado_prj.runs\impl_1\system_wrapper.bit')
     % Path to the generated bitstream

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

Running the Software and Hardware on the Zynq board

The following software interface model allows you to run the example system in External mode or fully deployed. You must select the correct SDR receiver block for the hardware you are using.

Open the model.

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 816 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 400, 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.

Open the model.

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.