STIL ScanStructures - Application in ATE Domains

ST

ILSTIL ScanStructures - Application in ATE Domains

...and Concerns…

Greg Maston

Synopsys

© 2002 Synopsys, Inc. (2)

Purpose

• STIL ScanStructure information is being applied at Test, with mixed reviews

• This presentation identifies:

the concerns

what does work

what is required to allow it to work

… and when it doesn’t work…


Intent of STIL ScanStructures

• To maintain information about the internal scan constructs of a design

• To support accelerated-simulation contexts by bypassing serial scan loading


Caveat

As stated in the STIL spec, the ScanStructures data was never intended to go to test. Last sentence of the first paragraph of clause 20:

• The ScanStructures are not required for translation of STIL to a tester’s format, since the scan data is in tester ready format.


Reason to take this data to Test

• Provide for at-tester identification of the scancell that captured the failing situation

• Identify scan-based failures by more than “vector offset” information


Mapping Output Failures to ScanCells

• Assumes a direct (or identifiable) relationship of scan-out-measures by Vector, to scan cell order

V# 206, so=0

V# 205, so=0

// start Shift

V# 207, so=0

V# 208, so=1

V# 209, so=0

main.seg1.regb_15

main.seg1.regb_16

ScanCells

main.seg1.regb_14

main.seg1.regb_13

main.seg1.regb_12

ScanChain “A”

Scan cellslisted in reverseorder...


STIL Requirements to support this application

• The EFFECTIVE SCAN START of the scan operation must be definitively known

• The EFFECTIVE SCAN CHAIN related to this failure must be identified

• The EFFECTIVE STATE of the cell at the failure may be desired


Effective Scan Start

• The scan operation is commonly the application of the Vectors inside a STIL Shift block

• But scan shifts may occur before or after the Shift block as well, as single or multiple Vectors (in-line expansion of the scan operation or partial flattening of scan data).


Effective Scan Chain

Either:

• The failing output signal is uniquely identified in the scan chain definitions of the design

Or:

• The ScanChain statement must be present in the pattern sequence before a scan operation starts, to identify which chain(s) are in effect for the next scan operation.


Effective Scan State

• If the "actual state of the scancell" is desired, then it is critical that the scan inversion data be properly and completely represented in the ScanCell block in order to derive the proper state.


Mapping Scenarios

• Scenario 1

Clearly delineated scan application

Unambiguous scan chain reference

• Scenario 2

Reverse the order of the clock and output-strobe timing

• Scenario 3

Hidden scan


Scenario 1

Procedures { load_unload { WFT “TP”; Shift { V { se=1; ck=P; so=#...

Waveforms { “_ins” { 10 {‘0ns’ U/D; }} “_outs” { HLX { ‘20ns’ h/l/x; }} “_clks” { P { ‘30ns’ U; ‘45ns’ D;}}

Pattern { load_unload (so=HHHL...

ScanStructures { ScanChain “A” { ScanOut so; ScanCells ...


Scenario 1





1. Identify scan


Scenario 1





1. Identify scan2. Identify Start


Scenario 1





1. Identify scan2. Identify Start3. Identify Chain


Scenario 1





1. Identify scan2. Identify Start3. Identify Chain4. Map Failure to cell

V# 206, so=1/0

V# 205

// start Shift


Scenario 2


Waveforms { “_ins” { 10 {‘0ns’ U/D; }} “_clks” { P { ‘20ns’ U; ‘35ns’ D;}}“_outs” { HLX { ‘40ns’ h/l/x; }}



Only change: flip the order of eventson the clock and output measures


Scenario 2

Procedures { load_unload { WFT “TP”; V { so=#; } Shift { V { se=1; ck=P; so=#...




Consequential change: add a Vectorto capture first scan output


Scenario 2





1. Identify scan


Scenario 2





1. Identify scan2. Identify Start

Note the scan “starts” in the cycle before the Shift


Scenario 3: Hidden Scan

Procedures { load_unload { WFT “TP”; V { so=#; } V { so=#; } V { so=#; } V { so=#; }...

1. Got Milk ?


Scenario 3: Hidden Scan

Procedures { load_unload { WFT “TP”; V { so=#; } V { so=#; } V { so=#; } V { so=#; }...

1. Identify scan ?


STIL Requirements to support this application

• Convention to identify start of scan operation

• ScanStructure ScanChain definitions uniform to this convention

• ScanStructure ScanChain definitions logically correct (to interpret state)

• Use of the ScanChain statement in the patterns if ambiguous scan references from scan-out Signals


Possible Conventions

• Use STIL Shift statement to identify scan

• Pass all scan data on a single argument and define complete scanchains

• Pass data internal to the Shift in an argument; scan operations external to the Shift are not seen as “scan” and scanchain descriptions contain only the chain-internal-to-the-Shift


More Caveats for this application

• ScanStructures are an optional construct

Limited contexts that require this data

Some contexts will not define this data

• ScanStructures define a large amount of data

over half of a STIL test when present, for scancell names only


Caveats on the ScanChain ref stmt

• ScanChain ref statement supports single chain name only

• Scope of application is identified as “next set of statements”...

Procedures { load_unload { WFT “TP”; ScanChain “A”; ScanChain “B”; Shift { V { m=0; se=1; ck=P; so1=#…}} ScanChain “C”; ScanChain “D”; Shift { V { m=1; se=1; ck=P; so3=#…}}

Ambiguity between accumulation and reset behaviors


Final Caveat

• This functionality is not diagnosis

• The identified scancell (most probably) didn’t fail

• It captured a failure

• Identifying the failing element requires additional diagnostic operation


Conclusion

• STIL ScanStructures can be used at test

Provides additional fail information

Does not trace to causative fail

• Additional requirements on this data:

Uniform definition with application

Identifying constructs if shared-IO

• Conventions (usage model) required to interpret this data

Documents

STIL ScanStructures - Application in ATE Domains