Assurance Plan for Complex Electronics:
Assurance Process: Implementation
This printer-friendly page contains the following sections:
Implementation Phase
This Overview page for the Implementation Phase contains the following sections:
- Overview
- Implementation Process
- Entrance Criteria
- Exit Criteria
- Roles and Responsibilities
- Implementation Site Map
Overview
Once a design has been created, simulated, and synthesized, the next step is implementation of the design in the particular complex electronic device. The implementation process uses the tools supplied by the device (e.g., FPGA) vendor. The functions that were defined in the design have to be matched to the available blocks, gates, and other logic elements on the chip. Some basic steps in implementing a design are:
- Floorplan
- Translate
- Map
- Place and Route
Floorplanning is the process of identifying structures that should be placed close together, and allocating space for them. In designing complex electronics, there are multiple goals that must be met, and the goals often conflict. Finding the best balance between the various goals and requirements is something of an art. Some goals are:
- Minimize space on the chip (allows choice of less costly chips)
- Meet or exceed required performance
- Place everything close to everything else to minimize transmission time in the signal paths
Translation involves converting the results of the synthesis process to the format supported internally by the vendor's place-and-route tools. The incoming netlist is checked for adherence to design rules and is then optimized for the chip.
Translation may also be referred to as compilation or compiling. This process is automatic, but it takes some wading through the reports produced by the tool to verify that the translation/compile was correct. An intelligent post-processor, rather than the designer (or worse, the quality assurance engineer), should be used to find syntax and binding errors - otherwise you will have to do this for each design modification!
Mapping takes the logic blocks and determines what logic gates and interconnections on the device should be used to implement those blocks. During the mapping step, the functions within the device (such as counters, registers, or adders) are aligned with the logic resources of the chip. The exact process is device dependent. For example, FPGAs have look-up tables that perform logic operations. The mapping tool (part of the vendor's tool suite) collects the gates defined by the netlist into groups that will fit within the look-up tables.
Place and Route is the process of placing the logic blocks in the best spots on the chip to achieve efficient routing. Items that the place and route tool will look at include routing length (how far does a signal have to travel), track congestion (how many signals are coming into or out of an area), and path delays. While the process is usually performed automatically by the vendor-supplied tools, the designer can specify some parameters and constraints that the final layout has to meet, including:
- the initial placement of the cells
- a position for each physical connector
- a form factor
Programming the device
Once the design is successfully verified and found to meet timing and performance requirements, the final step is to actually program the device. At the completion of placement and routing, a binary programming file is created. It's used to configure the device. The process of programming is usually dependent on the type of memory used to store the device configuration and on the device type (e.g., FPGA or ASIC). ASICs are manufactured, rather than programmed by the end-user, and verification of the design if critically important. Re-generating an ASIC is costly, both in dollars and in schedule time. FPGAs and other programmable devices are programmed by the end-user, either in-circuit or in a special programming device. Usually, a software tool running on a PC will interface with the programmable device and download the program using the appropriate format.
Implementation Process
The diagram below shows the implementation process for complex electronics. The Develop Implementation page describes the engineering process to create the design. The Assurance Process page describes the activities to assess and verify the design.
Entrance Criteria:
The following criteria should be met prior to beginning the implementation process.
- The design is reviewed and approved.
- Design synthesis was successful.
- Design verification and simulation was successfully performed.
Exit Criteria:
At the end of the implementation phase, the following criteria should be met:
- The device is programmed with the design.
Roles and Responsibilities
The table below describes typical activities during the Implementation Phase for both engineers and assurance personnel.
|
Implementation Phase |
|
|
Role |
Typical Activities |
|
Systems Engineer |
No activities relating to the complex electronics. |
|
Electronics Designer |
Ensure the interfaces have not changed. Work with CE specialist to resolve any issues, especially regarding timing. |
|
CE specialist (optional) |
Implement the design in the chip, including programming the chip (if not an ASIC) and performing post-layout and other testing. |
|
System Safety |
No activities, unless the design changes. |
|
CE/Quality Assurance |
Process assurance activities. Start problem trend analysis. |
Implementation Site Map
The table below describes the information contained on the other pages in the Implementation section.
|
Implementation Site Map |
|
|
Overview |
This page |
|
Design Implementation |
The process of implementation for complex electronics. This is a high-level overview only, and is not sufficient information for an engineer to perform the activities. |
|
Assurance Process |
Describes the assurance process for complex electronics implementation. |
Implementation Process
Layout is a general term that includes floorplanning, mapping, translation, and place and route. The layout process generates the placement and routing information to meet the design rules, timing and other constraints. This phase provides reliable information about loads and coupling capacitors and the final design rule check that assures a verified netlist which can be forwarded to the foundry (if an ASIC) or programmed in the chip (if a programmable logic device).
This section covers:
Layout generation
The following tasks are performed as part of the layout process. As with all tasks within a complex project, the process and results of the various tasks should be documented in some manner.
- Finalize the floorplan of the chip (ASIC primarily)
- Perform Place & Route (P&R) taking into account all layout constraints
- Perform netlist optimizations for timing and design rules if necessary
- Generate the power distribution
- Generate the clock distribution (clock tree and buffers)
- Insert core and pad ring power distribution and possibly additional test pads in the circuit
- Determine the die size (ASIC only)
- Generate the bonding diagram respecting bonding and package constraints (ASIC only)
- Generate the Input Data for Mask or Programming file generation (IDMP).
Layout verification
Once layout is complete, it has to be verified to be correct before it is programmed in the device or sent to the manufacturer. The following tasks are typically performed:
- Layout Design Rule Check (DRC).
- Electrical Rule Check (ERC), check cross-talk sensitivity.
- Extract a netlist from the layout given in terms of IDMP.
- Verify that the post-layout netlist is consistent with the layout representing IDMP by performing a Layout Versus Schematic (LVS) comparison, or by performing a Netlist Comparison Check (NCC) between the post-layout netlist and the layout (IDMP) extracted netlist.
- Verify that the post-layout netlist is consistent in terms of functionality with the pre-layout netlist by simulation and/or formal methods.
- Extract the parasitic information. This delivers capacitance, resistance and inductivity values (only deep sub-micron technology), from which the actual delays are calculated for digital designs.
- Perform comprehensive post-layout verification. This is mostly accomplished by back-annotated simulations and timing analysis.
- Check relevant timing of l/Os.
- Perform transition check and load check on the nets inside the ASIC.
- ASIC/FPGA performances shall be characterized, such as max clock frequency, clock duty cycle, set-up and hold times for all inputs, and propagation delays for all outputs.
Manufacturing and Programming
ASICs require many more steps than are provided here. Once the layout is complete and verified, the chip is sent to a manufacturer for production and testing. Additional tests are performed once the chips are returned, to verify functionality and correct operations.
FPGAs and other programmable devices require some form of "burning" to program the device. This is handled by a combination of software (on a desktop computer) and the programming device. The programming can, and should, be verified to be correct, possibly through a checksum or CRC value or by "reading out" the program and comparing it to the correct version.
At this point, the design has transitioned almost completely into the realm of hardware. The next phase is testing to verify the device implements all the requirements.
Implementation Assurance
During the implementation phase, the higher level design is converted into a chip layout. The implementation process uses the tools supplied by the device vendor to match the functions that were defined in the design to the available blocks, gates, and other logic elements on the chip.
Much of the implementation process is performed by automated tools, so the assurance and safety engineers are usually not involved in any depth. The majority of assurance tasks are process verification
Use the Tailoring chart to determine which activities or analyses are required for a particular criticality classification. Activities that are not required may still be performed, if desired. Assurance activities for complex electronics implementation include:
The table below uses the Complex Electronics Classification to map the activities, and depth of each activity, against the classification. This table allows for easy tailoring of the assurance activities to the device complexity and criticality.
Problem Trend Analysis
Problem Trend Analysis identifies repetitive problems and assesses how often given problems occur. It also provides a mechanism to track progress of problem resolution. The main objective of this analysis is locating where key problems are occurring and the frequency of occurrence.
Problem Trend Analysis is more of a system-wide activity, rather than focused solely on complex electronics. As such, it should be performed by the quality assurance or systems engineer, to understand where problems are occurring. Regardless of who performs the analysis, a knowledgeable assurance engineer needs to review the problem reports that relate to the complex electronics (and the board, etc. that the chip is part of). Pay particular attention to problems that could indicate design errors in the complex electronics. Also note the number of unexplained anomalies that might relate to the device.
More detail on Problem Trend Analysis can be found in Section 8.2 of NASA Reference Publication 1358, System Engineering "Toolbox" for Design-Oriented Engineers
Process Verification
- Verify that the design process, as defined in the project plans, was followed.
- Verify that the tools specified in the project plans are the ones that are being used. Note any discrepancies and the rationale for using a different tool.
- Verify that the configuration management system is being used as defined in the project plans.
- Verify that the device is programmed according to a defined process and that it is witnessed by appropriate personnel (usually quality assurance).
- Verify that post-layout and post-programming verifications are performed. Record any anomalies or problems using the appropriate problem reporting process.
- Assess problem reports relating to complex electronics for adequate root cause identification and appropriate corrections.
Update Analyses
Analyses performed during the requirements phase should be updated at this time.
Risk Analysis
Evaluate previous risks to identify those that no longer apply or that have changed their priority based on changes in probability or impact. Identify any new risks relevant to this phase of development and determine which require mitigation plans. Check that preventive measures and/or contingency plans exist for all identified risk items and that the risk, with mitigations in place, is acceptable for moving to the Testing phase.
Other Analyses
The other analyses, FMEA, FTA, Interface, Traceability, and Criticality Mapping, do not require updates during this phase, unless there is a design change.