Compatibility with Previous Releases

The technology underpinning the features and workflows of the Communications Toolbox™ Support Package for Xilinx^® Zynq^®-Based Radio was updated in release R2018b. In releases before R2018b, the support package uses Analog Devices^® no-OS drivers to control RF devices. Starting in release R2018b, the support package uses Analog Devices industrial I/O (IIO) drivers and the corresponding libiio library for interfacing with Linux^® IIO devices. This transition gives access to more advanced device properties.

To run a design based on objects or blocks released before R2018b, you must update your design by replacing pre-R2018b objects and blocks with objects and blocks released in R2018b or later. All objects and blocks released before R2018b have been removed.

The next sections highlight compatibility considerations and describe how to update a design based on features released before R2018b.

How to Replace Radio Objects

In releases before R2018b, interfacing with a supported radio hardware is through a radio object dedicated to your radio hardware. For example, in this code, devADI is a comm.SDRDevADIRFSOM radio object, devZC706 is a comm.SDRDevZC706FMC234 radio object, and devZedBoard is a comm.SDRDevZedBoardFMC234 radio object.

% Before R2018b
devADI = sdrdev('ADI RF SOM');
devZC706 = sdrdev('ZC706 and FMCOMMS2/3/4');
devZedBoard = sdrdev('ZedBoard and FMCOMMS2/3/4');

Starting in release R2018b and later, you can interface with any of these radio hardware by using the comm.SDRDevAD936x radio object. To create this object, call the sdrdev function with argument 'AD936x'.

% From R2018b and later
dev = sdrdev('AD936x');

Starting in release R2018b and later, the only time you need to specify a radio hardware name identifier is when calling the downloadImage function.

% From R2018b and later
downloadImage(dev,'BoardName','ADI RF SOM')

Replace pre-R2018b radio objects by following these guidelines.

Functionality Removed in R2020a	Use Instead	Compatibility Considerations
`comm.SDRDevADIRFSOM` radio object	`comm.SDRDevAD936x` radio object;	In calls to `sdrdev`, replace the radio hardware name with `'AD936x'` and use a `comm.SDRDevAD936x` radio object instead. In calls to `downloadImage`, you must specify the radio hardware name. Remove calls to any of these object functions: `setupSession` `setAddress` `setupTools`
`comm.SDRDevZC706FMC234` radio object
`comm.SDRDevZedBoardFMC234` radio object

How to Replace System Objects

In releases before R2018b, sending or receiving data in MATLAB^® is through a transmitter or receiver System object™ dedicated to your hardware. For example, in this code, rxADI is a comm.SDRRxADIRFSOM receiver System object, rxZC706 is a comm.SDRRxZC706FMC234 receiver System object, and rxZedBoard is a comm.SDRRxZedBoardFMC234 receiver System object.

% Before R2018b
rxADI = sdrrx('ADI RF SOM');
rxZC706 = sdrrx('ZC706 and FMCOMMS2/3/4');
rxZedBoard = sdrrx('ZedBoard and FMCOMMS2/3/4');

Starting in release R2018b and later, to receive data in MATLAB from these radio hardware, use the comm.SDRRxAD936x receiver System object. To send data from MATLAB to these radio hardware, use the comm.SDRTxAD936x transmitter System object. To create the corresponding System objects, call the sdrrx or sdrtx functions with argument 'AD936x'.

% From R2018b and later
rx = sdrrx('AD936x');
tx = sdrtx('AD936x');

Replace pre-R2018b System objects by following these guidelines.

Functionality Removed in R2020a	Use Instead	Compatibility Considerations
`comm.SDRRxADIRFSOM` receiver System object	`comm.SDRRxAD936x` receiver System object	In calls to `sdrrx`, replace the radio hardware name with `'AD936x'` and use `comm.SDRRxAD936x` receiver System object instead. In System object calls, the second output argument is now a valid data indicator of `logical` data type and not the length of data. Replace references to property `EnableQuadratureTracking` with `EnableQuadratureCorrection` Replace references to property `EnableRFDCTracking` with `EnableRFDCCorrection` Replace references to property `EnableBasebandDCTracking` with `EnableBasebandDCCorrection` Consider using these functionalities of the `comm.SDRRxAD936x` object: Debug with built-in self-test (BIST) functionalities by using properties `BISTLoopbackMode` and `BISTToneInject`. Control I/O by using the `DataTimeout` property. Switch between default and custom filters by using the `UseCustomFilter` property.
`comm.SDRRxZC706FMC234` receiver System object
`comm.SDRRxZedBoardFMC234` receiver System object
`comm.SDRTxADIRFSOM` transmitter System object	`comm.SDRTxAD936x` transmitter System object	In calls to `sdrtx`, replace the radio hardware name with `'AD936x'` and use `comm.SDRTxAD936x` transmitter System object instead. Remove references to properties `EnableBurstMode` and `NumFramesInBurst`. For alternative methods, see Detect Underruns and Overruns. Update references to DDS properties by replacing them with the ones available in the `comm.SDRTxAD936x` object: `DDSTone1Freq`, `DDSTone2Freq`, `DDSTone1Scale`, `DDSTone2Scale`. Consider using these functionalities of the `comm.SDRTxAD936x` object: Debug with BIST functionalities by using properties `BISTLoopbackMode` and `BISTToneInject`. Control I/O by using the `DataTimeout` property. Switch between default and custom filters by using the `UseCustomFilter` property.
`comm.SDRTxZedBoardFMC234` transmitter System object
`comm.SDRTxZC706FMC234` transmitter System object

How to Replace Blocks

In releases before R2018b, sending or receiving data in Simulink^® is through a transmitter or receiver block dedicated to your hardware. You can replace these blocks with AD936x blocks by following these guidelines.

Functionality Removed in R2020a	Use Instead	Compatibility Considerations
ADI RF SOM Receiver block	AD936x Receiver block	Replace the pre-R2018b receiver block with an AD936x Receiver block by following these steps. Add an AD936x Receiver block to your model. Port the parameter values from the old block to the corresponding parameter fields on the AD936x Receiver block. The Simulate using parameter is not available in the new block. Match the lost samples port of the old block to the overflow port of the AD936x Receiver block. Match the data length port of the old block to the data valid port of the AD936x Receiver block. The data valid port is disabled by default. Also note that the data types of the data length and data valid ports differ. Consider using these functionalities of the AD936x Receiver block: Override the default sample time for ARM^® code generation by using parameters Override automatic sample time and Sample time. Debug with BIST functionalities by using parameters Loopback and Test signal injection. Control I/O by using the Data timeout (sec) parameter. Switch between default and custom filters by using the Use custom filter parameter.
ZC706 and FMCOMMS2/3/4 Receiver block
ZedBoard and FMCOMMS2/3/4 Receiver block
ADI RF SOM Transmitter block	AD936x Transmitter block	Replace the pre-R2018b transmitter block with an AD936x Transmitter block by following these steps. Add an AD936x Transmitter block to your model. Port the parameter values from the old block to the corresponding parameter fields on the AD936x Transmitter block. Special considerations: The DDS parameters have a different configuration in the new block. The Simulate using parameter is not available in the AD936x Transmitter block. The Enable burst mode parameter is not available in the AD936x Transmitter block. For alternative methods, see Detect Underruns and Overruns. Match the lost samples port of the old block to the underflow port of the AD936x Transmitter block. Consider using these functionalities of the AD936x Transmitter block: Debug with BIST functionalities by using parameters Loopback and Test signal injection. Control I/O by using the Data timeout (sec) parameter. Switch between default and custom filters by using the Use custom filter parameter.
ZC706 and FMCOMMS2/3/4 Transmitter block
ZedBoard and FMCOMMS2/3/4 Transmitter block

Hardware-Software Co-Design Considerations

To enable hardware-software co-design, follow the updated instructions in Installation for Hardware-Software Co-Design.

HDL Code Generation

Because the underlying FPGA image changed in R2018b, you must regenerate your FPGA bitstreams for your updated model. For FPGA targeting, follow the instructions in Step 4. Generate HDL IP Core Using HDL Workflow Advisor. For hardware-software co-design, follow the instructions in Step 7. Generate FPGA Bitstream and Program Zynq Hardware.

Software Interface Models

If you want to deploy a new hardware-software co-design model, follow the instructions in Hardware-Software Co-Design Workflow.

If you have a software interface model generated using a release before R2018b, you can update the generated software model by following these steps.

Replace the pre-R2018b blocks with the AD936x blocks by following the steps in How to Replace Blocks.
On the Advanced tab of the AD936x Receiver block mask, select the Override automatic sample time parameter. Specify the value of the ARM Frame Rate block for the Sample time parameter. Delete the ARM Frame Rate block.
Reconfigure the software interface model. On the Hardware tab, in the Prepare section, click Hardware Settings and select Xilinx Zynq-7000 Based IIO Radio from the Hardware board list.