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 One: Managing ASIC Development Tasks

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 Flow of an ASIC Program

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 Quick Look at ASIC Flow Major Processes

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

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:

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.

ASIC Trade-offs

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

GATE ARRAY

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.

STANDARD CELL

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

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:

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.

Partitioning

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.

ASIC Implementation

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.

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

Manufacturing

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.

Test & Characterization

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

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

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.

VENDOR CONTRACTS

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.

INTRA-ORGANIZATION CONTRACTS

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

Field Programmable Gate Arrays (FPGAs)

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:

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 DESIGN AND TEST

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.

FIELD-PROGRAMMABLE VERSUS MASK-PROGRAMMABLE TASK DIFFERENCES

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:

Although required by both types of programs, the following tasks have some minor differences:

The following tasks, while shared by both types of programs, have some fundamental differences:

While necessary for a mask-programmable gate-array user program, the following tasks are not part of an FPGA user program:

Summary


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