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 CE or electronic designer 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
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 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 design 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 design engineers, CE specialists, 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 design 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
|
