RF Design Magazine
About RF Design divider For Advertisers divider Contact Us divider Subscribe to RF Design divider HOME
RSS    Save to Del.icio.us  Digg This


Reducing RF design cycles through improved design methodologies
May 1, 2007 12:00 PM  By Per Viklund

The evolution of RF design methodologies has not kept pace with advances in RF technology, resulting in delays in the deployment of advanced RF capabilities caused by protracted design cycles. New practices based on the use of design tools working together in highly integrated environments can resolve this dilemma by considering system-level RF effects at the beginning of the design process.

Click here for the enhanced PDF version of this article

 
Resources
Spotlight on Automotive Wireless Connectivity

For complex RF system designs it is not uncommon for the RF portion to take up to 75% of the total design cycle. At the same time, today's RF systems have increased in complexity to a level where cycle times are counted in months rather than in weeks or days. In addition, circuitry that is exclusively RF is becoming increasingly rare, and this added system-level complexity frequently results in several re-spins before a design can be shipped.

Even with the additional functionality apart from the RF circuitry, it seems as the RF part always takes much longer to design. The design community has lived with these issues for a long time and many attempts have been made to shift this balance, but these have only had a marginal effect.

If it is assumed that a large RF system design takes 20 weeks from start to finish, and that the RF portion will claim the expected 75% of this time, this amounts to 15 weeks. If the RF part design cycle were to be cut by 50%, the entire design would be done in 12.5 weeks, which is almost a 40% reduction. This is a desirable goal, but it is clear that fine-tuning existing design methodologies can only marginally impact required design times. Significant time reductions require a completely new methodology.

Previous RF design methodologies

Between five and 10 years ago, it was common for circuit boards to exclusively contain RF circuitry. Most RF design tools in use today originated from this era. These tools work reasonably well when system-level complexity is low and the RF design structures are conventional. However, virtually every design today consists of multiple complex RF modules combined with ultrahigh-speed digital and analog circuitry in tight proximity on the same circuit board.

The problem is that design tools and methodology designed for older RF technologies and design philosophies are now being used to address modern RF design challenges. In reality, there have been very few truly new design tools. The tools that have emerged in recent years are mostly based on dated design practices and, therefore, fail to address the issue of design cycles that are too long, or repeated too frequently.

Current methodologies

A typical RF design flow is based on the fact that designers develop each RF block using a dedicated RF tool. These tools usually have their own component libraries and design file structures. The designer can make a parametric schematic or a physical layout, or both, and have a set of simulators at hand to validate the circuit.

Once the RF engineer is happy with the design, the next step is to translate the RF design database so that it can be imported into the system design environment as a schematic and layout. A PC board designer then completes the board design and typically works closely with the RF designer for the RF portion of the PC board layout. The PC board designer also adds ground fill and ground vias with assistance from the RF engineer.

To ensure integrity of the RF circuit, the RF engineer considers the full PC board implementation of the circuit and translates it to an equivalent circuit model. It can then be imported back into the RF design environment and simulated there. While this basic process is straightforward, it is also generally inadequate for meeting modern design challenges.

RF design challenges

The described methodology looks simple enough so what is wrong? Several aspects of the previously described system design flow are causing long design cycles with frequent re-spins. One reason for this is the designing of parts for a large system as isolated modules, rather than as a complete system in an integrated design environment that accounts for interactions among the various RF portions. The RF design tool has its own parts library, its own design database and above all, a data model that significantly differs from today's system design tools. The system design environment also has its own library and its own design data archiving. These multiple libraries must be kept 100% synchronized to avoid design errors. Furthermore, the resulting multiple storage sites for critical design data introduces multiple opportunities for failure.

The differences between data models are the reason why translation of design data between RF design tools and system design tools is always painful. Many designers agree that this translation always requires some manual intervention and needs to be manually reviewed. Nor does translation support incremental updates. Furthermore, it typically converts the intelligent RF shapes from the RF tool into a mere piece of metal in the system tool, preventing effective system-level verification.

Typically, ASCII-based IFF, AutoCAD DXF or binary GDS-II is used for this translation, and many of the problems are caused by the differences in the data model combined with data formats that are not intelligent enough to map critical data between the environments. Designers are simply applying data formats that were not designed to perform the tasks expected within an integrated environment. This, too, invites problems.

Again, while attempts have been made to address some of these deficiencies, the main causes of these difficulties have not been addressed, and only marginal improvements have been seen.

Improving existing methodologies

It is obvious that to resolve these difficulties, a completely different RF design methodology must be created. When creating a new methodology, the first step is to define a set of goals, which are as follows:

  • Dramatically cut cycle time for RF system design.

  • Reduce the total number of design cycles.

  • Eliminate dual library maintenance.

  • Eliminate multiple design data storage points.

  • Enable incremental design updates.

  • Enable design re-use and versioning of RF modules.

  • Enable use of latest versions of all involved tools.

  • Enable fast simulation of RF and mixed technology from both schematic and layout.

  • Enable real PC-board-level RF simulation.

  • Enable concurrent design at both the schematic and board levels.

It is clear that three factors in current RF design methods are obstructing these goals. One is the use of multiple parts libraries that need to be synchronized. A second is the existence of multiple design data storage points for a single project. Third, there is the set of fundamental differences between RF and system-level design tools, making smooth and seamless transition impossible to achieve.

The proposed methodology confronts all these obstacles in a direct manner. If translation between the tools has been a lingering design issue for more than 10 years, then it should be eliminated by any new RF design methodology. Likewise, if library maintenance and dual location storage is error prone, then it, too, should be eliminated.

Integrating RF and system design

With RF design being performed in isolated point tools, the design translation, library synchronization and data management become critical factors for success. Because these factors are extremely hard to resolve successfully, the solution is to change the entire methodology and make RF design an integral part of mixed system design.

In short, RF circuits should be designed directly into the system schematic and the system board layout rather than in a separate environment for later translation. All the simulation, tuning and optimization capabilities of the RF simulation environment are still needed, but the simulation environment can be fed with much more primitive data than the “actual” design. Hence, the differences between data models, and thus the issue of design translation, are eliminated.

The advantages of this approach are obvious. The RF portion of the design is now part of the complete system, so it can be designed alongside any other circuitry in the system. This way, it can be fully concurrent with other design disciplines rather than represented as a black box to be interfaced into the system at a later stage. The higher the level of this integration, the more transparent various design disciplines (including RF design) become at the system level. This enables one portion of circuitry to take surrounding circuitry into consideration, leading to improved accuracy. Most important, a single library is used and all design data is stored in a common location, which helps to manage the overall design process. A fringe benefit is that now RF can make use of standard system design features, such as design reuse, version control and design data management.

Design environment requirements

In order to do the RF design in the system design tools, there are some new requirements for the design environment. For example, RF design tools typically operate with parametric circuit elements, such as MLIN, MCURVE, MBEND and MBSTUB, whose dimensions are set by parameters such as W for width and L for length. To be able to use the system design tools for RF design, they need to be enhanced with parametric shapes in the schematic and the substrate or board layout.

In addition, there should be a mechanism to guarantee that the components in the parametric shape library in the system tools behave identically to their circuit-simulation model counterparts in the RF simulation environment. In reality, this means that the system design tools need to access and synchronize with the RF environment's library. This way, all manual library maintenance for system RF libraries is eliminated.

Integrating RF simulation

At this point, the foundation for RF system design is established. What is needed is a way to transfer the complete electrical characteristics of the RF circuits over to the RF simulator. This should be done not by translating the design, but by sending just what the simulator needs: a simulation net list referencing circuit elements. Fortunately, it is actually a simple process to simulate an RF circuit. A typical RF simulation net list is straightforward in its format and is shown in Figure 1. The lines are read as follows, using the upper highlighted line as an example:

  • Field 1: the circuit model (MLIN2).
  • Field 2: the reference designator for the RF element (RF_MLIN_57).
  • Field 3: the pin 1 net name (_I$7697__NET100).
  • Field 4: the pin 2 net name (ads_net_3).
  • Field 5: list of parametric properties (L = W = Subst = MSub1).

In the RF environment, a circuit test bed is defined to supply stimuli and termination as well as define the simulations and the analysis that is performed, as shown in Figure 2.

Current design tools make RF simulation in the context of a real PC-board design difficult. At best, the metal structures can be brought into the simulator using primitive artwork formats such as Gerber or GDS-II. Unfortunately, none of these formats are intelligent enough to convey any of the circuit intent needed for the simulation.

As previously mentioned, the proposed methodology would only involve the transfer of a simulation net list. It is a slightly more complex format, however, because it is now necessary to describe arbitrary metal shapes and cutouts, as shown in Figure 3, including all external connections, such as ports, for a true n-port S-parameter extraction.

This is radically different from attempting to translate the design. With the new approach, interactions between adjacent RF modules or interaction with non-RF structures can be modeled and analyzed.

Tool interaction

In its simplest form, the simulation net lists can be manually imported ASCII files. Further developing tool interaction so that the system design environment and the RF design environment dynamically can exchange design data over a network enables several interesting scenarios.

First of all, designers can cross-probe directly between system design and RF simulation. Second, if designers have a large or complicated RF circuit, they might want to distribute the circuit simulation to multiple computing platforms to run in parallel to shorten simulation time. Alternatively, they might want to send each circuit in a multimodule design to a separate simulator — again to save time. All that becomes possible when the tools are interconnected.

The way RF system design is now being conducted is undoubtedly the cause for long cycle times as well as frequent re-spins due to the complications introduced by unforeseen system-level effects.

To dramatically reduce the number and duration of design cycles, the new methodology described in this article better integrates RF design and system design, addressing all the current obstacles for efficiency. This new methodology is where RF design becomes an integral part of overall system design rather than an isolated point tool operation. This shift in RF design practices represents a paradigm shift. Planning and training will be required to deploy and fully use the new design tools and methods. However, the rewards can include predictable quality and lead times. Most important, it can also reduce the number and duration of design cycles for an RF system.

ABOUT THE AUTHOR

Per Viklund, director IC Packaging & RF, Systems Design Division, Mentor Graphics, is responsible for IC packaging, RF design, and embedded components product lines. He is a long-time IEEE and IMAPs (International Microelectronics and Packaging Society) member with more than 25 years experience in electronic design. He has spent the last 20 years with EDA tool design. He has also published several papers on IC packaging, embedded passives, RF and high-speed design. Prior to joining Mentor, he was chief technical manager of DDE-EDA for more than 10 years.


RSS    Save to Del.icio.us  Digg This

February Defense
 
Back to Top


Contact Us  For Advertisers  For Search Partners  Privacy Policy  Subscribe
© 2008 Penton Media, Inc.

popular searches: zigbee | quadrature modulation | OFDM | WiMAX