Advanced Packaging - RF Integration &#151 A Paradigm Shift

The character of RF design has changed quite dramatically in the past few years. It's quite rare that RF designs are isolated pieces of circuitry, but rather part of a much bigger context. While the classic RF design is seen as a self-contained, small RF module, today's RF designs typically are much larger and much more complex. Above all, they are multi-technology designs consisting of multiple RF modules integrated with high-speed digital, analog, power, and bias networks, all in close proximity on the same dense circuit board.

RF Design Methodology of the Past
A Dataquest report from 2003 mentioned RF design tools as "a limited seat market" with very small growth. The fact that no new RF design tools had been introduced for a long time was offered as a contributing factor. The truth is, not much has changed since. Although dramatically improved, classic RF design solutions are still applied in a system design flow based on the way RF design was done 10–15 years ago. The improved tools make the RF-specific part of the design flow efficient, but when applied to a mixed technology system design flow, the methodology falls apart. This is because a methodology designed for the design battlefield of the past is being applied to something it was never designed to handle — multi-technology integrated designs.

The result: a big-time failure. The patient is ill and shows the typical symptoms: long cycle times, frequent re-spins, and an abnormal amount of time spent interfacing designs between different tools.

It's common for up to 75% of the total cycle time of a system design to be spent on the RF section alone, which is excessive when considering that the majority of the design content typically is non-RF technology. Further investigations show that it's typical for around 75% of the total RF design time to be spent interfacing RF tools and system design tools, which adds up to 50% of the total cycle time. With cycle times counted in months rather than weeks, the situation is not sustainable, yet it is the reality for many companies.

However, if integration issues can be eliminated, cycle time can be reduced by half. Re-spins happen because it's extremely difficult and time-consuming to re-simulate RF modules and account for real circuit board features, such as surrounding analog and high speed circuitry, real fractioned ground and power planes, and real ground switch vias (Figure 1).

As a consequence, RF modules working perfectly in the simulator need further tweaks once the first test board has been built. Most will agree that building prototypes just to find predictable issues is outdated, and EDA tools should catch most issues and support a "correct-by-design" methodology. In this case, it means that in the system design environment, full round-trip integration to RF simulators is necessary.

The Solution to Long and Numerous Cycles
Focusing on tool interface issues is the key to resolving long cycle times and multiple cycles. Many attempts have been made to optimize this part of the design process. Different data formats have been applied and the interface applications have been tuned and re-tuned with mediocre results.

RF design environments and EDA system design environments are fundamentally different in their view of "the world." Hence, translating designs between these environments can only go so far before the differences obstruct further progress. Even translation file formats that have been specifically designed for this purpose — such as the well-known but rather ancient "IFF-format" — fail to resolve the issues because these formats don't address the root of problems. These problems are exacerbated by the iterative nature of RF design. A basic circuit is tweaked over and over again until it performs within desired specifications.

In a system design flow, this means repeated translations of updated RF circuits into the system design environment. The differences between the environments make it almost impossible to manage, as there is no methodology to support versioning or variant management, or even track the origin of the multiple RF circuits in a system design.
There may be good reasons for these differences. The data models of each toolset are designed to best support the tool's own operations. Interoperability is rarely allowed to outweigh performance and precision requirements.

Separate Tools, Data, and Libraries
As long as design is separated between design environments, there is the issue of keeping tool libraries absolutely synchronized. This takes serious effort and still is almost impossible, which leads to libraries being a common source of design failures.

The same is true with design data. Separate tools calls for a copy of the design to be archived in multiple places and lead to design data management issues. Which representation is the master? What needs to be archived for the future? How should versions and variants be managed?

Lost in Translation
Real progress can only be achieved with a different methodology: one that eliminates the issues caused by different tools having different data models, separate data archiving, and separate libraries. Every time we have a data model discrepancy between tools, some form of conversion needs to take place. If an entity has no representation in environment A, then data from environment B has to be represented by some other already-known data construct, and the mapping between them may or may not be straightforward.

The disadvantage to this is that it can only be a one-way translation. To achieve two-way translation, it must be possible to map data back again 1:1 without loss of data or intent.
At this point only data object compatibility has been dealt with, which is the easiest part in tool integration. The real challenge is the difference in semantics between tools.

To use a populist example: How do you tell a Martian that humans have their heart on the left side if Martians lack the concept of left and right, or even lack our concept of a heart? Communication quickly becomes a problem. Applied to RF and system design tool integration, this means that different tool sets are designed around different "world views" to allow for optimal modeling of the specific tasks the toolset is designed to solve. These differences can't be easily mapped between the worlds, and the typical solution requires that a design engineer define the translation result manually each time.

One solution would be either to define a common "world view" for the core of all EDA tools or define intermediate data models with a shared world view. Attempts have been made to design both of these, but, for various reasons, have been unsuccessful.

The Way Forward
Data translation back and forth between incompatible tools has to stop. This has been tried with IFF files for more than 10 years without success, which is reason enough to find other means. Instead, a new methodology is necessary where the added value of each tool can be fully used without attempting the doomed translation game. If we can keep the master-design in one tool and only transfer to integrated tools, what's needed as a minimum to access the tool's added value?

The data needed to let each tool add its maximum value is much less in quantity and much less complicated than the complete design, and completely bypasses the data model incompatibilities. This makes a solution based on this model much more robust. It automatically eliminates the need to maintain multiple libraries, and answers the question of where the data needs to be archived as well as opening up for variant and version management.

Obviously, the data passed between tool environments can still be files, and the operators in each environment can generate and import these files when desired. Why stop at this? When integration works without manual mapping each time, tools can be linked together over a dynamic network-based link so that changes made in one tool become available for re-simulation without any file transfer. With such a two-way dynamic link, it becomes possible to mark up circuit board entities such as surrounding RF or non-RF circuitry, ground planes, and vias, and feed the result back to RF simulation to validate the circuit in the context of the actual circuit board design (Figure 2).

While this methodology helps significantly cut cycle time, the validation of RF circuits in a system design environment is what helps cut design cycles and helps generate predictable lead times and quality in RF design. AP

Per Viklund, director, IC packaging and RF, may be contacted at Mentor Graphics Systems Design Division; E-mail: per_viklund@mentor.com.

Add RSS Feed