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

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 Specification

We 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 REQUIREMENTS

ASIC 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.

HDL Advantages:
HDLs Also Provide:

Configuration Management

During 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:

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:

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.

Summary


Now you may jump to: