Assurance Plan for Complex Electronics:

Assurance Process: Detailed Design

This printer-friendly page contains the following sections:

• Detailed Design Phase
• Detailed Design Process
• Detailed Design Assurance

Detailed Design Phase

This Overview page for the Detailed Design Phase contains the following sections:

• Detailed Design Process
• Entrance Criteria
• Exit Criteria
• Roles and Responsibilities
• Detailed Design Site Map

Detailed Design Process

For complex electronics, the Detailed Design phase primarily consists of design synthesis. This process takes the architectural design (HDL code) and translates it into a gate-level design (netlist), which can then be mapped to the logic blocks in a complex electronic device. This step also optimizes the design to make the most efficient use of the target device. It is during synthesis that timing and area constraints can be specified by the user.

The diagram below shows the detailed design process for complex electronics. The Develop Detailed Design 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 design synthesis process.

• The complex electronics requirements should be complete and baselined. At this phase, uncertainties should be the exception, rather than the rule.
• Synthesis tools have been selected. The tools were evaluated to ensure that they will work with the HDL or other design input and that they will produce output for the target device.
• The preliminary (architectural) design is complete and simulations have been performed to verify the design.

Exit Criteria:

At the end of the preliminary design phase, the following criteria should be met:

• The design is approved and ready for the implementation phase.
• Worst case timing analysis has been performed.
• Simulations that include timing have been performed.

Roles and Responsibilities

The table below describes typical activities during the Detailed Design Phase for both engineers and assurance personnel.

Detailed Design Phase
Role	Typical Activities
Systems Engineer	No activities relating to the complex electronics.
Electronics Designer	Assess any timing issues and design changes.
CE specialist (optional)	Synthesize the design. Perform verification of the synthesized design, including static timing analysis.
System Safety	No activities, unless the design changes.
CE/Quality Assurance	Process assurance activities. Assess the quality of the simulations.

Detailed Design Site Map

The table below describes the information contained on the other pages in the Detailed Design section.

Detailed Design Site Map
Overview	This page
Develop Detailed Design	The process of design synthesis 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 detailed design, with links to specific techniques.

Detailed Design Process

During this phase the high-level architectural design is translated into a structural description on the level of elementary cells of the selected technology/library. For digital designs, this structural description is a gate-level pre-layout netlist. The netlist is verified by the engineer to meet the requirements and goals, through simulations and timing analyses. In addition, information is generated for the subsequent implementation phase, such as layout constraints, floorplanning, production test programs and a detailed pin description.

The translation process is called synthesis. Synthesis is performed almost exclusively by a software tool. Modern synthesis tools do an excellent job optimizing complex designs, so designers do not need to manually perform that task. However, user input to the tools does have an effect on the output. These timing-driven tools perform complex trade-offs to achieve the timing constraint you specify, including adding extra parallel logic to paths where there is negative timing slack, or optimizing a critical path at the expense of a non-critical one. When you over-constrain a design, the tool sees many, many paths that don't meet timing and can generate lots of extra logic in a futile attempt to make all of them hit the timing goals. This can result in a much larger design with reduced overall timing performance. In a timing-driven tool the idea is to give the tool the real timing specifications, and let it work to meet that goal. Once that performance has been met, the tool will start optimizing for less area which translates to cost savings in your device. This can produce an even faster design because routing delays can be reduced by having less logic in non-timing-critical areas.

The main output of the Detailed Design is a set of scripts or other inputs that allows an automatic and repeatable generation of the above-mentioned inputs to the Layout. Repeatability in generating the inputs is essential to maintaining configuration control of the design. The scripts and other inputs should be included in the configuration management system.

This section covers:

• Netlist generation
• Netlist verification
• Verification Methodologies
• Documentation
• Engineering Design Review
• Good Design Practices

Netlist generation

In this step, the source description of the design is translated into the netlist, and any other information required for the layout generation, such as floorplan/placement information, constraints for timing driven layout etc. is generated. Iterations between design entry (part of the preliminary design phase), netlist and layout generation are required most of the time. Keep in mind that iterations back to the Architectural Design, by means of changes in the HDL model, will require re-verification of that model and should be avoided as much as possible.

The following tasks should be performed in generating the netlist (synthesizing the design):

• Include the required derating factors.
• Ensure that the appropriate library cells are used as to fulfill all the requirements collected in the Requirements Specification.
• Ensure that the intended operating (process, voltage, temperature) and environment (radiation) conditions are considered during the translation and verification activities.
• If synthesis tools are used, generate the scripts which allow performing the fully automatic pre-layout netlist generation in a repeatable way. These scripts being part of the inputs to the design, should follow the general requirements for documentation and commenting, and will be configuration managed.
• Timing constraints and vendor-specific design rules should be taken into account.

Netlist verification

Verification of the netlist is performed by the design engineer, though it never hurts to have an independent engineer check over your work. The following activities should be performed as part of the verification tasks:

• Perform gate level simulations, if possible using the complete test suite from the architectural design, or an equivalent set of methods, such as formal verification and static timing analysis.
• Verify key parameters, such as bias voltages/operating point, frequencies, bandwidth, matching, s-parameters, noise, dynamic and linear ranges, shaping times, etc.
• Verify functionality, including the interfaces.
• If a complete simulation of all modes (including test modes) at top level can not be performed (e.g. due to run-time restrictions), a representative subset must be simulated, and the cases not simulated can be verified by an extrapolating analysis.
• Verify that the specified test concept is implemented through scan paths, Design For Test (DFT) logic, measurement points, test busses, etc.
• Verify that the radiation-hardening concept is successfully included in the netlist. Consider performing a netlist inspection or SEU injection simulations.
• Verify that the specified power consumption is respected.
• If production tests or a pre- and post burn-in test are foreseen, generate the test vectors and verify the requirements for fault coverage.
• For IP cores and macro cells, include the core's test patterns in the overall test programs

Verification Methodologies

Several verification methodologies are commonly used in ensuring that the complex electronics design is correct. These methodologies are 1) assertion based, 2) transaction based, and 3) randomized.

Assertion based verification defines properties that are expected to be true in the design, and then verifies that they are indeed true. A property is a collection of logic and time relationships that characterize a design. The process of checking that the assertion is true can be performed dynamically during test, if ASSERT statements (VHDL) are included in the HDL model. If the ASSERT is never seen, then the property is true (assuming adequate testing). If it is seen, then the property is not true. Assertions can also be verified through model-checking, a "light" version of formal methods, or through a combination of the two methods. One advantage of using assertions is that the location of the error is clear. The error is located where the ASSERT statement is that triggered. Another advantage is that the assertions are included in the design for its lifetime.

Transaction based verification increases the level of abstraction of the test bench to improve productivity. The test bench is separated into two layers. The top layer is the tests, which orchestrate transaction level activity in the system without regard to the specific detail of signal-level protocols on the design's interfaces. The bottom layer is the transaction verification model (TVM), which provides the mapping between transaction level requests made by the tests and detailed signal-level protocols on the design's interfaces. With the separation of responsibility into these two layers, many new and complex tests can be developed quickly, as the detailed protocols are already captured in the TVM layer. One advantage of this approach is increased simulation speed. It also allows for stepwise refinement from functional testing down to clock-cycle accurate testing.

Randomized verification involves creating directed tests that target specific functionality or parts of the design. The tests have to perform valid operations for the design, but the contents and order of the operations are random. The main advantage of this strategy is that many small randomized tests are performed instead of one large directed test. This test strategy can also find unexpected bugs, because the random order of operations is more "real world" than the logical test prepared by the engineers. In most projects, directed tests are performed first, and randomized tests are added in critical or problematic areas of the design to flush out any remaining bugs.

Documentation

The complex electronics design information should include the results of the simulations and tests, and identify values (such as timing) that were selected during the design synthesis. The format of the documentation can be informal, especially for low criticality devices. A design folder (physical or electronic) can be used to gather all the information. The main goal is to have the final data, as well as information about why those values were selected. Documenting decisions, especially when they involve trade-offs, is a best practice for any design.

Engineering Design Review

The Engineering Design Review (EDR) is an in-depth review of the design by engineers and assurance personnel within and external to the project. The goal is to find any problems with the design prior to it being programmed into the production (flight) boards. The EDR is often a formal review, with a chair who is independent (not part of the development for that device, preferably from another project) and several board members. The EDR follows the same format as other project formal reviews, with a presentation by the engineers, board discussion, and formal actions. Minutes are taken of the review. Action items are documented and tracked to closure.

Information presented at the EDR must be readable to those not familiar with the complex electronics. Block diagrams, flow charts, and other graphics aid in understanding. HDL code is often meaningless to the reviewers without supporting information, such as the synthesized logic for the module.

The EDR presentation should cover the following topics:

• Updated requirements, with a verification matrix showing how they will be verified.
• Details of the design
• Interfaces between the device and other elements of the system
• Constraints imposed by the design on the system or operations
• Fault protection or other safety features

After the formal presentation, the EDR board should evaluate the design in greater detail. This process can be done as a design walkthrough, presented by the design engineer, or as individual reviews with a group discussion. Regardless of the format chosen, the main items to consider during this review are:

• Single Event Upset (SEU) mitigation
• Noise effects
• Power up/Power down/Reset transients
• Worst case simulation (process, temperature, radiation)
• External failure impact through inputs to the device.
• Handling of Finite State Machine illegal states
• Decode glitches
• Appropriate use of global clock signals
• Resynchronization across clock boundaries
• Timing analyses
• Interfaces with COTS IP modules
• Interfaces to other parts (input logic level thresholds and maximum input transition times)
• State machine:
• Unused states and lock-up
• Simultaneous assertion of flip-flop sets and clears
• Reset conditions

Good Design Practices

• A modular design makes testing and simulation easier.
• Use spare pins to increase observability during debug and test
• Build a test board to verify over temperature and over voltage effects
• Add test points to the flight board to help debug and test
• Make sure the board tests verify the complex electronics functions
• Verify margins on critical signals
• Avoid using probe/diagnostic pins for application signals
• Do a static timing analysis in both worst and best case corners
• Perform code coverage analysis of simulation and test vectors

Detailed Design Assurance

At the detailed design (synthesis) phase, assurance engineers are not deeply involved with verifying the design. The majority of assurance activities are process assurance oriented, such as:

• Verify that the design process, as defined in the project plans, was followed.
• Verify that the tools specified in the previous phase are the ones that are being used.
• Verify that the configuration management system is being used as defined in the project plans. Ensure that any scripts used in synthesize are identified and controlled.

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 detailed design include:

• Engineering Design Review
• Process Verification
• Update Risk analysis

Every method listed above does not have to be applied to every project. 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.

Tailoring Guidance for Assurance Activities - Detailed Design Phase
	Low	Moderate	High
Engineering Design Review	Informal	Formal	Formal, with engineering expert
Process Verification	Informal	Moderately formal	Formal Audits
Risk analysis	Informal	Informal	Formal

Engineering Design Review

The Engineering Design Review (EDR) is an in-depth review of the design by engineers and assurance personnel within and external to the project. The goal is to find any problems with the design prior to it being programmed into the production (flight) boards. The Engineering Design Review is discussed in the Develop Detailed Design page.

Process Verification

Process verification is an activity performed at each life cycle phase. The plans that were generated at the beginning of the project should be followed as the complex electronics is developed. Assuring that the processes are followed is one way to help the project stay on track. Processes are not written in stone, but can be changed to reflect project reality. One result of process verification is to advise the project when updating the processes is a necessary activity.

For the detailed design phase, the assurance engineer will:

• Verify that the entrance criteria were met before the project moved into this phase. If not, document the increased risk due to non-approved architectural design or other issues. Provide risk mitigation suggestions to the project.
• Verify that the exit criteria are met before the project moves to the Implementation phase. If not, document the increased risk due to non-approved design or other issues. Provide risk mitigation suggestions to the project.
• Check that the Design Description and other documentation are complete and documented in a level of detail sufficient to proceed with the Implementation.
• Check that the planned measures, tools, methods and procedures have been applied.
• Ensure that the complex electronics detailed design is under configuration control. At the end of the phase, ensure that the detailed design is approved and baselined.
• Verify that all planned activities for complex electronics were performed.

Additional assurance activities require someone with expertise in complex electronics. They can be performed by the quality assurance engineer or by an engineer independent of the project.

• Review the constraints specified by the design engineer as input to the synthesis process for reasonableness.
• Assess the simulations that were performed after design synthesis is completed. Did the addition of timing information affect the outcomes of the simulations? Did the simulations look at worst-case timing, including on incoming signals?
• Ensure that timing simulations or static timing analyses were performed.
• Verify that the simulations performed included out-of-range inputs, inputs that arrived in an incorrect order, and other “real world” problems that can be anticipated.

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