MWJ: Reconfigurable phased arrays are becoming central to next-generation radar and wireless systems. What is driving the shift from fixed-architecture arrays to reconfigurable wideband arrays, and what new system capabilities does that unlock?
DM: Reconfigurability is a hot topic in the industry, even beyond phased arrays. There are multiple advantages to phased arrays, specifically. The beauty of it is that it allows you to go from historically fixed architecture arrays – that enabled single radar modes, single communication standards, or single operating environments – to a multi-mission platform that enables multiple radar modes, multiple communication standards, and multiple operating environments. So, really, there's the benefit of taking a single architecture that was previously fixed to a single condition and translating it into a single architecture that is software-configurable for multiple missions at the cost of complexity.
Reconfigurable wideband phased arrays are being driven by the need for faster time‑to‑market, multi‑mission platforms, and lifecycle flexibility. This unlocks higher hardware reuse, better spectrum utilization, and the ability to upgrade performance post‑deployment. For new products being developed, there are hardware redesign savings, but for products already deployed in the field, software reconfigurability is critical for those customers rather than waiting for new ones.
At the same time, it introduces new challenges—greater architectural complexity, tighter coupling between RF and digital design, higher integration costs, and a much harder problem of predicting system‑level performance across operating modes.
MWJ: Your IMS presentation focuses on system-level design and verification across both radar and wireless domains. What are the biggest challenges engineers face when trying to design architectures that serve both sensing and communications applications?
GZ: The biggest problem is that even when we use the same hardware or the same hardware platform, we're actually designing for a completely different set of metrics. For example, when we look at communication systems, we optimize for linearity, error vector magnitude, efficiency, and compliance with 5G or satellite communications standards. When it comes to radar, we optimize for different parameters like target range, probability of detection, spatial resolution or dynamic range robustness to the environment, such as clutter and interference. This can lead to completely different trade-offs.
For example, in designing a transmitter for a communication system, it is important to be highly linear, whereas in radar, it doesn't matter. When you design a system for such different metrics, designing at the component level for these metrics makes optimizing the entire system extremely difficult and extremely complicated. Those differences drive very different tradeoffs in array size, RF front‑end design, beamforming strategy, and cost. When you try to serve both domains with a shared architecture, it becomes difficult to reason about performance using component‑level metrics alone.
Maybe this is a topic we will touch on a little later, but this was actually one of the many challenges we faced when we developed an RF digital twin for Analog Device’s (ADI) hardware platform, where we essentially created the digital twin that was suitable for the design of very different applications, both communications and radar, so there are layers of complexity that build on one another. Creating a digital twin that can support design and verification across such different end goals—using the same hardware platform—is non‑trivial but increasingly necessary.
MWJ: How are modeling and simulation tools changing the way engineers approach phased array design—particularly when dealing with mmWave bandwidths, beamforming algorithms, and RF front-end nonlinearities?
GZ: It requires a change in mentality. Many RF engineers tend to think at the component level. When looking at architectural or system-level metrics, you need to think at a different level of abstraction. We have created models that operate at different levels of abstraction and that are tied together through validation. We had models that were very accurate, high-fidelity, and closely matched the hardware's performance, and they were used as a reference.
We created models at a higher level of abstraction that allow system and application designers to make different trade-offs. But there is always a little bit of tension between fidelity, simulation speed, and application complexity.
One thing that is very specific to platforms that operate at millimeter-wave over a large bandwidth and are highly adaptive, with lots of possible configurations, is that essentially design-by-prototype doesn't work anymore. You can't just go to the lab and tinker until you hopefully end up in the optimal situation. So, models and simulations are needed.
DM: A huge initiative at ADI is meeting the customer where they're at, especially in terms of loyalty. They typically require different levels of fidelity in their models at various stages of their own design and development cycle.
The beauty of working in the MATLAB and Simulink environment is that it provides both its idealized baseband and its circuit-envelope techniques. Simulation techniques allow us to meet our customers at those different levels. They'll use the idealized baseband models for more systems- and application-level simulations, whereas they'll use circuit-envelope techniques for more card- and component-level analysis. The beauty of it is that if we're doing this before hardware is available, with actual bench data, there's a huge advantage in creating models; we can use the circuit envelope models or higher fidelity to go back and recalibrate the idealized baseband system level models. We have a more accurate, higher-fidelity system-level model that continues to operate at higher speeds. So, as Giorgia mentioned, there's that speed-fidelity trade-off, and it really depends on the customer, which is why it's critical to meet them where they're at.
MWJ: Digital twins are a major theme of your RF Systems Pavilion demo at IMS. How do digital twins differ from traditional RF component models, and what advantages do they provide for system-level design?
GZ: First we have to ask, “What is a digital twin,” and “Is it different from a model?” My conclusion is that yes, digital twins are models, but they are more than just models; they evolve throughout the life cycle of hardware.
They are executable models that provide an executable specification of the system, and they are a set of models that operate at different levels of abstraction, as Dan described, but they are tied together through a very strict validation process.
They are models that I'm going to say are a framework for regression testing, validation, and test benches that actually use the same waveforms and metrics as in the lab. So, there is a continuous lifecycle of the models and on the digital twin itself that is in sync with the hardware. Bottom line: a digital twin is different from a model. It is a family of models that are very much alive throughout the development process, and therefore, they also act as a bridge to enable communication between the system integrators and the device manufacturer.
WMJ: Analog Devices has developed digital twin models of its RF components directly in MATLAB and Simulink. How does that integration improve collaboration between hardware vendors and system integrators?
DM: This is an initiative that ADI is taking on at large and what we're really trying to do is what we call "shift left" in the design process. It's both shifting left in ADI's design process, but also our customers, who are the system integrators.
There are two major advantages here. One is really pre-tape out before hardware is available, and the second is after hardware is available. Before hardware is available, we can provide customers with a very early evaluation platform to help them understand how ADI products perform and how they integrate into their systems. The opportunity that it also provides is for customers to share feedback, critical feedback on our own designs. If they see feedback in their simulations, they can share it with us so we can integrate it into our design and stay on schedule. It's improving our design before our hardware is even available. So, there are major implications in really giving the customer a voice during our design cycles, which are becoming more and more critical as we develop systems for customers, not just individual components for them to plop into their environments.
The second piece is after we release our products. It's shifting the dynamic of how they evaluate our already released products, where we're going from, historically, customers using a static data sheet to get a snapshot of product performance, reading through hundreds of pages of the data sheet with various plots, and some example or recommended configurations. Now we’re transitioning into this dynamic simulation environment where you can tailor the model to your specific environment. You can configure it exactly to meet your requirements.
You can include your own application scenarios, write your environmental conditions and really get an interactive result that allows you to quickly configure for your environment. And again, it's dynamic and accelerates your design schedule. It does all these great things that customers are looking for. So again, pre- and post-release, there are major advantages to ADI interacting earlier and more efficiently with our system integrators.
MWJ: Many RF design workflows still rely heavily on lab prototyping and iterative testing. How can simulation and digital twins reduce the number of hardware iterations while still maintaining confidence in system performance?
GZ: Digital twins are not a substitute for lab testing. Lab testing will always be there. But if you have a digital twin next to your prototype, two things the digital twin helps with are: one, it's not just the models, it's also the test benches. It enables you to focus on testing specific scenarios, waveforms, hardware conditions, and configurations. It also helps in identifying critical or corner cases earlier.
Second, digital twins help in evaluating the system performance when things don't work as you expect. A digital twin can isolate and debug issues. One of the first things we did, for example, was to provide the ability to disable noise from the models, nonlinearity, or frequency dependencies. These are things that you cannot do in real life.
But because you can isolate each of these impairments or effects separately, and because our system is so complicated, it has so much configurability, so many different moving parts, it makes it a lot easier to really understand the root cause of the problems.
MJW: Your IMS demo includes a radar probability-of-detection simulation from Leonardo UK. What does this example reveal about how mission-level metrics can now be evaluated earlier in the design cycle?
GZ: It is not easy to get these metrics, especially for a radar because you need to have a transmitter model, a model of the receiver, a model of the target, and the model of the environment. If any one of these is missing, you cannot get that metric.
Before the actual hardware is available or finalized, it is a big advantage because it means that you can iterate a lot more rapidly, identify issues, and evaluate scenarios early in your development cycle, and then you can decide things such as, “Do I meet my requirements?” “Can I go to market now?” or “Are more improvements needed?”
Now you can iterate on specific aspects of the hardware or software until you optimize for cost, performance, or robustness. There is a paradigm shift in having this type of metric available early because it allows you or the system integrators to assess system performance early and perform analyses, such as assessing the impact of phase noise on your probability of detection. How many oscillators do I connect to my RF modulator? What happens if the phase noise is correlated or uncorrelated? All these types of analyses can be performed at the system level and assess the mission-critical metrics.
DM: The demonstration we're giving at IMS ties in with Leonardo, and Leonardo used the digital twin model that MathWorks helped us create, which was for a product that has yet to be released. They were able to take a digital twin of an ADI product that no one knew much about because it hadn't been released yet and then integrate it into their system-level scenarios to better understand the performance of their part in the system. It ties back nicely to your question where we discussed how we can improve the interface with the system integrators. This is a perfect example of using those early digital twin models before hardware is available, not only to validate performance, but also to give Leonardo confidence in ADI solutions, which, for any customer, justifies investing in our products. So, digital twins play a huge role in justifying cost investments, and, obviously, they have the major advantage of evaluating performance earlier in the design cycle.
MWJ: For engineers building complex RF systems—such as phased array radars or 5G/6G infrastructure—what role does hardware-in-the-loop testing play in validating the accuracy of digital twin models?
GZ: Lab testing and hardware in the loop testing are pretty much essential when developing a digital twin, and we're still working on it. We follow a very strict methodology: as soon as new measurements or information are available on the hardware, we validate the models hierarchically, from the component to the boards. Initially, you have just a component in standalone mode; throughout the hardware development process, these components are integrated onto evaluation boards, and then you take measurements on them.
Once you have evaluated the measurement, the lab results are compared with the digital twin providers' results. So, the digital twin is always in line with new silicon, new measurements, and new information as they become available.
The test benches the digital twin provides are the same ones used in the lab. So, you use the same waveform and metrics and get consistent results, which is essential when you deal with systems that have a certain level of complexity. It doesn't make sense to have a digital twin for a simple amplifier because there's not much to evaluate, but when you have dozens of components with hundreds of possible configurations, then it really makes sense.
DM: Something ADI really appreciated when we started working with MathWorks on these digital twins was the approach they took: one of them was to take the high-fidelity, circuit-envelope models and go back and calibrate the idealized higher-band models.
Same thing with hardware-in-the-loop: we have that extra layer that gives us the actual results on the hardware, so we can go back and recalibrate our digital twin models. So, when we deliver these later versions of the digital twin models, we can have much more confidence in how they actually represent the present.
And it's the same thing with customers. They also start to gain confidence in our results by calibrating or correlating them with hardware results. The other thing is that hardware-in-the-loop at this point offers capabilities that digital twins can't. Maybe they aren't efficient. One thing that often comes to my mind is timing analysis. Timing analysis in the digital twin is very computationally intensive. It takes a lot of time. It's very difficult to simulate as well. That requires, especially if there are third-party devices and things like that, a really accurate model of their device. There are definitely additional advantages to still pulling hardware in the loop, especially in cases where timing analysis is critical.
MWJ: As RF systems become more software-defined and adaptive, how important is the concept of a ‘digital thread’ connecting requirements, modeling, design, and measurement across the development process?
GZ: I think that the keyword here is traceability. A digital thread enables traceability throughout the system's complex life cycle. Analog Devices develops the hardware, Leonardo integrates it into a radar, but that radar will ultimately be part of an even larger system. So, the supply chain is really complex, and these products have a lifespan of tens of years. A digital thread is essential for traceability, especially when considering what happens if a component is redesigned for the next generation. What happens if I have derivative designs? What if a board gets redesigned? What happens if a component becomes unavailable? All these scenario types need to be constantly documented and verified. The digital twin provides a thread through the life cycle, allowing you to trace decisions back, document and justify them, and understand the consequences if something changes.
DM: This is good timing for this question because we just spoke with a customer the other day who said they are now requiring digital twins and digital thread to justify their investments in R&D projects and in new products in development and design. They are telling us we need more than just PowerPoint slides or spreadsheet calculations to justify investing in these very complex solutions. That's where digital twins come in. Or if you have these verified models in this digital thread to validate requirements, they can then justify investment and have confidence that it is worth investing in our products.
MWJ: Looking ahead, how do you see AI-assisted modeling, system simulation, and digital twins shaping the future of RF system development over the next decade?
GZ: We've already been using some AI tools for this specific modeling work in constructing this digital twin. One example, one of the components that is part of the digital twin had something like five different digital step attenuators (DSA). Each of these five DSAs had dozens of settings, so it ended up with a very large set of possible configurations for just one part of the system. And if you want to model all the possible configurations, then you need to have information such as, “What the consequences in terms of the specifications for each of the settings?”
Measuring gain, linearity, noise, and all possible configurations to provide a high-fidelity model is not feasible because it would take weeks in the lab to measure them all, not to mention the amount of data it would require. So, in this case, we use a Gaussian process surrogate model to reconstruct measurements or missing data from a subset of measurements. It is AI helping with a very complex task, grounded in the same models, requirements, and verification processes engineers already use.
Similarly, you can think of a similar use of AI for antenna pattern reconstruction, where you want to perform the integration over the antenna patterns in your system, but you only have partial data available for the antenna. These are very specific problems that AI can help with, but there are also more generic problems. Nowadays, we are starting to see more and more use of agentic workflows, for example, in the creation of test benches and regression.
I think that this is really where we will see a lot of help coming from AI. I don’t think that AI, will replace RF system engineers, but I do think it will make it much more productive, and that will help us create high-fidelity models in a shorter time while staying grounded in the models, requirements, and verification processes they rely on.
DM: This question ties back and brings things full circle to the first question, where we were talking about the reconfigurable multi-mission phased array products that are now coming out. If we're going down that path and creating these reconfigurable phased array modules, that means there's a ton of complexity built into them. That creates a usability problem for our customers. How do the customers take this super complex product and configure it? That's where we're looking for AI to help. Again, it's not replacing the engineer, but it's improving the usability of these complex products by helping find the optimal configuration for their environment.
This is the advantage of simulation in general: we can simulate thousands and thousands of scenarios much faster than you can do on the bench, collect all that data, and that's data for AI to learn from to go off and create that optimal configuration.
The beauty of the two is that you're not limited to the same restrictions you are with hardware. You can now test those edge cases and extreme environments through simulation. Whereas normally you'd be at risk of damaging your board, wasting money and time doing it in the lab, or spending more money on equipment that could even test those edge cases, now you can do all that in simulation. You can collect data, test these unique scenarios, configure the system for these scenarios, and gain a better understanding of how to use our products in your application.
All are using these new AI tools. I think it ties back nicely to the fact that we have these super complex parts. How do simulations, digital twins, and AI technology help us use them? This will all help lower the cognitive burden of working with complex hardware solutions.