Hardware/Software Co-Design Workflow | Developing Radio Applications for RFSoC with MATLAB & Simulink, Part 1
From the series: Developing Radio Applications for RFSoC with MATLAB and Simulink
Target SoC architectures like Xilinx® UltraScale+™ RFSoC devices using Model-Based Design. With the workflow featured in this video, you can evaluate how algorithms will perform on hardware/software platforms such as Xilinx RFSoC development boards.
This first video in the series, learn about Xilinx UltraScale+ RFSoC devices and their applications in wireless communications, aerospace and defense, and test and measurement. Discover a new workflow spanning modeling and simulation through application deployment.
An example of hardware/software coprocessing illustrates the design choices required to develop algorithms for the RFSoC hardware/software platform and lists the hardware boards supported by this workflow.
Published: 7 Jan 2021
In this video series, you will learn how to use a model based design approach to develop radiofrequency applications for the Xilinx RFSoC platform. In this first video, we'll do a brief overview of RFSoC and introduce the hardware-software co-design methodology and workflow for implementing algorithms on system-on-chip devices. Now, if you are a hardware designer, an embedded software engineer, or a systems engineer, one thing you may have asked yourself is, how can I make design decisions before touching the actual hardware.
And this is a challenging problem. Ideally, you don't want to wait until you've completed the design to find out that you wish you would have made a different design earlier on in the process. And so this is the question we're going to be keeping in mind throughout this video series, and we're going to look at how you can address it using some of the tools in MATLAB and Simulink.
Now, briefly, just an overview of what the RFSoC device is. It's a system-on-chip device from Xilinx, which contains an integrated FPGA, ARM processing core, and RF-ADC and DAC channels, up to 16 by 16 in the latest Gen3 devices, and 5 and 10 gigasamples per second, 6 gigahertz of direct RF bandwidth. It's a very powerful device.
Some of the benefits of using this device instead of separate components when developing your system would be reducing your power and footprint by having a single integrated package. It simplifies the interfaces between the processing system, programmable logic, and the data converters. And then finally, it shortens your development time in large part due to the simplified interfaces between the components.
Now, RFSoC is being used in a variety of applications, from 5G and LTE wireless communications, aerospace and defense, tested measurement equipment. It's a very popular device right now, and one that is being used for very high performance radiofrequency applications. So the bottom line here is that this is not a hobbyist part. It's a very complex device, and your key to success is going to be a design methodology that integrates the hardware, software, and RF components all together at the system level.
A common way to do this is through hardware-software co-design, and what defines hardware-software co-design is that we take a single top level system specification and use that to inform the design of the hardware, software, and the interface between those components all at once, rather than coming up with separate specifications for the hardware and software and interface and going through the design process separately. Some of the common challenges with hardware-software co-design will be things like, especially in this algorithm partitioning area, how do you decide what runs on the processor versus FPGA? What part of my algorithm needs to go where?
How does the interface bandwidth affect my system performance? So it could not just be the implementation of subsystem in hardware-software that's going to be your bottleneck, but rather the communication between those domains. And then finally, how do you identify where those bottlenecks occur? These are all challenges that we have commonly with hardware-software co-design. And so let's now take a look at a common paradigm here with hardware-software co-design and see some of the typical pitfalls when simulating such a system.
So this is a very common design pattern here, where you have one algorithm mapped to the FPGA component in your system producing data at some high rate, a period on the order of nanoseconds. And streams that data through a shared buffer space to the processor, where it's consumed by a second algorithm or second component, and this algorithm is running at a different rate than the FPGA. It processes data on a frame rate, which would be likely on the order of a millisecond period.
Now, you can model that communication between these two domains as just a simple buffer and rate change. That's one way to do it, but in practice, you are not accounting for the behavior of the actual hardware. You might find that, when you actually go and test this, data is being dropped, or your ARM processor is not able to handle the throughput of the data from the FPGA all because of factors that you didn't consider in simulation.
If we look at a more realistic picture of what's going on under the hood, the way this is going to be actually implemented is that buffer is going to look like a shared memory device with managed sub buffers inside of that memory. And you'll likely have a FIFO on the FPGA that is used in between the memory interface and your algorithm. On the software side, there's going to be a device driver likely handling the DMA transfer that's actually doing the memory read and feeding it to your algorithm. And then oftentimes, if you're in a larger system, there's going to be other memory readers and writers vying for access to the DDR, and then on the processor, other threads and processes, especially in an operating system context.
Along with that, that introduces things like back pressure, contention, and a number of design parameters that you have to determine. What is an acceptable data rate for the algorithm on the FPGA? What should my burst size to memory be in order for me to not drop any data at the memory controller interface?
How many buffers do I need to allocate in memory, and how do I synchronize my data on the software side with the execution of my algorithm task? These are all hidden parameters that we didn't see with our simplified buffer model I showed just a minute ago. So how do we think about these parameters and actually determine them upfront through simulation and modeling rather than through testing on the hardware after it's been implemented?
A tool that we have in MATLAB and Simulink is called SoC Blockset, where we can use this to answer some of those questions. And the goal of this tool and workflow is to accomplish system level design through modeling and simulation so that you can answer these system level questions for hardware-software co-design early on in the design process so that you can analyze performance of your system, make tradeoffs early on. With SoC Blockset, we could also use several on device profiling tools to characterize the hardware and verify your simulation numbers, and this tool also integrates well with our HDL and C-code generation tools for a seamless process from simulation to automatic code generation and deployment.
Now, with SoC Blockset, there's a number of development boards that are supported out of the box-- common Xilinx and Intel SoC boards. And one of those boards is the ZCU11 RFSoC evaluation kit, so that's a Gen 1 RFSoC device on there. And you can get up and running with that board and device out of the box with SoC Blockset, so you can take your algorithms from concept to prototype very quickly.
So this concludes this first video. In the next video in this series, we're going to look at a real world application in developing a Range-Doppler radar system with RFSoC. We'll see how to take high level specifications for that system and use those to make system level engineering decisions using modeling and simulation.