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.
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.
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.
"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:
- 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
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:
- 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:
- requirements
- specifications
- design
- libraries
- tools (in-house)
- tools (outside vendor's or third party's)
- vendor travelers for:
- processing
- assembly
- test procedures
- package
- 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.
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
- 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: