The NASA ASIC Guide: Assuring ASICs for SPACE
Chapter Four: Information Management
Objective:To prepare ASIC manager to plan and supervise all aspects of information management including: creating and storing data for concurrent and future retrieval.
Planning and supervising information management poses a number of challenges for today's ASIC manager. Sound planning of this task cuts down development time and cost, increases your chances of a program with a successful first pass silicon, and anticipates future applications. Considerations include creating a data base that ensures and preserves the integrity of the information throughout the changes within your present ASIC program, provides easy access for concurrent engineering, and archives the data for future use.
Typically any NASA space project builds upon the information derived from earlier missions. We recommend you approach data management aware that the information you gather today will be called upon for future projects. Proper archiving, for example, offers tremendous benefits for design reuse and helps target a design data base to a number of vendors and various technologies.
This chapter will address how to document ASIC design and specifications, how configuration management works to control ASIC design changes throughout the various levels of development, and concurrent versus sequential engineering practices.
ASIC SpecificationWe cannot overstate the importance of a comprehensive ASIC specification and why managers must have a clear understanding of what makes a complete ASIC specification. Documenting, preserving, and verifying the specifications through partitioning, designing, simulation, analysis, and test generation processes will virtually guarantee a first pass working silicon. With the exception of specification changes, most of the second pass silicons in ASIC programs stem from ambiguities in device and system level specifications. Since comprehensive specifications provide the cornerstone of a successful ASIC program you must define a structure for complete and implementable specifications. The structure of an ASIC specification has to address: identifying the source and nature of ASIC requirements; creating specifications at different levels; and reviewing every specification for compatibility at each successive level.
IDENTIFYING THE SOURCE AND NATURE OF ASIC REQUIREMENTSASIC specifications emanate from several sources as discussed in Chapter 1 of this section. These sources include projects, systems, mission classes (NASA specific), and the vendor. The ASIC manager and the design group identify the sources and nature of these requirements, often with input from the vendor. Once identified, the requirements are partitioned into system requirements, detail design requirements, and test and screening requirements.
CREATING AND DOCUMENTING DIFFERENT LEVELS OF AN ASIC SPECIFICATION"Most second pass silicons in ASIC programs stem from ambiguities in device and system level specifications."
Once the design team identifies and partitions the requirements into the four major groups discussed above, they create the functional specification, detailed specification, and contractual support specification.
Lack of familiarity with tools can make the complex task of defining an ASIC in the functional specification a frustrating undertaking for the designer. Fortunately hardware description languages (HDLs) or high order logic (HOL) languages offer well- defined, implementable and verifiable formats for specifying the functions of an ASIC. These languages enable designers to describe specifications precisely and, using HOLs, to compare requirements for completeness and internal/external inconsistencies. For more on this subject, see Appendix One: "Modeling and Translation."
The most common HDLs are VHDL (VHSIC HDL) and Verilog. These languages provide designers with a high level design approach. They are in wide use especially on high-end workstation-based electronic CAD systems. The Department of Defense requires documenting ASIC designs in VHDL. Many ASIC vendors have VHDL or HDL entry points. Because of this, the market is flooded with various versions of VHDL, Verilog HDL, associated HDL to gate level synthesis, and HDL simulation products. There are even hardware VHDL accelerator products on the market.
Logic designers who have not used HDLs and have done most of their work at the gate-level will have to go through a learning curve. Rather than looking at a graphical representation of schematics, the designer deals at the register transfer language (RTL) level which is closer to a programming language like C or Pascal than a CAD schematic entry tool. Most of the CAE vendors will let you mix a number of circuit representations in their HDL environments. You can choose the format that best represents a particular portion of your design, whether RTL, Boolean equations, or state-transition diagrams, etc.
- Second sourcing support: Designs are usually first captured in a technology-independent form in which a significant amount of simulation and debug is performed. Vendor specific technology is targeted in later HDL design stages. Until a vendor is selected, there are usually many choices for the ultimate implementation of a design.
- Better management of complexity than gate-level design: Designers can run a design at a number of levels in the same environment. They can run tests back and forth between different levels of their design to ensure correspondence. For example, an entire system may first be modeled and simulated in VHDL models written at the behavioral level. When one of those models is later turned into an ASIC, its VHDL gate-level model with timing and other detailed parameters can be substituted into the system simulation to check out both the ASIC and the system.
- Automated tools for creation of gate-level models: HDL representations at the RTL-level can be synthesized into gate-level models using design compiler tools, special vendor cell libraries, and vendor-specific technology files. This can help consistency and accuracy in creating gate-level models. It also holds some promise in speeding up the entire design process.
HDLs Also Provide:
- standard design and simulation environment format for use with tools from various vendors
- hedge against obsolescence -- tools that work with a design represented in HDL should be available long after tools that work with a proprietary CAD format are no longer available
- verifiable return on investment -- standard tools and techniques help in estimating the costs of a design because many examples are available
Configuration ManagementDuring an ASIC development cycle, specifications will change many times. Vendor tools and libraries will also go through several updates. Even operating systems may see a revision during an ASIC program. Configuration management practices ensure that:
- ASIC data remains valid for both the current ASIC program and future applications that have been identified
- revision levels of libraries and tools used to design the ASIC are correct at ASIC sign-off time
- proper tracking is done for different wafer lots and lot splits for engineering and flight parts
MIL-I-38535 offers a number of definitions for changes in the areas of design, fabrication, assembly, packaging, testing, managerial procedures, business plans and calibration procedures. We encourage managers to study MIL-I-38535 for details of configuration management and change control. This chapter focuses on configuration management for ASIC design data bases.
Some important areas for change control are:
- tools (in-house)
- tools (outside vendor's or third party's)
- vendor travelers for:
- test procedures
- designer and vendor CAD platforms and operating systems
The QML program addresses most of the above listed issues. However, even if you work with a QML vendor, managers need to be familiar with these controls and how the vendor handles them. Pay attention to vendor design, in-house developed tools, personnel, and business changes. Address library and tools updates in the contract and watch for the other changes.
Concurrent Engineering (CE)CE allows many ASIC tasks to occur in parallel. This supports early trade-off work and early detection of interaction problems, thus trimming overall development time and shortening time to market or time to flight build. Examining a typical design group's evolution will help us better understand the pluses of CE.
During any development program, you plan a strategy to acquire workstations as well as other hardware platforms, operating systems, libraries, and tools, etc. This strategy should not only serve the current program but also look to future programs. Since a complex project is a multi-stage design process, each phase of design has to communicate across all tools, otherwise you can not manage them.
CE frameworks promise to help us alleviate some of the translator problems by providing a design management infrastructure. CE provides a link between archived information, storage and its mode of use. CE also demands that the tools and other data bases brought into that environment be open. Thus, you avoid writing translations and linkers because CE provides a common data access mechanism, data models, etc. Today's non-concurrent world with the sequential moving of data from one step to the next will soon become the thing of the past.
- Important considerations for planning and supervising information management include creating a data base that:
- ensures and preserves the integrity of the information throughout the changes within your present ASIC program;
- provides easy access for CE;
- archives the data for future use.
- The structure of an ASIC specification must address the following: identifying the source and nature of ASIC requirements; creating specifications at different levels; and reviewing every specification for compatibility at each successive level.
- Configuration management practices ensure that ASIC data remains valid for both the current ASIC programs and future applications that you have already identified.
- CE will provide an integrated environment that simultaneously addresses concerns of all disciplines and provides multiple users and tools with a common data base, thus enabling them to work in parallel.
- CE paves the way for interdisciplinary communication, intertool communication and tools encapsulation.
Now you may jump to: