DFT Compiler Next Generation 1-Pass Test Synthesis Technology Backgrounder

Contents

• Introduction
• Common Testability Problems
• Productivity with RTL TestDRC
• Streamlined DRC
• Ease-of-use in a Well Integrated Flow
• Designer Friendly Feedback
• Fixing TestDRC Violations Automatically in DFT Compiler
• Enhanced Test Coverage with Shadow LogicDFT
• DFT Compiler Helps Achieve DFT Closure

Introduction
Exponential growth in size and complexity of systems on a chip (SoCs), coupled with increasingly stringent quality mandates, demand new approaches in design for testability (DFT) technology. Full scan implemented using Synopsys 1-Pass test synthesis is the most widely adopted DFT methodology among ASIC designers. This methodology allows designers to achieve highly testable implementations with minimal impact on design constraints. Synopsys is now introducing the next generation of 1-Pass test synthesis, DFT Compiler^™. DFT Compiler includes all the previous capabilities available in 1-Pass test synthesis, and adds significant new capabilities including advanced RTL TestDRC and AutoFix features.

With Synopsys 1-Pass test synthesis, scan logic is synthesized directly from the RTL to testable gates with full optimization of synthesis design rules and constraints (Figure1). This means that DFT implementation and verification is available directly within the synthesis environment, allowing problems to be found and fixed early in the design cycle. The final design that comes out of synthesis is "ATPG-ready" with all test-logic verified and scan design rules checked, leading to very high and predictable test coverage results.

Figure 1 - 1-Pass Test Synthesis Flow

Synopsys 1-Pass test synthesis methodologies are already widely used in conventional ASIC and SoC design flows, but to keep up with today's design complexity and size, testability considerations must be addressed throughout the entire design process. To successfully meet all the design goals of these immensely complex devices, including function, timing, area, power and testability, swift convergence of all requirements must be simultaneously attained. New test methodologies must be adopted that enable fast and predictable DFT closure. Achieving successful DFT closure requires that RTL designers and DFT engineers work in concert on a unified view of the design, using integrated tools and flows.

DFT Compiler, a key element of Synopsys' DFT closure strategy, makes DFT implementation transparent in the high-level design flow, without interfering with the designers' need to meet functional, timing and power requirements. With new RTL TestDRC and AutoFix capabilities tightly integrated within the 1-Pass test environment, DFT Compiler enables register transfer level (RTL) designers to quickly and accurately account for testability and resolve any test issues earlier in the design cycle, thus rapidly achieving their DFT goals without costly design iterations.

Common Testability Problems
With traditional design methodologies, test related problems might not show up until late in the design cycle. Fixing testability violations at the gate level will negatively impact overall design productivity. Customer survey results show that as a design approaches the critical tapeout phase, the designer/DFT engineers face a daunting challenge. They must not only fix testability problems in the module/chip, they must still satisfy all test design rules and synthesis timing/area constraints before re-synthesis. This often involves multiple design iterations during the synthesis process at a time when the design should be going to the foundry. The survey results also showed that the impact of test violation fixes on the design cycle ranges anywhere from two days to two months, depending on the extent of violation. With some of today's product life cycles being less than a year, every day, week or month lost to unneeded iterations can mean high losses of revenue.

One of the key problems that affect the testability of a design is its controllability during test. Lack of controllability on many of the internal signals /nets in the design, makes it extremely difficult to achieve high fault coverage. These types of problems (Figure 2) manifest themselves as reduced fault coverage and/or increased test pattern generation time. Typically, lack of controllability of the following signals during test mode causes test design rule check (DRC) violations, both during DFT insertion as well as during test generation.

Figure 2 - Types of Testability Problems

When the testability violations are not fixed, they invariably cause errors in:

• Scan shift
• Capture (of the next state value)

Traditionally, most testability violations are detected at the gate level and the fixes implemented on the post scan-inserted design. This means that the engineer must first debug the violation at the gate level and then manually determine the fixes, which likely involves the addition of new logic or modification of existing logic. These fixes are then manually added to the design. After the fix, the designer goes through additional logic synthesis iterations to re-optimize timing, and simulation iterations to again validate the design.

Productivity with RTL TestDRC
In a typical high-level design flow, multiple designers focus on module designs and then the system architects assemble the modules to create the final chip. By using Synopsys DFT Compiler, the module designer can invoke the RTL TestDRC feature on the RTL module prior to synthesis to verify DFT rules. The primary function of RTL TestDRC is to provide feedback on the testability of the design during the pre-synthesis stage. The designer has the option to fix the violations in the RTL source code based on the feedback. This enables the designer to account for the RT level testability early in the design process and satisfy a key DFT closure requirement.

Streamlined DRC
A tool that the designer uses to verify testability at the RT level must have three important attributes:

1. Be able to identify, verify and cover a wide set of testability rules that can be checked at the RT level.

2. Ensure consistency with downstream gate-level DRCs to avoid false violations, which cause iterations late in the design cycle.

3. Provide feedback in the designer's language (Verilog or VHDL).

RTL TestDRC was designed around these key attributes to enable the designer to create "test-friendly" RTL that can then be easily synthesized in the 1-Pass test synthesis environment.

By using simulation techniques, RTL TestDRC ensures that the testability analysis is completely accurate, and will not cause false DRC violations in the downstream process. A comprehensive check of all pre-scan rules by RTL TestDRC ensures that the rules checked at the RT level are consistent with the corresponding rule checks at the gate level, as well as in Synopsys' TetraMAX^™ automatic test generation (ATPG) environment. A majority of rules checked by RTL TestDRC are pre-scan DRCs that comprehensively cover the following set of violations:

• Violations that prevent Scan insertion
  (e.g., uncontrollable clock or asynchronous set/reset to a flip-flop)

• Violations that prevent data capture
  (e.g., clock signal drives data pin of flip- flop)

• Violations that reduce fault coverage
  (e.g., combinational feedback loops)

An important requirement for any TestDRC tool is to take into account test initialization constraints. The initial test constraints are set up using existing test synthesis commands. RTL TestDRC simulates the initialization so that the test rules can be checked in their presence. Otherwise, the results of the DRC verification would be erroneous.

Ease-of-use in a Well Integrated Flow
To ensure designer productivity, RTL TestDRC is tightly integrated into the DFT Compiler 1-Pass test synthesis flow. A typical design flow (see Figure 3 below) shows how a designer can verify testability at the beginning of the design cycle and ensure that the design is testable from the very start. The ability to verify testability of the design before targeting to a specific technology enables the designer to fix problems at the RT level before committing to gates. The tight iteration loop prior to synthesis helps in cutting down potential back-end iterations.

Figure 3 - 1-Pass Test Synthesis Flow with RTL TestDRC and AutoFix

Designer Friendly Feedback
When testability problems are discovered at the RT level, it is critical that the feedback information is presented in a manner that can be readily used by the designer. Localizing testability problems in large and complex designs (i.e., thousands of lines of RTL code) is extremely difficult, and the DRC analysis capability must help designers identify problems and then provide guidance to help them solve these problems. This was a key requirement when RTL TestDRC was developed. After the violations are flagged, RTL TestDRC provides the user with a description of the violation with a pointer to the relevant line of RTL code and provides a brief description of the cause for the violation through the "man page" (Figure 4).

Figure 4 - A Sample man page for a Violation (RTL TestDRC)

Because navigating through thousands of lines of a DRC error report can be onerous, DFT Compiler's feedback is in HTML so that it can be easily browsed. This greatly improves productivity and drastically cuts down the time to identify the problem. The browser capability has been designed so that the user can control the number and type of messages displayed. These capabilities help the designer refine the feedback and show only the information that is necessary.

Figure 5 shows the top-level view of the violation browser with controls to refine the feedback information that the user chooses to view.

Figure 5 - A View of the Violation Browser

Figure 6 illustrates a typical clock controllability violation and the output from RTL TestDRC analysis. The clock to flip-flop B (Figure 6(a)) is controlled by the data output Q from flip-flop A. This is a clock controllability violation, since the clock to flip-flop B is not controlled by a test clock. RTL TestDRC reports this as a DRC error (Figure 6(b)) and points to the line of RTL code (Figure 6(c)) which causes this violation.

Figure 6 - An Example with DRC Violation

Fixing TestDRC Violations Automatically in DFT Compiler
The feedback from RTL TestDRC enables designer to identify the nature of the testability violation and then choose to fix any of these violations at the RT level. The designer also has the option to let the AutoFix capability fix these violations at the gate level during the synthesis stage. AutoFix is a new capability developed within DFT Compiler to automatically fix the testability violations within the synthesis environment while meeting timing constraints. Manual implementation of testability fixes at the gate level can break design constraints and invariably leads to additional synthesis iterations to preserve timing constraints.

AutoFix focuses primarily on the controllability of clocks and asynchronous set/reset signals, since these are some of the most common testability problems. After DRC violations, such as lack of controllability of clocks and asynchronous set and reset signals are detected, the designer uses the AutoFix capability to automatically insert test logic at the gate-level to fix these violations. It ensures the netlist is testable and ready for ATPG. Since AutoFix is integrated within 1-Pass test synthesis, the testability fixes have minimal or no impact on the overall timing and area constraints of the design. Figure 7 shows an example circuit with uncontrollable clock and asynchronous reset inputs to a bank of flip-flops. These are gross DRC violations which will drastically reduce the test coverage.

Figure 7 - Design with DRC Violations (before AutoFix)

Figure 8 shows the necessary gating logic automatically synthesized by AutoFix to fix the DRC violations.

Figure 8 - Design with no DRC Violations (after AutoFix)

The RTL designers ability to deal with test design rule violations at the gate level rapidly diminishes as design size and complexity grow into the multi-million gate range. For example, a half-million gate design can have anywhere from 5-10K test design rule violations and would need 2-3K test points to fix the violation. To manually fix this many violations while preserving timing constraints, the designer could easily spend a month or longer. On the other hand, when using the AutoFix feature, the designer is able to rapidly fix the violations within a day while, at the same time, preserve the timing constraints.

The design flow for fixing testability violations using AutoFix is a seamless part of the current scan synthesis flow. It allows designers to retain their current test synthesis flow and use minimal modification to their scripts to engage the AutoFix capability. The flexibility of AutoFix lets designers use the capability either in a top-down or bottom-up high-level design flow.

Enhanced Test Coverage with Shadow LogicDFT
Most of today's complex IC designs implement multiple embedded memories. Typically, the shadow logic around the embedded memory doesn't get tested due to lack of testability on both the input and output side of the memory (RAM) modules. This invariably results in lower-than-expected fault coverage. In addition to fixing clock related problems, AutoFix technology has been extended to support the testing of shadow logic around embedded memory modules. Using this new DFT Compiler capability, called Shadow LogicDFT, the designer is able to synthesize testability logic at the embedded memory module I/O.

Any logic that is accessible only from the input/output ports of an embedded memory module is called 'shadow logic.' The embedded module which is not directly observable or controllable during test, is said to cast a shadow that potentially reduces the testability of the logic in that shadow. Figure 9 illustrates shadow logic around an embedded RAM module. The outputs of the combinational logic driving the RAM inputs are unobservable and the inputs to the combinational logic driven by the RAM outputs are uncontrollable. Shadow LogicDFT is inserted around the embedded module to enhance the test coverage of shadow logic.

Figure 9 - Shadow Logic Example

Figure 10 shows an example of Shadow LogicDFT around a memory module automatically inserted by DFT Compiler. The logic on the input side enhances shadow logic observability and the logic on the output side enhances shadow logic controllability. The flip-flops in the shadow logic are synthesized as a part of the scan chain and used by ATPG to enhance the fault coverage.

Figure 10 - Example Shadow LogicDFT for an Embedded Memory

DFT Compiler Helps Achieve DFT Closure
With the incredible growth rate of chip complexity and increased demands for quality, the adoption of scan DFT is mandatory. Full-scan is the dominant DFT methodology because it can guarantee high fault coverage very quickly. However, there are still testability issues that impact the overall cost of the design. Many of these are due to traditional practices where the design flows do not address the impact of DFT during the high-level design process. Further problems arise due to lack of consistency between design processes, such as scan implementation and the ATPG tool, leading to unanticipated design iterations.

DFT Compiler, the next generation 1-Pass test synthesis, addresses these issues and is uniquely positioned to offer the most transparent test synthesis flow. Achieving testable designs require that designers consider testability at the RTL stage to minimize the costly back-end iterations that wreak havoc with design schedules. DFT Compiler, with the revolutionary RTL TestDRC capability and AutoFix, enables the designers to meet the test requirements easily and predictably towards achieving DFT closure. Forward thinking companies that embrace these DFT tools and methodologies will ensure that quality products reach the market on schedule, and ahead of the competition.