Enabling analog-IP reuse: relating requirements to reality

By Tina Najibi, Cadence Design Systems, Inc

The number of ICs requiring analog, RF, and mixed-signal components is increasing exponentially. The current number of analog designers can’t keep up with the demand for analog components. Coupled with the increasing complexity of the analog blocks, this situation has created an analog-design bottleneck. As the chasm between requirements (analog blocks) and reality (lack of analog designers and increasing complexity) continues to widen, designers are asking analog IP (intellectual property) to fill the gap. It should be possible to reuse analog IP from a third-party vendor or a previous in-house design, but is it?

If you could reuse analog IP, the benefits would be tremendous. Companies could realize decreased time to market and increased cost effectiveness; novice designers could be leveraged to free up more of experienced designers’ time; and analog designers could avoid a complete redesign when migrating from one process to the next and stop the loss of designs when creators leave the company with the IP in their heads. Analog-design reuse would also facilitate design sharing and help avoid duplication of effort between different groups simultaneously working on various parts of the design.

Requirements and adjustments

Unfortunately, analog IP cannot simply be “black boxed,” or handed over and expected— or even trusted—to work “as is.” Analog designs are complex, and many factors affect them. Analog designers must have access to a number of requirements to understand the conditions under which they can expect the IP to work.

To effectively reuse analog IP, designers need sufficient design documentation to be readily available. This documentation should include the thought process behind the design— that is, why designers made certain decisions. For analog IP to be reusable, designers need to know the specifications under which the IP is expected to function. They also need to know the testbenches that were used to test the design and the conditions (corners and sweeps, for example) under which the IP was tested.

In addition, analog IP rarely just fits; it almost always requires customization. Adjustments are necessary for a variety of reasons, including integration into different chips, designspecification changes, process changes within a foundry, and process changes from one foundry to another (second sourcing).

Required expertise

Another important aspect of analog-IP reuse is of real concern to design managers and project leaders: the level of expertise required to reuse the IP. If reusing the IP is so difficult that you need an experienced analog designer to decipher the design, set up the test conditions, make necessary changes, and verify that the changes are correct, then you cannot hand the task to a novice designer. Obviously, needing an experienced analog designer to understand and unravel the way to customize the IP defeats the purpose of the analog IP’s reusability altogether. Information concerning the IP, therefore, needs to be easy to locate, understand, and modify. To ensure that it is, many operations need to be straightforward. Designers must be able to use different process models, design variable values, and make design changes. They must know how to make changes to characterize the new design and be able to determine if it meets specifications. And they must be able to quickly optimize the new design to bring it into specification. Rerunning the characterizations on the optimized new design and rechecking the design to verify that it meets specifications must be easy tasks.

Effective reuse strategy

Analog IP must meet many prerequisites before you can consider it reusable. In fact, the primary reason IP-reuse strategies are not widely in place today is the extra effort required to package all the preceding requirements into a reusable form. Properly documenting everything required to pass the design to a different designer depletes precious design time. Therefore, to make a reuse strategy effective, you must minimize the extra effort to document and package the design. The most effective method is, of course, to capture and package the design process as it transpires, along with data for use in design reviews. A reuse strategy requiring minimal effort is, of course, more likely to be adopted.

The many requirements for effective analog-IP reuse demand new technology, the goal and inherent flow of which would make IP reuse a reality. This new technology should address all the necessary requirements and automatically package them in a reusable form. The designer that receives the IP must be able to view the documentation, specs, and test conditions. He or she must also be able to modify and rerun the IP.

The first issue a successful analog IP strategy should solve is design documentation (Figure 1). Documentation is useful to a designer tasked with reusing his or her design, and essential for a different designer to reuse that design. Without it, he or she can waste a lot of time replacing missing information and answering questions. The problem becomes more difficult when designers work in different time zones. When the original designer leaves the company and becomes unavailable for questions, reuse can become virtually impossible. A built-in documentation tool that allows a designer to automatically create design documentation solves this problem. A detailed description of the design and design decisions, with the test conditions, specs, plots, and measured results, is essential to understanding the design. You can automatically generate this information, with the exception of design decisions (in the designer’s mind) that need to be entered manually, making it available when another designer needs it.

Figure 1—You need to create and store documentation in the project, along with the rest of the project-related information. You can easily switch process parameters to a different set and parameterize directories, files, and corner defaults.

Spec sheets are the second factor critical for IP reuse (Figure 2). They include specs that the design meets as well as the ranges and actual values the design achieves. It is useful, for instance, to know whether a design barely passed spec or is solid. This step requires a builtin, dynamic spec sheet that displays information with a simple pass/fail status. It must be possible to examine the details of each value of a sweep or corner, in particular, in the event of a failed spec. It is also necessary to adjust the spec limits and for the tool to automatically compare the data against the new limits.

Figure 2—A spec sheet makes readily available the measures you compare, their results, and the values they achieve.

The third requirement is for subsequent designers to have access to the testbench under which the design was originally tested. Often, the testbench is schematic-based; it may also reside in the same library as the design. It is useful to keep the testbench with the rest of the project information. This requirement necessitates a tool with a built-in capability to create testbenches. The designer should be able to choose the stimuli and loads, assign parameter values, and hook the testbench to the schematic design by selecting the relevant nets. Designers may run many types of analyses over their designs—whether a simple test (including analyses, options, and measures), sweeps, corners, Monte Carlo, or optimization. These analyses should be part of the project. A designer needs to see all conditions under which the design was tested—for example, how far out the transient was run, what parameters were swept and over what range, and what corners were run. The ability to easily and quickly rerun any of these conditions is essential.

Customizing the IP

After verifying that the IP performs as advertised, you will often need to modify the design to account for design changes. As a result, you may need to change the specs, test conditions, or testbench. Making these modifications should be a simple, straightforward process. All the test conditions and spec-sheet setup, regardless of whether modifications are necessary, should continue to function even though the design has changed.

The IP-reuse environment should include the ability to handle a new set of process models, design-variable values, and potentially a new lib/cell/view, if the design change requires the creation of a new schematic. It needs to support multiple sets of parameters that are easy to switch in and out, as processes change. In addition to design variables, process-model names, paths to library files, and sections within library files need to be parameterizable. Designers could run the project setup using one set of process parameters and, simply by selecting another set, they could rerun the project setup using the new process parameter and models set.

If the designer needs to copy the design itself to a new lib/cell/view and modify it, he or she must be able to quickly and easily rerun the same test, sweep, or corner setup on that new lib/cell/view. If the design introduces new nets or instances, it must be simple to modify existing measures for the new nets, instances, or terminal currents. The designer may also need to add new measures, change parameters on existing measures, or turn off existing measures. It must be possible to reuse the same spec sheet to compare the results of the new design with the same specs, modify the spec sheet to add new specs, or adjust ranges to meet different specs. It is also useful to compare the results of the original design with the new design. This step becomes especially useful if you are replacing transistor-level blocks with behavioral-model equivalents.

Often, the designer will need to add new test conditions. For example, if the design was tested using three corners, the designer might need to add two additional corners. These changes should be easily allowed. Once they are complete, the designer should be able to open the previously created spec sheet and compare the results with the specs, and the pass/fail status should automatically include the results of all the corners. If failures exist, the detailed results should be easy to examine to determine which corners failed and at what values. It should be possible to sort this detailed information to easily spot trends, such as most failures appearing to be dependent upon a certain temperature. Likewise, the sweep should be modifiable to account for more or fewer values, or a new parameter. The same spec sheet should then be reused, specs compared, and the new pass/fail status examined. New measures should be easy to add to the list of existing measures in the spec sheet, and again, designers should be able to make comparisons with these new measures.

If a new design fails to meet specifications, the designer needs to optimize it. Existing setups should be usable within the optimization tool. In fact, if the original design setup included an optimization run, that same run should also be reusable even with additional corners or sweep changes. After optimization is complete, comparing the design against the same spec sheet would once again give the new pass/fail status.

In addition to these basic building blocks, which allow designers to both examine and change the setup, a built-in design-management system is required and essential for design sharing and collaboration. You could create a library of projects from which designers could check out an entire project or any part of a project. For example, a designer could have the option of checking out only the corners information, or of checking out all the test conditions. Once a designer chose a project from the repository, he or she could make changes and check it back in for another designer to pick up. A library of reusable projects that packages all the essential information would simplify design reuse.

Analog IP reuse is possible. It requires an environment that packages everything related to the design, including documentation, spec sheets, and test conditions. The design environment must allow you to rerun conditions change them with minimal effort. This environment would guide a designer through the process of design reuse from start to finish.

References

1. Ohr, Stephan, “Interest in analog IP outpaces execution,” EE Times, Feb 12, 2003.
2.  Morrison, Gale, “Analog IP: Dream or Reality,” Electronic News, March 6, 2002.
3. Singh, Raminderpal, “Analog IP re-use: concerns for ‘digitally oriented’ SoC designers,” EE Times, Dec 19, 2002.

Author’s biography

Tina Najibi is an architect on the Custom IC team at Cadence Design Systems, Inc. She began her career in EDA in 1984 at what was then Harris Semiconductor. While at Harris, she worked on all aspects of Spice simulation, including algorithm development, modeling, and language development. In 1989, she joined Cadence as one of the original developers in the company’s Analog Mixed-Signal division. She continued to work on Spice, mixed-signal simulation, and Analog Artist and was the project lead for OASIS (third-party simulator integration) and OCEAN (Skill command line Artist interface). Najibi joined Antrim in 1999. She came to Cadence for a second time from Antrim Design Systems after its acquisition by Cadence in 2002. At Antrim, she helped create the Virtuoso Specification Driven Design Environment. She has two master’s of science degrees, one in computer science and the other in applied mathematics, from the Florida Institute of Technology. She also holds a BA in math education from the University of South Florida.