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.