This example shows how to implement algorithms on the USRP® E310 radio platform that are partitioned across the ARM and the FPGA fabric. Specifically, this example concerns the reception and decoding of Automatic Dependent Surveillance Broadcast (ADS-B) transmissions, with receive functionality implemented in hardware and software, and a transmit waveform embedded in hardware.
HDL Coder Support Package for Xilinx Zynq-7000 Platform
Embedded Coder Support Package for Xilinx Zynq-7000 Platform
Communications Toolbox Support Package for USRP® Embedded Series Radio (this package)
This example involves the reception of ADS-B transmissions either from the air, or from a previously recorded Mode S signal which can be transmitted locally using the embedded transmit waveform. The transmit and receive FPGA implementations are combined into one HDL IP core and implemented on the Zynq programmable logic (PL). The data decoding is run on the Zynq ARM processor through code generation. Some control parameters are added to the FPGA IP core to show how the design can be adjusted in real time using AXI4-Lite registers accessed from Simulink.
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 Toolbox Support Package for USRP® Embedded Series Radio (this 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 Toolbox Support Package for USRP® Embedded Series 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.
Mode S is a transponder interrogation mode used to transmit information about an aircraft upon request from an interrogating system. Mode S signals can be either short (56 bits) or long (112 bits). The content of different Mode S message types can vary significantly, although most will contain information regarding the message type, the ICAO24 identification address of the aircraft, and a cyclic redundancy check (CRC) checksum. For this example, we will specifically consider Mode S Extended Squitter (Mode S ES) transmissions, which are 112 bit signals that can contain additional information about the altitude, position, velocity, flight status, and callsign of an aircraft. The structure of a typical Mode S ES signal is shown in the diagram below.
The initial 8 bits of any Mode S signal are the control bits. These bits contain information on the downlink format (DF), which is used to describe which type of Mode S message is being received. For Mode S ES, the value of the DF should be equal to 17. This is followed by the ICAO24 code, which is a unique 24-bit aircraft identification code. The additional 56 bits of information included in a Mode S ES Signal make up what is known as the ADS-B message.
The content of an ADS-B message is identified through its Type Code (TC), which is the first 5 bits of the message. Depending on the type code, an ADS-B message can contain information about the aircraft ID (TC=4), airborne position in terms of altitude, latitude and longitude (TC=9), and horizontal and vertical velocity (TC=19). This example is specifically concerned with the decoding of airborne position messages, which are structured as shown in the diagram below.
Mode S signals are preceded by an 8-bit preamble pattern, which is used by receivers to determine if a valid message has been transmitted, and when the message bits start. The signals are transmitted at 1090 MHz at a data rate of 1 Mbit/s, and are modulated using Pulse Position Modulation (PPM), as illustrated in the following figure.
For PPM, a Logic 1 is obtained when the signal is ON for the first half of a bit interval and OFF for the second half. Likewise, a Logic 0 is obtained when the signal is OFF for the first half of a bit interval, and ON for the second half. As PPM Modulation is extremely time sensitive, it is important that a Mode S receiver is able to use the preamble to determine the exact sample where the message bits start.
The hardware generation model is used to develop the functionality that you wish to implement on the FPGA fabric. This involves modelling an HDL-optimized ADS-B receiver for implementation onto the PL. In this example, we transmit and repeat on a single board (through the use of the embedded transmit waveform), however, the example could be modified to receive ADS-B signals from the air. This could be done by changing the receive center frequency from the default 2.4GHz value to 1090MHz, and disabling the transmitter blocks.
Hardware/software partitioning: In general, the programmable logic of the FPGA is used for high rate signal processing while the ARM is used for slower rate, control functionality. In this example, the receiver algorithm is implemented entirely in the PL, as the matched filtering and cyclic redundancy checks (CRC) introduce high rate signal processing requirements. The embedded transmit waveform is also implemented in the PL. The Tx and Rx algorithms have been placed in two separate subsystems -
HDLRxIpCore - within the main
HDL_ADSB subsystem. The ARM is used to send the received data back to the host for decoding and printing.
This model contains an AXI4-lite control port,
TxTransmitPeriod. This allows control over the rate at which ADS-B messages are transmitted. The
Threshold port sets the minimum received amplitude required to register a correctly received preamble. The transmit subsystem is shown below.
The pre-recorded ADS-B extended squitter messages are stored in a 2-D Lookup Table block, where each column contains 520 samples. The first HDL Counter block counts to the value specified by the
TxTransmitPeriod port. Once the period value is reached the first timer resets while in the same instance incrementing the second timer, which selects the next column to read from. The second timer resets every 8 periods, for the 8 stored extended squitter messages. The model is configured to allow a transmit period of up to 4s to be used.
The receive algorithm, shown below, uses a discrete FIR filter block to correlate the received data to the preamble. This correlation value is then used by the Timing Control state machine to trigger reception of data.
The timing control state machine in this example has been implemented in MATLAB code using a MATLAB function block. The preamble is detected if a peak with amplitude greater than the threshold value is output from the FIR filter. The threshold value is calculated dynamically using an estimate of the received signal power. Once the preamble has been located, the state machine will wait for the start of the first message bit before triggering the processing of a message.
Bit Process subsystem, the amplitude of the samples for the first and second halves of the bit period are calculated and compared in order to determine whether the current bit is Logic 1 or Logic 0. This can be considered a form of PPM demodulation. A HDL counter is also used within this subsystem in order to determine the starting point of each new bit, based on the 4MHz sampling rate of the system. The output of this counter is used to compute a CRC checksum within the
Compute and Check CRC subsystem, which will then be compared to the received checksum in order to ensure that the received ADS-B message is valid. In order for this comparison to take place, the timing control state machine empties the CRC registers for the final 24 bits of the received message. This is achieved by setting the EmptyReg signal appropriately.
At the output, the received and processed data is delayed by the length of one long Mode S signal and converted into a 16-bit integer for ease of decoding. A message will be decoded using some MATLAB code if the valid output is at Logic 1.
This model can be run to confirm its operation using the embedded transmit waveform within the
HDLTxIpCore subsystem. When you run the model, the received messages are decoded and presented on a table GUI.
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 to run on the ARM.
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 HDL_ADSB subsystem and selecting
HDL Code / HDL Workflow Advisor.
In Step 1.1, select
IP Core Generation workflow and the appropriate radio platform:
In Step 1.2, select
Receive and transmit 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 4MHz, so a synthesis frequency of around 8MHz is more than sufficient.
In Step 1.3, the interface table can then be used to map the user logic signals to the interface signals available in the reference design. In this example, we are only using a single channel, so the channel 1 connections should be connected to the relevant ports as shown below.
Step 2 prepares the model for HDL 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, or, if you are already familiar with preparation and HDL code generation phases, right click Step 4.1 in the table of contents on the left hand side and select
Run to selected task.
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 which has been generated from the
HDL_ADSB subsystem. Note that this exposes only the AXI4-lite control ports, and not the data ports. The data ports are present on the Receiver/Transmitter blocks which represent the data interface between the FPGA user logic and the ARM. If you use the library blocks in your downstream models, any updates you make to your HDL subsystem will automatically be propagated to this library and then to your software generation models when you run through the workflow. In this example, the hardware generation model did not contain any SDR transmit or receive blocks so the parameters on these blocks could not be populated. When using the library blocks you must ensure to configure the parameters correctly for your application.
Software Interface Model
The software interface model can be used as a starting point for full SW targeting to the Zynq: External mode simulation, Processor-in-the-loop and full deployment. Note that this generated model will be overwritten each time Step 4.2 is run, so it is advisable to save this model under a unique name and develop your software algorithm in there. A software interface model has been provided which shows how you may decide to structure this model, see section Running the Software and Hardware on the E310 platform.
The rest of the workflow is used to generate a bitstream for the FPGA fabric and download it 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 will complete in a couple of minutes after some basic project checks have been completed, and the step will be marked with a green checkmark. However, you must 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 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('E310'); >> 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.
A software interface model has been provided which shows how you could modify the generated model to set it up for the ADS-B Mode S example. This interface model will allow you to run the model in
External mode or fully deployed.
Note that the Transmitter block in the provided software interface model has had its outputs terminated. Even though no data is being sent from the ARM to the FPGA, this block is required to initialize the required RF parameters and to enable the transmit data path, therefore it must be included in the interface model.
The SW interface model has been configured to run from a timer-driven scheduler. The downstream decode and display processing will take place when a valid waveform has been received, controlled by the data valid output. If no valid ADS-B signal is received, the attempt to receive data from the FPGA will time out.
In order to successfully receive an ADS-B signal with this example, you can run in one of two ways:
Detect a live signal off-the-air. For this option you will need to set the center frequency of the receiver block to the ADS-B transmission frequency, which is 1090MHz. You should also comment out the transmitter block to ensure no interfering signal is transmitted.
Use the provided embedded transmit waveform. In this case, the centre frequency of the transmit block should be set to a frequency that is unlicensed and legal to use in your area, with the receiver block set to the same center frequency.
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. In this mode you will not be able to tune parameters.
Once the ARM has successfully received an ADS-B message, it sends the result back to the host over the Ethernet link using the UDP send block found in the software interface model. The UDP send block has been configured using the default IP address of the host '192.168.3.1'. If you altered the IP addresses during the hardware setup process, you must supply that address instead. A simple UDP receive model has been supplied which has a MATLAB function block used to decode the received messages.
The decoded information is presented on a tabular GUI, or more detailed information can be logged into a text file if you press the
Start Logging button. If you want to observe the plane traffic in your area you will have to tune your receiver on the interface model to 1090MHz.
Additionally, if you have a valid license for the Mapping Toolbox, you can observe the planes on a map. The recorded waveform that comes with this example contains 8 captured ADS-B extended squitter messages of two different flights. For each flight there are 2 airborne position (TC=9), 1 aircraft ID (TC=4) and 1 vertical velocity (TC=19) messages that are repeatedly transmitted at a rate regulated by the
TxTransmitPeriod control port.
USRP® is a trademark of National Instruments Corp