Hello, and welcome to the webinar Getting Started with Software-Defined Radio Design Using MATLAB and Simulink. My name is Noam Levine, technical marketing for FPGA and SSE solutions here at bat365. And I'll be joined in this presentation by Robin Getz from Analog Devices and Luc Langlois from Avnet. By the end of this webinar, we hope you understand the elements of a new workflow for SDR design that allows you to go from system simulation to production deployment in one hardware/software tools environment.

We'd also like you to know where you can find resources to help you with your radio implementation project. The topics we'll be covering in this webinar include modeling and simulation of the RF signal chain, modeling and simulation of communications algorithms, testing and verification of algorithms with real-world data, and finally, deployment of communication systems to hardware for prototyping and production.

This workflow can be applied to a number of Zynq-based SDR platforms, including the new PicoZed SDR system on module from Avnet, which allows you to go from development to production deployment using the same hardware. For design to prototype deployment, the workflow can also be applied to other development platforms featuring the Zynq-7000 All Programmable SoC, and Analog Devices AD9361 RF agile transceiver.

I'll now turn things over to Luc Langlois from Avnet to describe the new PicoZed SDR platform.

Hello to all designers of software-defined radio. I'm Luc Langlois from Avnet Global Technical Marketing, here to introduce our latest PicoZed SDR software-defined radio, featuring a production-ready system on module in small form factor with low power consumption.

The system includes the Analog Devices AD9361 RF agile transceiver, Xilinx Zynq-7000 All Programmable SoC, and can run embedded Linux. We worked closely with industry leaders Analog Devices, bat365, and Xilinx to create a production-ready system on module that integrates transmit and receive functions in a device the size of a deck of cards, enabling 2 by 2 MIMO configurations, and frequency bands from 70 megahertz to 6 gigahertz. And it can be used for development, and ultimately, plugged right into an end product.

Applications include portable agile wireless communications, public safety radio, point-to-point communications, femtocell and picocell base stations, and portable instrumentation.

PicoZed SDR SOM features the Xilinx 7Z035 Zynq SoC device, the Analog Devices 9361 RF transceiver, one gigabyte of DDR 3 low power, 256 megabits of Quad SPI non-volatile memory, USB 2.0 on the go, Ethernet, a microSD card, and 204 user I/O all on the SOM. The full development kit adds an FMC carrier card, antenna, power supply, and cables. More information and ordering at picozed.org/sdr.

Thanks, Luc. Now that we've identified our target hardware, we can start the design process. This simple block diagram shows the main elements of a software-defined radio system. As we saw in the description of the PicoZed SDR SOM, the hardware consists of an RF transceiver, the AD9361 from Analog Devices in this case, and a baseband processing engine, the Xilinx Zynq-7035 All Programmable SoC. We've added another block, test, and verification to show how your development workflow can be integrally tied to your hardware.

In this webinar we will be employing a Model-Based Design, or top-down approach, to system development. In this approach, we start with software simulation in MATLAB and Simulink of all of the major system elements, and then migrate those elements to hardware as they are developed and verified. We'll start by modeling our entire signal chain in MATLAB and Simulink in order to verify our baseband processing algorithms and overall system concept.

We'll then validate and tune our algorithms in Simulink with real streaming data. Once our algorithms are validated with real data, we can deploy them to hardware in a prototyping environment with real-time parameter tuning and analysis in MATLAB and Simulink to verify performance on target. Finally, we'll deploy our algorithms to a standalone system for production implementation.

Now let's examine each of these steps in more detail, starting with software simulation. In this part of the workflow, we'll work purely in a Simulink environment, simulating our entire signal chain starting with the RF transceiver. Our system will use the Analog Devices AD9361 RF agile transceiver, which Robin gets from Analog Devices we'll now describe.

So what we're going to talk about today is the 9361, 9364. This is a complete RF transceiver. It's 70 megahertz, a 6 gigahertz tuning range, and 200 kilohertz to 56 megahertz of channel bandwidth. So it's incredibly wide band, incredibly wide tuning range, incredibly integrated. So everything you see on the screen is integrated into a single 10 by 10 package, two complete receiver chains, and two complete transmit chains for the 9361.

So what we have is a complete LO generation from a single crystal, so it drives our VCO. That in turn drives our receive PLLs, transmit PLLs, baseband PLLs, complete ADC/DACs, digital filters, digital interface, enable state machines, a very complex automatic gain control that can be operated in multiple different modes, from fast attack, slow attack, to manual mode.

And one of the things is, when you talk about integrated systems like this, is can you actually achieve the performance that you would in a discrete solution? And we can in this kind of device because of the digital and analog calibration and correction that we do internal to the device.

So again, if you look at the parts, it has many stages of programmability in it. And just from the analog receive path, we have our transimpedence amplifier, we have our low pass filter, we have our half bands that can be used to divide the ADC rates down. We have programmable FIR filters. And when we're looking at things we need to understand with great programmability becomes great confusion.

So when we talk about 1,000 ways, or 1,000 spy configuration registers, it's basically 999 ways to make it wrong, and only one way to actually make it correct, and work properly, and get the performance you're looking for.

Thanks, Robin. To help you get it right, programming the AD9361, bat365, in conjunction with Analog Devices, built a behavioral simulation model to give RF and system designers visibility into the entire RF signal chain. This lets you understand exactly how your algorithm will perform in a real hardware environment.

This is a true multi-domain system level model that accurately represents the behavior of the AD9361, giving users access to all of the programmable features available to them on the actual silicon. We won't have time in this presentation to explore the model in too much depth, but we will provide a link to more detailed information. For the sake of this example, we'll be looking at just the receive path of the AD9361 transceiver model.

You can see here all of the major components of the device are represented in Simulink, incorporating state flow charts to model the automatic gain control, and SIM RF blocks to model the RF portions of the transceiver. For this discussion, we'll be using a QPSK receiver as our example processing algorithm. Let's take a look at how we can model the processing.

Here we have our QPSK system running in Simulink. As you can see, we have our QPSK transmitter connected directly to our QPSK receiver. This is where you would start in your design process-- purely algorithmic simulation with ideal sources providing your inputs into your model.

Now let's take our modeling a step up and let's introduce the model of that AD9361 RF transceiver into our system so we can see the effects of that device on our simulated signal. We'll now elaborate our system model to include a model of the receiver section of the AD9361, along with some controls for input signals, like the addition of a continuous wave source to better mimic potential real-world implementations.

We're still using the same QPSK receiver model that we saw in the last example. But now we can see how changes in transceiver settings and system conditions can affect algorithm performance. For example, we can adjust the level of our QPSK transmit power relative to our CW power and see how that affects our receive signal.

Looking inside the AD9361 receiver, we start to understand the complexity of the device, but you also gain the ability to inspect the entire signal chain--something that's not possible with hardware alone. Again, we'll provide you with links to more in-depth discussion of the simulation model, but I did want to highlight some of the main sections of this model, including the AGC, which is implemented as a state diagram in Stateflow. Your gain tables, which you have the ability to edit. Again, providing that fine control of the device. Your RF receive section, where you can get as deep in there as you want into the de-modulator. These are all modeled in blocks from our SIM RF libraries. And then several programmable filters on the receive side, and our digital down converter.

And all these filters are configurable through the use of the AD9361 filter wizard, which is a MATLAB app that's available from Analog Devices. So the filter wizard lets you specify all your filter parameters that you can then download into your model to fine-tune the operation of the device.

Now that we've seen our algorithm work in simulation with simulated data, we now look to verify the operation of our algorithm using real data streamed from the AD9361 into MATLAB and Simulink. We can think of this operation as radio-in-the-loop simulation. Using the Zynq SDR support from Communications System Toolbox, you can stream data from the AD9361 into MATLAB and Simulink. The support package allows you to control transceiver parameters.

In this part of the workflow, there is no code running on the Zynq. All of the baseband processing is happening in MATLAB and Simulink, with the ARM core on the Zynq packaging data for streaming over Ethernet. Here's our QPSK receiver, which looks very much like the QPSK receiver model we looked at in our last example, except now instead of connecting it to a model of the AD9361, I'm going to connect it to this SDR receiver block. And this SDR receiver block is what sets up my communications link between Simulink and my Zynq target hardware.

I'm going to make one change to this model. This is our shipping example, and it doesn't come with a constellation plot. So I'm going to add in a constellation plot from our Communication System Toolbox. So we're going to bring that in so we can just see our data, another visualization of our data. We are also going to be transmitting messages from our transmitter--that "Hello, World!" message that we saw in the previous example when I opened up my MATLAB screen.

And what we're going to do now is we're going to run this model. On the other side of the room I've got another Zynq-based SDR kit running a QPSK transmitter, and we're going to see if we can capture that data, which we have. And if I open up my MATLAB window, we can see the Hello Worlds that are being transmitted and picked up by this QPSK receiver.

In this example, we're not running any of the QPSK algorithm on the Zynq device. The algorithm is running purely in Simulink, but the data is coming from the AD9361. We can see what happens now when I shut my transmitter off to show that we are, in fact, receiving real data live over the air. So let me shut off my transmitter. And we can see that my constellation is gone. I'm not receiving anything anymore.

Now that our algorithm has been verified with real data, we can generate HDL code targeting the programmable logic on the Zynq SoC to implement our design. Here are some of the steps that need to be taken to generate good HDL code from your Simulink design.

First, you need to create a floating point reference. Convert that floating point reference to fixed-point data types. Elaborate your design for more efficient hardware implementation. Generate and synthesize HDL code and then explore various HDL optimizations and verify your code.

The first step we've already done. The QPSK receiver model we've been looking at during this presentation is our reference implementation. We now need to make some changes to make it more HDL friendly.

So that we can implement our model on an FPGA, we first need to convert it to work with fixed point data types. bat365 provides a number of tools within Fixed-Point Designer to help automate and streamline this task. When completed, you'll want to simulate the fixed-point version of your model to see how it matches the floating-point simulations you've already done.

Another critical step in making the model HDL friendly is to convert how we process incoming data, which for the most part has been frame-based up 'til now. We need to convert the architecture, use sample-based processing, and look at the elements of our model that we may want to modify to be more hardware friendly. And again, re-simulate and compare against your earlier model elaborations to maintain continuous verification.

This slide shows what we can do in the QPSK transmitter to produce streams of data. And on the receiver, we can modify elements like coarse frequency compensation for more hardware implementation-friendly architectures. All of which results in an HDL-optimized QPSK model.

Here we have our HDL-optimized QPSK receiver example, with the various blocks implemented in a more hardware-friendly fashion. Now that we have an HDL-friendly version of our model, we can now generate HDL code and deploy it on the target. The first step is to generate the HDL code, and we'll do that using the HDL Workflow Advisor.

This is my HDL Workflow Advisor, and it's going to take me step by step through the process for generating code for my model. I've already set my targets and my SDR options; in this case, we're targeting an SDR platform. The next step is to check my model to make sure that it's valid, uses valid blocks for HDL code generation.

So what we're going to do is we're going to run through all of those model checks just to make sure that everything is good. Now that our model checks are complete, we're ready to generate HDL code. There are a lot of options that we can choose from for optimization. And we have some basic options for reporting that I'm going to choose so that we can take a look at some of the features of our code generation afterwards. Now we'll go and generate our HDL code.

Our code generation is now complete. And let's take a look at some of the reporting that we've asked for. So the first thing we can get is a code generation report for the module that we've generated code for. And this is great. This tells you all about how you're targeting the device. You have Resource Reporting at a very high level to show you how much of your FPGA, roughly, you're going to utilize.

We also have the ability to trace our code. So the beauty of this is that you can go from code to model and model to code so you get full traceability. If you want to see what your HDL looks like, you can click on any of these hyperlinks and it'll take you back to the block in the model that generated that code.

Similarly, you can go to any block in your model and navigate to the code that was produced by that block. This is very handy when it comes time to doing things like design reviews; or if you have to worry down the line about standards compliance, this is a traceable workflow.

The next steps in our process, unfortunately we don't have time to show in this presentation. And those would be to create and synthesize a Vivado project within Simulink and then create the IP core for use with the PicoZed SDR reference design in Vivado. This uses our IP core generation workflow to target the Zynq-7000 SoC.

We also have a lot of options for optimizing HDL performance. When we generated our HDL code we chose All System Defaults. In a real-world situation, you would probably start using all defaults, see how fast your application is running, and then start looking at various optimizations for speed and area to get the best possible HDL code generation.

We were really only able to scratch the surface of the SDR design process in this discussion. If you're interested in more in-depth training, Avnet, along with bat365, Analog Devices, and Xilinx are offering a series of two-day hands-on workshops to be presented in select cities worldwide. These workshops will take you through the entire design process that we outlined in this webinar, from design to production employment using MATLAB, Simulink, and the PicoZed SDR SOM.

More information is available at picozed.org/sdr. If you don't see a workshop scheduled in your area, please either contact your local Avnet representative, or you can contact us at fpga_expert@bat365 to discuss alternative training arrangements.

To fully understand the HDL code generation process and the SDR design process, there are a number of topics that we can go into in more depth. These links will be sent to all webinar registrants in a follow-up email. And they include resources on Zynq workflow and Zynq training, a more in-depth analysis of the AD9361 simulation model, along with information on the IP core generation workflow. As always, you can contact us at fpga_expert@bat365. Thank you.