NASA Office of Logic Design

NASA Office of Logic Design

A scientific study of the problems of digital engineering for space flight systems,
with a view to their practical solution.


The NASA ASIC Guide: Assuring ASICs for SPACE

Appendix One: Modeling and Translation

Objective:

To present the concepts of modeling and translation as the apply to many areas of ASIC work.

Modeling--the set of techniques used to predict aspects of an ASIC's behavior under various electrical and environmental conditions--is central to ASIC design and verification. Long before the designer sees the packaged ASIC, various forms of modeling have anticipated and shaped all of its important behavioral aspects. Software models, by far the most common, are becoming increasingly complex and accurate. While carrying out modeling tasks, both anticipated and unanticipated translations are often necessary.

Translation changes models and testing schemes from one form to another. ASIC design and test tools support the bulk of translation needs. However, no modeling tool set supports all types of models. A design group's tool set often fails to support essential modeling needs, such as stuck-at-fault analysis. When this problem occurs, the question is: "Can the design team create a model to achieve the desired benefit in an economical way?" The answer lies in the cost and effectiveness of buying or writing translators that move the model from one tool to another. Given the complexity of today's ASIC designs, translation is not an easy task.

Today's profound levels of ASIC complexity require simulation-based methodology (i.e., computer modeling) for timely, economical and reliable ASIC development. Simulation allows designers to develop ASICs entirely on computers. The days of modeling ASICs exclusively with breadboard prototypes are rapidly coming to a close as the amount of information necessary to accurately model ASICs becomes manageable only by computer. Today, computer modeling has become so competitive and central to design that most vendors guarantee the predictions of their simulators about the final part's behavior.

The philosophy that drives modeling in an ASIC program can be simply stated as "model early, often, as accurately and completely as possible, in an economically intelligent fashion." This philosophy holds for everyone involved in the ASIC business: ASIC vendors, ASIC designers, and third party organizations. The same philosophy holds on all levels of ASIC modeling, from the top level (specifying objectives and requirements) to the bottom level (simulating transistor behavior).

This appendix has two goals: to inform the reader about how modeling and translation fit in to ASIC technology, and to provide insight into how these issues effect making economical decisions.

To accomplish these goals, we begin with a section on "Model Development," reviewing the far-reaching world of modeling and model creation at all levels including fabrication processes, cell libraries, and modeling tools. We then relate this information to vendor evaluation issues.

Section 2: "Modeling and the Design Cycle," describes the tools available to the designer for ASIC design and verification, and discusses how to be a smart consumer of these products.

Section 3 is devoted to "Translation," describing its possibilities and limitations to show how it can save time and money, as well as how it can become a major bottleneck to the progress of an ASIC program. We then give some tips on how to exploit the former and avoid the latter.

Model Development

Modeling and model creation begin far before the ASIC design cycle, involving developments in three key areas: the vendor's process (fabrication line), libraries (logic cell models), and tools that use those libraries (computer simulators). Third party organizations develop technology in all three areas, particularly in tool development. Processes, libraries and tools are intimately related: the effectiveness of one limits the effectiveness of the other two. Although vendors depend only on themselves to develop their specific processes and libraries, they do not solely rely on themselves to develop tools, due to the highly competitive electronic design automation (EDA) industry.

Because of the vibrant EDA market, tool sets usually outpace the processes and libraries they intend to model in terms of handling complexity, performance, and accuracy. The EDA industry may put out products that can simulate an ASIC running at 50 gigahertz, but if processes can only fabricate ASICs that run at 2 gigahertz, the extra simulating power cannot be used effectively. Similarly, if simulators can predict parametric performance parameters with 0.01 percent accuracy, this is immaterial if library parameters have only 0.1 percent accuracy. Thus, the most pervasive limitation to modeling is library development.

When vendors develop fabrication processes, library development naturally must follow the process developments the libraries aim to reflect. Thus, designers cannot use tools to model these processes until the vendors develop their libraries. As cell behavior becomes more complex and multi- dimensional, each behavioral level to be modeled demands larger and more accurate data bases for correct simulation. Finally, library development is a voluminous task: hundreds of cells require modeling, and each cell model must have several versions corresponding to the many tools that designers use to support it.

We now discuss process, library, and tool development in greater detail, referring to figure A.1.1.


Figure A.1.1
Process, Library, and Tool Development Flow

PROCESS DEVELOPMENT

Vendors use process modeling as the first and most fundamental modeling step in developing ASICs. Process modeling includes two and three-dimensional geometric models of transistors to predict capacitive and resistive effects that higher level models (SPICE level and higher) fail to notice. Using these tools allows vendors to create and improve their processes. Process improvements include: scaling devices to smaller dimensions; enhancing performance; and improving quality and reliability.

Three factors influence both building new processes and improving preexisting processes (such as scaling devices to smaller dimensions): user needs, industrial competition, and government and industry standards. Users provide feedback to vendors about what process improvements would best serve their future goals. Competition in industry constantly motivates vendors to make their products faster, cheaper, and more reliable. Standards motivate process changes that have been modified, such as updating test method standards in MIL-STD-883, or standards that have been created such as the IEEE JTAG Boundary Scan, IEEE STD 1149.1.

Unlike most higher level models, process models take relative positioning of transistor components into account (i.e., they use distributed parameters) and are able to model the shapes of those components with great accuracy. Developers then fabricate prototypes of parts and single cells for process debugging and for library development. Once a process is finalized, developers generate a list of process capabilities to guide library and tool development.

LIBRARY DEVELOPMENT

Cell library development requires accuracy and thoroughness. The accuracy of these cell libraries determines the effectiveness of the modeling tools. Libraries contain computer models of "cells," or predefined logic elements, programmed by the vendor and used by the designer. They provide the "building blocks" for modeling all important aspects of an ASIC's performance, including timing checks, predictions of post-layout capacitive effects, delay uncertainties due to process variations, and performance variations due to changes in temperature, operating voltage, radiation, etc.

Vendors use two types of models to develop and verify cell libraries: SPICE (circuit-level) and switch-level models. SPICE models are at a higher level than process modeling and switch-level modeling is at a higher level still.

SPICE models perform steady-state and transient analyses to predict circuit performance. They use more approximate parameters for each logic component than those used during process modeling, and do not consider placement and routing. Therefore, process modeling must consider all electrical side effects due to component proximity before modeling at the SPICE level. Just as process models should verify transistor behavior before using SPICE, SPICE should verify cell behavior before using switch-level models.

Switch-level models consider only whether transistors are "on" or "off." Modeling on this level is considerably faster than SPICE since it does not consider capacitive, resistive, and other electromagnetic effects of transistor performance. This allows entire designs to be modeled, rather than individual cells.

Once developers satisfactorily model these cells at the circuit and switch levels, they feed the results to a model compiler in the form of a functional description, timing data, and physical data. The model compiler then generates cell models formatted for the vendor tool set and often also for other EDA tools.

Some model compilers are more automated than others -- the more automated they are the better. Automation reduces the risk of inconsistent models, reduces human error and tedious labor, allows cells to be updated more efficiently as the process and model accuracy improves, and above all, increases accuracy.

TOOL DEVELOPMENT

ASIC and EDA vendors must create and continually update tools (computer modeling environments) for users to set up ASIC and system designs that can be fabricated by the vendor. Typically, these tools model designs at the gate and cell level.

Tool development aims to assure that designs are "correct-by-construction." This means that if the tool accepts a given design and models its performance, the process will indeed be able to fabricate that design with its predicted performance. Achieving this goal requires that tools automatically check for adherence to design rules. Design rules such as minimum spacing between wire set standards to assure that designs are consistent with process capabilities. Besides circuit design tools, vendors must develop layout tools.

Layout tools determine and model the geometrical positioning of all components (known as "place and route"). Vendors usually run layout software once the users design logic for their ASICs. Users then apply information learned from place and route to account for interactions between components in their logic models (in steps known as "back- annotation" and "post-layout analysis"). Designers sometimes use an intermediate step, called floor planning, to approximate layout information. This enhances the accuracy of timing delay models and makes routing more efficient.

VENDOR EVALUATION ISSUES

When selecting a vendor, users should consider what tools they want to use and whether the tools support the vendor's library. If some library cells are not supported, users may consider translators that import missing cells. Since these translators are often expensive or unavailable, users may choose to write their own translators. Translators often reduce accuracy and thus reliability while adding days, even months, to an ASIC program. However, they can also save money by allowing a user to use tools they have already purchased rather than buying them new. For more information on tools, see Section Two: "Vendor Evaluation."

Modeling and the Design Cycle

Designers rely almost solely on modeling throughout all stages of the design cycle. In the previous section, we saw how vendors use process, SPICE, and switch level modeling tools to develop process and cell models. Vendors also develop tools which use process and cell models as inputs to higher-level models. Here, we focus on user responsibilities by explaining the ASIC design cycle and how modeling fits in.

ASICs are modeled on a variety of levels. From the top level to the bottom level, these are:

Hardware description languages (HDLs) provide the foundation for a relatively new top-down modeling strategy. HDLs cover multiple levels of modeling, from algorithmic behavior to gate level. HDLs are useful because they maintain a similar syntax throughout these modeling levels. Similar syntax improves translation accuracy between HDL models and HDL modeling levels. Similar syntax also allows simulating designs with components at different modeling levels. The flexible HDLs are just one of the many tools used in design systems.

Today's ASIC design systems include tools for synthesis, optimization, logic simulation, hardware acceleration, timing analysis, automatic test pattern generation, fault grading, and timing-driven layout. These tools allow designers to model as low as the gate level.

Ideally, design systems allow designers to design from the top level (requirements) to the bottom level (gate), assuming that the vendor's libraries have been previously modeled sufficiently at the levels below gate level. As ASIC technology matures, it is rapidly migrating toward this top-down approach.

ASIC PROGRAM MODELING FLOW

Figure A.1.2 represents the modeling flow during an ASIC program. The flow begins with system objectives, and ends with the fabricated ASIC. Rectangular boxes in this diagram represent modeling levels. Round-edged buttons inside these boxes represent types of modeling used for each modeling level.

The flow can be summarized as follows. Beginning with system objectives, the user defines ASIC and system level requirement specifications, using verbal or formal methods. Engineers implement these specifications by designing the ASIC at the gate level, or by translating these specifications to a hardware description language (HDL) which in turn synthesizes (produces) a gate-level model. HDLs can model at the behavioral, register-transfer, and logic levels. Designers then simulate their gate-level models, using all or some of the following automated analyses: functional, parametric, testability, radiation, thermal, mechanical, and manufacturability. These analyses either verify the pre- and post-layout models, or reveal the need to manually modify the model at the gate, hardware description, specification, or system objectives level.

The rest of this section addresses specific aspects of this flow in greater detail.


Figure A.1.2
ASIC Program Modeling Flow

In Figure A.1.2, three types of arrows connect modeling levels:

FORMAL METHODS

The space community has begun to consider using formal methods for manned missions and those classified as critical to our nation's interests. Formal methods in the engineering world are those methods that use mathematical (formal) languages for writing specifications to prove that highest-level specifications are consistent with top-level objectives. They have an advantage over verbal prose and conventional simulators because they can be used to represent specifications that are provably consistent with objectives and higher level specifications.

The mathematical basis of formal methods gives them a compelling advantage over simulation. The mathematical models cover entire ranges of possible inputs to a system, and can be used to prove that assertions are true throughout these symbolically represented domains. Simulation, on the other hand, cannot prove anything in general, since it is empirical rather than theoretical. This means it relies on specific test cases for analysis. Simulation can reveal inconsistencies on a case-by-case basis, but without an infinite number of these test cases, it cannot prove that there is not some untested case that would cause a failure. Formal methods not only have the power to detect the presence of inconsistencies, as in simulation, but also the absence of inconsistencies, through symbolically generalized formal proofs.

Although powerful, formal methods are extremely labor intensive and thus rarely used. Simulation often suffices for practically thorough verification. Today, formal methods for integrated circuits find utility only at the requirement, behavioral, and register-transfer levels. Even at these levels, they are extraordinarily time consuming. For lower level modeling, designers must translate formal specifications to other tools. Engineers must use formal methods carefully, since they have no benefit if engineers do not fully understand the system that the formal methods attempt to describe.

Formal methods help only to the extent that designers know what needs to be proven to make a system reliable. Thus, formal methods can prove that an already well-engineered system conforms with its objectives, but they cannot create consistency. In short, there is no such thing as formal development; only formal verification.

Also formal methods are useless if they implement less rigorously verified specifications. Proving that implementations agree with specifications only helps to the degree that the specifications represent top-level objectives, or that the specifications prove consistent with top level objectives.

In principle, formal methods can be applied at any modeling level, to prove that an implementation agrees with its specification. However, tools still need extensive development to make this a reality. As formal methods become more accessible, wise verification strategies will often involve a mix of formal methods and simulation.

HARDWARE DESCRIPTION LANGUAGES AND SYNTHESIS

Designers use HDLs to model ASICs at structural levels that are intuitive and quickly understood by other engineers. VHSIC hardware description language (VHDL) is a government and IEEE HDL standard. Synthesis automates gate-level design, using HDLs as specifications.

Synthesis is a powerful tool for translating a design from the HDL level to the gate level. Before HDLs became prevalent, requirement specifications were manually translated directly to the gate level. Automating gate-level implementations by using synthesis saves designers time and reduces human error. HDLs support three levels of ASIC modeling: behavioral, register-transfer, and logic. However, at present most synthesizers can only implement register-transfer level models to produce a gate level representation.

All HDL model levels (behavioral, register-transfer, and logic) describe ASICs in a Pascal-like procedural fashion. Behavioral models describe ASICs in terms of high-level functions, without considering registers or combinational logic. Register-transfer models describe ASICs at a lower level, by modeling them as a set of registers that change contents, ignoring the logic that induces the changes. Logic models describe ASICs at the lowest HDL-supported level, the gate level. Modeling an ASIC often uses an HDL description that mixes these strategies.

Not all HDL descriptions, even at the register-transfer level, synthesize into working gate-level designs. Usually, problems occur when accounting for timing. For instance, VHDL allows spikes to be dealt with differently for each port, whereas many other HDLs do not have such flexibility (spikes occur when an input changes before the result of the previous input propagates to the output).

Designers can also translate gate-level models to HDLs. This practice, called reverse synthesis, allows designers to either use HDL versions of old gate-level designs that were not first designed using an HDL, or incorporate them into new designs on an HDL platform.

TOOL EVALUATION ISSUES

Applying several criteria helps judge a particular tool's worthiness: proven accuracy, debugging thoroughness and efficiency (such as rule checks that occur during model entry and features to trace requirements from one specification level to another), execution speed, how much memory it requires, translatability, efficiency and thoroughness of its information management, and compatibility with existing tool sets.

Translation

Whether automated or manual, translation often impedes timely ASIC programs, and thus managers should plan for it. Engineers generally prefer automated translators since they are fast and less subject to human error. Most EDA tool sets include such automated translators that are largely transparent to the user. When automated translators are insufficient, under special circumstances the user or the vendor must write custom translators. However, custom translators can be expensive, inefficient, and unreliable. For low volume work, if the design data base uses ASCII format, then editing tools on Unix systems such as SED, AWK, and ED can help facilitate manual translation.

The trend toward design language standards reduces translation problems. However, standards still remain far from universal. VHDL, EDIF, and SDF are today's design language standards that simplify translation, but until one standard prevails, translation between standard and non-standard formats remains a monumental task.

Creating "universal" design language standards today poses a dilemma. Since the ASIC industry uses many platforms, languages, and formats, standards must support many design styles to achieve wide-spread support. This makes design language standards undesirably complex. Furthermore, this often drives developers of systems that use the standards to define subsets of the standards. Consequently, these subsets become incompatible with each other and in effect unmake the standard. Once developers deviate from a standard, then it is no longer a standard.

PLANNING FOR TRANSLATION

Planning for translation involves anticipating the efficiency of translation tasks. A good translator is efficient, inexpensive, and keeps information consistent. Good translators generally use standard formats and the vendor's tools support both the source and destination modeling levels. Engineers encounter troubles when they must use incompatible third-party tools due to insufficient vendor tool sets. They encounter another trouble spot when they must use non-standard formats.

Users anticipate and minimize translation problems by understanding the limitations of a vendor's tool set during vendor evaluation (see Section 2). QML and QPL specify that the vendor supplies all necessary design tools to the user, and handles placement and routing in house. However, the vendor may not adequately support one or more modeling areas, particularly in high- reliability applications. The user must weigh all issues regarding these deficiencies: availability or ease of writing translators to third party tools that fill the modeling need, and the efficiency and reliability of performing such translations.

DESIGN IMPLEMENTATION TRANSLATION MATRIX


Table A.1.1
Translation Between Models

Table A.1.1 shows a matrix illustrating several modeling levels. This matrix also shows if and how engineers can accomplish translations. The table represents successively lower levels of modeling along both the rows and the columns. Each cell in the matrix represents translating from the row modeling level to the column modeling level. Cells with dashes mean engineers rarely, if ever, perform translations. All other cells indicate whether translation is manual (no tool exists today to automate the process) or automatic. If the translation is automatic, the table indicates the type of tool needed. The table also offers other comments concerning possible problems, where appropriate.

There are many tools that can translate to and from ASIC and system levels:

SYSTEM LEVEL TO ASIC LEVEL

ASIC LEVEL TO SYSTEM LEVEL

TRANSLATION TO TESTER

There are several test vector standards, and translation between them is not an easy task. In some cases, third parties have translators, but they are always expensive. Test vector formats hopefully will become more universal thus reducing or eliminating format incompatibilities. WAVES, the IEEE VHDL test vector format standard, has the best chance of becoming universal. The most efficient way to minimize tester format translations is to use JTAG boundary- scan and full-scan testability schemes, since they are standardized and well-supported.

PERSPECTIVE

Modeling is the common rule in present ASIC work. Serious ASIC activity requires many modeling tools and a good understanding of their proper use. Process modeling tools now give vendor process engineers much more control over fixes and modifications to their fabrication processes. Synthesis tools and standards give designers a choice of design levels in which to work. They also support simulation at higher levels of abstraction, making system-level simulation and analysis possible.

Formal methods are in their infancy for use in ASIC design. However, as EDA systems become more powerful and formal method tools become more efficient, then formal methods can greatly strengthen the link between top-level requirements, specifications, and final ASIC parts.

In recent years EDA vendors have recognized that no one system can have every feature that users require. The solution that has emerged is known as "open framework" tool design. This approach allows designers to link tools more easily than in the past. Tool vendors enable linking by making public the nature of their data formats and tool interface designs. Vendors are also making additional tools just for creating links. Hybrid systems, customized to a particular users' requirements, result from this activity.

Modeling styles and tools changes almost as fast as microelectronic device designs. They can only increase in their importance to ASIC work as they continue to improve their accuracy and their ability to model new aspects of microelectronic technology.


Now you may jump to:


Home - NASA Office of Logic Design
Last Revised: February 03, 2010
Digital Engineering Institute
Web Grunt: Richard Katz
NACA Seal