Improving test coverage

This article covers the various techniques/flow/suggestions that can be used to improve the test coverage.

Black Boxes:
Black boxes are source of X in the design. These Xs blocks the fault detection. Always try to have least number of black boxes. The faults on the pins of black-boxes will never get detected. It will be a good idea to remove these faults. If the outputs of the black box are known to be constant, then model it accordingly for better coverage. (Refer to the SolvNET articles listed at the end)

Bus Behavior:
For external bidi pins, if the target tester understands the Z state then enable the same with command set_buses external_z Z The default value for this is X, which affects the coverage.

Constraints:
Check for all the constraints that you are putting on a design. Each constraint reduces the test coverage. Sometimes there are legacy scripts and a constraint which was used in a given project may not be needed. The various constraints are add_pi_constraints add_atpg_constraints add_cell_constraints add_capture_mask add_po_mask set_delay nopi_changes set_delay nopo_measure add_slow_bidi

(For At-Speed Test) (For At-speed Test) (For At-speed Test)

Exceptions:
Exceptions are generally for the At-speed Test, but sometimes they are there for the Stuck-At fault test also. The command to use exceptions for Stuck-At fault model is set_simulations -timing_exceptions_for_stuck_at Exceptions are read in TetraMAX in the form of SDC file.

The test environment is different from the functional environment. Check if the SDC file is for the TEST mode or functional mode. In functional mode there can be a number of exceptions which are not needed in TEST mode. These unwanted exceptions can decrease the coverage. In case of compression based designs these exceptions pose one more problem of Xs. Any Xs can affect both your coverage and number of patterns. It is recommended to use the flow as given in TetraMAX User Guide under utilities chapter. Topic: Converting Timing Violations into Timing Exceptions

Memories:
Mostly all the designs will have memories. For best coverage with memories it is recommended to have the simulation model of the memory and use the fast sequential ATPG engine with capture cycle more than or equal to 4. Even if the simulation models are available check that these models are usable. Check for the DRC violation S30, C20 , C21 and other related to memory. If you have these violations then memory model is not useful in improving test coverage. If fast sequential engine cannot be used or there are no ATPG models available, then implement memory bypass logic in the TEST mode.

Non-Scan cells:
Mostly the designs have non-scan cells. Depending on the behavior, even these non scan cells can be useful in increasing the coverage. During the DRC checks each nonscan cell is assigned a behavior type indicating how the cell is used for scan-based fault simulation and test generation. These are the nonscan behavior types: C0 (constant zero) - This is a nonscan cell that has been initialized to a 0 state from the test setup procedure and will always retain that state in the presence of the current PI (primary input) constraints. C1 (constant one) - This is a nonscan cell that has been initialized to a 1 state from the test setup procedure and will always retain that state in the presence of the current PI constraints. CU (clock unstable) - This is a nonscan cell that does not have clock-off stability and does not qualify to be a transparent latch (described below). L0 (load 0) - This is a nonscan cell that has been set to a 0 state at the end of the scan chain load, but is not restricted to always retain the state. L1 (load 1) - This is a nonscan cell that has been set to a 1 state at the end of the scan chain load, but is not restricted to always retain the state. TLA (transparent latch) - This is a nonscan DLAT that is not stable when all clocks are off. This allows it the opportunity to behave as a transparent latch when one of its clock inputs is active while the other clock/set/reset inputs are inactive. The transparency condition must occur at the force_pi time of a pattern when all clocks are off. LE (leading edge clock behavior) - This is a nonscan DFF that is stable when all clocks are off and the clock-off state results in a 0 on its clock input lines. An LE cell captures data on the leading edge of a clock pulse. TE (trailing edge clock behavior) - This is a nonscan DFF that is stable when all clocks are off and the clock-off state results in a 1 on its clock input lines. A TE cell captures data on the trailing edge of a clock pulse. LS (level sensitive behavior) - This is a nonscan DLAT that is stable when all clocks are off. For Basic Scan ATPG L0, L1, C0, C1 and TLA can be used. For Fast sequential ATPG. Along with the above the LE, TE and LS cells can also be used. If you have a number of CU non-scan cells then your coverage may be affected. Try to have a design with maximum number of flops on the scan chains for best coverage.

DRC Violation:
Each DRC violation in the design affects either the coverage or quality of the pattern generated. Check each violation and see if it hits the test coverage. Resolve these violations to minimum possible. Some time it may warrant a design changes.

Clock-Gating and Bidi-fixing:

Use scan enable port for the clock gating cells TE hookup and for fixing the direction of bidi ports. This gives the ATPG tool more freedom. Using testmode port restricts it to be always one where as scan enable can be 1 or 0 as required by the pattern. The diagram below gives the coverage difference when Testmode is used vs scan enable.

LE-TE logic:
In case the design has lot of logic where data is fed from LE to TE (Leading edge flops to trailing edge flops), then coverage may be improved by using set_atpg -lete_fastseq and using the fast sequential engine. When the -lete_fastseq option is set, Fast-Sequential ATPG will be target faults based on Leading Edge (LE) Trailing Edge (TE) relationships between sequential elements. With -nolete_fastseq (the default),Fast-Sequential ATPG will target all the faults as if there is no such LE/TE clocking relationship, which is the typical mode of fastseq ATPG. The -lete_fastseq option is intended to get extra fault coverage when there are many faults whose detection depends on LETE effects.

New capture on Trailing Edge Device:

The simulation behavior of trailing-edge (TE) devices is to always capture the state after the leading-edge (LE) and level-sensitive (LS) devices have captured. Creates patterns that are much more likely detect such target faults, this includes: Leading edge to TE state elements LS to TE state elements LS to LS state elements

The default is -nonew_capture

Abort Limit:
If there are too many ND faults at the end of the ATPG. Run ATPG with increased abort limit. It is recommended to increase the abort limit in steps otherwise the runtime is affected.

ATPG Engine:
If basic scan does not gives the desired coverage, then use the fast and full sequential engine.

Inserting Testpoints:
If design changes are permitted, then a testpoint analysis (What if) can be done in TetraMAX. run_testpoint_analysis: This command controls test-point insertion based on undetected fault topology.

Refer to the man page for more details.

Analyze X sources:
Use the command set_simulation -analyze_x_sources to find X generating sources in the design. These X sources lead to both decreases test coverage as well as an increase pattern count. The following X source types are considered: User capture mask Cell constraint to X Capture masking due to any of the following rule failures: S29, S18, C1, C5, C6, C7, C8, C9, C10, C11, C12, C13, C14, C22, C25. Clock disturb Multiple clocks on Clock at X Excess simulation passes Timex simulation Capture X from any of the following: nonscan cell, transparent latch, scan master, scan slave, scan dslave, scan shadow, RAM, ROM, TIEX, global TIEX, TIEZ, global TIEZ, floating BUS, contending BUS, from tristate driver, WIRE, PI, or feedback path Unknown capture X source Unknown simulation X source

Analyze X Effect:
Use the command set_simualtion analyze_x_effect to see how many Xs are there in an individual pattern for each shift. This command assists the above command to analyze the Xs in the design further.

Hierarchical Browser:
The Hierarchy Browser displays a designs basic hierarchy and enables graphical analysis of coverage issues.

As shown in figure above the data displayed in the Tree map is color-coded according to the test coverage. Dark green indicates the maximum coverage, light green is slightly lower coverage, yellow is minimal coverage, and dark red is coverage below the minimum threshold. When you hover your mouse over a particular instance, a popup window will display detailed coverage information for that instance.

Loadable Non-Scan Cell:

Nonscan cells are nonscan flip-flops or latches that capture known values during the last shift cycle. You can configure TetraMAX to recognize any nonscan cells that load the value of a combinational logic function of multiple scan cells during simulation or ATPG. Logic and fault simulation can simulate these load values for depths up to the length of the longest scan chain. ATPG can control these load values with a sequential depth of 1. Note: Refer to the TetraMAX Online Help Using Loadable Nonscan Cells in TetraMAX for limitations.

Functional Pattern:
Use functional patterns for un-scanned logic. Typical example is JTAG logic. Since JTAG logic is non-scanned logic, a lot of faults are undetected. Use the functional patterns for covering the faults in it. (Refer to the SolvNET articles listed at the end)

Post-Clock Contention Prevention:

Enables ATPG support to actively prevent post-clock bus contention during pattern generation. Designs with many Z1 violations and M181 messages may benefit with better test coverage and/or lower pattern count at the expense of increased run-times. Use the command set_atpg post_capture_contention_prevention, to enable this.

Solvnet Articles on debugging low coverage:

https://solvnet.synopsys.com/retrieve/012901.html
How to model a block with constant outputs for ATPG

https://solvnet.synopsys.com/retrieve/900726.html
How to Analyze Low Test Coverage

https://solvnet.synopsys.com/retrieve/022696.html
Flow for Debugging Low Module Level Coverage

https://solvnet.synopsys.com/retrieve/018868.html
Why is there coverage loss after multi-mode and Adaptive Scan insertion?

https://solvnet.synopsys.com/retrieve/017440.html
Effect of coverage when using gate or MUX to fix asynchronous reset

https://solvnet.synopsys.com/retrieve/025189.html
Block Level Pin Constraints to Debug Low Coverage

https://solvnet.synopsys.com/retrieve/018712.html
TetraMAX Combined Test Coverage for JTAG and ATPG Patterns