Checking Test Design Rules 6 - Semantic Scholar › f001 › 499f53fff349ab274bbb1961… · violations on scan-replaced cells cause insert_scan to unscan scan elements as explained

v1999.10 Scan Synthesis Reference Manual

6Checking Test Design Rules 6

Test design rule checking provides you with feedback on the testabilityof your design. By performing test design rule checks early in thedesign cycle, you can incorporate testability features into your designand greatly increase your chances of rapid success later in the designcycle.

This chapter explains the workings of the DC Expert Plus test designrule checker. Test Compiler also uses the same test design rulechecker. You can determine and efficiently fix test design ruleviolations in your design using the test design rule checker.

This chapter includes the following sections:

• Design Rule Checking Functions

• Preparing for Design Rule Checking

• The check_test Command

/ 6-1HOME CONTENTS INDEX


• Working with check_test

• The check_scan Command

• Design Rule Checking Related Commands

• Debugging Commands

Design Rule Checking Functions

The test design rule checker has three distinct functions.

• As a stand-alone program (check_test), it provides feedback onthe testability of the design to guide DFT.

• As a preprocessor to test insertion (insert_scan), it flags validsequential cells for scan replacement. When the insert_scancommand runs check_test, it produces no user output.

• As a preprocessor to create_test_patterns, it extracts the scancircuitry from your design so that the automatic test-patterngeneration (ATPG) processor sees only the functional portion ofyour design. When the create_test_patterns command runscheck_test, it produces no user output.

When used as a preprocessor, the check_test command checks thecircuit for circuit configurations that Test Compiler ATPG cannotsupport. TestGen and TestGen XP are more flexible and powerfulATPG tools and can accept some circuit configurations that TestCompiler ATPG cannot. However, the fewer capture violationsreported by the check_test command, the easier it will be for you toachieve good results with TestGen and TestGen XP.



Scan shift violations reported by the test design rule checker will alsohave serious impact on TestGen and TestGen XP and should alwaysbe fixed.

The test design rule checker uses a symbolic simulation approach tochecking test design rules. This approach generalizes the scanelement concept to include any sequential element that can becontrolled and observed through a test protocol. The symbolicsimulation approach frees you from the rigid scan path methodologyand enables you to use the functional modes of your design to loadand unload test data from scan registers. This freedom, however, onlycomes with a thorough understanding of the dynamics of testprotocols, as explained in Chapter 7, “Developing a Test Protocol.”

In this chapter, and without loss of generality, it is assumed that thetest design rule checker is driven by a default test protocol. Thiscorresponds to the basic tester cycle described in the Test Managerchapter of the Test Compiler ATPG Reference Manual.

Because rule checking depends on the dynamic operation of thedesign, design rule violations can be caused by both structuralproblems and operational problems. You can often modify thedynamics of the scan operation to fix a problem that appears to bestructural. See the section “Defining a Test Mode” later in this chapterfor an example of modifying the dynamics.

Preparing for Design Rule Checking

This section describes checks you should perform in preparation forrunning the check_test command before building scan chains andafter building scan chains. This section also describes checks thatyou should apply before running the check_test command.



Preparing for Designs Before Building Scan Chains

Before using the check_test command to check for design ruleviolations, perform the following checks:

• Ensure that the following timing parameters are correctly set inyour .synopsys_dc.setup file (see Chapter 7 for details):

- test_default_delay

- test_default_strobe

- test_default_bidir_delay

- test_period

• Explicitly create waveforms for clocks with the create_test_clockcommand if you do not want to accept the defaults (see Chapter7 for details).

Verify that the -existing_scan true constraint is not set using thereport_test -configuration command (see Chapter 7 for detailsregarding the report_test command).

Preparing for Designs After Building Scan Chains

• Ensure that the following timing parameters are correctly set inyour .synopsys_dc.setup file (see Chapter 7 for details):

- test_default_delay

- test_default_strobe

- test_default_bidir_delay



- test_period

• Ensure that signal type attributes (see Chapter 7) exist on testports. You can list test ports using the report_test -port command.Check that the signal types reported by the report_test commandmatch you requirements. If you used the insert_scan commandto build scan chains, DC Expert Plus automatically establishesthe signal type attributes. If you did not use the insert_scancommand (for example, you read in an ASCII netlist), use theset_signal_type command to establish the signal type attributes.

Note:

Consult your ASIC vendor for timing value requirements.

• Check the scan state of the design using the report_test -statecommand (see Chapter 8 for details).

If the state is not “existing scan circuitry,” use theset_scan_configuration -existing_scan true command toestablish the scan state as existing scan circuitry. If you used theinsert_scan command to build scan chains, the existing scancircuitry scan state is set automatically.

The check_test Command

Use the check_test command to check the current design for testdesign rule violations. This command checks for design rule violationsaccording to the test methodology and scan style you choose withthe set_scan_configuration -methodology -style command. If thedesign has violations, the check_test command issues warnings orerror messages.



The check_test command operates on designs with or withoutexisting scan chains. The -existing_scan option of theset_scan_configuration command asserts that a design alreadycontains scan chains.

Note:By default, check_test assumes a test methodology of full scanand the style specified in your .synopsys_dc.setup file by theenvironment variable test_default_scan_style.

The syntax of the command is

check_test [-verbose] \[-check_contention true |false | \

scan_shift_only | capture_only] \[-check_float true | false | \ scan_shift_only | capture_only

-verbose

The -verbose option causes the check_test command to generatewarnings for all similar cells or pins involved in the same designrule violation. If you do not designate -verbose, the check_testcommand lists warnings only for the first cell or pin that violatesa rule, followed by the number of additional violations.

-check_contention

The -check_contention option determines when the check_testcommand performs contention checking on bidirectional ports. Ifyou set it to true, the default, the check_test command checkscontention for bidirectional ports in the parallel measure vectorand scan shift mode. If false, the check_test command does notcheck contention. If you set it to scan_shift_only, the check_test



command checks contention only during scan shift mode. If youset it to capture_only, the check_test command checks contentiononly during capture mode.

-check_float

The -check_float option determines when the check_testcommand performs float checking on bidirectional ports. If youset it to true, the default, the check_test command turns on floatchecking for bidirectional ports in the parallel measure vector andscan shift mode. If false, the check_test command does notperform float checking. If you set it to scan_shift_only, thecheck_test command turns on float checking only during scanshift mode. If you set it to capture_only, the check_test commandturns on float checking only during capture mode.

Information, Warning, and Error Messages

When you check your design for test design rule violations, thecheck_test command generates information, warning, and errormessages.

Note:No check_design messages are generated during check_test.

Information messages give you the status of the design rule checkeror more detail about a particular rule violation.

Warning messages indicate a test design rule violation and warn youof the possibility of reduced fault coverage. Design rule violationsaffect fault coverage and subsequent DC Expert Plus and TestCompiler commands. Try to correct all violations, because a cell that



violates a design rule, as well as the cells in its neighborhood, arenot testable. A cell’s neighborhood can be as large as its transitivefanin and its transitive fanout.

When the check_test command issues an error message, it stopsprocessing your design. You must fix the problem that generated theerror before you can issue further DC Expert Plus or Test Compilercommands.

All warning and error messages are linked to the schematic in DesignAnalyzer. You can automatically select the pins, cells, and netsinvolved in a test design rule violation on the schematic. This featurehelps you debug testability problems in your design. For moreinformation on this capability, see the Design Analyzer ReferenceManual.

If you need more information about a warning or error message, usethe online help facility to display a detailed explanation andsuggestions for what to do next. The syntax of the command is

help error_id

For example

dc_shell> help TEST-131

To keep a record of the information, warning, and error messages foryour design, direct the output from the check_test command to a filewith a command such as

dc_shell> check_test > my_drc.out

In this example, my_drc.out is the name of the output file.



Effects of Violations on Scan Replacement

For designs that are synthesized using the compile -scan command,violations on scan-replaced cells cause insert_scan to unscan scanelements as explained in Chapter 7.

For designs that are not synthesized using the compile -scancommand, violations on sequential cells cause the insert_scancommand not to perform scan replacement, as explained in Chapter8, “Building Scan Chains.”

If you previously ran the check_test command, the insert_scancommand uses the results. The insert_scan command issues thefollowing message:

Using test design rule information from previous check_testrun

If you have not explicitly run the check_test command, the insert_scancommand runs check_test as a preprocessor to determine whichsequential elements can be included in scan chains. The insert_scancommand issues the following message:

Checking test design rules

In both cases, when violations occur, insert_scan command issuesthe following message:

Warning: Violations occurred during test design rulechecking. (TEST-124)



You should determine the causes of these violations beforeproceeding. Sequential cells with violations are not included in a scanchain because they would probably prevent the scan chain fromworking as intended.

In the context of partial scan, sequential cells with violations remainblack boxes. Because of their violations, these sequential cells eithercannot retain their state during scan or they cannot reliably capturedata. A cell can be valid-nonscan (that is, a cell that retains stateduring scan shift and captures data during parallel operation) only ifit follows all scan design rules but is not actually scanned.

Effects of Violations on Fault Coverage

If you are using Test Compiler ATPG, test patterns are generated bythe create_test_patterns command, as explained in the Test CompilerATPG Reference Manual. If you previously ran the check_testcommand, the create_test_patterns command uses the results. Thecreate_test_patterns command issues the following message:

Using test design rule information from previous check_testrun

If you did not explicitly run the check_test command, thecreate_test_patterns command runs the check_test command as apreprocessor to correctly model each sequential element accordingto its controllability and observability characteristics. Thecreate_test_patterns command issues the following message:

Checking test design rules



In both cases, if test design rule violations occur, thecreate_test_patterns command issues the message

Warning: Violations occurred during test design rulechecking. (TEST-124)

A scan cell is modeled as a pair of controllable pseudo-primary inputports and observable pseudo-primary output ports. If a cell violatestest design rules, it is modeled as a pair of uncontrollable pseudo-primary input ports and unobservable pseudo-primary output ports.

An uncontrollable pseudo-primary input is an X generator; it reducesfault coverage. The magnitude of the loss in coverage depends onthe size of the region affected by the X generator—it can be as smallas one node or as large as a significant portion of the design. Anunobservable pseudo-primary output also reduces fault coveragebecause a portion of the fanin region of this pseudo-primary outputis unobservable.

Faults that remain undetected because of design rule violations aremarked as untested. See the Test Compiler ATPG Reference Manualfor an explanation of the various fault classes.

Working With check_test

The check_test command performs test design rule checking in fourdistinct phases:

• Modeling checks

• Topological checks

• Protocol inference



• Protocol simulation

As check_test checks test design rules, it displays information aboutwhere it is in the process and generates warnings about design ruleviolations. Cells corresponding to design rule violations areimmediately marked as violated and modeled internally as black boxcells. Black boxes inject unknown values into the simulation. Unknownvalues can trigger other violations. Two or more warnings issued inapparently different contexts can indicate multiple manifestations ofa unique underlying problem. In general, a good strategy is tocorrelate various warnings, paying particular attention to the earlierones.

At the end of design rule checking, check_test displays summaryinformation about your design, including

• Net tracing results (optional)

• Test design rule violations summary

• Sequential cells summary

This section describes how check_test performs design rule checkingand how to interpret warnings, information messages, and check_testsummary information. You can use the information in this section toimprove the DFT characteristics of your design.

Example 6-1 shows the type of information you might see incheck_test results for a small circuit (without trace_nets results).



Example 6-1 check_test Outputcheck_test

Loading target library ‘xyz.lib’Information: Starting test design rule checking for existing scan design.(TEST-220)

...full scan rules enabled...

...basic checks...

...basic sequential checks...

...checking combinational feedback loopsWarning: The design contains unreachable circuitry (closed loops). (TEST-118)Information: The loop contains c/g/A, c/g/B. (TEST-175)

...inferring test protocol...Information: Inferred system/test clock port ck(45.0, 55.0). (TEST-260)

...breaking combinational feedback loops...Warning: Combinational feedback loop broken at pin A of cell G2 (AN2) (TEST-117)Information: The loop contains: G2/A, G2/Z, G4/A, G4/Z.

...simulating parallel vector...


...simulating serial scan-in ...

...3 bits scanned-in to 3 cells (total scan-in 3)...


...binding scan-in state...


...simulating capture clock rising edge at port ck....Warning: Pin D of cell o1_reg(FD1S2) cannot capturereliably.(TEST-478)Information: Cell X_reg launches response data from pin Q at rising edge of clockport ck (pin CK) at time 45.(TEST-472)Information: Cell o1_reg captures data on pin D at falling edge of clock portck (pin CK) at time 55.(TEST-473).Information: There is a path from X_reg to o1_reg.(TEST-474)Information: The path contains: X_reg/Q, o1_reg/D. (TEST-282)

...simulating capture clock falling edge at port ck ...


...creating capture clock groups...Information: Inferred capture clock group : ck (TEST-262)Warning: Data can not be captured into cell o1_reg (FD1S2). (TEST-310)

...binding scan-out state...

...simulating serial scan-out...

...data scanned-out from 1 cells (total scan-out 3)...

...simulating parallel vector...Information: Test design rule checking completed. (TEST-123)*************************************************************

Test Design Rule Violation SummaryTotal violations: 3

*************************************************************TOPOLOGY VIOLATIONS

1 Combinational feedback loop violation (TEST-117)



1 Unreachable circuitry violation (TEST-118)CAPTURE VIOLATIONS

1 Illegal path violation (TEST-478)1 Cell cannot capture violation (TEST-310)

*********************************************Sequential Cell Summary1 out of 3 sequential cells have violations

*********************************************SEQUENTIAL CELLS WITH VIOLATIONS

* 1 cell has parallel capture violationso1_reg

SEQUENTIAL CELLS WITHOUT VIOLATIONS* 2 cells are valid scan

Checking for Modeling Violations

The check_test command performs modeling checks locally, one cellat a time.

Black Boxes

A cell whose output is considered unknown is a black box cell. Blackbox cells can be cells without a functional description in thetechnology library (cells marked as black box in the report_libcommand) or black box sequential cells identified in the check_testcommand.

The check_test command requires that you have a functional modelin your library for each leaf cell in your design. Test Compiler usesthe functional model to perform test pattern generation. Cells that arenot functionally modeled, and cells in their neighborhood, are nottestable. If you use cells that do not have functional models, thecheck_test command displays the following warning:

Cell %s (%s) is unknown (black box) because functionalityfor output pin %s is bad or incomplete (TEST-451)



See the Library Compiler reference manuals for more information onmodeling the behavior of cells.

Unsupported Cells

Cells can have a functional description and still not be supported bythe check_test command. Using state table models, librarydevelopers can describe cells that violate the current assumptionsfor test rule checking. The check_test command detects those cellsand flags them as black boxes.

DC Expert Plus and Test Compiler support single-bit cells; these cellshave the following characteristics:

• The functional view, which Design Compiler understands andmanipulates, is either a flip-flop, a latch, or a master-slave cell withclocked_on and clocked_on_also attributes.

• The test view, used for scan shifting, is either a flip-flop or a master-slave cell.

• The functional view and the test view each have a single clock perinternal state.

DC Expert Plus and Test Compiler only support multibit library cellswith identical functionality for each bit. The multibit library cellinterfaces must be either fully parallel or fully global. For cells that donot meet these criteria, DC Expert Plus and Test Compiler use single-bit cells. For example, if you want to infer a four-bit banked flip-flopwith an asynchronous clear, the clear signal must be either differentfor each bit or shared among all four bits. If the first and second bitsshare one asynchronous reset, but the third and fourth bits shareanother reset, DC Expert Plus and Test Compiler do not infer a multibit



flip-flop. Instead, DC Expert Plus and Test Compiler uses four single-bit flip-flops. For more information about multibit cells and multibitcomponents, see Design Compiler Reference Manual: Optimization.

DC Expert Plus and Test Compiler do not support registers orduplicate sequential logic within a cell. If the check_test commanddetects such a cell, it issues the following warning:

Cell %s (%s) is not supported because it has too manystates (%d states). This cell is being black-boxed forTest Compiler.(TEST-462)

When the check_test command recognizes part of a cell as a master-slave latch pair but finds extra states, it issues one of the followingwarnings (depending on the situation):

Master-slave cell %s (%s) is not supported because statepin %s is neither master nor slave. This cell is beingblack-boxed for Test Compiler.(TEST-463)Master-slave cell %s (%s) is not supported because thereare two or more master states. This cell is beingblack-boxed for Test Compiler.(TEST-464)Master-slave cell %s (%s) is not supported because thereare two or more slave states. This cell is beingblack-boxed for Test Compiler.(TEST-465)

If the check_test command detects a state with no clocks or withmultiple clocks, it issues one of the following warnings:

Cell %s (%s) is not supported because state pin %s has noclocks. This cell is being black-boxed for Test Compiler.(TEST-466)Cell %s (%s) is not supported because state pin %s ismulti-port. This cell is being black-boxed for TestCompiler.(TEST-467)



In addition, the check_test command detects and rejects sequentialcells with three-stated outputs and issues the following warning:

Cell %s (%s) is not supported because it is a sequentialcell with three-state outputs. This cell is beingblack-boxed for Test Compiler.(TEST-468)

Black box cells have an adverse effect on fault coverage. To avoidthis effect, you must replace unsupported cells with cells that TestCompiler can support.

Note:Unsupported cells can originate only from explicit instantiation.They are not used by Design Compiler or by DC Expert Plus. Formore information on modeling sequential cells, see the LibraryCompiler User Guide, Volumes 1 and 2.

Generic Cells

Your design should be a mapped netlist. You can still use thecheck_test command if your design contains generic logic cells.However, when the check_test command finds a generic cell, thecheck_test command displays the following message:

Information:Cell %s (%s) is generic. (TEST-113)

Note:Some generic cells, such as unimplemented DesignWare partsand operators, have implicit functional descriptions. Thecheck_test command treats them as black box cells and displaysthe following message:

Warning:Cell %s (%s) is unknown (black box) becausefunctionality for output pin %s is bad or incomplete. (TEST-451)



Scan Cell Equivalents

When checking test design rules in a design without scan chains, thecheck_test command verifies that each sequential element that is notexplicitly marked by using set_scan_element false or set_test_isolatehas a scan cell equivalent in the target library. If a scan cell equivalentdoes not exist, the check_test command issues the followingmessage:

Warning: No scan equivalent exists for cell %s (%s).(TEST-120)

Note:Use the set_scan_element false command to prevent scanreplacement rather than the set_test_isolate command. Useset_test_isolate with great caution; it can adversely affect testdesign rule checking if used inappropriately. See “Effects ofset_test_isolate on Design Rule Checking” for details.

The cells in violation are marked as nonscan. In full-scanmethodology, these cells are black boxes. In partial-scanmethodology, these could be valid nonscan cells. If not valid nonscan,these cells are in violation and are black boxes. You can suppress theTEST-120 warning with the set_scan_element command. Forexample, to ensure that a nonscan latch cell is not made scannable,enter the command

dc_shell> set_scan_element false latch_name



If you use the set_scan_element command, the check_test commandissues the following informational message:

Information: Cell %s (%s) will not be scanned due to aset_scan or set_scan_element command. (TEST-202)

If the check_test command cannot find scan cell equivalents in thetarget library, the probable cause is that the target library does notcontain test cells. In such cases, the check_test command issues thefollowing warning:

Warning: Target library for design contains no scan-cellmodels. (TEST-224)

For more information on library modeling, see the Library CompilerReference Manual.

Scan Cell Equivalents and the dont_touch Attribute

If you set the dont_touch attribute on a cell in your design, that cell isnot modified or replaced when you optimize the design. As a sideeffect, when you use DC Expert Plus to add scan circuitry, sequentialcells with the dont_touch attribute cannot be substituted with theirscannable equivalents and are not connected in the scan chain.

If your design contains a sequential cell that has the dont_touchattribute assigned, the check_test command produces the followingwarning:

Warning:Cell %s (%s) could not be made scannable as it isdont_touched. (TEST-121)



Note:Use the dont_touch attribute carefully, because the dont_touchattribute increases the number of nonscan cells and nonscan cellslower fault coverage.

You can use set_scan_element false if you do not want to make asequential cell scannable but you do want to be able to modify thecell during optimization. See Chapter 7, “Developing a Test Protocol,”for details.

Latches

DC Expert Plus replaces latches with scannable latches wheneverpossible. If the check_test command cannot find scan cell equivalentsfor the latches, it marks the latches as nonscan and issues theTEST-120 warning as previously explained.

Nonscan Latches

DC Expert Plus and Test Compiler models nonscan latches in fourways:

1. As sequential elements, in partial scan

2. As black boxes

3. As synchronization elements

4. As transparent devices

In a full-scan methodology, a nonscan latch is treated by default asa black box. However, if the latch satisfies the requirements for asynchronization element, the check_test command treats the latchas a synchronization element. See “Synchronization LatchesPreventing Capture Violations.”



If a latch is scan-replaced by compile -scan and check_testrecognizes this cell as a synchronization latch, it is unscanned byinsert_scan. You can ignore the check_test pre-scan warnings relatedto “no scan equivalent” for latches if they are synchronization latches.

You can instruct the check_test command and subsequent testcommands to treat a nonscan latch as a transparent device using theset_scan_transparent command:

dc_shell> set_scan_transparent true latch_name -existing

In transparent mode, the values at the output pins of a latch dependonly on the current values at the input pins, not on the stored state.A simple D-type latch is in transparent mode when the enable pin isactive. The truth table for a simple D-type latch in transparent modeis shown in Table 6-1.

Note:In most cases it is not necessary to add test mode logic to testlatches in transparent mode. Latch enable does not need to beasserted always.

Figure 6-1 shows the transparent latch model.

Table 6-1 Truth Table for Transparent Latch Model

D G Qactual Qmodel

0 1 0 0

1 1 1 1

X 0 Qprevious X



Figure 6-1 Transparent Latch Model Used by Test Compiler

The check_test command displays the following message to informyou when latches are tested transparently:

Information: Latch cell %s (%s) assumed non-scan andusing transparent model for testing. (TEST-204)

Note:Treating latches as transparent can cause more design ruleviolations than leaving them as nonscan sequential elements. Forexample, feedback loops can appear and cause a substantial lossof fault coverage.

Checking for Topological Violations

Topological checks are global connectivity checks that check_testperforms in a structural manner.

Nets and Drivers

If the check_test command cannot determine the logic functionassociated with a wired net, it issues the following message:

Warning: Type of wired net %s is unknown. (TEST-114)

G

Q

QND

X



The presence of a non-three-state driver on a three-state net (seeFigure 6-2) results in contention on that net.

Figure 6-2 A Non-Three-State Driver

If the check_test command detects such a condition, it flags theviolation with

Warning: Three-state net %s has non three-state driver(s).(TEST-115)

Note:A node that is isolated by using the set_test_isolate command isinternally modeled as a node driven by a strong X. As a result,isolating a three-state net produces the TEST-115 message.

If the check_test command detects the presence of a pullup or apulldown on a non-three-state net, it flags the problem with

Error: Pullup/pulldown net %s has illegal driver(s).(TEST-331)

Any violation on a net forces the net to the value X for the entireprotocol simulation.

OUTAIN3

E2

IN2

E1

IN1



Combinational Feedback Loops

Combinational feedback loops lower fault coverage because theyintroduce internal states to a design that cannot be synchronouslycontrolled. Figure 6-3 shows a circuit with a combinational feedbackloop.

Figure 6-3 Combinational Feedback Loop

When you view the schematic with Design Analyzer, you can see thehighlighted feedback loop, as shown in Figure 6-4. See the DesignAnalyzer Reference Manual for more information on viewingschematics.

Figure 6-4 SR Latch With Highlighted Feedback Loop

Another type of circuit that the check_test command sees as acombinational feedback loop is a three-state bus transceiver, asshown in Figure 6-5.

S QR ZA

BA

B

S QR ZA

BA

B



Figure 6-5 Combinational Feedback Loop in a Three-State Bus Transceiver

Note:Feedback loops reported by the check_test command are not thesame as timing loops reported by Design Compiler.

Breaking Combinational Feedback Loops

The check_test command identifies combinational feedback loopsthen breaks them. At the start of checking for combinational feedbackloops, the check_test command generates the following message:

...checking for combinational feedback loops...

To break a combinational feedback loop, the check_test commandinjects an X at a point judged to be appropriate. The X propagatesthrough the design; fault coverage suffers as a result. When thecheck_test command breaks a loop, it also lists the cell pins that formthe loop. For example, for the circuit shown in Figure 6-3, thecheck_test command displays the following:

TEST-117 - Combinational feedback loop broken at pin B ofcell U1(NOR2)Information: The loop contains: U1/B, U1/Z, U2/B, U2/Z.(TEST-175)

direction

port1

Z

port2

ZA

A A



The check_test command uses the following three methods to breakcombinational feedback loops:

1. It looks for constants that break the feedback loops.

2. It looks for logic values generated by the initialization portion ofthe inferred test protocol that disable the loop.

3. It tries to find a place within the combinational feedback loop thatcauses a small loss in fault coverage.

In verbose mode, the check_test command generates the followingmessages:

• When constant values break combinational feedback loops, thelocation of the break is reported.

TEST-440 - Combinational feedback loop is disabled atpin %s (%s) by constant values

• When a combinational feedback loop is broken as the result of aninitialization protocol, the location of the break is reported.

TEST-441 - Combinational feedback loop is disabled atpin %s of cell %s(%s) by initialized state of circuit

• If the two previous conditions do not apply, the check_testcommand reports the combinational feedback loops broken bycheck_test, along with the location of the break.

TEST-117 - Combinational feedback loop broken at pin %sof cell %s(%s)

To restore testability, you can insert flip-flops or scannable latches tohold the internal state.



You can control where the check_test command breaks acombinational feedback loop by using set_test_isolate,set_test_hold, and set_test_assume commands to set constantvalues. Use set_test_isolate with caution, because its effects can befar-reaching. See “Design Rule Checking Related Commands” laterin this chapter for more information on using these commands. Youcan also change the initialization portion of the inferred test protocolto control where the check_test command breaks combinationalfeedback loops. For more information, refer to Chapter 7, “Developinga Test Protocol.” After any of these changes, you must reruncheck_test.

While tracing feedback loops, the check_test command also checksfor unreachable logic (closed loops). Unreachable circuitry reducesfault coverage because it is untestable. If such logic is identified, thecheck_test command issues a warning:

Warning: The design contains unreachable circuitry (closedloops). (TEST-118)

Inferring the Test Protocol

The check_test command infers a test protocol from attributes on thedesign or from variables in the test group, as described in Chapter 7,“Developing a Test Protocol.” The check_test command must inferthe clock ports and the asynchronous ports to build a completeprotocol, however. In the process of identifying these ports, thecheck_test command might detect violations, as described in thefollowing sections.



Inferring Clock Ports

The clock ports are determined by tracing back from the clock pinsof all sequential elements to input ports. Only active paths areconsidered. A path is not active if some constant logic values on inputsprevent the flow of information. For example, in Figure 6-6, ifSEL = 1, the path from CLK1 is active, although the path from CLK2is not. In general, you use the set_test_hold command to specifyconstant logic values on ports, as explained later in this chapter.

Figure 6-6 A Clock Selector Network

The sense of a clock is determined by simulation.

In the process of identifying the clock ports, the check_test commandmight discover clock pins that are not fully controllable from inputports, as in Figure 6-7. In this case, you see the following warning:

Warning: Normal mode clock pin %s of cell %s (%s) isuncontrollable.(TEST-169)

The check_test command issues a TEST-169 violation when itidentifies clock gating in which clock pins are controlled by sequentialelements when clock ports are inactive. In Figure 6-7, when theexternal clock port CLK is held inactive (low), the clock pin of FF_Ais driven by FF_B.

OUT

AN2

AN2

OR2

FD1IVAIN

SEL

CLK2

CLK1



Figure 6-7 Invalid Clock Gating

You can correct invalid clock gating violations by inserting test modelogic, as explained in “Defining a Test Mode” later in this chapter.

If a clock pin is driven by constant logic, the check_test commandissues a warning:

Warning: Clock/enable pin %s of cell %s (%s) tiedconstant. (TEST-125)

The waveforms of the inferred clocks are taken either from a previousinvocation of the create_test_clock command or from given scan-style-dependent default values.

Inferring Asynchronous Ports

To reliably shift data in and out of scan chains, the asynchronouspreset and clear pins of sequential cells must be held to their inactivevalues during the shift operation. The check_test command infers theasynchronous ports of the design and their active values in the sameway it infers clocks: by tracing asynchronous pins back to input portsthrough active paths. The check_test command flags uncontrollablepins with the following message:

CLK

OR2

DFF1

U1

A

BZ FF_A

P

D Q

P

D Q

DFF1FF_B

D_2

D_1 OP



Warning: Asynchronous pins of cell %s (%s) areuncontrollable. (TEST-116)

Uncontrollable pins usually occur when the asynchronous signal isgenerated from the state of other sequential devices, as shown inFigure 6-8. You can correct this violation by inserting test mode logic,as explained in “Defining a Test Mode” later in this chapter.

Figure 6-8 Circuit With Uncontrollable Asynchronous Clear

Simulating the Test Protocol

The check_test command uses symbolic simulation techniques tocheck the operation of scan chains in your design. This use ofsimulation techniques frees you from the possibly restrictivetopological rules that govern scan design and focuses on the behaviorof scan circuitry. Ultimately, the controllability and the observability ofeach sequential cell matter more than the means of achievingcontrollability and observability.

The check_test command assumes a generic flow for scan testing.After initialization, each pattern consists of the following sequence:

1. Scan in

CLK

OR2

DFF1

U1

A

BZ

FF_AP

D Q

P

D Q

DFF1FF_B

POR

D OP

RESETQN

QN



2. Parallel measure and capture

3. Scan out

As the protocol simulation proceeds, the check_test commandsequences once through these phases according to the data providedin the protocol. For example, the presence of a scan-in symbolic valuein the protocol puts the check_test command in the scan-in phase.In each phase, the check_test command verifies that the state of thesimulation is consistent with what would be expected of a scan design.

Initialization Phase

The initialization phase puts the circuit into scan mode. No checksare done in this phase. As protocol vectors are simulated, thecheck_test command reports the vector type.


Checking for Scan-In Violations

The scan-in phase starts when the check_test command detects ascan-in symbolic value in the protocol. The check_test commandissues the message

...simulating scan-in vector...

The check_test command confirms that scan in reaches the first flip-flop, and that the contents of flip-flop n reach flip-flop n+1. If theseevents occur, check_test reports

...<unique> bits scanned-in to count cells (total scan-intotal)...



unique

Is the number of unique scan-in values retained in state elementsand applied at scan-in ports.

count

Is the total number of state elements storing these values.

total

Is the cumulative sum on all scan vectors and streamsencountered in the protocol.

The unique and count values differ when the data diverges and getsclocked into multiple state elements. The total value can be less thanthe number on previous streams and vectors because of data lossafter scan in.

If the first scan-in cycle has no visible effect on the state of the scanchains, the check_test command issues the message

Information: Extending scan in by one cycle because duringthe first scan-in cycle does not shift indata. (TEST-301)

The check_test command automatically adds one cycle to the scan-in phase of the protocol. So if, within a cycle, the active edges of thescan clocks occur before the data application time, the last cell onthe longest chains is still loaded.

Binding the Scan-In State to the Scan Flip-Flops

At the end of the scan-in phase, the scan-in state is bound to the scanflip-flops. The check_test command warns you that elements with anunknown state are not scan-controllable.

Warning: Cell %s (%s) is not scan controllable. (TEST-302)



Information messages accompany each TEST-302 warning; theyexplain why the cell is not scan-controllable. A cell can beuncontrollable because of clocking problems, asynchronousproblems, or loading problems. A cell can have more than one ofthese problems.

If a violation occurs on more than one cell, the check_test commandlists the first occurrence. In verbose mode, the check_test commandlists all occurrences of the violation.

Use the trace_nets command on nets connected to the flip-flop’s pinsto determine why the scan data is not shifted into the cell. Using thetrace_nets command is described later in this chapter, in “DebuggingCommands.”

Elements that are not scan-controllable become X generators for therest of protocol simulation.

Constant Values

Sequential elements with a constant state generate warnings thatthey have a constant value.

Warning: Sequential cell %s (%s) has constant logic 1/0state. (TEST-142).

Checking for Capture Violations

The check_test command determines if scan cells can reliablycapture data during the parallel phase of the protocol. Cells thatcannot reliably capture data are those for which Test Compiler ATPGcannot predict the captured state, regardless of the input patternapplied.



The parallel phase consists of two operations: parallel measure andcapture. The parallel measure operation must occur before thecapture operation. The parallel phase is initiated by the presence ofa parallel data symbolic value in the protocol.

The parallel measure operation consists of applying test data onprimary inputs and strobing primary outputs. The circuit then operatesas it would in functional mode. The scan circuitry is inactive. Nochecks are performed during this operation.

The capture operation is initiated by the presence of a capture clocksymbolic value in the protocol. The check_test command determineswhether scan cells can reliably capture data in parallel operation.Cells that cannot capture data are marked with a capture violation. Acapture violation means that Test Compiler ATPG cannot predict thecaptured state, regardless of the input pattern applied.

A typical capture cycle results in the following sequence of messages:


...simulating capture clock rising edge at port ck2...

...simulating capture clock falling edge at port ck2...

...simulating parallel vector

...creating capture clock groups...Information: Inferred capture clock group : ck.(TEST-262)

Parallel measure and capture operations can be collapsed into asingle vector in strobe-before-clock protocols unless they require twoconsecutive vectors in the standard protocol. For more informationabout parallel measure and capture, see Chapter 7, “Developing aTest Protocol.”



Scanned-In State Dependency Rules

The captured data value must depend only on scanned-in state, validnonscan state (for partial scan), and primary input values. It shouldnot depend on the following:

• Uncontrollable sequential elements

• Floating inputs

• Clock signals

• Other captured values

In addition, the gating conditions of a capture cell’s clock must notdepend on other captured values; otherwise Test Compiler ATPGcannot determine if the value present on the data pin of the cell isactually captured.

The following sections describe how the check_test command checksfor clock signals used as capture data, capture data gating the clock,and unreliable capture conditions.

Note:The test design rule checker does not check for the possibledependency of captured data on uncontrollable elements andfloating values.

Clock Signals as Data

When a clock signal drives the data pin of a cell, as in Figure 6-9,ATPG tools cannot determine the captured value. The check_testcommand flags this problem with a warning:

Warning: Data pin %s of cell %s (%s) is driven by aclock/enable signal. (TEST-131)



Figure 6-9 Clock Signal Used as Data

Captured Data Gating the Clock

For data to be reliably captured in a register with a sequentially gatedclock, all clock gating conditions must remain stable while the clockpulse is applied at the clock pin of that register. Test Compiler ATPGcannot determine a cell’s captured value if the clock gating conditionfor a cell depends on the state of other cells that have the same clockand the scanned-in state of the gating registers changes before theactive (capture) edge of the clock at the clock pin of the gated register.The capture value cannot be determined because the gatingcondition for the clock of the identified cell changes before the active(capture) edge of the clock reaches that cell. In this situation, thecheck_test command issues the message

Warning: The clock signal to cell %s (%s) is illegallygated. (TEST-140)

Consider, for example, the circuit in Figure 6-10. Clock port CLK isdefined as a return-to-zero clock, with a {45 55} waveform. At therising edge of clock CLK (time 45 in the capture cycle), the gatingcondition for the clock of register U2 is changed as a result of thecaptured value in register U1. Test Compiler ATPG cannot determinethe captured value of cell U2.

OP1D1

CLK

U2 U1



Figure 6-10 Example of Invalid Clock Gating

The clock gating in Figure 6-10 would be valid if U1 were clocked onthe negative edge of the clock. Figure 6-11 illustrates this concept byinverting the clock signal. The gating condition for the clock of cell U2changes at time 55 after cell U2 captures reliably at time 45.

Figure 6-11 Example of Valid Clock Gating

Another way to ensure that data is reliably captured in a register witha sequentially gated clock is to use synchronization latches.

Synchronization Latches Preventing Capture Violations

Many designs use latches to synchronize data, to prevent raceconditions between data and clock, or to fix testability problems ofdesigns with scan test logic. Figure 6-12 is an example of a

DD

A1

A2O1

CLK

U1U2

DD

A1

A2O1

CLK

U1U2



synchronization latch. The latch L1 delays the propagation of achange on the output of U1 by half a clock cycle and compensatesfor conditions that cause capture violations if the latch is not used.

Figure 6-12 Synchronization Latch Used to Prevent Capture Violations

For the check_test command to recognize a component as asynchronization latch, the component must meet these requirements:

• The enable signal to the latch must be controllable from a top-level port.

• The latch must be transparent in the parallel measure cycle.

• The latch must not have the scan_transparent attribute, and thescan_element attribute must not be set to false on the latch.

If a latch is scan-replaced by compile -scan and check_testrecognizes this cell as a synchronization latch, it is unscanned byinsert_scan. You can ignore the check_test pre-scan warnings relatedto “no scan equivalent” for latches if they are synchronization latches.

L1

QD

DA2

O1

CLK

U1U2

A2



To ensure safe capture operation when a synchronization latch isused, at least one of the following conditions must be true:

• All registers in either the transitive fanin or the transitive fanout ofthe synchronization latch are clocked by the same capture clockas the synchronization latch.

• The synchronization latch is not clocked at all in the parallelcapture cycle.

If neither condition is true, a warning message informs you ofunreliable capture operations. When Test Compiler generates testpatterns using ATPG, it models the offending synchronization latchesas black boxes.

If a synchronization latch prevents unreliable capture, the design rulechecker does not issue warnings. When Test Compiler generates testpatterns using ATPG, the design rule checker treats the latch as abuffer. Because the latch is treated as a buffer, the faults on the enablesignal are not detected (that is, they are untested faults).

Note:These untested faults can be detected only in the case of a timingproblem (a hold violation, for example).

Unreliable Capture Conditions

When both source register and destination register are clocked bythe same clock signal, either of the following conditions can cause acell to capture unreliably:

• Source register launch of response data before destinationregister capture

• Asynchronous path between the source register and thedestination register



Source Register Launch Before Destination Register Capture

Unreliable capture occurs if a combinational path exists between twosequential elements that are clocked by the same clock source andthe clock signals at the clock pins of these two elements are notproperly aligned. The captured value of the destination elementdepends on the response value of the source element instead of thescanned-in value.

Note:In designs with master-slave clocking, unreliable captureconditions of this type are not typically a problem if data capturewith master clocks can be completed before sequential celloutputs are updated with slave clocks.

Consider, for example, the latch-based circuit in Figure 6-13. Whilethe clock is active, both devices are transparent. When the clockbecomes inactive, the second latch (U2) can capture the valueoriginally on port D1 or on its data pin, depending on the relationshipbetween the clock width and the delay on the data path. This causesthe destination latch (U2) to capture unreliably.

Figure 6-13 Latch-Based Circuit With Source Register Launch BeforeDestination Register Capture

Example 6-2 shows the set of diagnostic messages issued for thecircuit in Figure 6-13. The clock source is defined as a return-to-zeroclock with a {45 55} waveform. The destination register is a latch oftype LATCH1.

D

G

QD1 OP1

G

D Q

U2U1

CLK



Example 6-2 Diagnostic Messages for the Circuit in Figure 6-13Warning: Pin D of cell U2(LATCH1) cannot capturereliably.(TEST-478)Information: Cell U1 launches response data from pin Q atrising edge of clock port CLK (pin G) at time45.(TEST-472)Information: Cell U2 captures data on pin D at fallingedge of clock port CLK (pin G) at time 55.(TEST-473)Information: There is a path from U1 to U2.(TEST-474)Information: The path includes....(TEST-282)

The diagnostic messages for unreliable capture violations includeinformation about the combinational path between the source anddestination registers. In this example, source register U1 launchescaptured response data from pin Q at time 45 in the capture cycle(rising edge of the clock). The D pin of the destination register U2captures response data at time 55 in the capture cycle (falling edgeof the clock). New response data, captured in U1 at time 45, canappear at the D input of the destination register U2 before that registercaptures at time 55.

Note:A configuration such as the one shown in Figure 6-13 might notcause a problem during normal circuit operation if the paths arecarefully timed. Because the test design rule checker and TestCompiler ATPG operate under zero-delay information, theycannot guarantee that the generated patterns perform the captureoperation reliably.

Consider the same design with flip-flops instead of latches. Becauseflip-flops are edge-sensitive, an unreliable capture condition isprevented. Although the output of the first flip-flop changes at capturetime, the arrival of modified data at the input of the second flip-flophas no effect on the state of that flip-flop.



Other examples of unreliable capture conditions caused by sourceregister launch before destination register capture include

• Q-to-D path between a positive edge-triggered flip-flop and anegative edge-triggered flip-flop, clocked by the same return-to-zero clock source. In this case, the response data launched fromthe source flip-flop at the rising edge of the clock can arrive at thesynchronous input of the destination register before it arrives atthe falling edge of the clock.

• Q-to-D path between a negative edge-triggered flip-flop and anenabled low latch, clocked by the same return-to-zero clocksource. This condition occurs in the circuit shown in Figure 6-14.In this case, the destination latch captures response data at therising edge (first edge) of the clock. The source flip-flop launchescaptured (or response) data at the falling edge (second edge) ofthe clock. The destination latch becomes transparent at the fallingedge of the clock, however, and the initial captured value of thatcell is overwritten by the newly launched response data from thesource register.

Figure 6-14 Flip-Flop Circuit With Source Register Launch BeforeDestination Register Capture

Example 6-3 shows the set of diagnostic messages issued for thecircuit in Figure 6-14. The clock source is defined as a return-to-zero clock with a {45 55} waveform. The destination register is alatch of type LATCH2.

D

G

QD1

CLK

OP1D Q

U2U1

CP



Example 6-3 Diagnostic Messages for the Circuit in Figure 6-14Warning: Pin D of cell U2(LATCH2) cannot capturereliably.(TEST-478)Information: Cell U1 launches response data from pin Q atfalling edge of clock port CLK (pin CP) at time55.(TEST-472)Information: Enable pin G of cell U2 becomes active atfalling edge of clock port CLK at time 55. (TEST-477)Information: There is a path from U1 to U2.(TEST-474)Information: The path includes....(TEST-282).

Interpreting Diagnostic Messages

If the check_test command detects an unreliable capture conditioncaused by source register launch before destination register capture,it issues the following message:

Warning: Pin %s of cell %s (%s) cannot capturereliably.(TEST-478)

The pin indicated in the TEST-478 message is marked with a violation;Test Compiler ATPG does not use this pin for observing fault effectsin the register. Note that Test Compiler ATPG uses other data pins ofthe cell (if any) for observing fault effects as long as those pins arenot violated.

In addition to the unreliable capture warning, the check_testcommand issues diagnostic messages related to the source anddestination registers, indicating the cause of the unreliable captureproblem.

The first diagnostic message describes the source register and thetime at which response data launches from that register. If responsedata is launched from that register at a clock transition in the capturecycle, the check_test command issues the following message:



Information: Cell %s launches response data from pin %s at%s edge of clock port %s (pin %s) at time %s.(TEST-472)

Cell %s

Is the source register from which response data launches.

pin %s

Is the output pin of the source register.

%s edge

Is the transition (rising or falling) of the clock when response datalaunches.

clock port %s

Is the name of the clock port that is the source of the clock signal.

(pin %s)

Is the launching register’s clock pin affected by the transition atthe clock port.

time %s

Is when the clock transition occurs in the capture cycle (thecheck_test command assumes zero delay and does not considercell delays or wire delays).

If response data is launched from the source register before the startof the capture cycle, the check_test command issues the followingmessage:

Information: Cell %s launches response data from pin %sprior to the start of the capture cycle.(TEST-479)

This message identifies the source register and the output pin of theregister that launches response data. For example, if the sourceregister is an enabled-low latch clocked by a return-to-zero clock, then



the latch is transparent at the start of the capture cycle, and responsedata has launched from that register before the start of the capturecycle (at the one-to-zero transition of the clock in the last scan shiftcycle).

The second diagnostic message issued for an unreliable capturecondition caused by source register launch before destination registercapture includes information about the destination register and thetime at which response data is captured in that register.

Information: Cell %s captures data on pin %s at %s edgeof clock port %s (pin %s) at time %s.(TEST-473)

Cell %s

Is the destination register where response data is to be captured.

pin %s

Is the synchronous input pin of the destination register.

%s edge

Is the transition (rising or falling) of the clock when response datais to be captured in the destination register.

clock port %s

Is the source of the clock signal.

(pin %s)

Is the target register’s clock pin affected by the transition at theclock port.

time %s

Is when clock transition occurs in the capture cycle (the check_testcommand assumes zero delay and does not consider cell delaysor wire delays).



If the destination register is level-sensitive and it becomestransparent at the resting value of the clock, the check_testcommand issues the following message:

Information: Enable pin %s of cell %s becomes active at%s edge of clock port %s at time %s. (TEST-477)

Enable pin %s

Is the destination register enable pin that is affected by thetransition at the clock port.

cell %s

Is the destination register (where response data is to be captured).

%s edge

Is the transition (rising or falling) of the clock when the clock returnsto its resting value. The enable pin of the destination registerbecomes active at this edge.

clock port %s

Is the source of the clock signal.

time %s

Is when clock transition occurs in the capture cycle (the check_testcommand assumes zero delay and does not consider cell delaysor wire delays).

Asynchronous Path between Source Register andDestination Register

Another condition that causes unreliable capture occurs when thesource and destination registers are clocked by the same clock port;the response value captured in the source register canasynchronously affect the response value captured in the destinationregister.



Consider the example in Figure 6-15, where the captured value in U1can asynchronously affect the captured value in U2. Registers U1and U2 are clocked by port CLK. The signal driven by port A3 gatesthe Q output of register U1 to the asynchronous clear pin of registerU2. If the test protocol does not hold port A3 to logic 1 during theparallel measure and capture cycles, the response value captured inU1 can asynchronously affect the response value captured in U2.

Figure 6-15 Circuit With Asynchronous Path Between Source andDestination Registers

Example 6-4 shows the set of diagnostic messages issued for thecircuit in Figure 6-15. The clock source is defined as a return-to-zeroclock with a {45 55} waveform. The destination register is a positiveedge-triggered flip-flop of type FF.

Example 6-4 Diagnostic Messages for the Circuit in Figure 6-15Warning: Asynchronous control pin CLRZ of cell U1 (FF) canchange in the capture cycle. This can cause the cell tocapture unreliably.(TEST-471)Information: Cell U1 launches response data from pin Q atrising edge of clock port CLK (pin CP) at time45.(TEST-472)Information: This can cause a change on asynchronouscontrol pin CLRZ of cell U2.(TEST-476)Information: There is a path from U1 to U2.(TEST-474)

DD

A1

A2O1

CLK

U1U2

A3

Q

CLRZ



Information: The path includes....(TEST-282)

These messages indicate that the launch of captured response datafrom cell U1 at time 45 in the capture cycle (rising edge of the clock)can cause a change on the asynchronous control pin CLRZ of cellU2. Such a change can disturb the values captured in cell U2 throughany of the synchronous inputs of that cell.

Other examples of unreliable capture conditions due to anasynchronous path between source register and destination registerinclude

• A combinational path between output of a negative edge-triggeredflip-flop and an asynchronous control pin of a positive edge-triggered flip-flop, clocked by the same clock port

• A combinational path between output of the master stage of amaster-slave register and an asynchronous control pin of anotherregister, both clocked by the same clock port

Interpreting Diagnostic Messages

When the check_test command detects an unreliable capturecondition caused by an asynchronous path between the sourceregister and the destination register, it issues the following warningmessage:

Warning: Asynchronous control pin %s of cell %s (%s) canchange in the capture cycle. This can cause the cell tocapture unreliably.(TEST-471)

Asynchronous control pin %s

Is the pin of the destination register affected by the launch ofresponse data from a source register.

cell %s



Is the name of the destination register.

(%s)

Is the destination register type.

In this case, the check_test command marks the asynchronouscontrol pin of the destination register with a violation, and TestCompiler ATPG does not use the cell for observing fault effects.

In addition to the unreliable capture warning, the check_testcommand issues diagnostic messages related to the source register,the destination register, and the combinational path between the tworegisters.

Diagnostic messages related to the source register

The first diagnostic message describes the source register and thetime at which response data launches from that register. If responsedata is launched from that register at a clock transition in the capturecycle, the check_test command issues the following message:

Information: Cell %s launches response data from pin %sat %s edge of clock port %s (pin %s) at time%s.(TEST-472)

Cell %s

Is the source register from which response data launches.

pin %s

Is the output pin of the source register.

%s edge

Is the transition (rising or falling) of the clock when response datalaunches.

clock port %s



Is the name of the clock port that is the source of the clock signal.

(pin %s)

Is the launching register’s clock pin affected by the transition atthe clock port.

time %s

Is when the clock transition occurs in the capture cycle (thecheck_test command assumes zero delay and does not considercell delays or wire delays).

If response data is launched from the source register before thestart of the capture cycle, the check_test command issues thefollowing message:

Information: Cell %s launches response data from pin %sprior to the start of the capture cycle.(TEST-479)

This message identifies the source register and the output pin ofthe register that launches response data. For example, if thesource register is an enabled-low latch clocked by a return-to-zeroclock, then the latch is transparent at the start of the capture cycle,and response data has launched from that register before the startof the capture cycle (at the one-to-zero transition of the clock inthe last scan shift cycle).

Diagnostic messages related to the destination register

The second diagnostic message describes the unreliable capturecondition at the destination register.

Information: This can cause a change on asynchronouscontrol pin %s of cell %s.(TEST-476)



pin %s

Is the name of the destination register’s asynchronous control pinaffected by the launch of captured response data from the sourceregister.

cell %s

Is the name of the destination register.

Diagnostic messages related to the combinational path

The remaining information messages (TEST-474 and TEST-282)describe the combinational path between the source and destinationregisters.

Capture Clock Groups

A situation similar to the unreliable capture conditions discussed inthe previous sections can arise between two cells clocked byindependently controlled signals. In Figure 6-16, for example, the datalaunched from U1 at time t1 might propagate to the capture pin of cellU2 at time t2, but it might not. So, in cycles for which both clocks areactive, Test Compiler ATPG and other ATPG tools cannot computethe expected response in U2. Because C1 and C2 are independentlycontrollable, however, the check_test command can avoid anunreliable capture condition by ensuring that only one clock—C1 orC2—is active in any capture cycle. These two clocks are placed indifferent capture clock groups. A capture clock group is a set of clocksthat can be safely clocked in the same cycle.



Figure 6-16 Multiple Capture Clock Groups

During test pattern generation, only one capture clock group isactivated in any given cycle. As a result, the cells controlled by clocksfrom inactive clock groups retain their scanned-in state until scan out.

The check_test command automatically assigns clocks to capturegroups while checking for unreliable capture conditions. Thisassignment takes into account the topology of the design (which flip-flops drive other flip-flops), the relative timing of the capture clocks,and a coarse indication of expected clock skew.

Note:Only capture clocks, those clocks denoted as Cp in the testprotocol, are assigned to capture clock groups. Scan clocks inlevel-sensitive scan design (LSSD) or in clocked-scan are neverpart of a capture clock group. In multiplexed flip-flop designs,where the same clocks are used for both scan shift and capture,the configuration of the scan chains has no effect on how clocksare partitioned into capture clock groups.

The check_test command reports on capture clock groups as follows:

Information: Inferred capture clock group: CLK.(TEST-262)

D QC1

C2

D Q

U1

U2



Each TEST-262 message refers to a different clock group; themessage lists all the clocks in that group.

Note:Unreliable capture conditions resulting from capture on bothedges of a single clock cannot be eliminated by clock groupassignment. In addition, unreliable capture conditions resultingfrom a mixture of edge-triggered and level-sensitive devicescontrolled by the same clock cannot be eliminated by clock groupassignment.

Controlling the Inference of Capture Clock Groups

Short of changing the topology of the design, you can control thecapture clock group inference in two ways.

1. Specify different clock waveforms by using the create_test_clockcommand.

The timing of the launch event on the upstream cell relative to thecapture event on the downstream cell is what matters. For anedge-triggered cell, the two events are simultaneous. For a level-sensitive cell, launch occurs when the last stage becomestransparent; capture occurs when the first stage closes.

2. Specify a coarse estimate of clock skew using thetest_capture_clock_skew variable. This variable has threepossible settings: no_skew, small_skew, and large_skew. Thedefault setting is small_skew.



no_skewThe waveforms on clock pins of cells are assumed to be identicalto the waveforms specified on the top-level ports. As a result, thesequencing of events on clock pins is the same as the sequencingof events on the top-level ports. You can safely put clocks withidentical waveforms in the same capture group.

The no_skew setting results in the least number of clock groupsand possibly the smallest test program. But it is also the most riskysetting, as it can induce Test Compiler ATPG to generate invalidexpected responses. Use this setting with caution. Validate yourvectors through simulation.

small_skewThe waveforms on clock pins of cells are assumed to be identicalto the waveforms specified on the top-level ports except forsimultaneous events that are slightly skewed. Assume that cellU1, controlled by clock C1, launches at time t e (where e is smallerthan any time difference specified in the clock waveforms), andcell U2, controlled by clock C2, captures at time t e, and there isa path from U1 to U2. C1 and C2 are split into different capturegroups to avoid creating an unreliable capture condition.

Although the possibility of invalid vectors is not eliminated by usingthe small_skew (default) setting, it is greatly reduced.

large_skewThe clock skew is assumed to be arbitrarily large. As a result, thesequencing of events on clock pins of cells is unknown. Any pathfrom one clock domain to another causes the two clocks to be inseparate clock groups, independent of clock waveforms.

For most purposes, this setting produces overly conservativeresults: a maximum number of clock groups, and hence, a largertest program. This setting does, however, completely eliminatethe possibility of invalid vectors caused by skew.



Note:The test_capture_clock_skew variable annotates the skewbetween clocks that are independently controllable. The clockskew between two capture cells in the same clock domain isassumed to be zero.

Table 6-2 shows the number of clock groups resulting from combinedeffects of specifying different waveforms and different skews for thecircuit of Figure 6-16.

Unsuccessful Data Capture

If data cannot be captured into a cell, the check_test command issuesthe following warning:

Warning: Data can not be captured into cell %s (%s).(TEST-310)

Table 6-2 Clock Group Results Generated by Different Skew Assignments

Clock waveforms no_skew small_skew large_skew

1 1 2

1 2 2

2 2 2

C1

C2

C1

C2

C1

C2



Scan-Out Phase

The scan-out phase is initiated when a scan-out symbolic valueappears in the protocol. In general, the scan-out operation for thecurrent pattern is shared with the scan-in operation of the next pattern.The simulation of the scan-out phase proceeds from fully loaded scanchains. The scan-out phase repeats the simulation of the scan-invectors, verifying that each vector passes its contents to theneighboring vector and that the last vector in the chain is observable.the check_test command issues the following report:

... unique bits scanned-out from count cells (total

scan-out total )...

unique

Is the number of unique scan-out values retained in state elementsand applied at scan-out ports.

count

Is the total number of state elements storing these values.

total

Is the cumulative sum over all scan vectors and streamsencountered in the protocol.

Checking for Scan Connectivity Violations

After the check_test command completes test protocol simulation, itanalyzes the simulation results to determine the following:

• The architecture of the scan chains

• Whether the capture state and the state of the cell that is scannedare the same



The report_test -scan_path command reports the scan chainarchitecture determined by the check_test command. The write_testcommand uses the scan chain architecture, determined by thecheck_test command, to properly format the test pattern dataproduced by Test Compiler ATPG.

Running an incremental compile or other command that affects thedatabase can cause the information gathered by check_test to bediscarded. If you run a report_test -scan_path and get an errormessage saying that there is no scan path defined, try runningcheck_test again, immediately followed by a report_test -scan_pathcommand.

Scan Chain Extraction

A scan chain is a group of sequential elements through which auniquely identifiable bit of scan data travels. The check_testcommand extracts scan chains from a design by tracing scan databits through the multiple time frames of the protocol simulation. Scanchains are protocol-dependent: For a given design, specifying adifferent test protocol can result in different scan chains. As acorollary, scan chain related problems can be caused by an incorrectprotocol, by incorrect set_test_hold specifications, or even byincorrectly specified timing data.

Incomplete Scan Chains

When the scan data of a scan chain originates from an internalcomponent of the design rather than from an input port, thecheck_test command issues the following warning:

Warning: Scan chain terminating at ’%s’ is not scancontrollable. The chain originates from cell %s.(TEST-363)



When the scan data of a scan chain is not visible on an output port,the check_test command issues the following warning:

Warning: Scan chain originating from ’%s’ is not scanobservable. The chain terminates at cells %s. (TEST-362)

Divergent Scan Chains

If, during protocol simulation, a scan bit is loaded into two or moresequential cells in parallel, the check_test command flags all but oneof these cells as part of divergent scan chains. This is a violationbecause test-pattern generation cannot account for correlated scandata. The cells that are not part of the scan chain are marked asuncontrollable and the check_test command issues the followingmessages:

Warning: Scan chain originating from port ’%s’ divergesafter %s. (TEST-361)Information: Because independent scan data cannot beshifted into cells %s from cell %s. (TEST-360)Information: As a result, the following cells are notcontrollable: %s. (TEST-365)

For example, the check_test command issues the precedingmessages if a scan cell drives multiple sequential cells. In that case,you can suppress the messages by using the set_test_isolatecommand on the elements that must not be part of the scan chain.The set_test_isolate command makes the specified elementsuncontrollable.

Another example of a situation that causes a violation is when scandata skips a cell, as shown in Figure 6-17. In this example, scan datamoves from cell A to cell B on the rising edge of the clock and



immediately from cell B to cell C on the falling edge of the clock. Atthe end of each shift cycle, cell B and cell C always have the samedata.

Figure 6-17 An Apparently Diverging Scan Chain

For the circuit shown in Figure 6-17, the check_test command issuesthe following messages:

Warning: Scan chain originating from port ’test_si’diverges after A. (TEST-361)Information: Because independent scan data cannot beshifted into cells B,C from cell A. (TEST-360)Information: As a result, the following cells are notcontrollable: C. (TEST-365)

IN1

FD1SCLK

IN2

IN3

Atest_si

test_se

FD1S

B

FD1S

OUT2

OUT3

C

OUT1

IVA



Scan-Out State Inconsistent With Capture State

If a scan cell is a master-slave cell, such as an LSSD scan cell, andthe inferred behavior for the B clock pulse causes the cell capturestate to be different from the cell scan-out state, Test Compiler ATPGgenerates bad test vectors. The check_test command checks for thiscondition and warns you when it finds this condition.

The check_test command attempts to analyze the circuit and createa scan style protocol that creates good test vectors, but for somecomplex cases, the check_test command analyzes the circuitincorrectly and creates a scan style protocol that creates bad testvectors.

Consider the circuit shown in Figure 6-18. If the C clock is pulsed inthe capture cycle but the B clock is not, the captured value is in themaster state of the cell, not in the slave state.

Figure 6-18 Clocked LSSD Cell With a Separate SO State

For the cell shown in Figure 6-18 and an incorrect test protocol, thecheck_test command issues the following message:

Warning: Data was captured in the master state of cell %s(%s) but scanned out of the slave state. (TEST-311)

SI

C1

1D QC

D

C1

D

Q'

2D

C2A

B

SO

SO'



In the Test Design Rule Violation Summary, the check_test commandissues the following message in the capture violations section:

Lost value captured in master state of cell violations(TEST-311)

A second example is a single latch LSSD cell with the capture in theslave state of the cell shown in Figure 6-19. In this example thecapture value is in the slave state of the cell when the C clock ispulsed. The captured value is destroyed when the B clock is pulsed.

Figure 6-19 Single Latch LSSD Cell With Capture in the Slave State of theCell

For the cell shown in Figure 6-19 and an incorrect test protocol, thecheck_test command issues the following message:

Warning: Data was captured in the slave state of cell %s(%s) but scanned out of the master state. (TEST-312)

In the Test Design Rule Violation Summary, the check_test commandissues the following message in the capture violations section:

Lost value captured in slave state of cell violations(TEST-312)

SI

C1

1D Q/SOC

D

C1

D

Q'/SO'

2D

C2A

B



To generate good test vectors, you have to either pulse the B clockin the capture cycle, the solution for the first example, or not pulsethe B clock in the capture cycle, the solution for the second example.To do this you must infer the protocol again while controlling the Bclock during the capture cycle. Use thetest_infer_slave_clock_pulse_after_capture variable. You can set thetest_infer_slave_clock_pulse_after_capture variable to one of thefollowing:

• pulse—If the variable is set to pulse, all slave clocks are pulsedafter the capture cycle.

• no_pulse—If the variable is set to no_pulse, all slave clocks arenot pulsed after the capture cycle.

• infer—This is the default setting. If the variable is set to infer, theprotocol determines whether slave clocks are pulsed after thecapture cycle.

If the test_infer_slave_clock_pulse_after_capture variable is set to aninvalid value, the check_test command issues the followingmessages:

Warning: Invalid value fortest_infer_slave_clock_pulse_after_capture variable,assuming "infer". (TEST-314)1 Invalid test_infer_slave_clock_pulse_after_capturevariable value violation (TEST-314)

Summarizing Violations

At the completion of design rule checking, the check_test commanddisplays a violation summary. Example 6-5 shows the format of theviolation summary.



Example 6-5 Violation Summary*************************************************************

Test Design Rule Violation SummaryTotal violations: <number of total violations>

*************************************************************MODELING VIOLATIONS

n <type of modeling violation>TOPOLOGY VIOLATIONS

n <type of topological violation>PROTOCOL VIOLATIONS

n <type of protocol violation>SCAN IN VIOLATIONS

n <type of scan in violations>CAPTURE VIOLATIONS

n <type of capture violations>SCAN CONNECTIVITY VIOLATIONS

n <type of scan connectivity violation

The total number of violations for the circuit appears in the header. Ifthere are no violations in the circuit, the check_test command displaysonly the violation summary header. Within the summary, violationsare organized by category. A violation category appears in thesummary only if there are violations in that category. For eachcategory, the check_test command displays the number (n) ofviolations along with a short description of each violation and thecorresponding TEST message number. Using the TEST messagenumber, you can find the violation in the check_test run.

Unknown cell violations have message numbers in the TEST-450 toTEST-459 range.Unsupported cell violationshavemessage numbersin the TEST-460 to TEST-469 range. The following is an excerpt froma violation summary for unsupported and unknown cells:

MODELING VIOLATIONS 5 unknown cell violations (TEST-45x) 10 unsupported cell violations (TEST-46x)

Example 6-6 shows a violation summary for a small circuit.



Example 6-6 Violation Summary for a Small Circuit*************************************************************

Test Design Rule Violation SummaryTotal violations: 4

*************************************************************TOPOLOGY VIOLATIONS

1 Combinational feedback loop violation (TEST-117)1 Unreachable circuitry violation (TEST-118)

CAPTURE VIOLATIONS1 unreliable capture (data pin) violation (TEST-478)1 Cell cannot capture violation (TEST-310)

Classifying Sequential Cells

After the violation summary, the check_test command displays asummary of sequential cell information. Example 6-7 shows thesyntax of the sequential cell summary.

Example 6-7 Sequential Cell Summary*************************************************************

Sequential Cell Summary(w+x+y+z) out of <total> sequential cells have violations

*********************************************SEQUENTIAL CELLS WITH VIOLATIONS

* x cells have scan shift violations* n cells are not scan controllable* n cells are not scan observable

* y cells have parallel capture violations* Z cells are black boxes* w cells have constant values

SEQUENTIAL CELLS WITHOUT VIOLATIONS* n cells are valid scan* n cells are valid non-scan cells* n cells are transparent latches* n cells are synchronization latches



The number of sequential cells with violations appears in the header.This number is the sum of cells with scan shift violations, captureviolations, and constant values, along with cells that are black boxes.If a design has no sequential cells, only a header with the followingmessage appears:

There are no sequential cells in this design

Within the summary, sequential cells are divided into two groups:those with violations and those without. Only the categories ofsequential cells that are found in the design are listed in the summary.In verbose mode, cell names are listed within each category. Moreinformation about the sequential cell categories is provided in thefollowing sections.

Sequential Cells With Violations

This section of the sequential cell summary points to problematicsequential cells. The cells in this group have corresponding violationsthat can be found in the check_test output.

Cells With Scan Shift Violations

This category includes cells with scan-in and scan connectivityviolations. Within this category, cells are listed by the type of scanshift violation.

• Not scan-controllable

The check_test command cannot transport data from a scan-inport into the cell.

• Not scan-observable



The check_test command cannot transport data from the cell toa scan-out port.

Note:

Cells in multibit components are homogenous. If a cell in amultibit component has violations, then all of the cells in thatmultibit component have violations.

In the example circuit shown in Figure 6-20, if cell U4 has anasynchronous glitch during the scan cycle, the following conditionsarise:

• Cells U1, U2, and U3 are scan-controllable, but not scan-observable.

• Cells U5, U6, and U7 are scan-observable, but not scan-controllable.

Figure 6-20 Circuit With Scan-Controllable and Scan-Observable Problems

For this example, the check_test command generates the sequentialcell summary shown in Example 6-8. Because check_test wasinvoked with the -verbose option, each category contains a list of cells.

Example 6-8 Sequential Cell Summary for the Circuit in Figure 6-20********************************************* Sequential Cell Summary 8 out of 8 sequential cells have violations

SI

U1 U2 U3 U4 U5 U6 U7

SO

CLK

RESETSO



*********************************************SEQUENTIAL CELLS WITH VIOLATIONS * 8 cells have scan shift violations * 4 cells are not scan controllable U4 U5 U6 U7 * 4 cells are not scan observable U1 U2 U3 U4

Once check_test has run, you can invoke the report_test -scancommand to observe the scan chains as extracted by the check_testcommand. Refer to Chapter 8, “Building Scan Chains,” for moreinformation on this command.

Cells With Capture Violations

Cells in this category are sequential cells that cannot capture. Eachof these cells has a corresponding TEST-310 message. Captureviolations are just as important as scan shift violations because TestCompiler ATPG cannot use cells with capture violations to observecircuit response data. A circuit with capture violations but no scanshift violations can only be used to shift scan data through the scanchain.

A cell with a capture violation can still be considered scan-observable.For example, cell U6 in Figure 6-20 can have a capture violation andstill be scan-observable if its state can be shifted out to a scan-outport.



Black Box Cells

In the black box category are sequential cells that cannot be used foreither scan shift or capture. A cell that is not scan-controllable or scan-observable and that has a capture violation is a black box. Unknowncells and unsupported cells are also black boxes. Black box cells arenot scan-replaced by insert_scan. In a partial-scan design, asequential cell can be a black box if it cannot capture or does notretain the same state during scan shift.

Constant Value Cells

The constant value category includes sequential cells that areconstant during scan testing. These cells are assumed to holdconstant values for Test Compiler ATPG; they are not scan-replacedby insert_scan. For every constant value sequential cell, there is acorresponding TEST-280 or TEST-142 violation.

Sequential Cells Without Violations

The valid scan cells category displays the number of sequential cellsthat have no test design rule violations. ATPG tools can use thesecells for scan shift and for measuring circuit response data. Valid scancells can be scan-replaced by insert_scan.

The second category, valid nonscan cells, lists the number ofsequential cells whose state is not affected by the scan shift operation.This category is used only in a partial-scan design.

The number of transparent latches is listed in the third category.These latches are not scanned. The model used by the check_testcommand and Test Compiler ATPG for these latches is shown inFigure 6-1.



The number of synchronization latches is listed in the last category.For more information about synchronization latches, see“Synchronization Latches Preventing Capture Violations.”

The check_scan Command

The check_scan command is an alternative to the check_testcommand that runs faster but performs fewer types of checking. Thetwo commands work alike, except that check_scan does not checkfor capture violations or inconsistency between scan-out states andcapture states.

All commands related to design rule checking affect the check_scanand check_test in the same manner. The scan chain results are thesame for the two commands. Like the check_test command, thecheck_scan command generates all the information necessary forpreview_scan or insert_scan to build good scan chains.

This is the syntax of the check_scan command:

check_scan[-verbose][-check_contention true | false][-check_float true | false]

-verbose

By default, the check_scan command gives a warning for only thefirst cell or pin that violates a rule, followed by the number ofadditional violations of the same type. Using the -verbose optioncauses the command to generate warnings for all similar cells orpins involved in the same design rule violation.



-check_contention true | false

The -check_contention option determines whether thecheck_scan command does contention checking on bidirectionalports. When this option is set to true (the default), the commandchecks bidirectional port contention during the scan shift mode.It you set this option to false, the command does not do contentionchecking.

-check_float true | false

The -check_float option determines whether the check_scancommand does float checking on bidirectional ports. When thisoption is set to true (the default), the command does float checkingfor bidirectional ports during the scan shift mode. If you set thisoption to false, the command does not perform float checking.

Note:The check_scan command does not do contention or floatchecking during capture mode. To perform this type of checking,use the check_test command.

Differences Between check_scan and check_test

The main advantage of check_scan over check_test is that it runsfaster. This is because it skips the capture-related checking steps.The amount of time saved depends on the size and content of thedesign.

Although the scan chain results are the same, the violation reportsare different because check_scan does not report any captureviolations. The violation reports are otherwise the same.



Also, the completeness of the report generated by the report_test -scan_path command depends on whether check_test or check_scanhas been run. The report shows the same results for the integrity ofthe scan chain, the inversion of scan data along the chain, and orderof the scan elements, regardless of whether check_test orcheck_scan has been run. However, after check_test has been run,cells that cannot capture are listed with the notation “(x).” This notationdoes not appear in the report after check_scan has been run.

Using check_scan for Test Pattern Generation

The check_scan command is not suitable for generating test vectorswith the create_test_patterns command. Test Compiler ATPG needsthe capture checking information generated by check_test. If you onlyrun check_scan and then attempt to run create_test_patterns, TestCompiler ATPG detects the lack of necessary information and runscheck_test automatically. In that case, the time spent runningcheck_scan is wasted.

However, the check_scan command can be useful if you plan to writeout the STIL protocol and use TetraMAX ATPG to generate the testvectors. (For details, see Chapter 10, “Exporting a Design toTetraMAX ATPG.”) The capture-related checks done by check_testare conservative and are intended for Test Compiler ATPG. Not all ofthese checks are needed by TetraMAX ATPG. By using check_scan,you eliminate these checks and thereby reduce the “noise” ofirrelevant violation reports.

However, some of the capture checks might be relevant to TetraMAXATPG, so there is a risk that check_scan will fail to detect somecapture violations that reduce the final test coverage. You will not seethese violations until after you import the design into TetraMAX.



Design Rule Checking Related Commands

You can use several commands to guide the check_test command,thereby enhancing the capability of DC Expert Plus. You should runcheck_test after explicitly using set_test_hold, set_test_initial,set_test_isolate, set_scan_transparent, or set_test_assume.

The set_test_hold Command

Often you can alleviate design rule violations by defining a test mode.A test mode is a set of static logic conditions you define at the inputports. The check_test command maintains these conditions whileperforming test design rule checking, and Test Compiler ATPGmaintains these conditions while testing your device. Theset_test_hold command thus establishes a static test mode fordesignated input ports in your design.

One valuable use of the set_test_hold command is to explicitly breaka structural combinational feedback loop by applying a constant logicvalue.

Defining a Test Mode

You can configure your design in test mode to disable circuitry thatcauses design rule violations. For example, if an on-chip oscillatordrives the clock signal of a flip-flop in system mode, you can definean external port to drive the clock signal during test mode. The testmode is in effect during the entire scan-test sequence—from datascan in, through normal operation, to data scan out.



Use the set_test_hold command to hold one or more input ports at agiven logic value (1 or 0) during test. This command places a test_holdattribute on the selected ports. Use the set_test_hold command onthe top-level design in the design hierarchy. The command syntax is

set_test_hold value port_list

value

Is 1 or 0.

port_list

Is a list of port names in the design that you want to have theassigned value. To identify more than one port, enclose the list incurly braces ({}) or use the find command.

When you check design rules, the values defined at ports withtest_hold attributes are propagated through the circuit and their effecton design rules is evaluated.

The conditions you set with the set_test_hold command also applywhen you generate test patterns with the create_test_patternscommand. See Chapter 10, “Generating Test Patterns,” for details.

As an example of how to fix a violation by defining a test mode,consider the circuit in Figure 6-21. This circuit contains anuncontrollable clear signal violation (TEST-116).



Figure 6-21 Circuit With Uncontrollable Clear Signal Violation

To fix this violation, modify the circuit as shown in Figure 6-22 anddefine a test mode with the following command:

dc_shell> set_test_hold 1 TM

Figure 6-22 Asynchronous Pin Controlled by a Test Mode

CLK

OR2

DFF1

U1

A

BZ

FF_AP

D Q

P

D Q

DFF1FF_B

POR

D OP

RESETQN

QN

CLK

OR2

DFF1

U1

A

BZ

FF_AP

D Q

P

D Q

DFF1FF_B

POR

D OP

RESETQN

QN

OR2U2

A

B

Z

TM



The set_test_initial Command

If you know the initial logic values on internal cell output pins at thestart of testing, you can set the values with the set_test_initialcommand. When you check the design rules, the check_testcommand simulates the effect of an initializing vector sequence on adesign.

When an initialization protocol fails to simulate correctly due to thelimitations of three-valued simulation, you can emulate the effect ofpower-up initialization by specifying initial values for some registersin your design using the set_test_initial command. The check_testcommand uses the specified initial values only in the first vector ofthe initialization protocol. After the first vector, protocol simulationdetermines the register values. You must ensure that the initializationprotocol brings the design into a known state.

The command syntax is

set_test_initial value pin_list

value

Is 1 or 0.

pin_list

Specifies the leaf cell pins in the design that will assume the valueyou designated.

The set_test_initial command places a test_initial attribute on the pinsyou define in the pin list. To see a list of pins with the test_initialattribute, run the report_test -assertions command.



The set_test_isolate Command

If you want the test design rule checker and Test Compiler ATPG toknow that a pin or a cell has an unknown value during test, useset_test_isolate before you run the check_test command. Theset_test_isolate command has the effect of logically cutting the netsat a pin or around a sequential cell. The check_test command treatsan isolated pin as a pin whose value remains unknown, regardlessof the connectivity and other logic values present in the design. Thecheck_test command treats an isolated sequential leaf cell as one forwhich all pins are isolated. Such a cell is automatically a black box.The set_test_isolate command also suppresses warning messagesabout design rule violations for the pins and leaf cells you identify.

Caution!Use set_test_isolate with great caution; it can adversely affectfault coverage. To prevent scan replacement, use theset_scan_element command rather than the set_test_isolatecommand.


set_test_isolate object_list

object_list

Includes the pins and leaf cells in the design that you wantisolated.

The set_test_isolate command places a test_isolate attribute on thepins and cells you define in the object list. To see a list of pins andcells with the test_isolate attribute, run the report_test -assertionscommand.



Figure 6-23 shows how the test design rule checker models pinsisolated with the set_test_isolate command.

Figure 6-23 How the Test Design Rule Checker Models Isolated Pins

Note:You do not need to use the set_test_isolate command on a cellthat is already a black box.

Using set_test_isolate Effectively

The set_test_isolate command is particularly effective in certainsituations, such as the following:

• On a pin, to break a combinational feedback loop at a differentpoint than that chosen by the check_test command

• On a pin, to break a path to a pin that doesn’t reliably capture

• On a design port, to force the test pattern generation algorithm tonot use the port

• On a sequential cell that is known to be a black box, to suppresswarning messages

U1

U2

U3

U1

U2

U3

X

U1

U2

U3

X

Original Circuit set_test_isolate U1/Z set_test_isolate U2/A



Effects of set_test_isolate on Design Rule Checking

Isolated pins and cells are held unknown during protocol inferenceand during protocol simulation. The presence of isolated pins on thepath of asynchronous signals or clocks can influence the inferredprotocol. The presence of isolated pins in the test circuitry (scan pathsor scan enables) adversely affects protocol simulation. For example,an isolated scan pin breaks the scan chain, makes the initial portionof the chain controllable-only, and makes the tail portion of the chainobservable-only.

Effects of set_test_isolate on Pattern Generation

No information passes through an isolated pin in a test pattern. So,for test generation, an isolated pin is considered an uncontrollablepin. Depending on the location and the function of the isolated pin,the effect on fault coverage can be negligible (if, for example, the pinis otherwise violated) or catastrophic (as in the case of isolating theenable pin of a three-state driver). If the enable pin of a three-statedriver is isolated, there is no way to avoid contention during testing:create_test_patterns flags the presence of an ATPG conflict andgenerates zero percent fault coverage results.

Special Cases for set_test_isolate

Special cases in which you can use set_test_isolate include

• Input and output ports

Isolating input and output ports has the obvious effect—input portsbecome uncontrollable, while output ports become unobservable.Signals driving internal logic from an output port are leftuntouched, however.



• Bidirectional ports

Using set_test_isolate on a bidirectional port cuts off the port fromits bidirectional driver, as shown in Figure 6-24. In test patterngeneration, the port is treated as an output port and is consideredunobservable. If floating is not allowed, the generated patternsforce the driver into output mode.

• Internal three-state pins

Isolating an internal three-state driver pin has the effect ofenabling the driver and forcing an unknown value through it. Thiseffect is equivalent to a non-three-state driver on a three-state net,and it is flagged as such by the check_test command. To avoidthis situation, isolate load pins of three-state nets as shown inFigure 6-24.

Figure 6-24 Isolating Bidirectional Ports and Internal Three-State Nets

The set_scan_transparent Command

Use the set_scan_transparent command to designate cells astransparent for rule checking and test generation.

X

Data

X

U1

U2

set_test_isolate Data set_test_isolate U1/Z



The syntax is

set_scan_transparenttrue | false[ cell_design_ref_list ][-multibit multibit_component_list ]-existing

true | false

A Boolean value that determines whether to make level-sensitivesequential elements transparent during Test Compiler ATPG. Thedefault setting is false. This value is not case sensitive.

cell_design_ref_list

A list of design objects to be made transparent or not transparent.Objects can be any of the following sequential types: latches,hierarchical cells (containing latches), references, library cells,and designs.

-multibit multibit_component_list

Use this option if one or more of the cells you are specifying aremultibit components. You can use a separateset_scan_transparent command to specify multibit cells, or youcan combine regular and multibit cells in the same command asin the following example:

set_scan_transparent true c_a -multibit mc_b

-existing

Indicates that no additional logic is required to make a latchtransparent. Using this option is mandatory in theset_scan_transparent command.



The set_test_assume Command

Use the set_test_assume command to assign a known logic state tooutput pins of black box sequential cells. This command places atest_assume attribute on the selected output pins. When thecheck_test command and Test Compiler ATPG take into account theconditions you define with the set_test_assume command.

You must use the set_test_assume command on the current design;the test_assume attribute is instance-specific, and instances do notinherit this attribute from the reference design.


set_test_assume value pin_list

value

Specifies the assumed value, 1 or 0, on this output pin.

pin_list

Specifies the names of output pins of unknown (black box) cells,including nonscan sequential cells in full-scan designs. Thehierarchical path to the pin should be specified for pins insubblocks of the current design.

Caution!Use the set_test_assume command with caution, because thecheck_test command cannot determine whether the conditionsyou define with this command are correct.



Following are example situations in which you can use theset_test_assume command.

• Suppose your design has flip-flops or latches that are not scan-loadable and their state is considered unknown. If you know thatthese flip-flops or latches have a fixed state during testing, youcan define that fixed value with the set_test_assume command.

• Suppose your design includes a RAM cell and you devise a seriesof test vectors that load the RAM with a logic 1 value in everyposition. If you apply these vectors to the device under test beforethe test vectors generated by Test Compiler ATPG, and if the datain the RAM is not overwritten during testing, you can assume thatall RAM data output pins are at a logic 1 level during scan test.The command for this example is

dc_shell> set_test_assume one find(pin h1/ram/DOUT*)

• Suppose your design has a combinational feedback loop with afanin driven by the output of a black box sequential cell. If you useset_test_assume, the propagation of the assumed value at theoutput of the black box sequential cell can break the combinationalfeedback loop.

The report_test -assertions Command

Use the report_test -assertions command to list the test_hold,test_initial, test_assume, and test_isolate attributes on your design.This command lists all ports for which an assertion has been made,the asserted values, and the nature of the assertion. The commandsyntax is

report_test -assertions



The following is a sample report generated by this command:

****************************************Report : test -assertionsDesign : AM2910Version: 1998.02Date : Tues Apr 21 10:40:39 1998****************************************Assertions: AM2910: ENABLE_Y port held to 1

To remove an attribute listed in this report, use the remove_attributecommand. To remove all attributes and constraints from a design,use the reset_design command. See the man pages for moreinformation on these commands.

Caution!Using the reset_design command removes all constraints andattributes from a design, not just test related constraints andattributes.

Debugging Commands

You can use the results of the check_test command net tracingfunction to debug and verify test protocols and to debug the scanoperation of your circuit.

This section covers the use of trace_nets and related commands indc_shell. You can also specify nets for tracing using the trace_netsprotocol statement.



Tracing Nets

You can trace net values on your design as the test design rulechecker simulates the test protocol. After rule checking and beforeproducing any summary information, the check_test command printsa table of simulation values of selected nets. You can use thisinformation to debug and verify test protocols and to debug the scanoperation of your circuit.

To specify nets for tracing, you can use the trace_nets command indc_shell, as explained in the “trace_nets Command” section later inthis chapter.

Example 6-9 shows the trace_nets results for a small circuit.

Example 6-9 trace_nets Results in check_test Output***************************************************LEGEND: 1. VECTORS IV ‘i’ : ‘i’th Initialization Vector SI(i) : Serial Scan in (repeated ‘i’ times) PMV : Parallel Measure Vector CAP : Capture Vector 1SO : First Scan-out Measure Vector SO(i) : Serial Scan Out (repeated ‘i’ times) VEC : Parallel Vector 2. VALUES 0 : Logic 0 1 : Logic 1 z : High Impedance Value u : Uninitialized Si : Scanned-in Value Is : Initial State Rd : Response Data x : Unknown So : Scanned-out Value

Na : Net Values Not Available (Vector Not Simulated)



***************************************************

STARTING PRINT OF TRACE INFO FOR: Nets Traced From The Command Line: CLK data out1 test_seNets Traced In the Protocol File: test_se test_siNets Traced In the Protocol File that are not in the Design: fish_net jumbolaya

C d o t t L a u e e K t t s s . a 1 t t . . . _ _ . . . s s . . . e i =======+==+==+==+==+=== IV 1 ----------------------- 0.0 0 u u u u IV 2 ----------------------- 0 u u u u SI(1)----------------------- 5.0 0 u Is 1 Si 45.0 1 u Si 1 Si 55.0 0 u Si 1 Si PMV ----------------------- 5.0 0 u Si x x CAP ----------------------- Na Na Na Na Na 1SO ----------------------- 5.0 0 u Si 1 x SO(1)----------------------- 45.0 1 u x 1 x 55.0 0 u x 1 x =======================



The legend at the beginning of the trace_nets results briefly describesvector acronyms and vector values that might appear in the table ofsimulation values. A more detailed description appears in thefollowing sections.

After the legend, the check_test command lists which nets are beingtraced and where net tracing is specified. Nets are grouped bycategory.

• Nets specified in the trace_nets command

• Nets specified in the trace_nets protocol statement

• Nets specified for tracing in the trace_nets protocol statement butnot found in the design

In the table of simulation values, each column represents a netspecified for tracing.

Each row of the table is associated with a particular time in theprotocol. A row of net values is printed in the table each time a tracednet changes value. At least one row is printed for every vector in theprotocol. A vector-relative time stamp appears at the beginning ofeach row.

Vector Acronyms in trace_nets Results Tables

In a trace_nets results table, vector acronyms tag the horizontal linesthat separate vectors. The legend at the beginning of the trace_netsresults table briefly defines the vector acronyms. A more extensivedescription follows.



• IV (i)

The initialization vector tag includes a number (i) that correspondsto the vector’s position in the sequence. For example, if aninitialization sequence contains 20 vectors, the first vector in thesequence is tagged IV 1 and the twentieth vector in the sequenceis tagged IV 20.

• SI(i)

The serial scan-in vector is associated with the stream statementin the protocol. The tag includes a number enclosed inparentheses (i) that indicates the number of times the serial scan-in vector is repeated. For example, if the longest scan chain in adesign that uses a default protocol is 120 vectors long, the vectoris denoted by SI(120).

• PMV

The parallel measure vector is used to apply primary inputs andbidirectionals used as inputs. This vector is also used to strobeprimary outputs and bidirectionals that are used as outputs.

• CAP

The capture vector in the protocol.

• 1SO

This is the first scan-out measure vector in the protocol. It is notpresent in strobe-before-clock protocols. The strobe-before-clockprotocol type is discussed in Chapter 7, “Developing a TestProtocol.”

• SO(i)



Serial scan-out vectors are associated with the stream statementof the protocol. The SO tag includes a number in parentheses (i)that has a value equal to the longest scan chain.

• VEC

Applies to any parallel vector that appears in the foreach_patternsection of the protocol but is not a parallel measure, capture, orfirst scan-out vector. The trace_nets output for default protocolsdoes not contain vectors of this type.

Vector Values in trace_nets Results Tables

Vector values appear in each row of a trace_nets results table. Thelegend at the beginning of the table briefly defines the vector values.The vector values are

0

Logic 0.

1

Logic 1.

z

High impedance value.

u

Uninitialized describes a net that was never assigned a value.

Si

Scanned-in value is the scan-in value propagated from a scan-inport.



Is

Initial state is the symbolic state of a sequential element beforethe start of scan operation.

Rd

Response data is the symbolic state of a sequential elementimmediately after the capture operation.

x

Unknown value.

So

Scanned-out value is response data observable through a scan-out port.

Na

Net value not available (vector not simulated) appears for all netsin vectors that are not simulated.

trace_nets Command

Net tracing occurs during the symbolic simulation of the test protocolassociated with the design. To enable net tracing for some nets inyour design, use the trace_nets command. When the check_testcommand simulates the test protocol, the check_test commanddisplays the values of the nets you indicate and records the discretetimes when their values change. The command syntax is

trace_nets { hierarchical_net_list }



{hierarchical_net_list}

Identifies a list of hierarchical net names that you want to trace.Use a comma or space to separate net names.

You can use asterisks (*) as wildcards within a net name in thehierarchical net list. If an asterisk is encountered within the list, allnets containing the specified partial net name are traced. Forexample, to trace all the nets in a given level of hierarchy, specifylevel_of_hierarchy*. To trace all nets containing the name fragmentfoo, specify *foo*.

Note:Use wildcards carefully. For example, the following commandorders the check_test command to trace every net in the currentlevel of hierarchy, which creates a difficult debugging situation.

dc_shell> trace_nets{*}

When you run the check_test command, it displays trace_nets resultson the nets you selected. See “Tracing Nets” earlier in this chapterfor an explanation of trace_nets results. The trace_nets commandhas no effect on how check_test infers test protocols. It does not affecthow protocols are simulated; it simply provides selective informationabout the state of the simulation.

Figure 6-25 shows the scan input nets for a multiplexed flip-flopdesign.



Figure 6-25 Scan Input Nets on a Multiplexed Flip-Flop

To trace the values on nets CLK, DATA, OUT1, and TEST_SE duringscan shift, execute the trace_nets command shown in Example 6-10.Example 6-11 shows the trace_nets results generated by thiscommand (appears in check_test output).

Example 6-10 trace_nets Command for Scan Shift Debugdc_shell> trace_nets (CLK, data, out1, test_se)

Example 6-11 trace_nets ResultsSTARTING PRINT OF TRACE INFO FOR: Nets Traced From The Command Line: CLK data out1 test_seNets Traced In the Protocol File: test_se test_siNets Traced In the Protocol File that are not in the Design: fish_net jumbolaya C d o t t L a u e e

test_si

OUT1

OUT2

DATA

OUT1

OUT2

CDN

TEST_SETEST_SI

CLK

IN1FD26

FD26



K t t s s . a 1 t t . . . _ _ . . . s s . . . e i =======+==+==+==+==+=== IV 1 ----------------------- 0.0 0 u u u u IV 2 ----------------------- 0 u u u u SI(1)----------------------- 5.0 0 u Is 1 Si 45.0 1 u Si 1 Si 55.0 0 u Si 1 Si PMV ----------------------- 5.0 0 u Si x x CAP ----------------------- Na Na Na Na Na 1SO ----------------------- 5.0 0 u Si 1 x SO(1)----------------------- 45.0 1 u x 1 x 55.0 0 u x 1 x =======================

The untrace_nets Command

To disable tracing on nets previously selected with the trace_netscommand, use the untrace_nets command. The command syntax is

untrace_nets {hierarchical_net_list} | -all

Use the hierarchical_net_list to identify the hierarchical nets that youwant to untrace. Use commas or spaces to separate net names. Useasterisks for a wildcard net search, as described in the previoussection, “trace_nets Command.”



Use the -all option to disable net tracing on all nets in the currentdesign that have net tracing enabled by the trace_nets command.

Note:The untrace_nets command has no affect on net tracing enabledby a trace_nets statement in an existing test protocol.

If you specify a net that does not have net tracing previously enabled,the check_test command issues the following message:

(error) Global tracing not enabled for net ‘%s’ in design‘%s’. (UIT-30)

This message is not issued if at least one of the nets within a groupof nets identified with a wildcard (*) has net tracing enabled.

If you invoke untrace_nets when no nets have been marked for tracingusing the trace_nets command, the following error message appears:

(error) No nets have global tracing enabled in design‘%s’. (UIT-29)

The report_test -trace

Use the report_test -trace command to list the nets in a design thatwere identified for tracing with the trace_nets command. Thecommand syntax is

report_test -trace

This command generates a report similar to the one shown inExample 6-12.



Example 6-12 report_test -trace Results****************************************Report : testDesign : UPC6Version: 1998.02Date : Tues Apr 21 12:12:19 1998****************************************GLOBALLY traced nets--------------------OUTPUT_2_NETOUTPUT_3_NETOUTPUT_4_NETOUTPUT_5_NETOUTPUT_6_NETOUTPUT_7_NETtest_setest_si


Documents

Checking Test Design Rules 6 - Semantic Scholar › f001 › 499f53fff349ab274bbb1961… · violations on scan-replaced cells cause insert_scan to unscan scan elements as explained