In this week’s podcast, we’re diving deep into the world of RF system design! My guest is Giorgia Zucchelli from MathWorks. Giorgia and I explore what an RF digital twin is, how it revolutionizes the design and validation workflow, and how AI is playing a critical role in its development.
Links for May 8, 2026
MATLAB and Simulink for Wireless Communications – general overview of tools and applications
Digital, RF, and Antenna Design – offers a comprehensive overview of joint optimization from antenna to bits
International Microwave Symposium (IMS) 2026 – an overview of MathWorks at IMS 2026
What Is mmWave? – an overview of mmWave
Click here to check out the Fish Fry Archive.
Click here to subscribe to Fish Fry via Podbean
Click here to get the Fish Fry RSS Feed
Click here to subscribe to Fish Fry via Apple Podcasts
Click here to subscribe to Fish Fry via Spotify
Amelia’s Weekly Fish Fry – Episode 681
Release Date: May 8, 2026
Hello there everyone. Welcome to episode number 681 of this here electronic engineering podcast called Amelia’s Weekly Fish Fry, brought to you by EEJournal and written, produced, and hosted by yours truly, Amelia Dalton.
Today, we’re diving deep into the world of RF system design. We’re going to discuss why system integration has become the single highest-risk phase in RF programs, and why traditional RF, EM, and signal-processing tools just aren’t cutting it when it comes to full system visibility. The solution? A new paradigm: the RF digital twin.
My guest this week is Giorgia Zucchelli from MathWorks. Giorgia and I explore what an RF digital twin is, how it revolutionizes the design and validation workflow, and how AI is playing a critical role in its development.
So without further ado, please welcome Giorgia to Fish Fry.
Amelia: Hi Giorgia, thank you so much for joining me.
Giorgia: Thank you for having me.
Amelia: Absolutely. Okay, so we’re talking all about RF system design today. But first, Giorgia, what do you think is driving the recent increase in complexity in RF system design?
Giorgia: Yeah, it’s a huge trend, and it’s really something that we are experiencing almost every day. RF systems are no longer single-purpose designs. They are highly reconfigurable, multi-mission platforms where performance depends on the interaction between the hardware, the digital signal processing, the algorithms, and the environment where they operate.
There is also a major trend pushing RF toward higher and higher frequencies. For communications like 5G and 6G, we are talking about FR3 — around 10 GHz — and more and more applications are moving toward the millimeter-wave range: 20, 30 GHz, and even up to the sub-terahertz range.
So, higher frequencies, larger bandwidths, and also the trend of packing together more and more antennas. We now have highly reconfigurable systems with higher frequencies, larger bandwidths, and more antennas. This means a lot of headaches for system designers and RF designers because these platforms are extremely complex.
We’re no longer talking about individual RF components — we’re really talking about platforms: beamforming platforms, active electronically scanned arrays (AESA), and systems that are modular, programmable, and reconfigurable, with thousands, if not millions, of possible states.
Typical designs are made of tiles that can be combined to extend the size of the phased array depending on the application designers are targeting. For example, the same platform can be repurposed from radar systems to satellite communication systems.
This is amazing because system integrators — whether they are building radar systems, satellite payloads, or base stations — can use one architecture and retarget it through software to support multiple modes, communication standards, and operating environments. So it’s essentially one hardware platform to serve them all.
This hardware flexibility enables faster time-to-market, multi-mission systems, and simpler lifecycle management once the products are deployed. However, there is another side to the coin: this flexibility makes design-by-prototyping impractical.
Back in the day, a lot of RF work was done in the lab by tweaking, tuning, and turning screws. Nowadays, because systems are so highly reconfigurable, design-by-prototype simply isn’t possible anymore.
So all of these parallel trends make the life of system designers very interesting — if not complicated.
Amelia: So Giorgia, why is system integration now the highest-risk phase in RF programs?
Giorgia: It’s because these systems are highly reconfigurable at every level: the front end, the signal processing, the algorithms. Integration is where everything comes together, and it’s the first point where all of these cross-domain interactions become visible.
Issues that don’t appear in isolation suddenly show up once you connect all the parts together.
Because these systems are so reconfigurable, it’s extremely difficult to validate all possible operating modes independently — especially since nothing is truly independent anymore.
Another important thing to keep in mind is that the human mind tends to make assumptions when dealing with this degree of complexity. We make assumptions to simplify the design process and help us cope with the complexity. But those assumptions often break down once the real hardware is integrated and exercised in an operating environment.
And if you discover integration issues at the integration stage, it’s often too late. Prototyping these systems is incredibly expensive, so these are costly errors that add a lot of risk to the success of projects.
This is really where tools like MATLAB can help. By bringing algorithms, components, and impairments together earlier in the workflow, you can identify problems and validate assumptions much earlier in the development cycle — well before prototyping.
Amelia: So Giorgia, why can’t traditional RF, EM, and signal-processing tools provide full system visibility?
Giorgia: Each of these tools is perfectly fine individually. One thing I like to say is that engineers do not fail because they don’t have tools — or the right tools — but because different tools don’t talk to each other.
And I don’t just mean through APIs or programming interfaces. I mean in terms of abstraction levels and functionality.
Each tool does a very good job, but they often work in isolation. They focus on component-level or domain-specific analysis rather than end-to-end system behavior.
That’s one reason these tools cannot capture cross-domain interactions between RF, digital signal processing, algorithms, and the environment. But these interactions absolutely occur in the real world.
Many workflows rely on datasheets or small-signal assumptions — one of my favorite assumptions when dealing with RF systems — but those assumptions fail under real mission conditions, different hardware reconfigurations, or different impairments.
As architectures become more adaptive and multimode, integration problems become critical issues that only become visible late in development, driving up both cost and project risk.
One example I like to bring up is a satellite communication system where you have a large phased array on Earth pointing toward satellites flying 500 or 600 kilometers overhead. The satellite pass only lasts a couple of minutes — it’s extremely fast.
You then have to steer hundreds or thousands of antenna elements toward the satellite. Some elements operate in saturation, others in more linear conditions, so every element behaves differently.
That makes the system extremely difficult to analyze and build robustly. This is where building models and performing system-level analysis becomes critically important.
Amelia: So Giorgia, what is an RF digital twin, and how can it change the design and validation workflow?
Giorgia: Exactly — that’s what I was pointing toward earlier. Modeling and simulation help anticipate impairments and problems before they happen.
A digital twin is essentially a virtual representation of the hardware together with the system-level context. It’s not just a standalone component model. It combines multiple abstraction levels, measurement data, behavioral models, and physics-derived models into a single workflow.
I like to think of a digital twin as a big container that builds a digital thread connecting requirements, simulations, and measurement data as the project evolves.
Digital twins are more than just models — they become companions to hardware and application development.
A digital twin can help build applications, such as a satellite communication link using a specific hardware platform, or conversely help design hardware for a specific application.
It really provides the glue between the component level and the system level.
Amelia: Okay, so how do you think AI can help in the development of these RF digital twins?
Giorgia: AI can help in millions of ways.
First of all, with the extraction of behavioral models from measurement data, and with analyzing simulation and measurement data. These systems are so highly configurable and multimode that you essentially drown in data.
You have enormous amounts of data, and it becomes difficult to make sense of it or find the needle in the haystack.
AI helps process and understand this data, and eventually helps build better behavioral models or higher-fidelity models that simulate faster and provide more meaningful results at the system level.
I see AI in a very utilitarian way. AI automates manual characterization workflows and streamlines tedious tasks nobody enjoys doing. It improves speed, repeatability, and scalability.
By building neural networks for specific applications, you can close gaps that traditional behavioral modeling techniques struggle with.
One of my favorite examples is using neural networks to reconstruct antenna radiation patterns based on orthogonal cuts or partial measurement data.
On top of traditional machine-learning techniques, we now also have agentic workflows, which provide enormous productivity boosts for experienced designers. They automate boring work and free engineers to focus on the creative aspects of design.
AI is a fantastic companion for building complex models and digital twins for today’s RF systems.
Amelia: So how do cross-domain interactions in RF systems impact performance, power, and thermal behavior?
Giorgia: Ideally, an amplifier just amplifies a signal, a modulator just converts frequencies, and filters just filter.
In reality, impairments propagate upward and affect system-level performance metrics like error vector magnitude, detection probability, or overall link performance.
These tradeoffs require designers to constantly move between component-level details and system-level impacts. Designers need tools that let them isolate impairments and directly observe their effects at the system level.
One thing you can do with simulation models is remove noise entirely and ask: “Does my system still fail?” If it does, then the issue probably isn’t noise-related.
This ability to analyze scenarios and create “what-if” test cases is essential for understanding where systems succeed or fail.
That’s why digital twins are so important — they help isolate and understand cross-domain interactions before systems are deployed in the field.
A classic example is understanding how a mobile phone behaves inside a crowded stadium with thousands of other devices operating simultaneously. That’s incredibly difficult to test in real life, but increasingly feasible using behavioral models and digital twins.
Amelia: So Giorgia, your work in this area will be discussed at the upcoming IMS 2026 in Boston, which takes place June 7th through the 12th. What are you hoping engineers will take away from those sessions?
Giorgia: Yes, I’m very excited to come to Boston and participate in IMS. We’ll have a lot of presentations and sessions.
The main message for me is that system integration is now the highest-risk phase of RF design and requires the most attention from system developers.
It’s not about optimizing a single component anymore. I often see RF designers spending enormous amounts of time squeezing the last bit of performance out of an amplifier or filter, when in reality that optimization may not improve overall system performance because the actual issues are elsewhere — or because digital signal processing can compensate for those impairments.
I hope people understand that RF digital twins are the way forward. They allow engineers to connect hardware behavior to system-level metrics and evaluate mission-level performance very early in development — before prototypes are built.
At IMS, MathWorks will have workshops, presentations, and booth demonstrations showcasing measurement-validated workflows connecting antennas, RF components, and algorithms into complete system-level workflows for communication and radar systems.
I hope attendees leave understanding when to use physics-based models, when to use AI-assisted models, and when to use hybrid approaches. Depending on where you are in the development cycle and where your biggest pain points are, you may need different models to balance fidelity and simulation speed.
That’s really the key takeaway I hope engineers bring home from IMS.
Amelia: Fantastic. Okay Giorgia, one last question before you go. If you could have one meal right now — doesn’t matter where in the world it is — what would you have?
Giorgia: I’m Italian and I’ve been living in the Netherlands for almost 20 years now, so sometimes I miss Italy quite a bit.
I would go with total comfort food: a flatbread from my home region called Piadina. It’s kind of like a funky sandwich — only better.
It’s what I ate as a child, so it brings back really good memories. Nothing fancy.
It’s funny — you can find fancy food all over the world, but the simplest street food is often the hardest thing to reproduce.
Amelia: I agree completely. I love it. Well Giorgia, I think that’s all I have time for today. Thank you so much for joining me.
Giorgia: Thank you very much for having me on the podcast.
If you would like more information about this topic, I’ve included a couple of links below the player on this week’s Fish Fry page on EEJournal and in the description for this week’s YouTube episode as well.
Hey, have you checked out EEJournal on social media yet? Well, you should! You can find us on Facebook at:
If LinkedIn is your thing, you can follow us — or me — on LinkedIn. We’re also on BlueSky Social and Mastodon as well.
And of course, we have a YouTube channel:
Folks, it is chock-full of all kinds of techie videos, including our very popular Chalk Talk webcast series hosted by me.
Thank you everyone for tuning in. If you know of any cool new technology — or heck, if you just want to chat — shoot me a line at Amelia@eejournal.com or post a comment on our forums at EEJournal.
For the week of May 8th, 2026, I’m Amelia Dalton, and you’ve been fried.
