software-凯发k8网页登录

welcome to the mathworks webinar on software defined radio development using matlab and simulink. my name is vidya viswanathan, and i'm an application engineer at mathworks india specializing in wireless design and fpga implementation. in case you have any questions about the content being presented, i request you to post them in the q&a window that you see in your webex window. we will take a couple of minutes at the end to address these, or we follow up with you on your query.

in case you are facing any issues with the logistics, you can reach out to us in the chat window. during the webinar, there will be a couple of poll questions that will pop up on your screen. i request you to keep a lookout for the poll questions towards the right side of the webex window. with this, let's get started with the session.

so what is a software defined radio system? if i had to put it in simple terms, a software defined radio is one in which the physical layer functionality are software defined or software programmed. the programmability of sdrs enable upgradation to the design at any point in time, the addition of new functionalities, as well as the reuse of algorithms.

so here is how we view an sdr system. there is an analog front end doing the direct rf conversion with local oscillators and mixers. there are data converters to get the data in and from the digital domain. and you have the digital front end of the sdr, which is responsible for high rate digital signal processing algorithms like digital up-conversion down-conversion, iq balance, dc offset correction. and then you have the baseband processing with the iq data amendment.

we think that such a system can be built out of commercial, off-the-shelf hardware. here's an example of one such system. you have an fmc-based tunable rf card connected to the fpga evaluation board, which is in turn connected to the desktop computer running an environment like matlab or simulink, using an interface like the gigabit ethernet, which you can use to tune rf parameters like the center frequency and rf tilt.

so why is it important to actually look at the implementation workflow for software defined radios because radios have been around for a several number of years now? so in addition to the traditional applications where radios were used, there is a rapid growth in the new application areas of wireless communication. with everything getting connected, even the non-traditional applications, like public safety, surveillance, medical monitoring, agricultural monitoring, smart meters, have started to use cutting edge wireless technology. in addition, the emergence of new wireless standards, like 5g, lte, and v2x, are enabling this too. however, this requires higher adaptability from the system and a need to quickly design, simulate, and prototype radios. in this regard, software defined radios can be considered as a perfect fit for these applications, yes.

as appealing as the idea of sdrs sound, there are also several challenges involved in developing such system. given the nature of sdrs, there are a number of different skill sets that are required for creating a robust system, ranging from baseband dsps, rf and antenna analysis, hardware and software architecture design, fpga or hardware design, and embedded software development, to name a few. each of these is a domain by itself, and the skill sets that are required and the design environment that are being used for each are very different. so it is practically difficult for one to be an expert in all of these areas. therefore, there is a need to have a common design environment that can address multiple domains and also allow the experts in each field to collaborate easy. that is the idea behind this session, to see how matlab and simulink can act as that common development platform.

before we get started with the work flow, here is an example of how an organization like orolia used mathworks' model-based design workflow to develop a receiver for emergency locator beacons. while they have a lot of experience and expertise with respect to the communication system design or the domain, they had limited experience with fpga design. so they understood that this would actually take a significant amount of the design time, and it would also have an impact on the time that they were able to come up with the first prototype. so with the help of simulink and hdl coder, they were able to reduce the fpga implementation time by 50%, giving them more time for rapid algorithm innovation and technological advancements, while still able to meet their tight deadlines with ease.

so let us look in more detail the workflow that is involved. so you can broadly define the stage of software defined radio development into four aspects. system modeling, that involves the simulation of the entire system to identify the potential design issues only. once the algorithm has been developed, they can be tested with real signals by integrating matlab and simulink to do the hardware front end. once you use that to gain the confidence with respect to the algorithm that is developed, the next part of the design process would involve hardware and software development for prototyping and rapid verification with the verification infrastructure or the framework within matlab. and the last part of the process would involve the standalone development of the hardware and the integration with the peripherals.

so let's look in a little more detail the first step, that is the modeling and simulation of the entire signal chain, the baseband, the rf front end, as well as the test framework. matlab and simulink provides a wireless designer the ability to model multi-domain system in a single environment, therefore allowing the user to analyze the interrelationship between the different components and how one affects the performance of the other system. you have a host of waveform generation capabilities as well as algorithm development capabilities within matlab and simulink in the form of library functions as well as blocksets.

you can design and architect your rf front end and include the effects of nonlinearities in your system. you can also design your data converters, like the analog to digital converters or the dacs, and finally integrate the sim with the effects of antenna as well as the propagation channel. so matlab provides a rich set of library functions and graphical user interface to generate the standard compliant waveforms for different wireless standards, like 5g, lte, wlan, zigbee, nfc, as well as bluetooth low energy. you can also reuse this framework to design custom waveforms and provide parameterizations for them.

the processing ability within matlab and simulink also enable you to do the complete physical layer development starting from the waveforms generation, including the effects of channel and the rf impairment and design of a practical receiver. there are several set of examples for the end-to-end link level simulation for standard as well as non-standard-based wireless systems that you can use as a starting point for your algorithm development. these are all available in the form of matlab code and simulink models that you can easily configure and modify based on the system that you are making.

the fidelity of the system or the end-to-end simulation, link level simulation that you have created can be further improved by integrating the physical layer design with the behavioral aspects of rf front end. the introduction of the rf front end models enables the user to develop more practical and robust receivers. the rf front end is simulated through rf blockset, and you can use this framework to perform a closed loop simulation of the baseband with the rf front end by integrating matlab and simulink and running the complete chip.

there is also a set of modules that are available and simulink models available for commercial, off-the-shelf rf front end transceivers, like the analog devices ad9361 and ad9371 transceiver. these behavioral models have been tested against the actual hardware setup in a lab kind of an environment, and we have been able to correlate the results between the simulation model and the hardware model. therefore, if you're working on sdr platforms which involve these rf transceivers, you can directly plug in these models into your baseband algorithm.

there are also a number of reference examples that show how you can connect your baseband processing with the transceiver models. let's look at an example now. i have here a qpsk-based transmitter where the baseband algorithm is defined in simulink, which is connected to the transmitter model of my ad9361. then there is a channel representation which is also in turn connected to the ad9361 receiver, and the algorithm for the demodulation happens there. and you're seeing the constellation as well as the error rate estimation.

so a closer look at the ad9361 receiver architecture actually gives you the insight that this particular model actually has the complete architecture of the transceiver model, including the rf front end, the series of analog as well as digital filters, and the analog to digital converter, and the agc that is present in the ad9361 transceiver. if you're interested, you can download these models of the rf transceivers in the link that you see on the screen. in case you're working on custom rf front end design, there are multiple examples that show you how you can simulate the practical radio with the rf transmitter and receiver models, and again, these examples range between lte, wlan, 5g, as well as non-standard protocol-based radios as well.

so let's move to the next part of the sdr design, which is validation of the algorithm with streaming rf data. so here, what we see is the baseband processing and the test infrastructure is still with within matlab and simulink environment. however, the data that i'm actually feeding to test my baseband processing is coming from a real life scenario.

so you can connect matlab to several rf instruments and sdr platforms directly for over dl testing of the radio with real signals. you can get a near real time streaming of the rf data into matlab, and the reason i say near real time is because you would be limited by the interface transfer rate and the host computer's performance. but you can bring in a continuous burst of data and then use that for further algorithm design or downstream analysis. so this helps you validate your design even before you start looking into the hardware and the software aspects of the design. and this is enabled through system objects and blocks that help you connect easily to different sdr platforms and also tune the radio parameters.

let's see an example of how an fm broadcast signal can actually be captured by an sdr platform and brought into matlab. so the first step would involve configuring or connecting to the radio hardware. so you have a function to connect to the hardware. you can then start configuring certain parameters, like the center frequency, the baseband sample rate, as well as the data type of the samples that you're receiving, and then use the captured function to actually record the data into either a file or into a variable in the matlab work space.

so what i'm doing in this case is i created a file where i captured the fm signal. once i have that file present, i can import that into matlab using the baseband file reader. and then once it is brought into matlab environment, you can use this for doing any kind of analysis, or you can also pass it to your receiver.

so here, i created a spectrum analyzer, and i'm actually going to look at the frequency of the received captured fm bank. so you can see in this view that there is a spectral view as well as a spectrogram that you're observing with respect to this signal. the same thing can be replicated for an lte signal which you can capture from the real scenario into matlab environment and perform the cell search.

so again, similar to what we saw previously, i'm first connecting to the radio object. then i'm using the capture function to get the received waveforms, and i'm collecting it for a couple of seconds. and then i'm actually using the functions with an lte tool box to actually do the cell search and figure out what is the cell id of the signal. so you can see that the detected cell id or the recorded cell id actually matches what i was expecting or what i was looking at receiving. so this helps you validate if the algorithm that you developed is robust enough and whether any further modifications are required to be able to adapt to the real impairments that are introduced by the cell.

so let's actually see what are the different sdr platforms that are actually supported for this radio streaming as well as capturing of rf signals within matlab environment. you can see the list of the sdr platforms here. if you're also interested in understanding more on the specifics of these configurations, i would request you to actually click on the link, which contains the link to the support package.

all right, so now, we have looked at two different aspects with respect to sdr design. one was the compute system modeling and the second one was algorithm and validation with real life signals. so let's move to the next aspect of the sdr development, which basically involves partitioning your algorithm into hardware and software components and then start prototyping on the implementation platform, which could be either an fpga, or it could be a system-on-chip platform.

so this involves the design of rdl code for targeting your fpgas, as well as c code for targeting the processor and to be able to communicate between these two as well as with the rf front end, to do a complete implementation or prototyping on any of these standard development ports. so if you actually look at the wireless reference algorithms that we were developing up to this point, the frameworks that we used for the development of these reference algorithms are quite different from what a hardware implementation engineer would actually be looking at. so what i mean is that if you consider the wireless reference algorithms that we were previously building, it was mostly working on a vector of data or a frame of data. we assumed that we had a compute chunk of data available with us. and most of the operations that we were performing were on floating point precision.

whereas if you look at the hardware implementation side, it is important to understand how you're going to be working with streaming bits as the data samples keep coming in and also how you can work with fixed point architecture. so there is a disconnect between these two aspects, and what we will be looking at is to figure out a way to actually smoothen this transition from the wireless reference algorithm to the hardware implementation. so this would involve a couple of intermediate steps, which is what we're going to be looking at in a little more details.

so if you actually look at the workflow that is involved with respect to the wireless algorithm design, you can-- the first step would involve categorizing the whole aspect into three different parts. the first would be the stimuli. the second would be the reference algorithm. and the third part will be whatever verification or analysis that you want to do with the results. so i can write a test script, or i can use the existing examples within the matlab framework to create different kinds of waveforms that i feed into my reference algorithm. and then i can use again the matlab environment for either visualizations, or i can use that to get the error matrices.

so now, the important aspect that would come into picture to make this a little more representative of what actually gets implemented on the hardware is to translate this reference algorithm into a sample-based or a stream-based process. this is where we make use of a combination of matlab as well as the simulink environment. matlab, being more script-based, is well suited to work with large matrices of data. and simulink, since it works on the basis of a software and has the notion of time built in it, it can be used to better represent the sample-based process.

so we are going to be looking at translating the reference algorithms into the sample-based processing and start bringing in the streaming nature and modify the algorithms accordingly. so another important aspect, when you're working with the streaming data, is to be able to figure out at what point you're actually starting the ballot samples, and at what point you're ending the data, and in the middle of all of these, how many of those have been valid samples. so we can create those control signals, which will also help you with the comparison against the matlab golden reference.

so once i have architected my model in such a way that it actually considers some of the hardware aspects in the picture, the next step that is involved is the fixed point quantization. matlab and simulink allows you to modify the data types of your signals from floating point, which is the default data type, into fixed point representation, which is suited for the hardware architecture that you're looking at. it's important to choose the right set of fixed point data types because this not only controls the accuracy of your algorithm, but it also controls the amount of resources that it's going to occupy on your fpga platform. with the help of fixed-point designer, you can convert the matlab and simulink floating point algorithms into an equivalent fixed point representation. and at each stage, you can compare it against the golden reference that you're starting with to see what is the amount of quantization introduced and whether that is within the error tolerance that you're looking for.

so with respect to wireless design, one of the ways in which we have tried to ease this process of transitioning your reference algorithms into a hardware-friendly version is by the introduction of the wireless hdl toolbox, which basically consists of hardware ips for streaming-based wireless design, which works in such a way that they're very friendly on the fpga architecture. and we also have a set of reference applications that you can use as a starting point for different standards, 5g, lte, wlan, or any custom configuration. and you can create your reference simulink model using the blocks within the wireless hdl toolbox. and the advantage of that is once you have created this system and compared it against your initial reference, you can use code generation techniques to actually generate the synthesizable open rtl code from within this environment.

so just like how we have looked at the elaboration with respect to the fpga aspect, simulink can also be used to represent the software aspect. so if you actually look at the model, and i'm just simplifying it into two aspects, algorithm one is what is going to be targeted on the fpga. and algorithm two is what is going to be on the processor.

so from this model, with the help of hdl coder and embedded coder, i can generate the corresponding programming language, the hdl verilog in case of hdl coder and cc code in case of embedded coder. and if you actually look at this representation, this is a form where we have translated the algorithm which was at the high level representation like simulink into a code which is one step towards hardware implementation. but if you look at the ultimate hardware platform that you're going to be running this, there is another important aspect that actually comes into picture, in addition to just the fpga and the processor aspects, which is the interconnects between these two and the peripherals.

so the effect that these interconnects can have is pretty significant on the algorithm design. so although there is a direct transition from the algorithm model to the algorithm code, this code may or may not work directly when just directly plugged into the hardware environment because of some of the effects of these interconnects. so the idea is to bridge this gap of transitioning from this algorithm model into a more closer representation of what my hardware platform would look like, and that is primarily what we're going to be looking at in the next aspect.

in addition to your fpga algorithm and your processor algorithm, simulink allows you to also simulate the interconnects between the fpga and the processor. so if it is interacting with an external memory environment, what are the latencies that are introduced in that case? if you're working with axi-based registers, again, what are the different configurations with respect to that? what are the i/os that the fpga and the processor are interacting with? all these aspects can actually be simulated first, along with your algorithm. this gives you a more realistic view of what you're going to expect from your hardware, and this is enabled to soc blockset.

the different steps that are involved in this process would be simulation of the hardware architecture, along with the algorithms, then deploy it on the prototyping fpga or soc platforms. and the third step that can also be done is to profile the results from the hardware and bring it back into the matlab simulated environment to actually understand what was the effect of the os or whether there was actually real stream detail of the input, output samples and how much was the core algorithm actually utilizing in terms of the resources. so if you've been able to simulate this entire system, and then if you go in for the code generation process, you can be a little more assured that what you can expect out of the hardware, you've actually identified some of those potential issues and corrected those in the algorithm.

so the next aspect would be to come up with a standalone implementation of this review, where you're not only taking into consideration the algorithm aspects, but also the interconnects. and this is enabled through reference designs. so let's actually look at an example of how such a system and be developed, by looking at a simple model.

the example that i'm considering here is a 5g cell search reference application. so you can see that one important aspect would be to create the 5g reference waveform, which you can easily do with the help of 5g toolbox. then you would have to define or architect your cell search algorithm which is going to be running on your own hardware, and there could be certain portions which would run on your software.

so in this case, i have a search control algorithm which i'm running on my software, which helps me choose the strongest ss block and also correct for the frequency offset and help determine the cell id. so the software component actually provides as an input to the fpga, the frequency offset as well as the subcarrier spacing. and decoding of the demodulation to actually find out the sss, pss, as well as the cell id, is actually implemented in the hardware aspect, which is the fpga code.

so like i mentioned previously, you can use the reference example within the wireless hdl toolbox, which consists of a simulink model that actually does the complete cell search. this simulink model can be tested with the data stimulus from the matlab environment. so you can create a series of test waveforms using 5g toolbox, feed that into the simulink model, and do a comparison of the results that you are getting from the matlab golden reference as well as the simulink model. and the reason this step is important is you can actually see what is now the effect of the latency as well as the quantization that your fixed point architecture is going to bring into picture. and there are a whole set of intermediate signals that you can actually tap, and you can do the edit analysis or the comparison between these.

so once you have tested this particular algorithm with the simulated set of data, the next step that is involved is to include the simulation of the architecture aspects, and if possible, bring in the capture of the rf signal from the livestream. so what we see here is a model of the nr cell search algorithm, where the same fpga logic consists of the receiver algorithm. i'm also having the processor module, the memory interface simulator, as well as the rf data converter. so this is representative of a xilinx rfsoc architecture.

so if you actually take a closer look at the fpga part of the subsystem, you can see the simulink model for the cell search receiver, and you can observe that this is a model completely using fixed point representation. and this basically gives out the cell id that you're detecting. so this the processor part of the model, which consists of a task manager as well as the ability to send the data into the host computer. so now, i can simulate this entire system, which is basically consisting of captured rf data and the algorithm, to see at what point the pss is found or the sss demodulation is done. and this also includes, in addition to just the algorithm aspect, some of the latencies that are introduced because of the memory interfaces that are also being used.

so now, i've kind of simulated the entire system and gotten confidence with respect to the complete development of what i can expect from my hardware environment. so the next aspect involved in this process would be to implement this on the hardware. you can target different fpga and soc platforms with the help of the reference designs that we provide in the hardware support package.

you can see the two links on the screen here. this consists of the reference design for a different set of hardware, and this basically helps you then pick not only the algorithm code that you generate from the code products but also integrated with the rest of the design, and you generate a bit stream for the particular hardware that you're looking at. in this example, i've actually programmed the rfsoc by connecting to this front end simulink model and directly running the hardware as well as the software aspects on the rfsoc hardware.

i can also use this to actually plot certain signals and actually understand the hardware state for the pss search and demodulation. so this is data from the hardware that i'm probing back. and you can also see that the processor sends in the decoded cell id as well as the pss and sss snr values, which i'm visualizing back within the matlab environment by using the udp receive block. this helps you with the complete prototyping and development framework with respect to sdr platforms. i have taken as an example rfsoc, but like i mentioned previously, there are a whole set of hardware that we support in this workflow.

so before we look into the different platforms that are supported, i also wanted to bring your notice to another customer success story. rf pixels used this particular workflow for targeting their lte reference algorithms on the zynq rfsoc hardware. again, with the help of hdl coder, they were able to reduce the time to actually come up with the first prototype, and they were able to do the iterations of the design much more easily and quickly, thereby reducing the iteration times from weeks to days. there is also a link to this particular article. if you're interested in knowing a little more details about how they used this workflow, you can look at that.

so here is a snapshot of the different sdr platforms that we support for targeting. when i say these are the supported platforms for targeting, what i mean is that in addition to the algorithm code, for these particular hardware platforms, we have the reference design available. however, you can also use the generated code. and if you can create or integrate with a custom reference design, you can also reuse this framework for targeting custom sdr platforms as well.

to get started with respect to the sdr development, we, again, have a number of reference applications that we have put together. depending on the scale of the system, these can be implemented on different hardware environment. so you'll see a whole set of 5g, or lte, or qpsk-based system that are being modeled and tested on either rfsoc or the zynq-based sdr system.

if i had to summarize, we have seen in this particular session how much matlab and simulink can act as this unified platform for wireless development, which involves the design of the algorithm, which will be the baseband, rf front end, antenna, and the channel effects. you can then validate this algorithm by connecting to real instruments or the rf test instruments and sdr platforms, through the integrated workflow that we have and the support that we have to connect to these hardware. and once you have validated your algorithm, you can then use the code generation technology to actually target the algorithms that you have developed onto fpga, or a processor, or a system-on-chip environment.

so if you're interested in knowing a little more about the model-based design workflow that i covered for a software defined radio development, you can actually visit the sdr page within the mathworks website. this has a set of white papers, videos, as well as reference examples that you can use to get started with this workflow, and it will cover all the aspects that you just looked at in this webinar. if you're working with rfsoc development board, we have a dedicated page to actually talk about the way in which we support rfsoc platforms. so again, the link of that is provided, and we can see what are the reference examples that are available in this and also what kind of support we offer with respect to the rfsoc targeting.

and if you want to get a more hands-on experience with this particular workflow, we have a range of training that we offer. these are hands-on training which ranges from the wireless communication algorithm design, or it could be on the hdl code generation part, or it could be on the software development or the customization of the linux os or this complete software defined radio on zynq platforms that we just looked at. and if you're interested in customizing these training courses as per your needs to make it more suited for the requirements that you are working on, i would encourage you to contact the training services team within mathworks, and the link is provided there to reach out to them.