Testability Analysis Based On Ever-Evolving Technology

The complexity of system-on-chip (SoC) designs continues to grow, so the corresponding design-for-test (DFT) logic required for manufacturing has become more advanced. Design teams are challenged by high gate counts and an array of internally developed and third-party IP integrated into their designs. Understanding if one can create high-quality manufacturing tests for these complex designs must occur early, ideally before the design team implements DFT. After implementation, sophisticated DFT architectures are challenging to verify and easily create pressure on the design team since they are late in the design cycle. Unfortunately, these challenges arise because debugging a DFT logic problem is time-consuming. Because the causes of such potential issues vary and increase with each chip generation, unique testability analysis technologies need to constantly evolve to provide the actionable insights that are needed to fix DFT issues early.

The concept of “Shift Left,” or the ability to do steps earlier in the design, verification, and analysis phases, has become more common in recent years for finding and preventing bugs early in the design cycle. The primary goal is to improve manufacturing test quality by moving DFT tasks earlier. However, the value of this activity is directly related to the comprehensiveness of testability analysis.

Some of the current challenges for a user, a DFT engineer, or an RTL designer today include the following:

• Verification of readiness checks for SCAN
• Increased fault and test coverage requirements with ever-increasing hard-to-test faults
• Identification and isolation of X sources
• Increased ATPG efficiency
• Connectivity verification for test and functional modes

Fig. 1: The feature set for a testability analysis solution.

An ideal solution will offer tools to help ensure the design is DFT-friendly. The following are the key functionality highlights that help RTL and DFT engineers:

• Testability profiling: Testability profiling assesses test robustness—the susceptibility of test patterns, clock violations, reset violations, and many more—and identifies RTL constructs that limit maximum stuck-at and transition fault coverage
• Rule violations: Rule violations reference the RTL so that designers know exactly where to make changes. Designers can then implement changes to ensure the design is test ready. The rule check is there to alleviate the testability issues early in the flow to verify scan readiness, increase fault and test coverage, identify and isolate X sources, and increase ATPG efficiency and connectivity verification for test and functional modes

Synopsys’ solution provides estimates of stuck-at and transition-delay fault coverage based on controllability and observability analysis. Coverage estimates are quick and patternless, avoiding the need for test benches or long runtimes. Audit reports provide step-by-step guidance that allows designers to isolate the source of coverage loss. For example, to interpret ATPG results in the early RTL design phase, a coverage audit profiles the design, pointing to the possible cause of low ATPG test coverage:

• Incomplete test intent for the three ATPG modes (shift, stuck-at capture, and at-speed capture)
• Topology/structures in the design that make faults ATPG untestable (i.e., test coverage loss)

These issues are sorted according to the most significant impact on test coverage loss, such as DRC and scanability. Some scenarios can be addressed only with the insertion of test points to increase the number of ATPG testable faults. However, the essential value of this report is that test points increase coverage, including RTL, accuracy and completeness of constraints.

Since analysis is run on RTL before code freeze, many testability issues that impact optimal ATPG coverage and ATPG efficiency can be identified early on. This has a significant impact on the last-minute ECOs to address testability.

The report indicates the current coverage for the design and the steps, in tabular format, that you need to follow to improve the coverage.

Each step has:

• The description of the root cause
• The improved fault and test coverage number if the reported issues for the step are fixed
• The diagnostic rules to debug the respective steps

Using the above methodology, a user could significantly increase coverage from 94.2% to 97.5%.

Test robustness checks, such as glitch detection and X capture, can be used by the DFT engineer and the RTL designer to ensure design health. Examples of checks include:

• Clock merge missed, i.e., in functional mode, one needs to prove a single clock passes through Clock Gating Cells (CGC)
  • In functional mode, users usually ensure a single clock passes through the Clock Gating Cells (CGC) by controlling the enabled pins
  • But, in Test Mode, since SCAN_ENABLE typically drives the SE pin of both the Clock Gates -> Clock can propagate through multiple CGCs leading to failure of ATPG patterns on tester
• DFT logic glitch, i.e., a glitch may occur if the latch EN-pin is not explicitly disabled, the latch may potentially not be treated as transparent, and the path can also be traced through its D-pin
  • Here, the main issue is reconvergence, which is the possible cause of a glitch
  • And the checks are sensitive to the unateness of the paths

In addition, some of the faults in the design are ATPG testable but difficult to test. Synopsys test tools identify hard-to-test areas in the design and report an ordered list of test points that can be inserted at hard-to-control areas and observe points to improve test coverage and reduce pattern count. Synopsys TestMAX Advisor coupled with Synopsys Fusion Design Platform allows automated insertion of the identified test points and solves area congestion caused by clusters of test points inserted. Physically aware test points are supported where physical information about the test points selected by the solution can then be used by the Synopsys flow, as shown in figure 2. Test points are grouped based on physical data, allowing one flop to be shared across multiple test points, resulting in significant area overhead reduction.

Fig. 2: Shift left flow using Synopsys Testability Analysis.

This feature is valuable if a test engineer has encountered self-gating logic in the design. Self-gating logic keeps the clock turned off if the D (input) and Q (output) have the same value. D and Q are XoR’ed. The RTL designer can implement self-gating logic. This allows significant power savings but creates hard-to-detect faults. The solution can auto-detect self-gating logic, allowing users to add specialized test points to improve pattern count and coverage.

Consequently, there is a need to validate connectivity across hierarchies, checking both paths and values. This validation applies to test logic added at the SoC integration level and any logic unrelated to the test. The above-mentioned solution addresses connectivity challenges such as back-to-back on-chip controllers (OCCs) that find no clock control connection. Examples of value checks include PLL resets or clock gating enable pins. Conditional checks are also supported, for example, memory sleep controlled by a pin at the IP level. Connectivity validation can be performed either at RTL or gate-level netlists.

Conclusion

Synopsys TestMAX Advisor, built on SpyGlass technology, is a solution for testability analysis. With the industry’s ever-changing demands, the solution has been constantly upgraded for a structured, easy-to-use, and comprehensive process for resolving RTL design issues, ensuring high-quality RTL with fewer design bugs. In addition, the method leads to fewer but more meaningful violations, thus saving time for the designer. The methodology documentation and rule sets are provided with TestMAX Advisor.