Objective:
To provide ASIC managers with a structure to plan and
control the flow of an ASIC program.
As a manager, the success of your ASIC program rests upon sound
up-front planning and regular guidance.
Delivering a usable part calls for preventing multiple passes of
silicon, schedule slips, and budget overruns. To plan your program
right you need to understand the entire process of producing reliable ASICs, from initial
concept to part acceptance.
This section presents a framework for planning and controlling all
the essential processes and fostering the unique partnerships
between everyone involved in each step of the program. To ensure
the success of your project, you must properly establish this
framework with sound engineering and management judgment,
taking into account the specific requirements of your ASIC program.
Be aggressive in cultivating the sources of this "good
judgment." Make sure that you know your own organization's
ASIC resources. Don't hesitate to use the resources of your ASIC
vendors; the difference between a good ASIC vendor and a
commercial off-the-shelf (COTS) VLSI vendor is the depth and
experience of their customer support staff.
For managers interested in FPGAs, the last part of this chapter
outlines the guide's approach to these new devices.
The ASIC processes chart illustrates the steps and sequence essential
for a successful ASIC program. The ASIC manager must plan and
supervise each process, from setting requirements to delivery of
qualified flight ASIC parts. Figure 1.1.1 presents a flow of major
ASIC tasks.
The boxes in the top row represent the inputs to the processes.
The boxes in the center row of the flowchart represent the
processes.
Circled entities in the bottom row represent the outputs from that
process.
Note: Some processes generate outputs which are terminated.
Though shown in a rough chronological, single-threaded sequence,
the processes may interact in a more complex fashion. Some
processes may be completed once for multiple ASIC programs.
Others must be completed for every ASIC. Still others require
multiple iterations for a single ASIC program.
Figure 1.1.1 Tasks of an ASIC Program
A brief look at the central processes in Figure 1.1.1 follows:
Setting requirements focuses the work of an ASIC program.
When complete, the results of this process define the ASIC program
criteria and the ASIC's relationship to its system.
ASIC trade-offs ensure that use of ASIC technology will
provide a contribution to the ASIC's target system and to the overall
organization.
Vendor selection delivers the most important strategic
partner to an ASIC program.
Partitioning carves out the correct part of the system for
implementation as an ASIC.
ASIC implementation delivers a complete ASIC design and
associated design and test files.
Physical layout is ASIC design at the final level. The ultimate
results of this design work are fabrication masks used to build ASIC
parts.
Manufacturing produces ASIC dice assembled into
packages.
Test and characterization ensure that the manufactured parts
meet the goals of the ASIC design.
Part acceptance applies quality and reliability criteria to parts
delivered for flight use, screening out devices that show serious
potential problems.
The following are more detailed discussions of the processes in an
ASIC program.
Setting requirements provides the technical foundation that guides
all parties involved in producing a satisfactory ASIC. Often the
architecture or system design group provides the ASIC manager with
the requirements. Once set, these requirements generate the next
level of activity: assembling the necessary resources. Setting
requirements is the primary job of the ASIC manager. We
recommend accomplishing the following in conjunction with the
system-level design work:
- identify all sources of requirements
- propose a subsystem architecture
- derive functional specifications from a preliminary ASIC
partition of the subsystem architecture
- put specification control in place
- review specifications
For more on setting requirements, see Section Three: Chapter 2
REVIEW
At the end of setting requirements hold a specification review to focus on producing
clear and thorough ASIC specifications. Many times ambiguities in
the specification lead to second pass silicon. The ASIC may work well
as a stand-alone, but not in its target system. Since ASIC programs
have such long lead times relative to COTS VLSI parts, freeze the
specifications for ASICs and the interfacing systems early.
When a designer specifies an ASIC, managers must consider all the
trade-offs before approving the design. To determine if ASICs offer
the best solution, managers must weigh schedule, resources
(equipment, personnel, etc.) as well as performance, power, mass,
and board space budgets. Seeking information from groups with
previous ASIC experience can inject reality into a proposed ASIC
program. Check with an ASIC group within a NASA center, other
groups who have done ASICs, consultants, and ASIC vendors.
Perhaps ASICs may not be appropriate for the project. In this case,
the ASIC development flow terminates. If you decide to go with an
ASIC, then you must again return to a series of decisions regarding
implementation.
The major factors guiding system designers who choose ASICs
include: board space, performance, cost, and reliability. ASICs
provide many new ways to approach these issues.
Let's examine some of the trade-offs involved in implementing ASIC
methodologies and technologies.
Note: For those wondering about FPGAs, we are describing the
disciplines required to design with mask-programmable gate arrays
or standard cell ASICs. As FPGAs become qualified for space use
(radiation tolerance, sufficient proof of reliability, etc.), future
editions of this guide will discuss their use.
This guide considers two main approaches to ASIC design: gate array
and standard cell. However, over the past several years, ASIC
vendors have introduced a number of variations in architecture for
gate arrays and standard cells, such as "Sea of Gates,"
"Channeled arrays," and "Cell-Based Compilers or
Arrays."
In a gate array, the ASIC vendor prefabricates ASIC transistors in an
"array" and then fixes the array in position on a given
wafer (die). Interconnecting these transistors with metal wires in a
metallization process achieves logic functions. Typically, a designer
selects and interconnects logical elements (also known as cells) from
a gate array library; these have a predefined transistor design.
Sometimes a vendor will also supply a set of hard macros (super
macros) with a predefined circuit and hence predictable performance
parameters.
Gate arrays have resisted predictions of their demise over the last
ten years and have become the dominant form of ASIC technology in
terms of volume sold. A combination of ever-increasing gate
densities, low cost, first pass successes, and fast turn-around times
continues to make gate arrays the volume winner over standard
cells.
Each cell may differ in a standard cell ASIC. The vendor optimizes
the transistors for area and performance, predefines each logical
element, and makes "super-macros" available. As in the
gate array approach, design proceeds by selecting the proper library
cells and defining their interconnection.
The difference between gate array and standard cell ASICs lies in the
nature of the cell. Whereas the gate array cell consists of an array of
identical transistors, the standard cell consists of different size
transistors, optimized for the cell's function, allowing the standard
cell to have a smaller, faster cell for a given function than the gate
array. However, the desirable characteristics of the standard cell
require a completely new design at every layer of the chip. Gate
array chips differ only in the top metal-related layers.
For a qualitative comparison of different ASIC technologies and
processes, refer to Section Two: Chapters
2, 3, 4, and 5 and
Section Three: Chapter 2.
Vendor selection can determine the success of an ASIC program. An
unwise choice of technology, tools or vendor can prolong a schedule
and put severe strain on a budget. Section Two of this guide has
extensive discussion of vendor selection. We divide this activity into
technical and managerial selection criteria. For more information on
working with procurement on this and other ASIC activity, see Appendix Five: "Procurement
Support."
"How fast are their ASICs? How many usable gates can I get
for this offering? Do they support the Computer Aided Engineering
(CAE) software and platforms I have already invested in and am
familiar with? How much does it cost? How soon can I get my
parts? Will they be around for the next few years?" These are
some of the questions the ASIC team asks before the selection
process starts. Performance requirements, quality, reliability,
money, and time should govern your choice of vendors. While it may
be tempting to select a vendor with relatively fast published gate
delay data compared to the rest of industry, the astute manager will
take a more comprehensive look at vendor capabilities, including:
- vendor data on technology and tools
- vendor performance on important benchmarks for the ASIC
application
- inputs from previous users of the vendor
- inventory of available in-house CAE tools and input from CAE
tool vendors
Experience shows that it is wise to limit the number of ASIC vendors. It is not wise to switch vendors for
small incremental gains unless absolutely necessary because users
confront a steep learning curve for each vendor. Managing a vendor
proves a task in itself. Therefore, as an ASIC manager, it behooves
you to limit the number. You will invest time and effort to develop
productive working relationships with the vendors' applications, test,
and production personnel. These contacts become extremely handy
when problems arise--and they will.
REVIEW
Tools selection review takes place during vendor selection. Section
Two gives recommendations for forming an evaluation team to
conduct this review. The review assures all participants that the
correct mix of tools and technology is available to implement the
ASIC specification and satisfy all ASIC requirements.
The designers may partition the system functional specification into
one or more ASICs. They often do the partitioning in parallel with
"Vendor Selection" and "ASIC Trade-offs." To
aid these processes, you need to estimate the complexity of the
functional specification.
System architects and ASIC designers have a good idea of the general
partitioning from the time system level specifications are laid out,
though the specifications are generally incomplete at this point.
Accounting for system level interface and trade-offs when
partitioning avoids repartitioning in the middle of the design phase.
Test and performance requirements, global device specifications,
such as rad-hard specifications and testability specifications, must be
taken into account in functional partitioning.
For more on partitioning, see
Section Three: Chapter 2.
The element of design introduces the most
striking difference between using ASICs and off-the-shelf VLSI
components. For ASIC design, the guide places primary emphasis on
the optimum use of resources to satisfy specific performance and
reliability requirements. Consequently, design, along with its
verification and testability analysis, are the most important events of
an ASIC program. Verification includes simulation and test vector
generation, which play a key role.
The guide's methodologies focus on first-pass successful silicon. In
this guide, we define first pass silicon as: An ASIC device built from
the first preliminary design review (PDR) and
critical design review (CDR) design data base,
that works correctly in its system, both parametrically and
functionally, and requires no redesign. All processes in this flow
follow from this assumption.
For more on ASIC design, see Section
Three: Chapter 2. For details on modeling, see Appendix One: "Modeling and
Translation." For radiation issues, see Section Three: Chapter 4, along with the radiation appendix.
REVIEW
Two reviews occur during the ASIC design process: a schematic or
prelayout review and a PDR. The schematic review provides expert
confirmation that the design at this point, will satisfy the system and
other requirements. The PDR satisfies the vendor's experts that the
design is ready for successful layout.
"To determine if ASICs offer the best solution, managers
must weigh schedule and resources as well as power, mass, and
board space budgets."
When you arrive at layout the ASIC design verification should be
complete from your design group's perspective. After the PDR sign-
off and resolution of any outstanding device specific issues, the ASIC
vendor will perform, place and route, using their physical libraries
and the PDR-released data base. Vendors in most cases will
encourage the designer to participate in placing major blocks, critical
nets, and clock distribution networks.
Some vendors offer designers the choice of performing place and
route task themselves. Other vendors will not accept a client's
physical design data and require that they do the work themselves.
In the guide, we recommend the designer let the vendor perform the
physical design or place and route function. However, a standard cell
approach may be necessary for place and route.
After completing the layout, the designers review the back-
annotated resistance and capacitance values that arise from the
interconnects in the physical layout. These numbers reflect
reasonable estimates of the final design's worst case and best case
performance. This review consists of post-layout simulation and path
analysis to make sure no significant changes in function or
performance have occurred because of layout. The designers must
perform this analysis themselves as the vendor engineers lack
familiarity with the system application of the ASIC and are generally
unaware of the significance of minor variations in timing or other
performance.
In addition to the customer's post-layout analysis, make sure you
verify against the original system and device level specification. The
designer can supply the vendor with full functional tests and
comprehensive individual pin and pin-to-pin minimum/maximum
timing tests that absolutely ensure the successful operation of the
ASIC in its larger system. Most of the time the vendor's engineers
can modify the ASIC layout to meet these constraints, assuming the
design had adequate margins before layout. For more on physical
layout, see Section Three: Chapter
2.
REVIEW
A CDR takes place after completing the layout analysis. The CDR calls
for the customer's ASIC designer, the parts specialist, and the
technical contract manager to determine if the design and test data
base for the ASIC is complete and ready for the device to be built.
Note: Following the CDR, the vendor generates a pattern-generation
(PG) tape. After the PG the vendor expends significant resources.
Because of this incurred expense, typically the vendor requires the
equivalent to a "release to production," known as the
formal "chip sign-off." The sign-off notifies the customer
and designer that future changes will be expensive. At this time, the
device and test specification must be completed.
The manufacturing stage incurs significant expense. Vigilant
attention to the preceding steps will help this process remain cost
efficient, timely, and successful. The ASIC vendor will make masks
from the PG tape first and start the manufacturing process, which
consists of three phases: wafer fabrication, wafer probe, and
assembly process.
The vendor assumes responsibility for fabricating, probing and
sorting wafers, then assembles and packages good dice per
requirements. The vendor only involves ASIC managers or designers
in this process if there are problems discovered with wafer probe or
in the assembly process. The Qualified Manufacturers List (QML) and
Qualified Products List (QPL) programs cover a number of directives
concerning manufacturing processes.
The boiler plate and device-specific contracts, with the needs for
prototypes, engineering or flight parts, will determine the number of
wafer starts the manufacturer puts onto the manufacturing process
line. The vendor controls this process and notifies the customer's
ASIC program manager if there are deviations in schedule or if the
vendor encounters a fabrication problem. The vendor sorts good
wafers; from these good wafers, the customer accepts according to
the criterion specified in the contract. Good dice are then packaged
according to the contract. The vendor often has a standard minimal
test and screen for prototype parts.
The ASIC part the vendor supplies is required to meet the test and
characterization outlined in the contract. This means that the
customer's parts specialist must write the test and characterization
requirements in clear, unambiguous language. Section Four and QML and QPL
documents discuss test and characterization in great detail.
The vendor and the customer test and characterize packaged parts
according to detailed device specifications, the contract, and the
vendor's procedures. For Part screening tests discussions, please
refer to Section Four: "Part
Acceptance," QML part manufacture (MIL-I-38535), QPL
part manufacture (MIL-M-38510), and MIL-STD-883 documents. If
requested in the contract, the vendor assumes responsibility for
documenting unusable devices and their modes of failure in the End
Item Data Package deliverable.
Part acceptance procedures set requirements for manufacturers to
accept parts according to specified quality and reliability criteria.
Section Four, which covers part acceptance, discusses specific tests
required for either engineering parts or flight parts in detail. Usable
devices will be subject to the parts acceptance tests, quality
conformance inspection (QCI), or optional vector quiescent current
measurement (IDDQ testing) as well as any other
screening requirements called for in the contract for engineering or
flight parts.
REVIEW
After the customers have received delivery and analyzed the
engineering parts, a flight build review is
held. This review ensures that the vendor and customer have
satisfactorily resolved all issues that may negatively affect the
quality of flight devices. At a review, engineers examine issues such
as fixes, changes in customer requirements, and waiver status so that
the vendor can proceed to fabrication.
Contracting spans a number of the previously discussed ASIC tasks,
so we have left it until last. As an ASIC manager you need to
understand the strengths and limitations of ASIC contracting, both
formal contracting with the ASIC vendor and other outside
organizations and informal contracting with groups in your
organization.
Contracts determine the product that the manufacturer will deliver
and the required resources; they describe the electrical and
mechanical requirements, testing requirements, and radiation
requirements as well as the costs and schedule. Consequently,
contracting demands accuracy, particularly an accurate description of
the ASIC. Given the complexity of ASICs, this task may prove more
difficult than it sounds. We urge that you spend the time necessary
to ensure that the contracts clearly define the product you expect the
vendor to deliver.
The procurement group usually completes these contracts, but an
ASIC manager has to understand all these issues to support
procurement from the technical, cost, and schedule viewpoints.
There are two types of contracts: a general or boiler-plate contract
and a device-specific contract that contains a statement of work
(SOW) and device-specific references. The boiler-plate contract is
usually part of a procurement package and may apply completely or
partially to a particular vendor. The device-specific contract
discusses the design-dependent nature of an ASIC.
For example, a general contract defines all the generic requirements,
issues, etc., that apply to an ASIC vendor's gate array available in a
256 pin LCC. The Cassini program uses 11 of these gate arrays to
implement a variety of functions. Thus, there are 11 separate design-
specific contracts, each one defining its own SOW, its special needs,
and its detailed requirements.
Contracting within your organization contributes a great deal to ASIC
success. The most important contract within your organization will be
the technical device specification. This contract provides the basis of
agreement between the ASIC managers, the designers, and the
system group. Give it careful attention -- much more than that given
to a "theory of operations" or similar document you may
be used to working with for off-the-shelf-based system design.
Remember, the technical specification becomes the "data
book" for your ASIC. As such, it must have detailed functional
and parametric descriptions completed in a timely fashion so the
appropriate information is available for system design and outside
contracting.
For more on this subject and building a complete specific contract,
see Section Three: Chapter 1:
"Technical Specification."
FPGAs represent a new and promising technology for projects with
short duration and quick turn around that have moderate density
and performance requirements. These devices offer a cost-effective
way to bring ASIC technology to low volume systems that require a
consolidation of off-the-shelf "glue-logic" or functional
blocks of modest complexity. However, because of present
limitations, present FPGA technology cannot replace mask-
programmable gate arrays in every flight application.
FPGA devices consist of general purpose logic element arrays. In the
field, users configure these elements into various circuits by
programming logic cells and interconnections between them. Field
programming eliminates the interconnection mask fabrication step
required when using mask-programmable gate arrays. Thus, using
FPGAs drastically reduces design-cycle time.
At present, the industry offers four FPGA interconnection
technologies:
- Conventional fuses blown to leave the desired logic element
interconnects. These devices may not be reprogrammed.
- Anti-fuses (a low impedance connection) created to achieve
desired logic element interconnects. These devices may not be
reprogrammed.
- Latches that control a multiplexer or three-state buffer are
loaded with a controlling value to create the desired element logic
and interconnects. These devices require an additional memory
storage chip on-board to contain their interconnect configuration.
These devices may be reprogrammed.
- Electrically programmed and erasable structures, used to
establish element interconnects. These devices may be
reprogrammed.
The guide addresses the major steps needed to build a successful
ASIC program. However, the ASIC guide does not address the
intricacies or trade-offs involved in designing FPGAs. Gather this
information from such sources as:
- FPGA industry seminars
- text books on the subject
- college EE design courses
- Computer-Aided Design (CAD) tool vendor classes and seminars
Here we compare using FPGAs with using mask-programmable gate
arrays in a flight application.
Design
Four major differences exist between designing FPGAs and designing
mask programmable gate arrays: density, speed, granularity, and
design-cycle time. State-of-the-art FPGAs offer lower usable density
than mask-programmable gate arrays. FPGAs have approximately 10
times fewer equivalent gates. Also FPGAs run slower than mask-
programmable gate arrays.
As a rule, FPGAs run two to three times slower than equivalent
mask-programmable devices. Keep this in mind, as most FPGA
vendors quote very optimistic FPGA speeds in their specifications.
The level of granularity available to the designer differs for the two
types of devices. A mask-programmable device library has devices
(inverters) available with as few as two transistors. The smallest
FPGA library elements have at least twelve transistors. This can have
serious implications, especially when trying to resolve both too fast
and too slow timing delay problems.
When considering design cycle time, note that the mask-
programmable vendor has specific responsibilities in the ASIC design
loop after completing each design. The FPGA vendor, on the other
hand, normally has no direct responsibility after delivering the
unprogrammed devices. This lowers the cost and time required for
many aspects of an FPGA-based ASIC program.
Test
Testing FPGAs often requires programming the device before testing.
Testing FPGAs after programming presents difficulties not associated
with the same testing of mask-programmable devices. The vendor
can thoroughly test unprogrammed FPGAs as off-the-shelf devices.
However, testing FPGAs after programming identifies parametric and
logical problems not detectable before programming. Parametric
testing of programmed FPGAs requires specialized equipment that is
frequently not available to most design groups. Also designers must
often perform logical and functional testing of programmed FPGAs
in-situ. This prohibits using specialized stand-alone testers and
associated system-level test support equipment needed to exercise
all device functions through as many states as possible.
Present FPGAs have architecture and density limitations that usually
make design-for-test approaches (such as scan-design or IEEE
1149.1) too expensive. Therefore, test vector development can take
much longer for an FPGA design than for the equivalent design in a
mask-programmable gate array.
Here we address the similarities and differences between the ASIC
tasks for field-programmable gate arrays and mask-programmable
gate arrays.
Table 1.1.1: Comparison of mask-programmable to
field-programmable gate array tasks and responsibilities.
Table 1.1.1 offers comparisons between FPGA program tasks and
mask-programmable gate array program tasks. This table shows that
an FPGA program requires two fewer tasks than a mask-
programmable gate array program--physical layout and
manufacturing. Tasks shared by both types of programs occur in
different sequences. Some other tasks appear in a different
sequence.
The following tasks are essentially the same for FPGA programs and
for mask-programmable gate array programs:
- Set requirements: What device-specific and system-specific
requirements must ASICs meet?
- ASIC trade-offs: What is the best mix of ASICs and off-the-shelf
parts?
Although required by both types of programs, the following tasks
have some minor differences:
- Vendor Evaluation: Unlike mask-programmable gate array
vendors, it is not necessary to evaluate a FPGA vendor for post-
layout back-annotation capability to a user's design system.
However, back annotation is done by FPGA software because this
software optimizes and reduces the hardware.
- Partitioning: Certain FPGA design features may drive a different
partitioning than for mask-programmable gate arrays.
- ASIC implementation: Again, FPGA design features may drive a
different design approach than used for mask-programmable gate
arrays.
The following tasks, while shared by both types of programs, have
some fundamental differences:
- Test and characterization: FPGAs undergo an off-the-shelf test
and characterization program by the vendor that does not require
user-generated test input. However, users are responsible for any
post-programming test and characterization.
- Part acceptance: Again, FPGAs undergo an off-the-shelf part
acceptance program, but any post-programming yield-loss and part
acceptance work is the responsibility of the user.
While necessary for a mask-programmable gate-array user program,
the following tasks are not part of an FPGA user program:
- Physical layout: For FPGAs this is done independent of the user,
typically long before the user selects a particular FPGA.
- Manufacturing: No part of FPGA manufacture requires any input
from the user or user's design.
Summary
- Rapidly evolving ASIC technology continues to drive changes in
electronic circuit design and system design, adding responsibilities to
all phases of an ASIC program, particularly design. The manager
must understand the impact of these changes and establish a broad
range of checkpoints to ensure that the program stays on track.
- The end (acceptable parts) depends on the beginning (planning).
The ASIC manager must plan and supervise each process from
concept to delivery.
- Setting requirements provides the technical foundation that
guides all parties involved in producing a satisfactory ASIC.
- The ASIC manager uses the detailed specification as a
"completion contract" with the ASIC designer. The SOW
and the detailed contract serve as powerful tools for clearly
delineating the ASIC responsibilities of other groups within the
manager's organization.
- Contracting determines the part that will be delivered.
Consequently, contracting demands accuracy, particularly when
describing the ASIC.
- There are two types of ASIC vendor contracts: the general or
boiler-plate contract, and the device-specific contract, which contains
an SOW and device-specific references. The boiler-plate contract is
usually part of a procurement package and may be completely or
partially applicable to a particular vendor.
- To determine if ASICs offer the best solution, weigh schedule,
resources (equipment, personnel, etc.) as well as performance, power,
mass, and board space budgets.
- Vendor selection can determine the success of an ASIC program.
Choose a vendor based on your requirements; don't base your choice
on other factors that may be impressive in the industry but do not
affect your requirements.
- Partitioning determines what part of a system will be
implemented by an ASIC or ASICs and what part will be
implemented by off-the-shelf devices.
- Design, along with its verification and testability analysis are the
most important events of an ASIC program.
- When you arrive at physical layout, the ASIC design validation
should be completed.
- The manufacturing stage incurs significant expense. Attention to
the preceding processes will help keep ASIC manufacturing efficient,
timely, and successful.
- The part that the vendor supplies should meet the test and
characterization that you outlined in the contract.
- Nothing can substitute for sound management and engineering
judgment. An ASIC program cannot hope to succeed without a
detailed consideration and careful weighing of all important tasks.
- FPGAs can provide very economical solutions to several
"glue-logic" ASIC applications. However, compared to
mask-programmable gate arrays, FPGAs must be used with full
knowledge of their environmental, performance, design, and test
limitations.
Now you may jump to: