Download this article in .PDF format
This file type includes high resolution graphics and schematics when applicable.

The complexity of RF systems is increasing for almost every application. The addition of digital, analog, and RF components, which are critical to the operation of most modern devices, necessitates multi-domain interactions. Yet the interfaces between these different domains are often difficult to describe and analyze in an accurate and timely way. With more tightly integrated and domain-interdependent functions, the barriers between the domains also are breaking down. To effectively model the operational behavior of such systems, the fast-paced RF industry may benefit from multi-domain, system-level modeling tools that can follow a design from conception to implementation.

By definition, system-level modeling is the functional block-level analysis of a system. There are levels of abstraction to consider when modeling a system. Micro-system-level modeling, such as transistor-level modeling, analyzes the interactions among the individual transistors based upon detailed device models. Conversely, macro-system-level modeling involves the interaction between a device and the much larger environment in which the device may operate. Different considerations exist at various levels of abstraction. 

Frank Ditore, product marketing manager for Agilent Technologies, shares an anecdote: “There is something that we joke around about on our team with system-level design or system-level modeling. It’s that the system is always one level higher than the person you are talking to.” The goal of a system architect is to choose a level of abstraction that can benefit a device’s design process while avoiding the time- and computationally intensive simulation of a too-inclusive system. For a system-level architect, a scalable modeling tool with methods of analysis for each domain would enable more efficient and accurate designs.

Until recently, office productivity tools like Microsoft Excel were the mainstay of the system architect. Spreadsheet-style tools provide a high level of flexibility and a mathematically open and definable environment. Yet spreadsheet tools often fall down when it comes to the effective incorporation of nonlinear effects and multi-domain modeling. Ditore elaborates, “If you look at a filter as a mathematical representation, it is a polynomial. I can model that in a spreadsheet. But if I need to implement that in a DSP or FPGA, it becomes a fixed point or Z-domain representation of that polynomial. If my tool can’t allow me to model in that domain very quickly, that tool becomes less effective.” Because the interfaces between various domains are often hard to detail mathematically, tools that can account for these issues may be best suited to enabling the latest designs.

System-Level Modelers Race The Design Cycle, Fig. 1

As RF systems are incorporated into more devices, specific tools for RF system-level modeling or RF-capable add-ons for EDA tools are becoming more available.  Modern tools for system-level modeling are often integrated design suites, which allow for the functional block-level analysis of complex systems. Such software includes The Mathworks MATLAB/Simulink/SimRF, Agilent SystemVue, CST Design Studio, and AWR Visual System Simulator (VSS; Figs. 1 and 2).

System-Level Modelers Race The Design Cycle, Fig. 2

An example of the recent advances in technology and industry collaboration is the development of the AD9364, a software-defined-radio (SDR) prototype module from Analog Devices. In this collaboration with The Mathworks, a fully integrated SDR was modeled—in detail—within the MATLAB, SimuLink, and SimRF environments. Reportedly, the model turned out to be highly consistent with the behavior models developed to enhance the prototyping platform. Such models can then be analyzed with the full capability of relevant MATLAB toolboxes and user-defined code.

The controls of the modeled and practical SDRs are supposedly the same, which could save significant time during product design. Another aspect of the prototyping system is that environmental and channel models can be imported into the simulation. This aspect adds another layer of model detail. It also could aid in preparing the design for market. In addition, an early prototype with a computerized test system could be deployed in real-world environments to confirm radio functions that the device is meant to perform. Other organizations, in contrast, would have to develop a custom system-level-modeling structure to enhance their design flow in such a way.

RF Integration, for example, has developed its own system-level-modeling processes known as the System Accelerator Tool (SAX). In discussing the effective use of system-level-modeling tools, Finbarr McGrath, the firm’s chief technologist, comments, “In the best case, it might save you a design cycle. What it certainly does is give you a much higher-quality design and a much better-understood design.” 

This design-enhancing process usually begins with an interpretation of customer specifications. Those specifications are broken down into individual block performance parameters. A system-level-modeling tool is used to cascade the system blocks into a functional model, in which early analysis is performed. Once the block-level definitions are refined, the optimized block parameters are given to the designers.

Using the system model to predict the system component specifications, the designers complete the internal block designs. The process of refining the block-level models with detailed component-level analysis is iterative. When the system blocks are adequately defined, the block performance metrics are fed into the SAX environment. If needed, the overall system is adjusted to account for the enhanced block-level information. McGrath notes, “This process partitions the design in such a way that the block-level model is contained and precise. The design engineer doesn’t have moving specifications, so changes come back to them less often. It also helps to break the chip down in this way early on, as you get a good idea of how you want to test it.”

If performed well, this type of process could prevent the over-designing of systems and enable much faster design-cycle turnaround. Ideally, the same test methods used with the software also would be used to test the physical device. In that case, troubleshooting, error correction, and design refinement could be dramatically decreased.

A critical step in this process is the description of the block-level parameters. As stated by John Broderick, director of systems engineering for RF integration, “Sometimes, we come up with how good a parameter needs to be from experience or estimates. ..we have to build off those behavior modules.” John further explains that depending upon the tool used, simulating the diverse blocks could be a complex or canned solution. Often, these simulation complexities occur when different components are better defined with time, frequency, fixed-point, or floating-point methods of simulation.

Download this article in .PDF format
This file type includes high resolution graphics and schematics when applicable.