p1450 1-D14

P1450.
1 Working-Draft 14, Aug 1, 2002
P1450.1
IEEE Standard Test Interface Language (STIL) for
Digital Test Vector Data Design Extension
Prepared by the STIL Working Group of the Test Technology Standards Committee
Copyright 2001 by the Institute of Electrical and Electronics Engineers, Inc.
Three Park Avenue
New York, New York 10016-5997, USA
All rights reserved.
This document is an unapproved draft of a proposed IEEE-SA Standard - USE AT YOUR OWN RISK. As such, this
document is subject to change. Permission is hereby granted for IEEE Standards Committee participants to reproduce
this document for purposes of IEEE standardization activities only. Prior to submitting this document to another standard development organization for standardization activities, permission must first be obtained from the Manager,
Standards Licensing and Contracts, IEEE Standards Activities Department. Other entities seeking permission to
reproduce portions of this document must obtain the appropriate license from the Manager, Standards Licensing and
Contracts, IEEE Standards Activities Department. The IEEE is the sole entity that may authorize the use of IEEE
owned trademarks, certification marks, or other designations that may indicate compliance with the materials contained herein.
IEEE Standards Activities Department
Standards Licensing and Contracts
445 Hoes Lane, P.O. Box 1331
Piscataway, NJ 08855-1331, USA
Table 1History
Date
By
Comments
04/01/2002
D14
tony taylor
See "D14 Review Resolution Document" for summary of the changes.
01/03/2002
D13
tony taylor
See "D12 Review Resolution Document" for summary of the changes. This
draft was finalized on March 21, 2002.
10/11/01
D12
greg maston
Changed draft version ident to integer 12 to reflect WG circulations. Added

()+ around cell-ref hierarchical names in clause 6.3 as well as elaborations
on supported constructs for [ ] here. Added SyncStart, Independent, and
LockStep to Patburst ParallelPatSet and back into annex example. Added
ScanEnable to ScanStructures. Removed annex C and changed reader to
consumer in annex N. Un-musted the normative clause of the document
(removed all "must", changed generally to "shall"). Added Figure names to
diagrams missing; ran spellcheck. Added new annex C that uses ScanEnable to show an example of a logic expression using signals.
Copyright 2001 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
Table 1History
Date
By
Comments
8/21/01
to 10/10/01;
0.98; D11
tony taylor
greg maston
Made changes as agreed to at 8/16 phone call.

Annex M.3 changes, added new clause 6 to elaborate on expression extensions to dot0 and to partition expression clauses formerly 5.4 and on into
their own clause. Added enum elaboration. Changed copyright notice per
IEEE. Added MergedScan to functions and Else statement. Added a sentence to clause 14 (ScanStructs) to indicate that one scan cell uses one scan
bit of data. Removed LockStep and references to CTL from Annex F, and
references to CTL except under the Environment block (lockstep is not currently defined and CTL is a dangerous reference in this spec, if the CTL
spec references this one...). Added Annex O on MergedScan from Doug
Sprague. Replaced occurrences of INTEGER with integer_expr in statements and added Scanstruct statements with integer_expr for Rohit.
8/15/01;
0.97; D10
tony taylor
Added Annex L.3 - complex scan cells and multibit scan cells defined using
hierarchical scan (by Greg Maston). Removed clause defining "engr_expr"
as it is now considered another form of "real_expr". Added UserKeywords,
UserFunctions and UserParameters to the STIL header block. Added file
type and file format keyword definitions. Added rules for formatting of integer values, and for truncation. Added Peters new definition of comparesubstitute events (s and S) to Signals, SignalGroups, Timing, Annex I.
7/25/01; 0.96;
D09
tony taylor
Made changes as agreed to at 7/19 phone call. Reworked some syntax definitions.
7/12/01; 0.95;
D08
tony taylor
Made changes as agreed to at 7/5 phone call.. Made adjustments to the SignalGroup->Variable definitions.
6/23/01;
0.94; D07
greg maston
tony taylor
Added inherit-constructs ref to state-element and changed pat_expr to

logical_expr in ScanStructures. Added integer_list definition and usage.
Reversed order of history table. Made formatting changes. Changed Variable type name from WFC to SignalVariable. Added new examples in the
annex.Added definition in clause 5 for: boolean_expr, sigvar_expr,
integer_expr, integer_list, real_expr, engr_expr. Added two more examples to the annex -
4/27/01; draft
0.93(b) 2001;
D06
greg maston
Added BistStructures. Removed TestResult() per minutes of ITC 2K

meeting. Added 16.3, NameMaps example, by request from reviewer.
Added AllNames construct to NameMaps per reviewer request. Pushed the
ScanStructures syntax around quite a bit (cleaned up), and moved it up in
logical clause order (before Pattern Data). Added InheritScanStructures
per reviewer. Completed cellref_expr definition (clause 5.7) Added definition of STIL0 to point to 1450, and added variable "STIL0" to substitute for
the full reference -review the changes to the titles of the Clauses here.
Added optional labels in front of the Pattern statements clause 14.1. Added
Loop Data construct. Cleaned up references to "conditional expression", to
reference "boolean expression" as appropriate. Pushed around and retitled
clause 11.5, describing variable usage, to logical expressions, clause 5.5.
Added 13.1, Cyclized Data, to define the use of logical expressions inside
pattern statements.

Table 1History
Date
By
Comments
3/1/01;draft
0.93(a) 2001;
D05
greg maston
Changed titles of tables 1,2,4-6 to include "Additions to", to indicate these

are incremental definitions to dot0 data. Changed WFCMap attributes to be
single-instance to be consistent with other attributes. Added statement on
the scope of constants in the Signals block. Removed PatternBurst refs in
BistStruct description in Table 5. Changed NonATEOnly to SimulationOnly
in SignalGroups clause. Added clause 5.3 to define support for constants (I
think I was supposed to do this before and forgot). Added clause 15, "extensions to procedure and macro data substitution". Deleted some redundant
clauses that repeated syntax definitions only (with no additional definitions), one in PatternBurst and two in Pattern statements. Added some
explanatory text to the Pattern statement definitions in clause 13.1.
Removed all occurrences of Eval in the examples, and replaced as necessary
with the C statement. Ran spellchecker for gross errors.
2/2/01...2/28/
01; draft 0.92
2001; D04
greg maston
Removed ScanStructures block from Environment NameMaps and replaced

it with ScanCells block. Moved the Variables and Enum blocks into the SignalGroups and defined "Constant". Added a Constant declaration to the
Signals, too. Added BistStructures block references in clause 5 and 6, in
prep for Peters additions. Removed Enumeration and Variable block references in the PatBurst clause, and added consideration for the If and While
as an attribute construct rather than a keyword statement in the PatBurst.
1/29/01; D03
greg maston
Changed WaveformChar to WaveformCharacter throughout doc (note:

these changes not change-barred to avoid confusion). Moved definition of
Variables and Enums from PatternBurst to their own new global clauses.
Moved WFCMap declaration from PatternBurst to Signals and SignalGroups (added new clauses to support these changes). Added table 3 and
clause 5.4 to delineate Variables, Enumerations and Environment effects.
Added clause 7 and tables 5 and 6 to delineate impact of Variables, Enumerations, and Environment placement in STIL files. Did a pass at spellchecker,
too.
8/6/00..1/10/
01; D02
tony taylor, greg

maston, peter
wohl
Changes to bring in line with CTL. Re-structured document as agreed at the

August working group meeting. Enhanced the Pattern Variable syntax.
Added pat_expr clause. Defined TestResult function. Added Scope and Purpose from the PAR. Incorporated the changes from Doug Sprague on Fail
Feedback. Changes to WFCMap. Format changes for IEEE, Added clause
for new reserved words and reserved characters. Started to change pat_expr
to logical_expr, moved definition of logical variables clause earlier and
added elaboration. Added name_map option to NameMaps in Environment
per CTL discussion. Changed tables to incremental forms. Changed
NameMapInherit to InheritNameMap (match all Inherit keywords), added
wfc_expr and explanation of cellref_expr in clause 5. Corrected Annex lettering. Added new AnnexA for local definitions and worked over clause 3.
6/25/00; D01
tony taylor
Original document created from the collected syntax definitions from prior
P1450.1 working groups.

1.
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.
Definitions, acronyms, and abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1 Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Acronyms and abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.
Structure of this standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.
STIL Syntax Description - Extensions to STIL0 Clause 6 . . . . . . . . . . . . . . . 9

5.1 Additional reserved words . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2 Additional reserved characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3 Extensions to STIL0 clause 6.10 - Signal and group name characteristics . . . . . . . . . .10
5.4 Additions to STIL0 clause 6.16 - STIL name spaces and name resolution . . . . . . . . . .10
6.
Expression Constructs - Extensions to STIL0 Clause 6 . . . . . . . . . . . . . . . .11

6.1 SignalVariables, enumerations and constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
6.2 Boolean Expressions (boolean_expr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
6.3 Cellname List (cellname_list) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
6.4 Integer Expressions (integer_expr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.5 Integer Lists (integer_list) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.6 Logical Expressions (logical_expr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.7 Real Expressions (real_expr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.8 SignalVariable Expression (sigvar_expr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.9 Expressions and Operator Precedence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.
Statement structure and organization of STIL information . . . . . . . . . . . . . . 19

7.1 Top-level statements and required ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.2 Optional top-level statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.
STIL statement - Extensions to STIL0 clause 8 . . . . . . . . . . . . . . . . . . . . . . 20

8.1 STIL syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.2 STIL example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.
UserKeywords statement - Extensions to STIL0 clause 11 . . . . . . . . . . . . . 21

9.1 UserKeywords syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.2 UserKeywords example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.
Variables Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1 Variables Block Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.2 Variables Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.
Signals Block - Extensions to STIL0 clause 14. . . . . . . . . . . . . . . . . . . . . . . 23

11.1 Signals block syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.2 Signals example (using WFCMap additions). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.3 Application of WFCMap constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.
SignalGroups Block - Extensions to STIL0 clause 15. . . . . . . . . . . . . . . . . . 25

12.1 SignalGroups syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.2 SignalGroups WFCMap and Variables example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
12.3 Default WFCMap attribute value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
13.
PatternBurst Block - Extensions to STIL0 Clause 17 . . . . . . . . . . . . . . . . . . 28

13.1 PatternBurst Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4


13.2 PatternBurst example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.3 LockStep Explanation and Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.4 Pattern Tiling and Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.5 If and while statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14.
30
31
33
34
Timing Block and WaveformTable Block - Extensions to STIL0 clause 18. . 34

14.1 Additional waveform event definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
14.2 CompareSubstitute Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
15.
ScanStructures block - Extensions to STIL0 clause 20 . . . . . . . . . . . . . . . . 35

15.1 ScanStructures Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
15.2 Example indexed list of scan cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
15.3 Example of Hierarchical ScanStructures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
16.
Pattern Data - Extensions to STIL0 clause 21 . . . . . . . . . . . . . . . . . . . . . . . 39

16.1 Cyclized Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
16.2 Vector data mapping and joining - \m and \j . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
16.3 Specifying Event Data in a Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
17.
Pattern Statements - Extensions to STIL0 clause 22 . . . . . . . . . . . . . . . . . . 41

17.1 Additional Pattern Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17.2 Pattern Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17.3 Vector data constraints - Fixed and Equivalent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17.4 X (cross reference) statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17.5 X Statement Syntax examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17.6 Loop Data and Shift statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17.7 Loop Statement Using an Integer Expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
43
43
44
46
47
48
18.
Procedure and macro data substitution - Extensions to STIL0 clause 24.5. 49
19.
Environment block. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
19.1 Environment Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.2 "MAP_STRING" Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.3 Environment Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.4 NameMaps Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
52
52
53
20.
BistStructures block (to be removed from the document?) . . . . . . . . . . . . . . 54
AnnexA Glossary (informative) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
AnnexB Signal Mapping Using SignalVariables (informative). . . . . . . . . . . . . . . . 63
AnnexC Using Logic Expressions with Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
AnnexD Using Boolean Expressions (boolean_expr) (informative). . . . . . . . . . . . 68
AnnexE Using Variables and Expressions in Algorithmic Patterns (informative) . 70
AnnexF Chaining Scan Chains with STIL (informative) . . . . . . . . . . . . . . . . . . . . 72
AnnexG Vector data mapping using \m (informative) . . . . . . . . . . . . . . . . . . . . . . 75
AnnexH Vector data joining using \j (informative) . . . . . . . . . . . . . . . . . . . . . . . . . 78
AnnexI Block Data Collection (informative). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
AnnexJ Signal constraints using Fixed and Equivalent statements (informative). 84
AnnexK Independent Parallel Patterns (informative) . . . . . . . . . . . . . . . . . . . . . . 86
AnnexL ScanStructures using complex scan cells (informative) . . . . . . . . . . . . . 87
AnnexM Fail data feedback from ATE using STIL (informative) . . . . . . . . . . . . . . 92
AnnexN BreakPoints using MergedScan() function (informative) . . . . . . . . . . . . . 99
5

P1450.1
IEEE Standard Test Interface Language (STIL) for
Digital Test Vector Data Design Extension
1.
Overview
STIL is an evolving standard being developed in support of various needs for interfacing between test generation
tools and test equipment. The IEEE Std. 1450-1999 (STIL.0) forms the basis for this evolution. New "dot" standards,
like this one, are being developed to address specific needs beyond STIL.0.
This (STIL.1) standard addresses "Design" related aspects of digital test data. This standard can also be viewed as the
addition of advanced features to the STIL.0 base-line to allow for the usage of STIL in more complex applications,
while leaving the basic standard unchanged as a vehicle for transmitting basic test data. The following is a brief overview of the new features in STIL.1 to support advanced applications such as: a) embedded cores, b) families of test
patterns, c) mapping to ATE systems, d) mapping to simulation e) devices with advanced DFT.
Environment Mapping - Data for a device exists in many forms and in many other software environments. Examples are: a) simulation environment, b) static analysis environment, c) specific ATE system environment. The STIL
"Environment" block is a new mechanism to relate STIL data to these other environments. No assumptions, expectations, or limitations are imposed on the other environments. This is just a way of relating one to the other.
Parameterized Data - Much of STIL data is declarative in nature (i.e., it defines various static attributes of a device
or pattern set). The addition of "Constant" declarations allows a data set to be created that applies to a family of
devices.
Complex Test Protocol Definition - Test protocol definitions are usually contained in STIL "Procedures" or "MacroDefs" and are used to specify the application of a series of data values to a device. STIL.0 supports scan chain data
passing and simple WFC data passing via the "#" and "%" characters. STIL.1 enhances this capability by allowing the
use of data substitution from signal-variables, integer-expressions in loops and vectors, "If"/"While" decisions on pattern statements. These capabilities are needed for BIST, embedded cores, and various test access mechanisms.
Advanced Scan Architecture - Advanced DFT techniques require additional capabilities beyond what is defined in
STIL.0. This includes multi-state scan cells, hierarchical scan-chain definitions, re-configurable scan-chains, and
scan-chain indexing.
Run Time Pattern Decisions - The "If", "While", "Loop Data" are new STIL.1 constructs that have been added for
specification of pattern activity. These statements are needed in the specification of patterns to be run in the simulation environment. Although there is no standardization amongst ATE systems on run time instructions for pattern execution, it is anticipated that restricted versions of these statements will be incorporated into ATE test patterns.
Pattern Burst Options - New variations on the "PatternBurst" have been added to allow for pattern running in parallel, patterns running in "LockStep", and patterns that can be re-ordered. For parallel pattern execution, the specification for how the patterns fit together can be specified by using the "Fixed", "Extend", and "Wait" statements.
Enhanced User Extensibility - The "UserKeyword" extensibility defined in STIL.0 has been extended to allow keywords to be defined on a per-block-type basis.
Signal Relationships - Additional syntax is provided to allow the specification of relationships between signals. This
is done via "\m" to map WFCs to another WFC, \j to join WFCs, "Extend" to define behavior of signals beyond the
bounds of a given pattern, and "Fixed" to restrict any further changes to signals within a pattern.
BIST Structure Definitions - A new "BISTStructures" block is added in STIL.1 to define the content and connection
of a BIST block into a design. As with "ScanStructures" the primary purpose of the construct is to allow for fast, efficient simulation of patterns with BIST controllers.
Fail Feedback - Two new features are added to facilitate the processing of failure data from an ATE system back to
design tools. The first is the "X" or cross-reference statement that allows the specification of where in a pattern/vector
sequence a failure occurs. The second is the "S"/"s" timing event that allows for the specification of a data capture
6


protocol for the purpose of capturing bulk fail data for processing.
1.1
Scope
Define structures in STIL to support usage as semiconductor simulation stimulus; including: 1) mapping signal
names to equivalent design references, 2) interface between Scan and BIST, and the logic simulation, 3) data types to
represent unresolved states in a pattern, 4) parallel or asynchronous pattern execution on different design blocks, and
5) expression-based conditional execution of pattern constructs.
Define structures in STIL to support the definition of test patterns for sub-blocks of a design (i.e., embedded cores)
such that these tests can be incorporated into a complete higher-level device test.
Define structures in STIL to relate fail information from device testing environments back to original stimulus and
design data elements.
1.2
Purpose
Enhance the STIL language definition to support the usage of STIL in the design environment. This includes extending the execution concept to support STIL as a stimulus language, to allow STIL to be used as an intermediate form
of data, and to allow STIL to capture design information needed to port simulation data to device test environments.
In addition, define extensions to support the definition of sub element tests, and to define the mechanisms to integrate
those tests into a complete device test. This effort is to be done in conjunction with IEEE P1500 which is defining
standards for the definition and integration of embedded cores.
Finally, define the constructs necessary to correlate test failure information back to the design environment, to allow
debug and diagnosis operations to be performed based on failure information in STIL format.
2.
References
This standard shall be used in conjunction with the following standards. When the following standards are superseded
by an approved version, the revision shall apply. These references are automatically updated during the editing process.
IEEE Std. 100-1996, The IEEE Standard Dictionary of Electrical and Electronics Terms, Sixth Edition.
IEEE Std. 1450-1999, IEEE Standard Test Interface Language (STIL) for Digital Test Vectors.
IEEE Std. P1500, IEEE Standard for Embedded Core Test (under development as of 25 September 2000).
IEEE Std. 1364-1995, IEEE Standard Hardware Description Language Based on the Verilog(R) Hardware Description Language.
3.
Definitions, acronyms, and abbreviations
3.1
Definitions
For the purposes of this standard, the following terms and definitions apply. Additional terminology specific to this
standard is found in Annex A. IEEE Std 100-1996, The IEEE Standard Dictionary of Electrical and Electronics
Terms, Sixth Edition, should be referenced for terms not defined in this document.
Core
A component or module that contains separately-developed functionality, integrated into a chip to provide
additional overall functionality (see System on Chip).
STIL0 Refers to IEEE Std. 1450-1999. This base STIL standard is commonly referred to as "dot 0" to differentiate
it from all the STIL extensions (such as this standard).
System on Chip (SoC)An Integrated Circuit containing modules that represent separately-developed functionality.

3.2
Acronyms and abbreviations
ATE
Automated Test Equipment
BIST
Built-In Self Test
CA
Cellular Automata
LFSR
Linear Feedback Shift Register
MISR Multiple Input Shift Register

PRPG Pseudo Random Pattern Generation
SoC
System on Chip
STIL
Standard Test Interface Language
STUMPS Self-Test Using a Misr and a Parallel Shift-register

WFC
WaveformCharacter
4.
Structure of this standard
This document is an adjunct to IEEE Std. 1450-1999. The conventions established and defined in IEEE Std. 14501999 are used in this document and are included verbatim below.
Many clauses in this document add additional constructs to existing clauses in the IEEE Std. 1450-1999 document
and are so identified in the title. The Environment and BistStructures blocks are new constructs introduced in this
document. All clauses in this document are normative. Example code is provided within each clause. More complete
examples are provided in the Annexes which are informative.
The following is a copy of the conventions as defined in IEEE Std. 1450-1999 and followed by this document.
Different fonts are used as follows:
a) SMALL CAP TEXT is used to indicate user data;
b) courier text is used to indicate code examples.
In the syntax definitions:
a) SMALL CAP TEXT is used to indicate user data;
b) bold text is used to indicate keywords;
c) italic text is used to reference metatypes;
d) () indicates optional syntax which may be used 0 or 1 time;
e) ()+ indicates syntax which may be used 1 or more times;
f) ()* indicates optional syntax which may be used 0 or more times;
g) <> indicates multiple choice arguments or syntax.
In the syntax explanations, the verb shall is used to indicate mandatory requirements. The meaning of a mandatory
requirement varies for different readers of the standard:
To developers of tools that process STIL (readers), shall denotes a requirement that the standard imposes. The
resulting implementation is required to enforce this requirement and issue an error if the requirement is not met
by the input.
To developers of STIL files (writers), shall denotes mandatory characteristics of the language. The resulting output must conform to these characteristics.
To the users of STIL, shall denotes mandatory characteristics of the language. Users may depend on these characteristics for interpretation of the STIL source.
The language definition clauses contain statements that use the phrase "it is an error", and "it may be ambiguous".
These phrases indicate improperly-defined STIL information. The interpretation of these phrases will differ for the
8


different readers of this standard in the same way that shall differs, as identified in the dashed list above (Clause 4).
5.
STIL Syntax Description - Extensions to STIL0 Clause 6
All constructs and restrictions for IEEE Std. 1450-1999 Clause 6 are in effect here, with the following additions:
Additional STIL reserved words specific within the context of this standard.
Additional STIL reserved characters specific within the context of this standard.
Extensions to the expression environment are defined in clause 6 of this standard. Three new types of variables
SignalVariables, enumerations, and constants are defined, and extensions to real expressions and Spec variables
are also defined. New types of expressions boolean_expr, cellname_list, integer_expr, logical_expr, real_expr,
sigvar_expr, and integer_list are also defined.
5.1
Additional reserved words
Table 1 lists all STIL reserved words defined by this standard and not defined in IEEE Std. 1450-1999. Subsequent
clauses in this standard identify the use and context of each of these additional reserved words.
Table 1Additions to STIL Reserved Words

CellIn, CellOut, Constant
Data, Design
E, Else, Enumeration, Enumerations, Environment, Equivalent, Extend
Fixed, FileFormat, FileReference, FileType, FileVersion
If, Independent, ScanModule, InitialValue, Instance, Iteration, InheritEnvironment, InheritNameMap,
Integer
Lockstep
NameMaps
Offset
ParallelPatList, PatSet
Real
ScanEnable, SignalVariable, SyncStart
Type
Usage
Values, Variables
Wait, WFCMap, While
5.2
Additional reserved characters
Several reserved characters identified in IEEE Std. 1450-1999 are applied in additional contexts for this standard.
Table 2 lists additional STIL reserved characters defined in this standard as well as additional contexts of previously


identified reserved characters Boldface text identifies extended applications defined in this standard.
Table 2Additions to STIL Reserved Characters

Char
5.3
Usage
exclamation (NOT sign) is used as inversion operator in logical expressions
per-cent sign is used as the modulus in logical expressions.
()
parenthesis reserved in timing, logical and signal expressions
multiply in timing and logical expressions
add in timing logical and signal expressions
subtract in timing logical and signal expressions
&
and operator used in logical expressions
or operator used in logical expressions
xor operator used in logical expressions
bit-wise negation operator used in logical expressions
<
less than in timing and logical expressions
>
greater than in timing and logical expressions
<=
less than or equal to in timing and logical expressions
>=
greater than or equal to in timing and logical expressions
==
equal to in timing and logical expressions
!=
not equal to in timing and logical expressions
?:
conditional selection in timing and logical expressions
assignment in: timing expressions, logical expressions, vector expressions, groupname expressions, spec category expressions, and spec variable expressions (6 contexts)
min, max
functions may appear in timing and logical expressions
Extensions to STIL0 clause 6.10 - Signal and group name characteristics
All constructs and definitions in IEEE Std. 1450-1999 clause 6.10 are in effect. In addition, signals expressed using a
bracketed construct shall allow the use of previously declared constants where integer values are allowed. See
clause 6.1 for the definition of constants.
5.4
Additions to STIL0 clause 6.16 - STIL name spaces and name resolution
Environment and BistStructures blocks augment the STIL namespace as defined in table 3. This table is incremental
to IEEE Std. 1450-1999 table 6 STIL name spaces; all definitions present in that table remain unchanged.
Enumeration names, Variable names, and Constant names are used by logical expressions in the PatternBurst or Pattern blocks. This space also contains Signals, the current selected SignalGroups, and the current selected Spec variables defined for the context of that expression. Variable and Enumeration names shall be unique against all Signals,
referenced and unnamed SignalGroups, and Spec variable names defined for a PatternBurst or application of a Pattern
10


referenced by that PatternBurst.
Table 3Additions to STIL name spaces

STIL block
6.
Type of Name
Domain restrictions
Environment
Environment domain
names
Supports a single unnamed block and domain

name blocks. Domain names shall be unique
across all Environment blocks.
BistStructures
BistStructures domain
names and BistStructures names
A single BistStructures block is optionally named.

Multiple BistStructures blocks shall be uniquely
named. BistStructures names shall be unique
inside a BistStructures block.
Enumeration, Variable,
Constant Names
(logical_expr)
Signals, SignalGroups,
Spec variables, Enumeration, Variable, and
Constant names
Names are present in this space dependent on reference statements in the PatternExec (for Spec
variables) and the PatternBurst (for named SignalGroups blocks). Signal names are present unless
overridden by the same name from a named SignalGroups block as specified for SignalGroup resolution in IEEE Std. 1450-1999. Names in an
unnamed SignalGroups block are present unless
overridden by the same name in a named and referenced SignalGroup block. It is an error for defined
Enumeration, Variable, and Constant names to
conflict with Signals, SignalGroups, or Spec variable names accessible in the same context.
Expression Constructs - Extensions to STIL0 Clause 6
IEEE Std. 1450-1999 defines Timing Expressions using Spec Variables and expression constructs presented in clause
6.13, and Signal Expressions in clause 6.14. This standard extends these expression contexts with additional variable
types and corresponding expression constructs. clause 6.1 presents SignalVariables, Constants, and Enumeration
types, and clause 6.2 - clause 6.8 detail the additional expression constructs supported by these additional types.
6.1
SignalVariables, enumerations and constants
SignalVariables, enumerations, and constants are declared under the SignalGroups block as defined in clause 12. In
addition, constants may be declared in the Signals block as defined in clause 11. SignalVariables, enumerations and
constants are used in logical or WaveformCharacter expressions as explained in clause 6.6 and 6.8, and constants are
allowed in bracketed Signal or SignalGroup contexts as explained in clause 5.3. STIL user-defined naming constructs
defined in IEEE Std. 1450-1999 subclause 6.10 are supported for SignalVariable, enumeration, and constant names.
Logical expressions may contain references to signals, groups, and spec variables. Therefore the name space for Variables, Enumerations, and Constants includes the names in effect in these additional namespaces. SignalVariables,
enumerations, and constants follow the same name scoping constructs as SignalGroup names, that is: these names are
unique across items in this names, in referenced (named) SignalGroup blocks; names defined in an unnamed SignalGroup block are accessible without reference unless overridden by another definition of the same name in a named
and referenced SignalGroup block, and items with the same name as a Signal shall be used instead of that Signal.
SignalVariables, Enumerations, and Constants are typed when they are declared. This standard defines Integer, IntegerEnum, and Constant variable types that may be used in boolean expressions as presented in clause 6.2, and integer
expressions as presented in clause 6.4. SignalVariable and SignalVariableEnum types are defined in this standard and
are used to supply WaveformCharacter expressions in assignments to Signal or SignalGroups as presented in
clause 6.8. The context of Spec Variables is extended from the STIL0 definition of Timing expressions to support a
11


general engineering expression as defined in clause 6.6, and to support real expressions as defined in clause 6.7.
Enumeration variables are defined to support declaration of variables that contain representative values. There are two
types of enumeration variables defined here: IntegerEnum variables, which contain a representative value that is
optionally mapped to a specified integer value, and SignalVariableEnum variables, which contain a representative
value that is interpreted in a signal-assignment context as a WaveformCharacter list. Enumeration variables are supported with a very limited set of expression constructs. SignalVariableEnum and IntegerEnum variables shall contain
only values defined under the enumeration values defined for that enumeration, and only enumeration variables shall
contain enumeration values defined for that enumeration. SignalVariableEnum variables shall be assigned declared
enumeration values only, and shall be assigned to Signal references only. IntegerEnum variables shall be assigned
declared enumeration values only, and are allowed in conditional expressions and assignments, only when manipulated with enumeration values supported by that enumeration type. Boolean expressions with SignalVariableEnum
and IntegerEnum variables support equals (==) and not-equals (!=) operators. Greater-than (>) and less-than (<), and
the also-equals forms of these operations (<=, >=) are supported only for IntegerEnumerations with declared integer
values.
6.2
Boolean Expressions (boolean_expr)
A boolean expression (boolean_expr) is a logical expression that evaluates to a true or false. The result of a boolean
operation (using boolean operators defined in table 5) is 0 if the result is False, and 1 if the result is True. The result
of a bitwise operation (using bitwise operators defined in table 5) is the entire expression; that is, a bitwise expression
is maintained as defined and not otherwise evaluated.
Contexts that require boolean expression values interpret the value 0 and negative values as False and non-zero positive values as True. All other types (bitwise logical or WaveformCharacter list values) shall be an error if provided as
the result of a logical expression and a boolean context is required.
6.3
Cellname List (cellname_list)
A cellname_list as defined in IEEE Std. 1450-1999, subclause 20.1 is extended as follows:

1.
It is allowed reference to other scan chains as well as scan cells, thus providing hierarchical scan chain
definitions (see clause 15). The names of scan cells and scan modules are separate and distinct from all
other name spaces.
2.
The operators allowed in a cellname_list are the bracket construct [ .. ] to define a series of cellnames,
and the ! operator to to indicate inversion. Supported constructs within the brackets are defined in
clause 6.5.
The following is an example containing a cellname_list:

STIL 1.0 { Design 2001; }
Header {
Source "P1450.1 Working-Draft 14, Aug 1, 2002";
Ann {* clause 6.3 *}
}
ScanStructures s1 {
ScanChain chain1 {
ScanLength 100;
ScanCells c1a c1b c1c ! c1d c1e ! c1[6..100];
}
ScanChain chain2 {
ScanLength 105;
ScanCells c2a c2b c2c c2d c2e s1.chain1;
}
ScanStructures struct2 {
ScanChain chain3 {
12


ScanLength 110;
ScanCells s1.chain2 ! c3a c3b c3c c3d c3e;
}
}
Integer Expressions (integer_expr)
6.4
An integer_expr is logical expression that evaluates to integer. See the list of allowed operators in Table 4 on page 17.
The following rules of interpretation apply to integers:
a)
A bare integer may be declared either with or without single quotes.
b) The underscore character may be used as a separator within an integer declaration.

c)
The suffixes k, M, G, P, T, E may be used to indicate multiple of 1000.
d) If an integer operation results in a number with a fractional part, the fraction shall truncate to produce an
integer value.
Integer expressions may contain integers, operators as previously indicated, Integer variables, and Constants. The following are examples of integer expressions and their usage:
Header {
}
Signals { sigA In; sigB Out; sigC InOut; }
Variables {
i Integer;
k Constant = 2;
}
SignalGroups {
sigref = A+B+C;
} // end SignalGroups
Timing { WaveformTable {
Waveforms {
sigref {
01 { 2ns+k*(0.5ns) U/D; }
} // end sigref
} // end Waveforms
} // end Timing
Pattern P {
C { i =
C { i =
C { i =
C { i =
C { i =
C { i =
C { i =
C { i =
C { i =
C { i =
C { i =
If i >=
1234; }
48000000; }
48_000_000; }
48M; }
48M; }
i + 2; }
i = 13; }
i = i/2; }
i = i * 0.5; }
i + 1; }
\h7FF_FFFF; }
99 {}
//
//
//
//
//
//
//
equivalent to 48000000
where x is an integer variable
expression containing assignment
truncate (i.e., if 13/2 yields 6)
truncate (i.e., if 13*0.5 yields 6)
// hex representation of integer

13


Loop i {}
} // end Pattern
6.5
Integer Lists (integer_list)
An integer_list is used to specify an ordered list of integer values. Allowed operators in an integer list is the ellipsis
.. which specifies a range of integers. An integer_list may contain either a single integer, a space-separated list of
integers or integer ranges. Previously defined Constants may appear in place of integers. An integer range is represented by 2 integers (or Constants) separated by ... For example, 3..6 is equivalent to 3 4 5 6 and 4 .. 2 is equivalent to 4 3 2. Spaces are allowed between the integer or Constant, and the ".." operator. The following underlined
code are examples of integer lists:
Header {
}
Signal {
sig[1..5] In;
prpg_sig Pseudo;
}
BistStructures mybist {
BistRegister reg {
TapPositions 0 2 4 6 8 10 12;
Connection prpg_sig 0..25;
}
Pattern pat {
V { sig[5 4 3 2 1] = 11001; }
}
6.6
Logical Expressions (logical_expr)
Logical expressions are enclosed in single quotes. The operator set and expression constructs supported by logical
expressions is the same as defined for IEEE Std. 1450-1999, Subclause 6.13 (Timing Expressions), with additional
bitwise and boolean operators supported. All logical expression operators are defined in table 5.
Logical expressions may evaluate to integer, real number, exponential number, bitwise logical, or boolean values. The
result of the last operation executed in evaluating a logical expression is the result of a logical expression, for example
the result of assigning a value to a logical variable is the value of that assignment.
Logical expressions consist of:
References to Variables, Enums, and Constants defined under Signals or SignalGroups blocks that are currently
applied in PatternBurst contexts.
References to Signals, SignalGroups, or Spec Variables that are currently defined in the PatternBurst and PatternExec context.
Integers, real numbers, or exponential numbers.
Expressions as described in IEEE Std. 1450-1999 clause 6.13 but not including event labels nor time marks, and
supporting the set of operators defined in table 5.
Expressions formed by algebraic combination of any of these as allowed regarding the unit of the combinants
(e.g., the following is not valid: 1.5V + 2.5ns, whereas 1.5V/2.5ns is valid).
Variables are declared under Signal or SignalGroup blocks, as defined in clause 11 and clause 12. Consider the following example definitions:
14


Header {
}
Variables {
cmds IntegerEnum {
Values { Run; Stop; Load; Unload;}
}
a Integer;
b Integer;
c Integer;
e Enum cmds;
h Integer { Base Hex LH;}
w SignalVariable { Length 4; }
}
Spec {
Category cat {
r = 25ns;
}
}
PatternBurst A {
SignalGroups supporting_decls;
} // end PatternBurst
// The following are some examples of logical expressions:
Pattern pat {
C { a = 0; } // False (in a boolean context)
C { a = 1; } // True (in a boolean context)
C { a = 956; } // True (if present in a boolean context)
C { r = 0ns; } // a real number in engr units
C { a = 5; } // set variable a equal to 5 (if a is a logical variable)
If a == 5 {} // test for a equal to 5; returns 1 if True and 0 if False.
If a <= b {} // test for a less than or equal to b
If a < min (b,c) {} // use of the min function
C { e = Run; } // set using enum definition
C { h = F8; } // set hex variable to 1111 1000
C { w = LH01; } // set WFC variable to the string LH01
// Variables are optionally initialized when declared,
// and are manipulated in logical expressions,
// which appear in cyclized pattern statements as defined in clause 16.1.
// Logical expressions may be used in the following contexts:
// As a boolean expression in a Pattern or PatternBurst:
If e == Load { V {sig=1;}}
// In an evaluation statement in a Pattern or a PatternBurst:
C { a = a+1; }
// Within a Vector statement (see clause 6.8 for an explanation
15


// of WaveformCharacter expressions):
C { w = ABBA;}
V { siggrp = w;}
} // end Pattern
6.7
Real Expressions (real_expr)
A real expression is defined in a Spec table as defined in IEEE Std. 1450-1999. The term real_expr is used in the syntax definition to indicate where a real number is to be used. A real number can be expressed in one of two formats.
A real number can be of the form: <number>e<+\-><number>. A real number can be used to represent values that are
not standard SI units, for example a slew rate in volts/ns.
A real number can also be of the form <number><prefix><SI unit>. For example, 23ns is a time expression, 10uf
is a capacitance expression. This generic reference can be used whenever one of the standard unit definitions is
allowed.
The following are examples of real number expressions:
Header {
}
Spec {
Category cat {
time = 25ns;
wattage = 25mw;
slewrate = 1v/1ns;
realvar = 25e-9;
} // end Category
} // end Spec
Pattern pat {
C { time = 23.5ns + 1.5ns/2; } // time expression
C { wattage = 5v * 2ua; }
// where wattage is of type Watts
C { slewrate = 5v/1ns; }
// where slewrate is of type Real
C ( realvar = 5v; }
// where realvar is of type Real
C { realvar = 5ma; }
C { realvar = 5e-3; }
} // end Pattern
6.8
SignalVariable Expression (sigvar_expr)
SignalVariable expressions are enclosed in single quotes. Variables declared to be of type SignalVariable are assigned
WaveformCharacter list values, and signal references are assigned the value of Variables of type SignalVariable.
A WaveformCharacter list value results by direct assignment of a WaveformCharacter list, variable of type SignalVariable, or variable of type SignalVariableEnum in a sigvar_expr. It is an error to manipulate a WaveformCharacter list
with operators or functions.
The application of signal variables is to hold signal data and to pass signal data from pattern vectors, macro calls or
procedure calls to macros, procedures or other vectors.
Signal variables are always have global scope and always retain their value upon return from a procedure or macro.
The following are examples of signal variable usage:
16


Header {
}
Signals {
X[1..5] In;
}
Variables {
sig_var SignalVariable { Length 5; }
}
SignalGroups {
grp_x = X[1..5];
}
Pattern pat {
C { sig_var[1..5] = 11100; }
C { sig_var[5, 4, 2, 3, 1] = 00011; }
C { sig_var[5..1] = ABBAB; }
V { grp_x = sig_var[1..5]; }
}
6.9
Expressions and Operator Precedence
Table 4 describes the usage of each type of variable and expression and where each variable type is defined. This table
does not have a corresponding table in IEEE Std. 1450-1999.
Table 4Variable and Expression Usage

expr-type
variable types
where defined
where used
syntax examples
engr_expr
- time_expr
- voltage_expr
- etc.
time
integer
real
@label
Spec
SignalGroups
Spec
Timing
Timing
23.0ns/2+16.5e-9-t2
t1/i + r - t2
real_expr
time
integer
real
@label
Spec
SignalGroups
Spec
Timing
Pattern
Same as an engr_expr except

that it may be used in a non-engr
unit context. e.g. volts/ns.
integer_expr
integer
SignalGroups
Pattern
Timing
PatternCharacteristics ->
NumberVectors max * mode;
integer_list
integer
SignalGroups
BistStructures
SignalVariables
1,2,3,4,5
3, 6, 4, 5, 1, 2
1..5
sigref_expr
signals
signal groups
SignalGroups
on-the-fly
most blocks
SignalGroups { a=b+c; }
V { x+y = 11; }
17

Table 4Variable and Expression Usage

expr-type
variable types
where defined
where used
syntax examples
sigvar_expr
SignalVariable
SignalGroups
Pattern
V { grp = sv1; }
V { grp = sv2[1..5]; }
V { grp = sv3[5 4 2 3 1]; }
logical_expr
integer
time
real
SignalVariable
Signal
SignalGroup
SignalGroups
Spec
Spec
SignalGroups
SignalGroups
SignalGroups
Pattern
Loop x*25 { }
boolean_expr
integer
time
real
SignalVariable
Signal
SignalGroup
SignalGroups
Spec
Spec
SignalGroups
SignalGroups
SignalGroups
Pattern
ScanStructures
If i == 0 {}
If period > 23.0ns {}
If value < 3e-6 {}
If sv2[1..5] == 11000 {}
If (s1==H) | (s2==H) {}
If grp != HHHH {}
ScanEnable sig1==U;
Table 5 is expanded from Table 5 of IEEE Std. 1450-1999, to identify operator usage in additional expression types,
and to define the following operators not supported in IEEE Std. 1450-1999: % (modulus), ! (negation), && (boolean
and), || (boolean or), ~ (tilde, bit-wise negation), & (bit-wise and), | (bit-wise inclusive or), ^ (bit-wise exclusive or),
and ^~, ~^ (bit-wise equivalence). Logical behavior of these operators is the same as defined in IEEE Std. 1364.
Table 5 defines the allowed operators on each type of variable. The table is ordered by precedence. Operators within
the bold line are of equal precedence and are processed left to right. Operators in each bold line separated group have
higher precedence that the groups below them and shall be processed first.
Table 5Operators and functions allowed in expressions

Op
Definition
time
real
int logic bool

eger
al
ean
sig
var
sig
ref
cell
ref
min()
minimum value
YES
YES
YES
YES
NO
NO
NO
NO
max()
maximum value
YES
YES
YES
YES
NO
NO
NO
NO
MergedScan()
boolean function that returns true

to select BreakPoint or other
option during scan operation. See
clause 6.9.1.
NO
YES
YES
YES
YES
NO
NO
NO
()
parenthesis
YES
YES
YES
YES
YES
NO
NO
NO
table 3,
table 4 of
IEEE Std.
1450-1999
SI units & prefixes
YES
NO
NO
NO
YES
NO
NO
NO
divide
YES
YES
YES
YES
NO
NO
NO
NO
multiply
YES
YES
YES
YES
NO
NO
NO
NO
modulus
NO
NO
YES
YES
NO
NO
NO
NO
18

Table 5Operators and functions allowed in expressions

Op
Definition
time
real
int logic bool

eger
al
ean
sig
var
sig
ref
cell
ref
add
YES
YES
YES
YES
NO
NO
YES
YES
subtract
YES
YES
YES
YES
NO
NO
YES
NO
<
less than (boolean value)
YES
YES
YES
YES
YES
NO
NO
NO
>
greater than (boolean value)
YES
YES
YES
YES
YES
NO
NO
NO
<=
less or equal (boolean value)
YES
YES
YES
YES
YES
NO
NO
NO
>=
greater or equal (boolean value)
YES
YES
YES
YES
YES
NO
NO
NO
negation (boolean value)
NO
NO
YES
YES
YES
NO
NO
YES
&&
and (boolean value)
NO
NO
YES
YES
YES
NO
NO
NO
||
or (boolean value)
NO
NO
YES
YES
YES
NO
NO
NO
==
equal (boolean value)
NO
NO
NO
YES
YES
NO
NO
NO
!=
not equal (boolean value)
NO
NO
NO
YES
YES
NO
NO
NO
bit-wise negation
NO
NO
YES
YES
NO
NO
NO
NO
&
bit-wise and
NO
NO
YES
YES
NO
NO
NO
NO
bit-wise inclusive or
NO
NO
YES
YES
NO
NO
NO
NO
bit-wise exclusive or
NO
NO
YES
YES
NO
NO
NO
NO
^~, ~^
bit-wise equivalence
NO
NO
YES
YES
NO
NO
NO
NO
?:
conditional expression
YES
YES
YES
YES
YES
NO
NO
NO
assignment
YES
YES
YES
YES
NO
NO
NO
NO
..
range operator (ellipsis)
NO
NO
NO
NO
NO
YES
YES
YES
6.9.1 MergedScan function

The MergedScan() function returns a boolean value which is used to determine if scan operations are to be applied in
a merged or unmerged fashion. The behavior of merged and unmerged scan is described in clause 5.5 of IEEE Std.
1450-1999. The evaluation of this function shall be in the context of the STIL consumer environment. If the STIL
consumer environment has no specific needs for altering the merged scan operation then this function shall return a
default value of True.
This construct in conjunction with the If and Else constructs allow the STIL producer to generate STIL patterns/procedures/macros which represent both merged and unmerged scan operations. See annex N for an example.
7.
Statement structure and organization of STIL information
This standard defines two additional top-level STIL blocks: Environment (clause 19), and BistStructures (clause 20).
These blocks relate to the top-level blocks of IEEE Std. 1450-1999 as defined below.
19

7.1
Top-level statements and required ordering
The BistStructures blocks, if present, have a required ordering with respect to other STIL clauses defined in IEEE
Std. 1450-1999. This ordering is shown in table 6. This table is incremental to table 7 in IEEE Std. 1450-1999 and
indicates the required position of the BistStructures block is following the ScanStructures blocks (if present). All
other definitions and requirements specified in Table 7 of IEEE Std. 1450-1999 remain unchanged.
Table 6Additions to STIL top-level statements and ordering requirements

Statement
Purpose
ScanStructures
As defined in IEEE Std. 1450-1999.
BistStructures
Defines internal BIST structure information. The BistStructures block or blocks are
optional. If there are multiple BistStructures blocks they shall be named. The Pattern
may contain a reference to a named BistStructures. BistStructures blocks shall be
defined before the Pattern blocks.
Spec
7.2
Optional top-level statements
Environment blocks, if present, do not have a defined order with respect to other STIL clauses defined in IEEE Std.
1450-1999. Environment blocks may appear any place a top-level STIL statement is allowed. This is delineated in
table 7, which is provided to be complete with table 8 in IEEE Std. 1450-1999.
Table 7Additions to Optional top-level statements

Statement
Purpose
Environment
Defines relationships of STIL data to external environments. Environment blocks, if

referencing other STIL data, shall be defined after the blocks that define that STIL data,
unless those references are to information contained in MacroDefs, Procedures, or Pattern blocks, which are allowed to be forward-references.
Some applications of the Environment block may place ordering constraints to satisfy issues specific to the application of this data.
8.
STIL statement - Extensions to STIL0 clause 8
The STIL statement identifies the primary version of IEEE Std. 1450-1999 information contained in a STIL file, and
the presence of one or more standard Extension constructs. The primary version of STIL is defined in IEEE Std.
1450-1999.
The extension to the STIL statement allows for a block containing extension identifiers that allow for additional constructs in the STIL file. There may be multiple Extension statements present, to identify the presence of multiple
extension environments. The extension name and the extension statements are defined in the individual documents for
those standards.
All other constructs and restrictions for IEEE Std. 1450-1999 clause 8 are in effect here.
8.1
STIL syntax
STIL IEEE_1450_0_IDENTIFIER {
( EXT_NAME EXT_VERSION; )+
} // end STIL
(1)
(2)
20

(1) STIL: A statement at the beginning of each STIL file.

IEEE_1450_0_IDENTIFIER:
(2)
EXT_NAME:
The specific name of the Extension. This standard is identified by the name Design.
EXT_VERSION:
8.2
The primary version of STIL, as identified by IEEE Std. 1450-1999.
The primary version of an EXT_NAME. This standard is identified by the value 2001.
STIL example
STIL 1.0 {
Design 2001;
DCLevels 2001;
CTL 2001;
}
Header {
}
9.
UserKeywords statement - Extensions to STIL0 clause 11
This clause defines additional locations in a STIL file where the UserKeywords statement is allowed to appear.
The UserKeywords construct is expanded from IEEE Std. 1450-1999, to allow the UserKeywords statement to be
defined within STIL blocks. When a UserKeywords statement is defined within a STIL block, those definitions shall
apply only within that block and contained sub blocks. This allows Userkeywords to be "locally scoped" to a containing STIL block.
All other constructs and requirements for IEEE Std. 1450-1999 Clause 11 are in effect here.
9.1
UserKeywords syntax
9.2
UserKeywords example

Header {
}
Signals { A[1..99] InOut; }
SignalGroups { allsignals = A[1..99]; }
/*
The UserKeywords construct is the same as defined in IEEE Std. 1450.0,

with the additional capability to be defined within another STIL block */
Timing one {
UserKeywords startup shutdown;
WaveformTable one {
21


startup { allsignals;}
}
}
10.
Variables Block
This clause defines variables and constants. If the block is unnamed then all definitions shall be globally available to
all other blocks in the STIL file. If the block has a name, then that name must be referenced by the Pattern or PatternBurst for the variables to be available.
This block should be considered in light of the Spec block that also can define constants and variables. The purpose
and usage of these two blocks is sufficiently different to warrent their separation. The Spec block is intended to contain parametric data used in specifying device/test characteristics. The Spec block has special handling defined for
Category, Min/Typ/Max/Meas, and Selector which are to facilitate a flexible definition of these test parameters. The
Spec block is designed to contain primarily constant values with one exception (Meas) which is to allow re-calculation of the constants based on a real-time measured value from a tester.
The Variables block is used to contain control variables and constants. Typical uses for these constants and variables
is to control flow of exectuion, to provide aliasing of values to meaningful names with Constants and Enumerations,
and to provide run time parameters.
10.1
Variables Block Syntax

Variables (VARS_BLOCK_NAME) {
( IntegerConstant CONST_NAME = DECIMAL_INTEGER ; )*
( IntegerVAR_NAME; )*
( IntegerVAR_NAME {
( Usage (STIL_BLOCK_NAME )+ ; ) // under review see GR-7
(1)
(2)
(3)
( InitialValue logical_expr ; )
( IntegerEnum INTEGER_ENUM_NAME; )
( Values integer_list ; )
} )* // end Integer
( IntegerEnum INTEGER_ENUM_NAME {
(4)
Values {
(ENUM (DECIMAL_INTEGER); )+
} // end Values
} )* // end IntegerEnum
( SignalVariable VAR_NAME; )*
(5)
( SignalVariable VAR_NAME {
( Usage (< CTL | Design | Simulation | Test | TRC | User USER_DEFINED >)* ; )// under review see GR-7
( Base < Hex | Dec> WFC_LIST ; )
( Alignment < MSB | LSB > ; )
( Length DECIMAL_INTEGER ; )
( InitialValue vec_data ; )
( SignalVariableEnum SIGNAL_ENUM_NAME)
} )* // end SignalVariable
( SignalVariableEnum SIGNAL_ENUM_NAME {
(6)
( Base <Hex | Dec> WFC_LIST ; )
( Alignment < MSB | LSB > ; )
( Length DECIMAL_INTEGER; )
Values {
(ENUM vec_data ; )+
} // end Values
} )* // end SignalVariableEnum
} // end Variables
tbd: (TT 7/28/02 - The following definitions need to be adjusted to the above syntax (pending wg approval of the
22


changes)
tbd: (TT 8/1/2002 - The two Usage statements above should be consistent. But there is another proposal to identify
the usage along with the application (AI Jim Tiesher)
(1) VAR_NAME < Integer | IntegerEnum INTEGER_ENUM >: Each variable has a name followed by a type
definition. The type is one of: Integer or IntegerEnum. IntegerEnum shall be followed by the name of the
Enumeration definition, which shall be previously defined. This statement is terminated by a semicolon, or a set of
braces defining optional attributes. Variables are differentiated from enumerations by the absence of the Values
attribute on these declarations.
(2) Usage STIL_BLOCK_NAME: This optional attribute allow to specify in which block types a variable is allowe
to be used. i.e., The statement Usage Pattern; restricts the usage of the variable to be allowed only in pattern blocks.
(3) InitialValue: This optional attribute allows the specification of the initial value that is to be assigned to the
variable at the onset of execution of the first or highest-level PatternBurst that uses this Variable. Variables declared
with no InitialValue shall contain an undefined value until they are assigned a value (written to). The value of the
expression defined on the InitialValue statement is not established until a context where this variable is applied is
initiated. This occurs under a PatternBurst that references a SignalGroup that contains this variable, in combination
with the PatternExec that invoked this PatternBurst.
(4) INTEGER_ENUM IntegerEnum: Each enumeration is identified by a name, followed by the type IntegerEnum,
followed by a required block of information. That block shall contain a single Values block defining at least one
enumerated value for this declaration. For enumerations of type Integer, the Values block present in this definition
shall contain at least one ENUM statement and an optional assignment of an explicit value for this ENUM. If no value is
assigned to this ENUM, then values are assigned with no external visibility. If any ENUM statement in a Values block
contains a value assignment, all ENUM statements in that Values block shall have value assignments.
Values: This required block contains all ENUM values that may be used for this ENUM_NAME. The Values block
shall be present once in each ENUM_NAME block. The Values block contains a list of enum/integer pairs:
ENUM:
The name assigned to an enumerated value and to be used when associating this named value to a variable
of this enumerated type.
DECIMAL_INTEGER: The integer value that is assigned to this enum name. A value is optional for enums. of type
IntegerEnum. Separate ENUM declarations may identify the same value; ENUM values do not have to be unique
within one ENUM_NAME.
(5) CONST_NAME Constant = DECIMAL_INTEGER : declaration of a named variable that is equivalent to the
specified integer value in all applications. Constants declared in the Signals block are globally accessible to all
logical_expr expressions and bracketed signal name constructs.
(6) VAR_NAME < SignalVariable | SignalVariableEnum SIGNAL_ENUM >: Each variable has a name followed
by a type definition. The type is one of: SignalVariable or SignalVariableEnum. SignalVariableEnum shall be
followed by the name of the Enumeration definition, which shall be previously defined. This statement is terminated
by a semicolon, or a set of braces defining optional attributes. Variables are differentiated from enumerations by the
absence of the Values attribute on these declarations.
Usage SimulationOnly: This optional attribute indicates that the named variable is intended to be used in nonATE applications. Typical uses would be for interacting with a simulation process or for defining conditions
processed during the translation process.
Base <Hex | Dec> WFC_LIST : This optional attribute defines the mapping from WFC characters to/from decimal
or hex integer values, as defined for the Base option of SignalGroups in IEEE Std. 1450-1999 Clause 14. This
statement is allowed only for variables and enumerations of type SignalVariable.
23


Alignment: This optional attribute is used to specify the mapping from integer to SignalVariable is to start with the
MSB or the LSB. The default is MSB to accommodate the convention used for scan data. This statement is allowed
only for variables of type SignalVariable.
Length: This optional attribute defines the number of bits that are to be used in the integer value. This statement is
allowed only for variables of type SignalVariable.
InitialValue: This optional attribute allows the specification of the initial value that is to be assigned to the variable
at the onset of execution of the first or highest-level PatternBurst that uses this Variable. Variables declared with no
InitialValue shall contain an undefined value until they are assigned a value (written to). The value of the
expression defined on the InitialValue statement is not established until a context where this variable is applied is
initiated. This occurs under a PatternBurst that references a SignalGroup that contains this variable, in combination
with the PatternExec that invoked this PatternBurst.
(7) SIGNAL_ENUM SignalVariableEnum: Each enumeration is identified by a name, followed by the type
SignalVariableEnum, followed by a required block of information. That block shall contain a single Values block
defining at least one enumerated value for this declaration. For enumerations of type SignalVariableEnum, the Values
block present in this definition shall contain at least one ENUM statement with an assignment of WaveformCharacter
values for that ENUM. The value is specified either as a WaveformCharacter list or as an integer or hex value. If a Base
statement is present, then the assigned value is interpreted as Base value by default unless overridden by an explicit
\w. The \r may be used to specify a repeated WaveformCharacter.
Values: This required block contains all ENUM values that may be used for this
shall be present once in each SIGNAL_ENUM block.
SIGNAL_ENUM.
The Values block
ENUM:
The name assigned to an enumerated value and to be used when associating this named value to a variable
of this enumerated type.
vec_data: The value is expressed as a vec_data expression as defined in STIL.0. It may be comprised of a string of
WaveformCharacters, or an integer value that maps into a set of WaveformCharacters. Separate ENUM declarations
may identify the same value; ENUM values do not have to be unique within one SIGNAL_ENUM.
10.2
Variables Example

Header {
}
Variables {
IntegerConstant bus1_top = 15;
Integer h1;
Integer h2 { Values 2; 4; 6; 8; }
Integer h3 { Values 1..100; }
}
Signals {
bus1[ bus1_top .. 0 ] Inout;
DIR In;
}
}
11.
Signals Block - Extensions to STIL0 clause 14
This clause defines additional statements supported within the Signals block. All statements and capabilities as
24


defined in IEEE Std. 1450-1999 clause 14 are unchanged.
A new attribute, WFCMap, allows mapping WaveformCharacter values to other WaveformCharacters on a signal or
group of signals. Refer to clause 16 for the definition of usage of the mapped WaveformCharacter values.
A new declaration type, Constant, is also defined in this block.
11.1 Signals block syntax

Signals {
( SIG_NAME < In | Out | InOut | Supply | Pseudo > {
( WFCMap {
( FROM_WFC -> TO_WFC( TO_WFC )+ ; )*
( FROM_WFC1 FROM_WFC2 -> TO_WFC ; )*
} ) // end WFCMap
} )*
(1)
(2)
(3)
(4)
}
The WFCMap attribute is defined for both Signals and SignalGroups (clause 12). This attribute defined here applies
to both environments.
(1) Signals: Refer to IEEE Std. 1450-1999 for the definition of the Signals block and statements not defined in this
extension.
(2) WFCMap is an optional attribute block.
(3) FROM_WFC -> TO_WFC(TO_WFC)+ : identifies a set of waveforms to use when the FROM_WFC waveform
contains a Substitute character; the FROM_WFC waveform referenced shall contain a Substitute character when there
is more than one TO_WFC character present. This statement supports the reverse mapping of information required to
support the CompareSubstitute. See Timing Block and WaveformTable Block - Extensions to STIL0 clause 18 on
page 35 for information about the CompareSubstitute event. The order of characters in the TO_WFC list is important:
the first WaveformCharacter represents the waveform reference to use when the S state identifies a CompareLow (L
event) state, the second WaveformCharacter represents the waveform reference when the S state identifies a
CompareHigh (H event) state, the third WaveformCharacter represents a CompareUnknown (X event), and a forth
WaveformCharacter represents a CompareOff (T event) state. A minimum of two TO_WFC characters shall be present
in this expression, to map to a CompareLow waveform a CompareHigh waveform.
(4) FROM_WFC1 FROM_WFC2 -> TO_WFC ; is a statement that indicates that two separate assignments to the
same signal, one using FROM_WFC1 and the other one using FROM_WFC2, should be interpreted as having assigned to
the WaveformCharacter value TO_WFC instead. The two WaveformCharacters FROM_WFC1 and FROM_WFC2 need not
be separated by whitespace and are not order sensitive.
11.2
Signals example (using WFCMap additions)

Header {
}
Signals {
bus1_top Constant = 15;
bus1[ bus1_top .. 0 ] Inout;
DIR In;
A0 In {
WFCMap {
z->x; //single-WFC mapping
25


01->x;//two-WFC mapping (requires presence of \j)
}
}
}
11.3
Application of WFCMap constructs
To use the mapping of a signal or signalgroup, two new flags are added to the cyclized pattern data: \m indicates that
the defined mapping from a single FROM_WFC should be used; \j indicates that the defined mapping from two
FROM_WFC1 FROM_WFC2 should be used. When \j is used, both assignments shall be preceded by \j. No more
than two \j-assignments to the same sigref_expr may occur in the same vector or condition. If there is only one
assignment to a sigref_expr then a \j, if present, is ignored.
The \m and \j flags apply to all WaveformCharacters of the flagged assignment. The WFCMap is applied only once
i.e., the mapped TO_WFC is not subject to further mapping. If \m or \j are used for a sigref_expr which does not
define a WFCMap, then the components of sigref_expr are descended until the first corresponding WFCMap is
found.
If the vector mapping \m is used but no WFCMap has been defined for the WaveformCharacter FROM_WFC to be
mapped (for sigref_expr or its components), then the same WaveformCharacter FROM_WFC is used unchanged. If
the vector mapping \j is used for two assignments of FROM_WFC1 and FROM_WFC2 then the corresponding WFCMap shall be defined.
12.
SignalGroups Block - Extensions to STIL0 clause 15
This clause defines additional statements supported within the SignalGroups block. All statements and capabilities as
defined in IEEE Std. 1450-1999 Clause 15 are unchanged.
As presented in clause 11, the WFCMap attribute has been added to SignalGroup declarations in this block. Additional details on the WFCMap can be found in clause 11 and clause 16.
In addition, new Variable types are declared in this block. These types are SignalVariable, Integer, SignalVariableEnum, IntegerEnum, or Constant. These variables, once defined, may appear in appropriate expressions, as presented
in clause 6. Variable declarations are differentiated from SignalGroup declarations by the type keyword that appears
immediately after the name.
Be aware that Spec variables, defined in IEEE Std. 1450-1999 clause 19, have different functionality compared to the
variables defined here. Spec variables may be referenced in logical expressions, but the value applied is a function of
the Spec and Selector operations and these variables cannot be assigned to in logical expressions.
While logical expressions and WaveformCharacter expressions may support the instruction capability of an ATE system, in general most ATE systems will be able to support only a limited sub-set of the design capabilities defined
herein. The full capabilities are intended for use by simulation applications or pattern translation tools.
12.1 SignalGroups syntax

SignalGroups {
( GROUPNAME = sigref_expr {
( WFCMap {
( FROM_WFC -> TO_WFC( TO_WFC )+ ; )*
( FROM_WFC1 FROM_WFC2 -> TO_WFC ; )*
} ) //end WFCMap
} )*
(1)
(2)
(1) SignalGroups: Refer to IEEE Std. 1450-1999 for the definition of the SignalGroups block and statements not
defined in this extension.
26


(2) WFCMap: See definition of WFCMap in clause 11 for details of this attribute.
12.2
SignalGroups WFCMap and Variables example

Header {
}
Signals {
}
Variables {
// Constant declaration
hi_index Constant = 5;
// SignalGroup that uses this Constant
busA = topbus_1[ hi_index .. 0 ];
// Variable declaration
index_cnt Integer;
complete_decl Integer {
InitialValue -1;
} // end complete_decl
conditions IntegerEnum {
Values {
red { Ann {* critical processing error *} }
yellow { Ann {* cautionary processing condition *} }
green { Ann {* processing OK *}
} // end Values
} // end conditions
h1 Integer
// { Base Hex LH; } No Base on Int
} // end Variables
// WFCMap code example
SignalGroups {
A = A0+A1+A2+A3 {
WFCMap {
z->x; //single-WFC mapping
01->x;//two-WFC mapping (requires presence of \j)
} // end WFCMap
} // end A
// SignalGroups code examples for constants Enumerations and variables
SignalGroups logical_expr_constructs {
// Enumeration declarations,
// because they contain Values {} blocks.
ucommands SignalVariableEnum {
Values {
fetch = AABBA { Ann {* command to fetch *} }
store = ABBBA { Ann {* command to store *} }
} // end Vaules
27


} // end ucommands
pcommands SignalVariableEnum {
Base Hex DU;
Values {
grab = FF { Ann {* moves cursor *} }
release = 00 { Ann {* releases cursor *} }
} // end Values
} // end pcommands
// Variable declarations
bus_state SignalVariableEnum ucommands;
cur_state SignalVariableEnum pcommands;
} //end SignalGroups logical_expr_constructs
// If integers are used in WFC-assignments, they need to follow the same semantics
// currently defined for WFC-assignments, for example:
SignalGroups {
grp_a = 'abus[1..8]' { Base Hex DU; } // Base on the Signal
}
MacroDefs {
mdata {
C { h1 = #; h2 = #; }
V { grp_a = 'h1'; }
}
}
12.3
Default WFCMap attribute value
The WFCMap attribute, if not present on a declaration, is undefined for that signal or signalgroup reference. If mapping is required for every use of a signal, all SignalGroups that contain that signal need a WFCMap that defines the
mapping required for that signal.
13.
PatternBurst Block - Extensions to STIL0 Clause 17
This clause defines additional statements supported within the PatternBurst block. All statements and capabilities as
defined in IEEE Std. 1450-1999 Clause 17 are unchanged.
Two new pattern grouping structures are defined - the ParallelPatList and the PatSet. Also, the Fixed, Extend, and
Wait statements are defined to allow the specification of how multiple patterns are to be executed.
Lastly, the If and While statements are provided to allow conditional execution of patterns within a burst.
13.1
PatternBurst Syntax
PatternBurst PAT_BURST_NAME {
( Variables VARIABLES_DOMAIN; )*
( Fixed sigref_expr (default_state) ; )*
( PatList {
( PAT_NAME_OR_BURST_NAME {
( If boolean_expr ; )
( While boolean_expr ; )
} )* // end pat_name_or_burst_name
(1)
(2)
(3)
(4)
(5)
(6)
28


} )*
// end PatList
( PatSet {
( PAT_NAME_OR_BURST_NAME ; )*
} )*
// end PatSet
( ParallelPatList ( SyncStart | Independent | LockStep ) {
( PAT_NAME_OR_BURST_NAME ; )*
( Wait; )
( Extend; )
( If boolean_expr ; )
( While boolean_expr ; )
} )*
// end ParallelPatList
(7)
(8)
(9)
(10)
(1) PatternBurst: Refer to IEEE Std. 1450-1999 for the definition of the PatternBurst block and statements not
(2) Variables: This statement allows reference to a named block of variables to by allowed by all patterns and
pattern bursts within this block. See Variables Block on page 22.
(3) Fixed: This statement allows the specification of a set of signals that are to be maintained in a fixed state. This
statement may be associated with a pattern or burst within a PatList, PatSet, or ParallelPatList. It requires that the list
of signals in the sigref_expr not be used in the associated patterns, but remain fixed in the state that they are defined in
prior to this pattern or burst. The state for the fixed signals is determined by the following conditions:
the optional default state in the Fixed statement;
the ending state of a prior pattern execution;
the default state as defined in the Signal block definition.
This statement performs a similar function to the Fixed statement that may occur within a pattern. The difference is in
the scope. The Fixed statement within a pattern is in effect from its occurrence to the end of the pattern, whereas the
Fixed statement outside a pattern is in effect for the entire pattern or burst of patterns.
(4) PatList: The PatList block performs exactly the same function as defined in IEEE-Std 1450.1999. It is repeated
here to show the new optional statements that are allowed within a pattern list, namely the If and While attributes.
(5) If: This attribute defines a conditional requirement on the execution of the PAT_OR_BURST_NAME; this block
will execute only if the boolean_expr is True. The expression is evaluated at the point this reference would start to
execute in the sequence defined.
The If statement determines whether the statements within the block are to execute or not. The statements within an If
block have the same effect and scope as if they were to be executed outside of the block - i.e., the statement "If xxx
{ Fixed yyy; }" will be in effect for the rest of the pattern if xxx evaluates to True.
(6) While: This attribute defines an iterative option for execution of the PAT_OR_BURST_NAME; this reference
will be executed repeated times as long as the boolean_expr is True. The expression is evaluated each time this
reference would start to execute; pattern sequencing iterates on this reference until the expression returns False.
(7) PatSet: This block defines a set of PAT_OR_BURST_NAME that have no requirement on the order of execution
of each reference. This construct is intended primarily for defining data in an interim format prior to being presented
29


to a tester, to identify a set of Patterns that have no external constraints on order of execution. If this data is presented
to a tester, then each Pattern shall be self initializing and capable of executing independently.
The PatSet block is similar to the PatList in that it is used to define a list of Patterns and the environment for interpreting them. The difference is that the PatSet does not imply any sequencing requirements. Thus, the system integrator is
free to take that Patterns and use them in any sequence desired. All of the optional statements that are defined in
STIL.0 for PatList also are available in a PatSet block.
The requirement on the Patterns in a PatSet is that they be self contained such that any initialization that is required is
done within the pattern and not dependent on the execution of a prior pattern. Also, because there is no required
ordering of Patterns in this block, If and While statements are not supported for these blocks because of ambiguity of
expression evaluation.
The PatSet is not used to do implicit parallel patterns, even if the set of signals between patterns are non-overlapping.
To do this, you need to define two bursts that contain PatSets, and reference them in a higher level with a ParallelPatList.
(8) ParallelPatList ( SyncStart | Independent | LockStep ): This block defines a set of PAT_OR_BURST_NAME
that are to be executed in parallel. Execution of this set of Patterns is controlled by optional arguments SyncStart,
Independent, or LockStep, as well as the optional statements Wait and Extend. Parallel patterns do not necessarily
run synchronously or finish together. If no arguments are specified to ParallelPatList then the default operation of the
Patterns is Independent. All of the optional statements that are defined in STIL.0 for PatList also are available in a
ParallelPatList block.
SyncStart: this keyword, if present, requires that all PAT_OR_BURST_NAME present in the ParallelPatList block
shall start executing at the same moment. During execution, pattern behavior may diverge if patterns contain
different Vector counts or different periods in the Vectors.
Independent: this keyword, if present, allows each PAT_OR_BURST_NAME present in the ParallelPatList block
to start as convenient. This option indicates that the set of patterns executing in parallel have little or no relationship
between each other and can be executed independently.
LockStep: This keyword is used to specify parallel testing of cores (sub designs) that require synchronization
throughout the pattern execution. A lockstep application may be used for situations where parallel cores have
common access constructs that require maintaining the same state on a set of signals for the cores during test (for
instance, common wrapper control logic around cores). Lockstep may be used for parallel testing of cores that have
serially connected scan chains. Lockstep can also be used to map patterns onto test equipment that has limited
timing flexibility that prevents true independant execution. See LockStep Explanation and Example on page 31..
(9) Wait: This statement signifies that all other patterns that are running in parallel are to wait for this pattern to
terminate. Wait is incompatible with LockStep; it is an error to specify Wait in a PAT_OR_BURST_NAME block
under a ParallelPatList block that defines LockStep.
Extend: This statement signifies that the last vector of this pattern may be extended in order to wait for completion of
other parallel patterns. The behavior of Signals during Extend is described in clause 13.4. Extend is incompatible
with LockStep; it is an error to specify Extend in a PAT_OR_BURST_NAME block under a ParallelPatList block
that defines LockStep.
If the Extend statement is not used, then the last cycle shall tile exactly with any other patterns that are running in
parallel.
The behavior of the Signals during the Extend period is determined by the last STIL statement in the Pattern. If the
last statement in the Pattern is a "BreakPoint;" then all Signals will maintain the last asserted state indefinitely until
the parallel set of Patterns is complete. If the last statement is BreakPoint { V { ...} }, then the Vectors present in
this BreakPoint block shall be executed for these Signals until all parallel patterns have completed.
If the last STIL statement in the Pattern is not a BreakPoint construct, then the last asserted state on all Signals shall
be maintained indefinitely as if a "BreakPoint;" statement was present in the Pattern.
30

13.2
PatternBurst example

Header {
}
Variables {
first_pat_passed Integer { InitialValue = 0; }
not_complete Integer { InitialValue = 0; }
}
PatternBurst burst_xx {
PatList {
first_pat;
second_pat {
If first_pat_passed;
}
third_pat {
While not_complete;
}
}
} //end PatternBurst burst_xx
13.3
LockStep Explanation and Example
This sub-clause explains in detail the semantics of the LockStep operation.

timing and sequencing - Each pattern in the ParallelPatList shall start executing at the same time, each vector in each
pattern shall start executing at the same moment in time, and each vector shall have the same period. When lockstep
is defined for a set of parallel patterns, these patterns shall enter and exit all data-dependent pattern constructs in parallel as long as the patterns are executing in parallel. In particular, lockstep patterns shall enter a shift block or loop
data block at the same point in the execution sequence, and shall finish executing these blocks at the same time. To
support this behavior, the definition of normalizing the length of data for each of these blocks is extended as follows:
-- For all shift blocks in parallel, the length of the scan data is defined as the longest data length of all signals with a
"#" across all shift blocks. To facilitate this determination, it is required of the integration process that the signal/
group definitions be adjusted such that the ScanIn/ScanOut-integer attribute defines the length to which each signal/
group is to be padded, and this value shall be used rather than padding to the longest scan chain length of an individual pattern.
-- For all loop-data blocks in parallel, the length of the loop data is defined as the longest loop required by any of the
patterns. All other patterns shall pad additional passes through the loop using the default state.
shift ordering on serial scan signals - When there are serially connected scan signals, the scan data is combined
according to the following rules. The data assigned to each scan signal in common in each shift block executed in parallel across all patterns in the parallelPatList, is the concatenation of the scan data for each reference to this signal for
each of the shifts executed in parallel. The data is concatenated in the order that the patterns are referenced in the ParallelPatList block. The first pattern in the list is the first to shift in and the first to shift out. Please see the example
below.
shift padding on serial scan signals - When there are serially connected scan signals, the scan data padding is done
according to the following rules (consistent with the rules as defined in IEEE Std. 1450-1999). Scan shift padding is
done by first concatenating each serial scan signal. Then the length of each scan signal is determined by the length of
each segment. Then the shorter combined scan signals are padded to the same length as the length of the largest combined scan signal. Please see the example below.
procedures, macros, and shifts - All patterns in the lock-step group shall have the same procedure and macro activity
31


- i.e., procedure/macro calls shall occur at the same point in each pattern and shall be of the the same length. All procedures/macros in the lock-step group shall have the same shift-block activity - i.e., shift-blocks must occur at the
same vector position in the procedure/macro.
signal overlap - In general, parallel patterns should operate on separate disjoint sets of signals. However, there are
cases where the same signal appears in two or more patterns. Such may be the case where two identical cores share a
common input sigal. The basic rule of signal overlap is that the WFC and the WFT that resolves it shall be the same.
One exception to the WFC rule is when the N event is used, in which case a shared input signal may be resolved in
favor to the pattern that has a required state (i.e., N can be interpreted as either U or D as needed). The other exception
to the WFC rule is when the X event is used on an output signal (i.e., the X event can be interpreted as a H or L as
required).
procedure considerations - In the case where parallel patterns call procedures, it is a requirement that the procedures
be called in parallel. The set of signals in all of the called procures shall, in combination, define the activity for all of
the signals. In general, it is expected that there be a one to one relation between the calling pattern and the called procedure, but this is not always the case. If there is overlap in the signals, then the signal overlap rules defined above
apply. If there are any missing signals, then they follow the normal default to the state defined in the Signals group
block, else the initial default state.
setup macro - Each pattern is required to define in the initial V or C statement the set of signals that are used by the
pattern. This is typically done in a setup macro. This setup macro should limit the definition to only the signals of the
pattern and not the entire signal width of the design. Note: Defining signal states that are used in other parallel patterns will preclude the use of the lock step operation, and indeed, any parallel pattern operation.
scan chain length determination - When patterns are executing in lock-step mode, an additional constraint is made on
the normalizing of scan chain data in that the scan chain length is determined by the decimal integer value that is
specified in the ScanIn/ScanOut statement. In the process of preparing multiple patterns to execute in lock-step, the
length of the longest scan chain (for the specific device or pattern set) is to be specified for all scan chains that are to
be loaded/unloaded in parallel. If the length specified for one device or pattern set is shorter than others in the lockstep group, then the shorter scan chains shall be normalized to the length of the longer chains. The process that interprets/loads the scan data shall pad the scan chains to the length specified according to the rules of IEEE Std. 14501999.
The following is an example of two pattern running in LockStep with a serially connected scan chain.
Signals { In si1; In si2; Out so1; Out so2; }
SignalGroups g1 {
si1=si1 { ScanIn 4; }
so1=so1 { ScanOut 4; }
}
SignalGroups g1 {
}
Procedures procs1 {
load_unload {
C { si1=0; si2=0; so1=X; so2=X; }
Shift { V { si1=#; si2=#; so1=#; so2=#; } }
}
Procedures procs2 {
load_unload {
C { si1=0; si2=0; so1=X; so2=X; }
Shift { V { si1=#; si2=#; so1=#; so2=#; } }
}
32


PatternBurst {
ParallelPatList LockStep {
p1 { Procedures procs1; SignalGroups g1; }
p2 { Procedures procs2; SignalGroups g2; }
}
}
Pattern p1 {
Call load_unload { si1=1234; si2=567; so1=1234; so2=567; }
}
Pattern p2 {
Call load_unload { si1=ABC; si2=DE; so1=ABC; so2=DE; }
}
SoC
M2
13.4
M1
CBA4321
si1
so1
CBA4321
ED765xx
si2
so2
xxED765
Pattern Tiling and Synchronization
Pattern tiling is the process of connecting patterns together end-to-end in time and side-to side by signal. For the purpose of specifying the desired actions when a PatternBurst contains patterns that may be run in parallel, the following
statements are availablefor this purpose:
Fixed sigref_expr (default_state) ;
Wait;
Extend;
The following is an example of Pattern Tiling using the statements available in the PatternBurst. Refer to clause 13
33


for definition of syntax and semantics.
signals
pat_a
pat_b
pat_c
pat_d
time
pat_e
pat_f
Figure 1A Collection of Patterns to be Executed

One example of STIL code which would specify the above action is as follows:
Header {
Ann {* clause K *}
}
PatternBurst burst_x {
ParallelPatList {
pat_a {Extend;}
pat_b {Extend;}
pat_c {Wait;Extend;}
}
PatList {
pat_d;
pat_e;
pat_f;
}
This code causes the following actions:
1.
pat_a, pat_b and pat_c are initiated at the same time
2.
pat_a and pat_b are allowed to extend, since they are expected to complete in less time than pat_c.
Extending means that the state of all signals at the end of the last vector of the pattern can be held, effectively extending the period of the last vector.
3.
pat_c must run to completion before any further activity in this burst can be started
4.
pat_c is allowed to extend its last cycle
5.
pat_d, pat_e, and pat_f are run sequentially, starting immediately upon completion of the last vector of
34


pat_c.
13.5
If and while statements
Conditional PatternBurst statements If and While defined here allow selective execution of a complete Pattern or PatternBurst based on the evaluation of a boolean expression.
The following example defines two Pattern Variables whose scopes are the pattern burst named with_vars. The Pattern Variable counter has an initial value determined by evaluating the expression t_Per / 25ns. The Pattern Variable failure is initially given an undefined value.
Header {
}
Variables {
count Integer {
InitialValue t_Per / 25nS;
} // end count
failure Integer;
}
SignalGroups block_one {
PatternBurst with_vars {
SignalGroups block_one;
PatList {
first_pat;
second_pat { If !failure; }
} // end PatList
} // end PatternBurst
// The If statement provides control over the execution of second_pat,
// depending on the value of the variable failure when second_pat is ready to execute.
Pattern first_pat {
UserFunction TestResult;
Loop count { V { clk = P; } }
V { some_pins = 11110000 HHHHLLLL; }
C { failure = TestResult(); }
} // end Pattern
14. Timing Block and WaveformTable Block - Extensions to STIL0

clause 18
This clause defines additional constructs supported within the waveform statement of a WaveformTable block. All
statements and capabilities as defined in IEEE Std. 1450-1999 Clause 18 are unchanged.
The only addition to the waveform statement is the additional event characters CompareSubstitute and CompareSubstituteWindow. This event is used to resolve event data with actual response during test generation, and is provided
primarily to support returning diagnostic information as presented in Diagnostic Information in "non-failure" Environments (informative) on page 76.
35

14.1
Additional waveform event definitions
The following table defines the additional Compare character CompareSubstitute. This table is incremental to Table
10 of IEEE Std. 1450-1999.
Table 8Compare events

Identifier
Icon
Definition
CompareSubstitute
Perform a Compare operation at this time, and return the value

of the resulting operation as a CompareHigh, CompareLow,
CompareUnknown, or CompareOff value.
CompareSubstituteWindow
Perform a Compare operation over a period of time, and return

the value of the resulting operation as a CompareHigh, CompareLow, CompareUnknown, or CompareOff value. Terminated
by a CompareOff event.
14.2
CompareSubstitute Operation
The CompareSubstitute event allows stimulus to be defined for device test, and supports a mechanism to return the
device response to this stimulus. How this response information is returned is outside the scope of this effort, but an
example is provided in annex I.
The CompareSubstitute event is expected to be found only once in a waveform definition. If multiple CompareSubstitute characters are present in one waveform definition, then all Compare operations shall return the same value or the
CompareUnknown state shall be returned.
The CompareSubstitute event is expected to be defined in conjunction with a WFCMap definition for each WaveformCharacter that represents a waveform containing the CompareSubstitute event. The WFCMap defines what
WaveformCharacter values are returned for each of the supported state values returned by CompareSubstitute. If no
WFCMap is defined, or a WaveformCharacter for a specific Compare value is not defined in the WFCMap for this
waveform, then the return information is not mapped to waveform references, but explicit \e events are returned with
the Vector data, as defined in Clause 13.3.
15.
ScanStructures block - Extensions to STIL0 clause 20
Simulation of scan patterns outside the test-pattern generator is often performed to verify timing, design functionality
or the library used to generate the patterns. The speed of the simulator is limited by simulating the load/unload (Shift)
operation of scan chains. Optimal simulation performance is achieved with no shifts, bypassing scan chain logic and
asserting/verifying the scan data directly on the scan cells.
The STIL.0 syntax is extended to support complex scan cells, where complex scan cell is defined to be a state element that is loaded/unloaded by a single element of the scan chain data, but may contain multiple states internally. A
related operation is that of loading multiple state elements from multiple elements of a scan chain which is defined by
using the ScanModule statement.
A scan cell may contain one or more state elements in various configurations. All state elements defined in one scan
cell access a single scan bit value; one scan bit in the data stream is allocated to each scan cell construct defined. Stability and capture ability are identified for each state element in the scan cell, in addition to the inversion information
with respect to both scan input and output by scan-oriented test pattern generators. For example, loading a single scan
bit may require setting values in several state elements. Additionally, there may be extra cycles in the load or unload
36


of only some test patterns, thus shifting the data. A typical scan-pattern simulation process is summarized below:
load: many cycles (Shift operation), not simulated in parallel load
skewed load: optional cycle, not simulated in parallel load, if possible
force values on primary inputs: simulated
measure values on primary outputs: simulated
pulse capture clock(s): optional cycle(s), simulated
observe procedure: optional cycle, not simulated in parallel unload, if possible
unload: many cycles (Shift operation), not simulated in parallel load
The ScanStructures block is extended to include additional information required for efficient simulation of scan patterns, i.e., eliminating the need to simulate load/unload (Shift) cycles. Additional constructs are defined on the ScanCell statement inside the ScanChain block. In addition, an ScanModule statement is added in the ScanStructures
block to support referencing previous ScanChain definitions from other ScanStructure blocks.
All other constructs and requirements for STIL0 clause 20 are in effect here.
15.1
ScanStructures Syntax
ScanStructures (SCAN_NAME) {
( ScanChain CHAIN_NAME {
ScanLength integer_expr ;
( ScanOutLength integer_expr ; )
( ScanEnable logical_expr ; )
( ScanCells ( cellname_list )+ ; )
( ScanCells {
(< cellname_list
| cellname_list {
( (If boolean_expr) CellIn STATE-ELEMENT-LIST ; )*
( (If boolean_expr) CellOut STATE-ELEMENT ; )*
} >)* // end cellname_list
})
// end ScanCells
} )*
// end ScanChain
// end ScanStructures
(1)
(2)
(3)
(4)
(5)
(6)
(1) ScanStructures: Refer to IEEE Std. 1450-1999 for the definition of the ScanStructures block and statements not
(2) ScanLength integer_expr : As defined in IEEE Std. 1450-1999, with the extension to support integer
expressions.
(3) ScanOutLength integer_expr : As defined in IEEE Std. 1450-1999, with the extension to support integer
expressions.
(4) ScanEnable logical_expr: This optional statement allows designation of a single Signal or a complete
expression to represent the design constraints, if any, necessary to allow access to the scan shift operations for this
scan chain. See example usage in Annex C.
(5) ScanCells: This statement shall appear at most once in a ScanChain block. It shall contain a combination of: a)
scan cell names as defined in IEEE Std. 1450-1999, b) cellname_list as defined in clause 6.3, c) scancell block, or d)
a scan segment. See annex L for more information.
A scan segment is a list of scan cells that are defined in a ScanChain block and are to be inserted in sequence in the
currently being defined scan cell list. The scan segment is defined as follows:
SCANSTRUCT
:: SCANCHAIN : INSTANCE
37


where SCANSTRUCT is the name of a ScanStructure block, SCANCHAIN is the name of the desired chain in the
ScanStructure block, and INSTANCE is a username that is assigned to each instance of the chain being referenced.
See example below for more detail.
(6) (If boolean_expr): Optional conditional clause on the CellIn and CellOut statements. The value of boolean_expr
is evaluated during pattern operation. When True, the following CellIn or CellOut statements are applied. See
clause 6.6 for information about boolean_expr.
STATE-ELEMENT is a name and STATE-ELEMENT-LIST is a list of names of state elements separated by
whitespace. State elements are internal design nets of CELLNAME. Inversion is indicated by inserting the !
character before or after names. When CellIn and CellOut constructs are inherited through InheritScanStructure
constructs, the names of all inherited state elements are prefixed with the INST_NAME (and a period) to identify
specific instances of these state element names.
CellIn: This is an optional statement indicating that the nets in STATE-ELEMENT-LIST are to be loaded with the
data value corresponding to the current scan cell, with possible inversion as indicated by a ! character. A !
indicates inversion between the input of the scan cell and the optional name following the !. If no name follows
the ! then the inversion is inside the cell CELLNAME, between the cell input and the state element.
CellOut: This is an optional statement indicating that, when the boolean_expr is true, the net STATE-ELEMENT is
to be unloaded (into the cellname-ref) with the data value corresponding to the current scan cell, with possible
inversion as indicated by a ! character. A ! indicates inversion between the name preceding the ! and the
output of the scan cell. If no name precedes the ! then the inversion is inside the cell CELLNAME, between the
state element and the cell output.
Both CellIn and CellOut statements may be qualified by If boolean_expr. This indicates that the nets in the CellIn
and CellOut statements are only to be considered in a pattern where the boolean_expr is True. The following cases
are all valid for CellIn:
No CellIn statement
All load operations are to be simulated.
CellIn statement
No load operations are to be simulated.
boolean_expr CellIn statements
Only load operations when all pat_exprs are false are to be simulated, other
loads use their corresponding CellIn statement.
Both simple CellIn and

boolean_expr CellIn statements
No load operations are to be simulated. Load operations when all

boolean_expr are False use the simple CellIn statement, other loads use their
corresponding CellIn statement.
The following cases are all valid for CellOut:

No CellOut statement
All unload operations are to be simulated.
CellOut statement
No unload operations are to be simulated.
boolean_expr CellOut statements
Only unload operations when all pat_exprs are false are to be simulated, other
unloads use their corresponding CellOut statement.
Both simple CellOut and

boolean_expr CellOut statements
No unload operations are to be simulated. Unload operations when all

boolean_expr are False use the simple CellOut statement, other unloads use
their corresponding CellOut statement.
38

15.2
Example indexed list of scan cells
The ScanCell naming constructs allow cells to be expressed as a list using the same notation defined for Signals and
SignalGroups in STIL0 clause 6.10. An example is shown below. Note that the presence of inversion between cells
requires multiple sets of cellnames to be present to represent the inversion at the correct point in the list:
Header {
}
ScanStructures {
ScanChain chain1 {
ScanLength 100;
ScanIn si1;
ScanOut so1;
ScanCells aa[1..50] ! aa[51..100];
} // end ScanChain
} // end ScanStructures
/* Once a scan chain is defined as an indexed list, then it can be referenced in statements that need to access these
cells, as shown in the following example. Note: This example is taken from 1450.6, but since it is within an Environment block it is acceptable syntax within 1450.1. */
Environment {
CTL {
Internal {
sig[5..9] { IsConnected In ScanSignal chain1 aa[23..27]; }
sig[12..22] { IsConnected In InternalSignal corex aa[55..65]; }
} // end Internal
} // end CTL
} // end Environment
15.3
Example of Hierarchical ScanStructures
The ScanModule block is used when a previous ScanChain found under one ScanStructures block, is incorporated
into another ScanStructures block. This mechanism allows for hierarchical scanchain declaration, with the requirement that the previous ScanCell declaration be precisely maintained in this new ScanStructures context. The following example is based on the structure presented in figure 2.
The scanchains of module CPUX are defined, in order to reuse these definitions as components of a scanchain for
module Custom1. The following ScanStructures supports this representation:
Header {
}
ScanStructures CPUX {
ScanChain A { ScanCells {} }
} // end ScanStructures
ScanStructures CUSTOM_1 {
39

module CUSTOM_1
module CPUX
INSTANCE_A
module CPUX
INSTANCE_B
scanchain A
scanchain A
Figure 2Hierarchical ScanChain Example

ScanChain A {
Scancells {
CPUX:A:INSTANCE_A;// use ScanChain A with label INSTANCE_A from CPUX
CPUX:A:INSTANCE_B;// use ScanChain A with label INSTANCE_B from CPUX
} // end ScanCells
} // end ScanChain A
} // end ScanStructures Custom1
16.
Pattern Data - Extensions to STIL0 clause 21
This clause defines additional formatting capabilities for defining pattern data. All statements as defined in IEEE Std.
1450-1999 clause 21 are unchanged.
16.1
Cyclized Data
The cyclized data construct is expanded to support the use of logical expressions. Logical expressions appear in two
contexts under cyclized data:
sigref_expr = logical_expr ;
logical_expr ;
When assigned to a sigref_expr, the logical expression shall be a sigvar_expr, or of type Integer and the sigref_expr of
Base Integer. When a logical expression is used as a complete statement, the expression is of any supported type. This
form of statement is used to manipulate Variable values.
16.2
Vector data mapping and joining - \m and \j
The vector data mapping function allows for a new waveform definition to be selected for a given waveform character
in a vector. This is most useful in the case of parameter passing to a macro or procedure, however can be used anywhere a waveform character string is formed. The Join function allows to have two WaveformCharacters against
the same signal in one vector. This enables structuring of STIL pattern output using Procedures.
The WFCMap statement, which is defined in clauses: Signals Block - Extensions to STIL0 clause 14 on page 24,
and SignalGroups Block - Extensions to STIL0 clause 15 on page 26 is used to specify the mapping on a per-signal
or per-group basis. This data, in conjunction with the \m and \j in the pattern data, together specify the resultant waveform character to use in resolving a vector.
40


The \m and the \j operators may be used in a stream of pattern data which typically is a list of waveform characters or
things that resolve to a list of waveform characters. The following are examples of pattern data containing these special characters:
STIL 1.0 { Design D14; }
Header {
}
Signals {
sig InOut { WFCMap AB->1 X->B; }
sigs[2..8] InOut;
}
SignalGroups { all=sig+sig[2..8] { WFCMap 0->L; 1->H; }
Macrodefs {
Macro m {
V { all = 1100 \m1100; }
// map the second group of 4 wfcs
V { all = 1100 \m 1100; } // space after the \m is allowed
V { all = \m 1100 1100; } // map only the first 4 wfcs (i.e., up to the space delimiter)
V { all = 1100 \m####; }
// map wfcs that are passed as parameters
V { all = 1100 \mvarx; } // map a signal variable
V { sig=A; sig=\jB; }
// sig is resolved by the joining of wfc-A and wfc-B
V { sig=A; sig=\j\mX; }
// sig is first mapped then joined with wfc-A
V { sig=A; sig=\m\jB; }
// ERROR - a map after a join is not allowed
}
}
16.3
Specifying Event Data in a Pattern
When specifying data for simulation stimulus, it is often times the case that the desired level of a given pin (input
drive or output compare) is known while the exact timing waveform which is appropriate for the cycle is not known.
This, in many cases, is why simulation for test generation is done. The simulator (or STIL consuming co-simulation
engine) would use the raw data, and the conditions of the device under simulation to determine the WaveForm Character which will be included in the test pattern.
Syntax Definition:
The base override flag, \e shall be added to the vec_data flags for specifying raw event data. The \e applies to all
characters that follow until the occurrence of a space or a semicolon. Raw data shall take the following form:
Drive
Expect
High
Low
Off
Unknown
Unspecified
\e Waveform Event Format (e.g., \eU).

41


Example:
The following Pattern block indicates how data can be specified without first knowing which waveform characters
should be used to reference to the WaveformTable. A WaveformTable reference is still made in a raw pattern, since
the successful waveform will ultimately come from that table. This example also illustrates the ability to mix raw and
resolved data using the CLK signal.
Header {
}
Signals {
clk In; sigA In; sigB In;
X[1..8] In; Y[1..8] Out;
} // end Signals
SignalGroups {
grpX = X[1..8];
grpY = Y[1..8];
Pattern RAW {
WaveformTable myTiming;
V { clk = 1; sigA = \eU; sigB = \eL;}
V { sigA = \eH; sigB = \eD;}
V { grpX = \eUUUUDDDD; }
V { grpY = AABB \eXXX AABB; }
} // end Pattern
17.
Pattern Statements - Extensions to STIL0 clause 22
This clause defines additional statements that are allowed within the Pattern block. All constructs and definitions of
IEEE Std. 1450-1999 clause 22 remain in effect.
17.1
Additional Pattern Syntax
( LABEL : ) If boolean_expr { (PATTERN_STATEMENTS)* } ( Else { (PATTERN_STATEMENTS)* } )

( LABEL : ) While boolean_expr { (PATTERN_STATEMENTS)* }
( LABEL : ) F(ixed) { (cyclized-data)* (non-cyclized-data)* }
( LABEL : ) E(quivalent) SIG-EXPR-LIST ;
( LABEL : ) ScanStructures SCAN_NAME ;
( LABEL : ) BistStructures BIST_NAME ;
( LABEL : ) X TAG ;
( LABEL : ) X (TAG) {
( Cycle VECTOR_CNT; )
( Iteration ITERATION_CNT; )
( PatternOffset VECTOR_CNT; )
( TagOffset VECTOR_CNT; )
}
( LABEL : ) Loop Data { ( pattern-statements )* }
( LABEL : ) Loop < boolean_expr | integer_expr > { ( PATTERN_STATEMENTS )* }
(1)
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9)
42


(1) If boolean_expr : defines a block of PATTERN_STATEMENTS to be executed only if the boolean_expr is True. The
value of boolean_expr is determined at the point that execution reaches this statement. The optional Else block
contains pattern statement that are executed if boolean_expr is False.
With regard to usage of If/Else within a Shift block, the following rule applies. In 1450-1999, p114, paragraph 3 it
states that "A particular sigref_expr shall appear only once in a Shift block. Consecutive shift blocks require unique
sigref_exprs for each Shift statement". The rule shall now be that a particular sigref_expr shall appear only once in
a Shift block for any given execution path as governed by the If/Else conditions.
(2) While boolean_expr : defines a block of PATTERN_STATEMENTS to be repeatedly executed as long as the
boolean_expr is True. The value of boolean_expr is re-evaluated each time execution reaches this statement.
(3) F(ixed) : Statement to define signals that are held at a constant value (held at the value specified or the current
value). Fixed statements do not define event sequences and are executed in zero-time, in the same manner as
Condition statements defined in IEEE Std. 1450-1999. See clause 17.3 for complete definition of this statement.
(4) E(quivalent) : Statement to establish WaveformCharacter relationships between signals. Equivalent statements
do not define event sequences and are executed in zero-time, in the same manner as Condition statements defined in
IEEE Std. 1450-1999. See clause 17.3 for complete definition of this statement.
(5) ScanStructures SCAN_NAME : The ScanStructures statement, when used within a pattern block, specifies the
set of scan chains that are active for the next set of pattern operations.
(6) BistStructures BIST_NAME : The BistStructures statement, when used within a pattern block, specifies the set
of BIST registers that are active for the next set of pattern operations.
(7) X : This statement defines a mechanism to identify the next pattern statement for the purpose of an external
application. The keyword "X" is intended to imply "cross-reference". See clause 17.4 for information on this
construct.
TAG. A user defined name (as defined in IEEE Std. 1450-1999 clause 6.8). For the block form of the X statement, if
no tag is present, then the offset and iteration shall be relative from the beginning of the pattern.
Cycle VECTOR_CNT. The number of vectors executed since the beginning of the current pattern. The first vector is
counted as vector number 1.
Iteration ITERATION_CNT. The number of iterations that the following vector being referenced has been applied
including the current iteration. This is associated with vectors which are surrounded by Loop constructs such as
can be defined with Loop, MatchLoop, and Goto statements. If the vector being referenced is within a nested loop,
the iteration count will be the total iterations that the vector has been applied across all loops. The iteration count is
always a positive integer.
PatternOffset VECTOR_CNT. The number of vectors executed (not including the following one being referenced)
since the beginning of the pattern. The Offset vector count is a non negative integer. The first vector of the pattern
is counted as 1.
TagOffset VECTOR_CNT. The number of vectors executed (not including the following one being referenced) since
the last cross-reference TAG was established. The Offset vector count is a non negative integer. If no offset is
specified then the default is zero.
(8) Loop Data : The Loop construct is expanded to support the keyword Data. This construct is used only for Loops
inside Macro and Procedure bodies. This Loop statement iterates, replacing each # parameter with a data value until
there are no more data values defined. It is an error if all data values are not consumed by the # parameters in the
Loop.
43


(9) Loop integer_expr : The Loop construct is extended to allow a variable expression of type integer. The Loop
statement iterates for the number of times indicated by the evaluation of the expression.
17.2
Pattern Examples

Header {
}
Signals { sig1 In; sig2 In; sig3 In; }
Pattern "needs to be resolved" {
F { sig1=1; }
E sig2 sig1;
If sig1 == 1 {
V { sig3=P; }
}
} // end Pattern
17.3
Vector data constraints - Fixed and Equivalent
Structured test patterns often have signals constrained to have a certain value or waveform during a pattern sequence.
This may be required, for example, for ATPG scan rules checking (such as a test mode signal always active) or for
differential scan or clock inputs. These constructs help reduce pattern volume, as the value of a constraint signal does
not need to be specified explicitly in the pattern data. Also, ATPG rules checking requires signal constraint information as input.
Two new STIL pattern statements are defined:
( LABEL : ) F(ixed) { (cyclized-data)* (non-cyclized-data)* }
The "Fixed" statement is used to define stimulus and/or response fixed for all subsequent vectors, until the end of the
current Pattern or Procedure. Every Procedure starts its own environment, not inheriting Fixed data from its caller.
Upon return from a procedure, the Fixed values of the caller are re-instantiated. Subsequent vectors may redundantly
define the same WaveformCharacter assignments as in the Fixed statements; however, no vector is allowed to define a
WaveformCharacter assignment in contradiction with the Fixed statements in effect. The Fixed pattern statement does
not result in a tester cycle, but constraints and sets values for all following cycles within its scope.
( LABEL : ) E(quivalent) SIG-EXPR-LIST ;
The Equivalent statement is used to define an equivalence relationship between two or more signals. Equivalence
implies that the signals are assigned the same WaveformCharacter. Additionally, a signal or signal expression is
optionally preceded by \m to indicate that the WaveformCharacter is to be mapped before the equivalence is applied.
All signal expressions in sig-expr-LIST shall have the same number of signals; the first signals of the signal expression are equivalent, the second signals of all signal expressions are also equivalent, etc. The scope of these equivalences extends for all subsequent vectors, until the end of the current Pattern or Procedure. Vectors may assign
WaveformCharacters to any non-empty subset of equivalent signals and the equivalence relationship extends the
assignment to the other signals in the equivalence class. For example, in:
Header {
}
Signals {
44


SIG_NAME1 In; SIG_NAME2 In;
a[15..0] InOut; b_low[7..0] InOut; b_high[15..8] InOut;
} // end Signals
Signalgroups {
b = b_high+b_low {
WFCMap {
0->1; 1->0; Z->Z; N->N; L->H; H->L; l->h; h->l; T->T; X->X;
} // end WFCMap
} // end b
/* SIG_NAME1 and SIG_NAME2 have the same WaveformCharacter; assigning a WaveformCharacter to one of
these signals is equivalent to assigning values to both signals. */
Pattern pat1 {
Equivalent SIG_NAME1 SIG_NAME2;
} // end Pattern
/* A more complex example is of two buses of bidirectional signals that are complementary both as inputs and as outputs: */
Pattern pat2 {
Equivalent a \m b;
V { a[15..0]=0; b[8]=H; } // implies also: b_low[0]=1; a[8]=L;
}
Every Procedure starts its own environment, not inheriting Equivalent data from its caller. Upon return from a procedure, the Equivalent values of the caller are re-instantiated. Subsequent vectors may redundantly define the same
WaveformCharacter assignments as in the Equivalent statements; however, no vector is allowed to define a WaveformCharacter assignment in contradiction with the Equivalent statements in effect. The Equivalent pattern statement
does not result in a tester cycle, but constraints and sets values for all following cycles within its scope.
17.4
X (cross reference) statement
The X (Cross-Reference) statement may be used to tag, as well as refer to, positions within a STIL Pattern block as
being important cross-reference points. Any vector may be preceded by an X statement, thereby associating that vector to the given cross-reference tag. Unlike Labels, the cross-reference tag may be identical on multiple vectors.
This supports the case where a single complex STIL vector is translated to multiple tester vectors.
One application of the X statement is to provide fail data feedback as a mechanism for failure diagnosis. For this, the
X statement is used in two contexts. First, the STIL pattern block is augmented with X statements to tag key vectors
during test generation. Secondly, the failures collected, when applying the patterns at the tester, are logged and then
converted into a STIL failure file. This failure file will contain X statement cross-references to correlate the failures
back to the vectors tagged in the original STIL file during test generation. For further details see annex N.
The X statement has two forms. The simple statement form shall be used to convey or refer to a cross-reference tag.
The block form shall be used to refer to a cross-reference tag and to convey offset information relative to that crossreference as well as the number of iterations that have occurred for the following vector being referenced.
Question: The following needs review by WG:
There is an implied hierarchy for X statements from the mainline STIL patterns to the
procedures/macros. This is realized by the concatenation of the "tag" of the current X
statement to that of the calling blocks (i.e. mainline STIL file or procedure or macro block) current X statement
value. I think we would
45


want to define some concatenation character such as ":" or ".".
Consider the following example STIL pattern file.
Procedures {
Proc1 {
...
X "Proc1-001";
V {...}
X "Proc1-002";
V {...}
...
}
Proc 2 {
...
X "Proc2-001";
Call Proc1;
...
}
Pattern ABC {
...
X "ABC-001";
Call Proc2;
X "ABC-002";
Call Proc2;
...
}
So any fail feedback file would identify the failures using the implied hierarchy:
Pattern ABC {
Proc1 {
X "ABC-001:Proc2-001:Proc1-001";
V {...}
// failed on call Proc2 following the "ABC-001" X statement
X "ABC-002:Proc2-001:Proc1-002"l
V {...}
// failed on call Proc2 following the "ABC-002" X statement
(failed 2nd vector in Proc1)
}
17.5
X Statement Syntax examples
The following are examples of X statement usage:

Header {
}
Signals {
pi In { ScanIn; }
po Out { ScanOut; }
so3 Out;
46


failpin Out;
clk In;
refpin In;
sb[1..8] InOut;
} // end Signals
SignalGroups {
sigbus = sb[1..8;
Pattern pat {
// Mark a parallel vector within a STIL pattern block
// with a cross-reference tag
X vec100058;
V {pi=11001101110; po=HLLLHHZZXHHLLXXZ;}
// Refer to the above vector failing an L state
// for a particular signal on a bus
X vec100058;
V {sigbus[8]=L;}
// Refer to an IDDQ failure
X iddq5; // identifies the fail immediately following
V { }
// there are no signal fails, since this is IDDq meas
// Mark call to a procedure which does an unload of scan data
X unload_058;
Call load_unload { so3=XXXHLHH; }
// Refer to a failure on a signal 5 vectors into the unload procedure
X unload_058 {Offset 4;}
V { so3=H; }
// Refer to a failure 10 vectors into a pattern block
// containing no X statements
X { Offset 9; }
V{ failpin=H; }
// a position 4 vectors after a Cross Reference sim1 at an unknown state
X sim1 {Offset 3; }
V { failpin=X; }
// Mark the beginning of a nested loop construct
X bist_33;
Loop 230 {
V { clk=P; }
Loop 5000 {
X inner_bist_33;
V { refpin=H; }
} // end Loop 5000
} // end Loop 230
// Refer to a fail on the 2nd iteration of the outer loop
// and the 4th iteration of the inner loop
47


X inner_bist_33 { Iteration 5004; }
V { refpin=L; }
} // end Pattern
17.6
Loop Data and Shift statements
The Loop Data and the Shift statements perform similar functions - the will loop over a sequence of pattern statements; they may be used only in procedures or macros; they take parameters from the calling pattern statements and
apply the parameters to signals; they take signal-variable data and apply it to signals. The difference between the Shift
and Loop Data is that the Shift is specifically designed in support of scan load/unload operations, whereas Loop Data
is a general construct for providing data-dependent loops. The following rules further identify the differences:
1.
Within a Shift block, the parameters to be shifted shall be determined by the presence of a ScanIn or
ScanOut attribute in the Signal or SignalGroups block. This is as opposed to implying the shift from the
presence of # characters.
2.
Foreach ScanIn/ScanOut signal within a Shift block, the shift data can be defined in two ways: a) a
parameter defined by # notation; b) an in-line series of wfcs
3.
Within a Loop Data construct at least one WaveformCharacter assignment inside this Loop shall contain
a # for the waveform-character.
4.
The loop size for a Shift block is determined by the length of the longest scan chain.
5.
The loop size for a Loop Data is determined by the length of the longest parameter.
6.
Padding rules are the same for both Shift and Loop Data.
The following is an example of Loop Data and Shift:

Header {
}
Signals {
sig1 In;
si1 In { ScanIn 14; }
si5 In ( ScanIn 17; }
ABC SignalVariable;
DEF SignalVariable;
XYZ[1..20] SignalVariable;
} // end Signals
Procedures all {
variable_loop {
Loop Data { V { sig1=#; }}
} // end variable_loop
shift_load {
C ( si1+si2+si3+si4+si5+si6 = 000000; }
Shift {
48


V {
si1 =
si2 =
si3 =
si4 =
si5 =
si6 =
} // end V
} // end Shift
) // end shift_load
} // end Procedures
10101 ABC 10101;

10101 ABC DEF 10101;
10101 XYZ[1] 10101;
10101 XYZ[11..20] 10101;
\w10101 ABC \w10101;
10101 ABC DEF 10101;
Pattern run1 {
Call variable_loop { sig1=010; }
Call variable_loop { sig1=00000; }
} // end Pattern
// ABC is a SignalVariable
// ABD, DEF are two SignalVariables
// with indexed SignalVariable
// with multi-bits of a SignalVariable
// illegal
// illegal
// Loop 3 times (010 is wfc-list)

// Loop 5 times
Pattern run2 {
Call shift_load {
ABC=1100;
XYZ[1..20]=11111000001111100000;
DEF=101;
} // end Call
} // end Pattern
17.7
Loop Statement Using an Integer Expression
The Loop statement as defined in STIL0 is extended to allow the use of integer expressions. This extension applies to
clause 22.6 "Loop statement" and to clause 22.7 "MatchLoop statement". The following are example of this usage:
Header {
}
Variables {
count Integer { InitialValue 100; }
}
Signals { clk In; a[1..8] In; b[1..8] Out; }
SignalGroups {
some_pins = a[1..8]+b[1..8];
Procedures {
proc1 {
C { count = #; clk=0; some_pins=\r8 0 \r8 X; }
Loop count { V { clk = P; } }
V { some_pins = 11110000 HHHHLLLL; }
} // end proc1
} // end Procedures
Pattern pat1 {
Call proc1 { count=200; }
} // end Pattern pat1
49

18. Procedure and macro data substitution - Extensions to STIL0

clause 24.5
All constructs and definitions of IEEE Std. 1450-1999 clause 24.5 remain in effect, with the additional capability to
pass data through nested procedure and macro calls with the following restrictions:
Data passed from one procedure or macro, into another procedure or macro, shall use the same argument name to
reference that data, as was used to specify that data to that procedure. Data cannot be passed into another procedure or macro call using a different signal or groupname on that data than was used to pass that data into the procedure.
Data passed into another procedure or macro is considered to consume all data values passed into the procedure,
in that procedure or macro call. The procedure or macro calling another procedure or macro shall not reference
the parameters passed to that called procedure or macro directly, except to pass them to the called procedure or
macro.
An example of a proper environment to pass data through procedure or macro calls is:
Header {
Ann {* clause 18 *}
}
Signals {
scansig In { ScanIn; }
ins[1..5] In;
clk In;
scanmode In;
} // end Signals
SignalGroups {
_ins = ins[1..5];
Procedures {
do_shift {
Shift { V { scansig = #; clk = P; }}
}
setup_and_shift {
C { _ins = #####; }
V { clk = 0; scanmode = 1; }
do_shift { scansig = #; }
} // end do_shift
}// end Procedures
Pattern "run_shifts" {
Call setup_and_shift { _ins = 00101; scansig = 010001010100; }
} // end Pattern
19.
Environment block
The Environment block contains constructs to cross-reference STIL information with other environments, for example a simulation or layout netlist environment. The Environment block may be used by tools that operate in the specified Environment and access STIL data. The Environment block may also contain additional information specific for
the particular environment.
50


Because the Environment block references information not contained in the STIL environment, no STIL blocks reference the Environment block. The Environment block is self-contained, but internally may reference other STIL
blocks as necessary to associate STIL information with the external context.
The Environment block contains additional blocks that have not been defined and that do not need to be declared
(with a UserKeywords statement) before they appear in the Environment block. These undeclared blocks are allowed
with the same restrictions as a UserKeyword block. It is expected that the definition of these undeclared blocks is
found in association with an extension definition. See clause 8 on page 20 for extension reference constructs. These
blocks, when present, shall follow all STIL syntax requirements for UserKeyword blocks. These blocks contain information specific to an Environment context (in STIL syntax form).
19.1
Environment Syntax
Environment (ENV_NAME) {
( InheritEnvironment ENV_NAME ; )*
( NameMaps (MAP_NAME) {
InheritNameMap ENV_NAME(.MAP_NAME) ;
( ScanCells { (CELLNAME MAP_STRING; )* } )*
( Signals { (SIG_NAME MAP_STRING; )* } )*
( SignalGroups (DOMAIN_NAME) { (GROUP_NAME MAP_STRING; )* } )*
( Variable { (VAR_NAME MAP_STRING; )* } )*
( AllNames { (ANY_NAME MAP_STRING; )* } )*
} )* // end NameMaps
( FileReference FILE_PATH_NAME; )*
( FileReference FILE_PATH_NAME {
Type file_type ;
Format file_format ;
Version VERSION_NUMBER ;
} )* // end FileReference
(ENVIRONMENT_DEFINED_STATEMENTS)*
// end Environment
(1)
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9)
(10)
(11)
(1) Environment: Defines an Environment block.

ENV_NAME: Optional name of the Environment block. A single global Environment block may be defined
without a name.
(2) InheritEnvironment ENV_NAME: Statement to reference a previously-defined Environment block, to

incorporate the definitions of that block as part of this block. Only statements with defined keywords are inherited,
that is: SignalGroups, NameMaps, and FileReference statements or blocks. See the InheritNameMap statement for
information on how NameMaps are inherited. If a FileReference block has the same name locally as an inherited
FileReference, the local definition will be used. ENVIRONMENT_DEFINED_STATEMENTS are not inherited.
(3) NameMaps (MAP_NAME): Defines one or more blocks containing references of STIL names to names defined in
an external Environment. The MAP_NAME is optional when a single NameMaps block is present; the MAP_NAME is
required if multiple NameMaps blocks are present. The MAP_NAME shall be unique across all NameMaps blocks in a
single environment when present.
(4) InheritNameMap ENV_NAME(.MAP_NAME): Statement to reference a previously-defined NameMaps block
inside a previously-defined Environment block, to incorporate the definitions of the NameMaps section of that block
only as part of this block. If an unnamed NameMaps block is referenced, then only the ENV_NAME is required to
reference that NameMaps block. If the referenced NameMaps block has a name, then a complete dotted name of the
ENV_NAME.MAP_NAME is required to reference that NameMaps block. A local definition of a CELLNAME,
SIG_NAME, GROUP_NAME, VAR_NAME, or ANY_NAME will override any inherited definitions for those names.
51


(5) ScanCells: Block to contain ScanCell references. Required if CELLNAME map information is provided.
MAP_STRING: Statement to map the STIL CELLNAME defined in a ScanCells block under
ScanStructures ScanChain, into the name used in the external Environment. All scancell names are defined under a
single namespace; a reference to a specific ScanStructures block is not necessary to resolve these names.
CELLNAME
(6) Signals: Required if SIG_NAME map information is provided.

SIG_NAME MAP_STRING: Statement to map the STIL SIG_NAME defined in a Signals block, into the name
used in the external Environment.
(7) SignalGroups: Required if GROUP_NAME map information is provided.

GROUP_NAME MAP_STRING: Statement to map the STIL GROUP_NAME defined in a SignalGroups block,
into the name used in the external Environment.
(8) Variable: Required if VAR_NAME map information is provided.

VAR_NAME MAP_STRING: Statement to map the STIL VAR_NAME defined in a Category or Spec block, into
the name used in the external Environment.
(9) AllNames: This optional block supports an Environment that does not partition namespaces with the same
structure as STIL, and supports mapping of names from additional STIL constructs (such as objects in user-defined
blocks).
ANY_NAME MAP_STRING: Statement to map any STIL NAME, into the name used in the external
Environment.
(10) FileReference FILE_PATH_NAME: The FileReference statement is used within an Environment block to specify
various other files associated information. The content and application of the referenced files is not specified in STIL,
but is the responsibility of the tool or application using the Environment block. For instance, if the patterns are in
STIL then they would be Included, but if the patterns were in WGL or some tester-specific format, this mechanism
would be used to reference that data.
(11) Type file_type: Specifies the type of this file. The file type shall be one of the specified types, or else User
followed by the user type name.
(12) Format file_format: Specifies the format of this file type. The file format shall be one of the specified formats for
the associated type, or else User followed by the user type name.
(13) Version VERSION_NUMBER: A quoted string identifying the version of this file. The format and information
of the VERSION_NUMBER is dependent on the file type and format, and not defined here.
(14) ENVIRONMENT_DEFINED_STATEMENTS: These are semicolon-terminated or braced statements that follow the
STIL requirements, but do not require a UserKeyword statement to identify these blocks. The environment defined
statement and semantics associate with the specification for the extension as identified in the STIL {} block.
19.2
"MAP_STRING" Syntax
The target "MAP_STRING" is used to map STIL names into an external environment. If the target name contains
either a double-quote or a back-slash, then the following syntax shall be used in the target string. It is an error for any
character other than double-quote or back-slash to following a single back-slash.
double-quote: "blah_blah\"blah_blah"
back-slash: "blah_blah\\blah_blah"
52


error:
"blah_blah\blah_blah"
A typical useage of this back-slash notation is in mapping strings into Verilog names. The following is an example of
this transformation:
MAP_STRING in STIL = "\\\"abc[15] "
Verilog string
= "\"abc[15] "
Note1: Per 1450-1999 definition, the double-quote character is NOT allowed in a STIL string.
Note2: In the above examples, the outer double-quotes are not part of the name, whereas the inner double-quote is
part of the name. The outer double-quotes are delimiters in both STIL and Verilog representations.
19.3
Environment Example

Header {
}
/* The following code is borrowed from 1450.6. Since it is within the Environment block it is also acceptable syntax
for 1450.1, although only a CTL parser would know how to interpret the syntax. */
Environment chip_internal {
CTL {
InternalSignals CoreA {
A0 In; A1 In; A2 In; Z0 Out; Z1 Out; Z2 Out;
}
InternalSignals CoreB {
a0 In; a1 In; d0 In; d1 In; z0 Out; q0 Out; q1 Out;
}
Internal {
B1 { IsConnected In InternalSignal CoreA A0;
IsConnected In InternalSignal CoreB a0;
IsEnabledBy In Signal B2 ForceUp;}
B4 { IsConnected In InternalSignal CoreA.A1;
IsConnected In InternalSignal CoreB a1;
Y0 { IsConnected Out InternalSignal CoreA Z0;
IsEnabledBy Out Signal B0 ForceDown;}
Y1 { IsConnected Out InternalSignal CoreA Z1 Invert;}
}
ScanInternal chipChain {
s0 { IsConnected In InternalSignal CoreB d0;
s1 { IsConnected In InternalSignal CoreB d1; }
s2 { IsConnected Out InternalSignal CoreB q0; }
s3 { IsConnected Out InternalSignal CoreB q1; }
}
}
19.4
NameMaps Example
The NameMaps block relates STIL names to external environments. An example of an application of this construct,
53


for a Verilog-style environment, is shown below.
module top_test;// Testbench Module
integer pattern;
wire [0:2] PO; // Primary Outputs Vector
reg [0:3] PI;// Primary Inputs Vector
wire A, B1, C1, D11, Q11, Q21;// Signals
assign A = PI[0], B1 = PI[1], C1 = PI[2], D11 = PI[3];
assign PO[0] = Q11, PO[1] = Q21;
// Design Instance
top dut (.A(A),.B1(B1),.C1(C1),.D11(D11),.Q11(Q11),.Q21(Q21));
endmodule
Figure 3Verilog Testbench Example for NameMaps

Header {
}
Signals { "A" In; "B1" In; "C1" In; "D1" In; }
SignalGroups { _pi = "A" + "B1" + "C1" + "D1" ; }
Environment my_verilog_testbench {
NameMaps vector_associations {
Signals {
"A" "top_test.PI[0]";
"B1" "top_test.PI[1]";
"C1" "top_test.PI[2]";
"D1" "top_test.PI[3]";
}
SignalGroups {
_pi "top_test.PI";
_po "top_test.PO";
}
Variable { _patcount "pattern"; }
} // end NameMaps
NameMaps wire_associations {
Signals {
"A" "top_test.A";
"B1" "top_test.B1";
"C1" "top_test.C1";
"D1" "top_test.D1";
}
SignalGroups {
_pi "top_test.PI";
_po "top_test.PO";
}
Variable { _patcount "pattern"; }
} // end NameMaps
54

20.
BistStructures block (to be removed from the document?)
The BistStructures block allows CAD tools (such as ATPG and simulators) to check BIST-related design rules (such
as X-propagation) and to compute BIST signatures. The simulation of BIST functions is very efficient because the
internal gates of the BIST registers do not need to be simulated once the function of the BIST register and its connections are known to the simulator.
20.1
Syntax Definition
BistStructures (BIST_NAME) {
( BistRegister BISTREGNAME {
Usage < PatternGenerator | SignatureAnalyzer | CircularBIST >;
Type < LFSRInternal | LFSRExternal | CA >;
Length integer_expr;
( BistClock SIGNAL_NAME; )
( TapPositions integer_list; )
( TapPositions {
Positions integer_list;
TapFrom integer_list;
} )* // end TapPositions
( Connection (!) SIGNAL_NAME integer_list; )*
( Seed integer_expr; )
( ScanChains (SCAN_CHAIN_NAME)+ ; )
( EndState integer_expr; )
( NextstateOffset integer_expr; )
( FirststateOffset integer_expr; )
} )*
// end BistRegister
( BistLength integer_expr; )
( BistcycleLength integer_expr; )
( CaptureCycles integer_expr; )
// end BistStructures
(1)
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9)
(10)
(11)
(12)
(13)
(14)
(15)
(16)
(1) BistStructures: Block to define BIST structures i.e., a group of BistRegisters that operate in parallel, and their
common attributes.
BIST_NAME: Optional name of this BistStructures block. Required if multiple BistStructures blocks are defined.
(2) BistRegister: Block to define a single BIST register. Multiple BIST registers may be defined in the
BistStructures block. BISTREGNAME is a unique name associated to each BIST register definition.
(3) Usage: Identifies the nature of the BIST register: PatternGenerator for a pseudo-random pattern generator,
SignatureAnalyzer for a signature register, CircularBIST for both (circular BIST).
(4) Type: Identifies how the cells of BIST register are connected to perform their function: LFSRInternal and
LFSRExternal for linear-feedback shift registers with the XOR gates between the cells (instream) and outside the
cells (out of stream) respectively; CA for cellular automata BIST register.
(5) Length: Identifies the number of bits the BIST register has.
(6) BistClock: Identifies the signal which advances the BIST register to its next value. This signal is a functional, not
a scan clock.
(7) TapPositions: Identifies how the cells of the BIST register are connected to each other. The first format applies to
all bits of the BIST register and identifies which bit positions are XORed to form the tapped input. In the second
format, Positions integer_list indicates to which bits of the BIST register TapFrom integer_list applies. Refer to See
clause 6.5 on page 14 for definition of integer_list.
55


For LFSR-type BIST registers, the integer_list is a list of non-negative integer positions, 0 being the bit that is
shifted out first (the bit at the opposite end as the XOR in a LFSRExternal-type input BIST register.) For
LFSRInternal BIST register integer_list indicates cells whose output is XORed with the feedback of cell 0 and
input to the neighboring cell. In a LFSRInternal BIST register the output of cell 0 is always input to cell Length-1.
For LFSRExternal BIST register integer_list indicates cells whose outputs are XORed to provide the feedback into
cell Length-1.
For CA-type BIST registers, the integer_list is a list of integer positions, 0 being the current cell, -1 its nearest,
more significant neighbor and +1 its nearest, less significant neighbor, such as neighbor -1 shifts out before cell 0,
which shifts out before neighbor +1. The cells identified by integer_list are XORed and the result is input to cell 0
(current cell).
More than one TapPositions entry is allowed only if all entries are of the second format.
(8) Connection: Identifies a connection between bits of the BIST register and a signal. For a BIST register of type
PatternGenerator, if integer_list includes more than one position, all positions are XORed and connected to the given
signal. For a SignatureAnalyzer BIST register, the indicated signal fans out to all positions in integer_list; if more
than one signal thus connect to the same position, all signals are XORed and connected to the given position. Any
connection to/from a signal may be optionally inverted. Any number of Connection constructs may be included for a
BistRegister. The order of Connection statements should not be changed because it may represent a sequence of
connections in a BIST environment.
(9) Seed: Optional field identifying the initial value of the BIST register. If not given, the initial value is considered 0
for all bits.
(10) BistCells: This statement references the name of a scan-chain that defines the list of scan-cells comprising this
BistRegister. The scan-chain shall contain a list of cells equal to the number defined in the Length statement.
BistRegister, the cells are ordered: Length-1, Length-2, ..., 0.
(11) EndState: Optional field identifying the final value of the BIST register.
(12) NextstateOffset: Optional field identifying the offstate of the BIST register after BistcycleLength cycles. If not
given, the BIST register is considered to continue cycling i.e., the default NextstateOffset offset is BistcycleLength.
However, in some BIST architectures, after BistcycleLength cycles, the BIST register is moved back. For example,
NextstateOffset 0 implies that every BistcycleLength cycles the BIST register is reset to its Seed value;
NextstateOffset 1 implies that every BistcycleLength cycles the BIST register is moved back to its value
BistcycleLength-1 cycles ago.
(13) FirststateOffset: Optional field identifying the offstate of the BIST register after the first BistcycleLength
cycles. If not given, the BIST register is considered to start clocking as soon as the first BIST cycle i.e., the default
FirststateOffset offset is BistcycleLength. For example, FirststateOffset 0 implies that the BIST register has the value
Seed after the first BistcycleLength cycles. If both FirststateOffset and NextstateOffset are given and they differ, then
FirststateOffset takes precedence over NextstateOffset at the end of the first BistcycleLength cycles.
(14) BistLength: Optional field identifying the total number of clock cycles BIST is run for.
(15) BistcycleLength: Optional field identifying the number of cycles the BIST register is run during each BIST
pattern. For example, a logic-BIST architecture may require BistcycleLength cycles to load the scan chains and pulse
capture clocks. All inputs to a SignatureAnalyzer BistRegister are considered to be 0 for the first BistcycleLength
cycles; in a logic-BIST architecture the scan chains are loaded for the first time during this time.
(16) CaptureCycles: Optional field identifying the number of capture cycles between a load and an unload in a logicBIST architecture. The default value is 0, i.e., the BIST register is not clocked during capture cycles (if any). Scan
chain loads thus require BistcycleLength-CaptureCycles cycles.
56

20.2
BIST Structures Example
The example defines a BIST registers: "cella_prpg" used as pattern generator. The register is an array of cellular
automata (Type CA). The Length field specifies the number of bits and the Seed specifies the initial value. The TapPositions fields describe the structure of the BIST register: For CAs, the tabs are relative to the current cell (cell 0),
thus "cella_prpg" has the odd bits (1, 3, 5, ...) connected to their two nearest neighbors and to themselves (-1, 0, 1).
Meanwhile, the even bits (0, 2, 4, ...) are only connected to their nearest neighbors (-1, 1). The Clock field declares
the signal ck1 that advances the BIST register. The Connection fields list the connections of BIST register bit cells to
points in the netlist. Bits 0, 1 and 2 are XORed and connected to prpg_sig1; bit 4 is connected to prpg_sig2,
etc.
Header {
}
Signals {
prpg_sig1 Pseudo; prpg_sig2 Pseudo; prpg_sig3 Pseudo;
prpg_sig4 Pseudo;
} // end Signals
BistStructures {
BistRegister cella_prpg {
Usage PatternGenerator;
Type CA;
Length 27;
TapPositions {
Positions 1, 3, 5, 7, 9, 11, 13, 15, 17, 19, 21, 23, 25;
TapFrom -1, 0, 1;
}
TapPositions {
Positions 0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26;
TapFrom -1, 1;
}
Connection prpg_sig1 0..2;
Connection prpg_sig2 4;
Seed \h7FF_FFFF;
} // end BistRegister
} // end BistStructures
20.3
Logic BIST Example
The example below shows a STUMPS logic-BIST architecture. The PRPG-LFSR, implementing the polynomial
4
f ( x ) = x + x + 1, and the phase shifter are from [1] page 176. The MISR-LFSR implements the polynomial
4
f ( x ) = x + x + 1 and is from [1] page 119. The compactor shown is ad-hoc.
57

PRPG
LFSR
si0
si1
si2
si3
si4
si5
so0 scan chain
so1 scan chain
so2 scan chain
so3 scan chain
so4 scan chain
so5 scan chain
phaseshifter
design tested
compactor
MISR LFSR
Figure 4STUMPS Architecture

The description of this logic-BIST architecture is shown below:
Header {
}
Signals {
58


si0
si3
so0
so3
Pseudo
Pseudo
Pseudo
Pseudo
{
{
{
{
ScanIn } si1 Pseudo { ScanIn }

ScanIn } si4 Pseudo { ScanIn }
ScanOut } so1 Pseudo { ScanOut
ScanOut } so4 Pseudo { ScanOut
si2 Pseudo {
si5 Pseudo {
} so2 Pseudo
} so5 Pseudo
ScanIn }
ScanIn }
{ ScanOut }
{ ScanOut }
}
ScanStructures {
ScanChain c0 {
ScanChain c1 {
ScanChain c2 {
ScanChain c3 {
ScanChain c4 {
ScanChain c5 {
}
ScanIn
ScanIn
ScanIn
ScanIn
ScanIn
ScanIn
si0;
si1;
si2;
si3;
si4;
si5;
ScanOut
ScanOut
ScanOut
ScanOut
ScanOut
ScanOut
so0;
so1;
so2;
so3;
so4;
so5;
}
}
}
}
}
}
BistStructures {
BistRegister prpg {
Usage PatternGenerator;
Type LFSRExternal;
Length 4;
TapPositions 0 1;
Connection si0 3;
Connection si1 0 1 3;
Connection si2 1..3;
Connection si3 0;
Connection si4 0 1;
Connection si5 0 2;
BistClock bclk;
}
BistRegister misr {
Usage SignatureAnalyzer;
Type LFSRInternal;
Length 4;
TapPositions 3;
Connection so0 3;
Connection so1 2;
Connection so2 1 2;
Connection so3 1;
Connection so4 0;
Connection so5 0;
BistClock bclk;
}
CaptureCycles 1;
}
// The following procedures outline the function of this logic BIST system:
Procedures {
bist_load_unload { // shift internal channels
W bist_waveform_table;
Loop 500 { // longest scan chain is 500
V { bclk = P; } // pulse bclk (waveform for P not shown)
}
}
load_unload { // shift prpg and misr
59


W shift_waveform_table;
Shift {
V { lfsr_scanin=#; lfsr_scanout=#; lfsr_clk=P; }
}
}
}
Pattern bist_pat {
W bist_waveform_table;
Call load_unload { lfsr_scanin=010100101; } // seed prpg and misr
Loop 1000 { // 1000 bist patterns
Call bist_load_unload; // load internal scan chains from prpg
V { ck1 = P; } // capture clock
}
Call load_unload { lfsr_scanout=00011001; } // check misr signature
}
[1] P. H. Bardell, W. H. McAnney, J. Savir, Built-In Test for VLSI: Pseudorandom Techniques, John
Wiley & Sons, 1987.
20.4
BistStructure-ScanStructure Interaction Example
Commonly, BIST registers will also be connected and accessed as a scan chain, to support observability and controllability operations. The BistCell statement of the BistStructure block is used to identify the relationship of the BIST
registers to the ScanStructure block. This is shown in the example below, which references only the LFSR and MISR
registers of the previous example, and identifies only the scanchain connection for these elements.
PRPG
LFSR
B1_si
L3
L2
L1
B1_so
L0
design tested
MISR LFSR
B2_so
M3
B2_so
M2
M1
M0
Figure 5Scanchains in the BIST sequential elements
60


Header {
}
ScanStructures {
ScanChain prpg {
ScanIn B1_si; ScanOut B1_so;
ScanCells L3 L2 L1 L0;
}
ScanChain misr {
ScanIn B2_si; ScanOut B2_so;
ScanCells M3 M2 M1 M0;
}
}
BistStructures {
BistRegister prpg {
BistCells L3 L2 L1 L0;
}
BistRegister misr {
BistCells M3 M2 M1 M0;
}
}
61

Annex A
Glossary (informative)
The following terms and definitions are used within the context of this standard: in this document.
A.1
boolean_expr: (A) A metatype used to present language constructs. (B) A reference to an logic expression
that evaluates to a boolean - True or False. See clause 6.2 on page 12.
A.2
cellname_list: (A) A metatype used to present language constructs. (B) A reference to a an expression containing internal cell names. See clause 6.3 on page 12.
A.3
False: The value 0 (zero) or a negative value returned from the evaluation of a boolean expression.
A.4
integer_expr: (A) A metatype used to present language constructs. (B) A reference to an logic expression
that evaluates to an integer value. See clause 6.4 on page 13.
A.5
integer_list: A list of space separated integers, or pairs of integers separated by the ".." operator. See See
clause 6.5 on page 14. See clause 6.5 on page 14.
A.6
logical_expr: (A) A metatype used to present language constructs. (B) A reference to a an expression containing Signals, SignalGroups, Variables, and Enumerations. See clause 6.6 on page 14.
A.7
sigvar_expr: (A) A metatype used to present language constructs. (B) A reference to a an expression containing WaveformCharacter lists. See clause 6.8 on page 16.
A.8
True: A non-zero positive value returned from the evaluation of a boolean expression.
A.9
WaveformCharacter: A single alphanumeric character representing a reference to a Waveform defined in
the current WaveformTable.
A.10
WaveformCharacter list: A list or series of alphanumeric characters, each character representing a reference to a Waveform defined in the current WaveformTable.
62

Signal Mapping Using SignalVariables (informative)
Annex B
B.1
Example of parameter passing to Macros (or Procedures)
STIL defines a mechanism for passing multiple bit data from a vector to a WaveformTable (see IEEE Std. 1450-1999
clause 21.2). Using pattern expressions, the same parameter passing mechanism also can be applied to the parameters
to a Macro or a Procedure. An example of this is:
Header {
Ann {* clause B.1 *}
}
Signals {
sig[1..5] In;
}
SignalGroup {
grp = sig[1..5];
p1 SignalVariable { Length 5; }
}
MacroDefs
m1 {
C {
V {
V {
V {
}
}
{
p1 = #; p2
grp = p1
grp = p2
grp = p3
=
;
;
;
#; p3 = #; }
}
}
}
Pattern p1 {
Macro m1 { p1=11111; p2=00000; p3=11111; }
Macro m1 { p1=00000; p2=11111; p3=00000; }
}
B.2
Parameter passing with signal mapping
Vector data is passed from vectors to Macros or Procedures by means of signal group oriented strings of waveform
characters. A new capability in MacroDefs or Procedures allows the waveform characters from the parameters to be
mapped onto other signal groups as required by the core test design interface. An example of a vector data expression
is:
Header {
Ann {* clause B.2 *}
}
Signals {
x[0..27] InOut;
}
SignalGroups {
63


xbus = x[0..27];
p1[0..13] SignalVariable;
p2[0..13] SignalVariable;
}
MacroDefs {
m2 {
C {p1[0..13] = #; P2[0..13] = #; }
V {xbus = p1[0..6] 1010HLHLXXXXXX p1[7..13];}
V {xbus = p2[0..6] 0000XXXXHLHLXX p2[7..13];}
V {xbus = p1[0..13] p2[0..13];}
}
}
Pattern p2 {
Macro m2 {p1[0..13]=1111111XXXXXXX; p2[0..13]=0000000LLLLLLL;}
Macro m2 {p1[0..13]=1111000XXXXXXX; p2[0..13]=0000111HHHHLLL;}
}
B.3
1.
2.
3.
4.
5.
6.
A more complete example of parameters and signal variable expressions

definition of SignalVariables in a SignalGroups block
use of parameters in a Macro (or Procedure call)
use of # to update the parameter values
application of parameters in a Macro (or Procedure)
use of logic expressions (logic_expr) with signal variables in a Macro (or Procedure)
process of re-using signal groups (un-mapped) as signal variables (mapped)
Top
sig_aa[1]
sig_aa[2]
sig_aa[3]
sig_aa[4]
sig_aa[5]
sig_a[1]
sig_a[2]
sig_a[3]
sig_a[4]
sig_a[5]
sig_bb[1]
sig_bb[2]
sig_bb[3]
sig_bb[4]
sig_bb[5]
sig_b[1]
sig_b[2]
sig_b[3]
sig_b[4]
sig_b[5]
Sub-module
sig_cd
sig_c[1]
sig_c[2]
sig_c[3]
sig_c[4]
sig_c[5]
sig_d
Figure 6Mapping of Signals of a Sub-Module

===================== un-mapped =====================
Header {
Ann {* clause B.3 - un-mapped *}
}
Signals {
64


sig_a[1..5] In;
sig_b[1..5] In;
sig_c[1..5] In;
sig_d In { Length 5; ScanIn; }
}
SignalGroups {
grp_c = 'sig_c[1..5]';
}
MacroDefs {
mac_a {
V { sig_a[1..5] = #; }
V { sig_b[1..5] = #; }
V { grp_c = #; }
Shift {
V { sig_d = #; }
}
}
}
Include pattern.stil;
===================== mapped =====================
Header {
Ann {* clause B.3 - mapped*}
}
Signals {
sig_aa[1..5] In;
sig_bb[1..5] In;
sig_cd In { Length 10; ScanIn; }
}
SignalGroups {
sig_a[1..5]
sig_b[1..5]
grp_c
grp_c[1..5]
sig_d
}
SignalVariable;
SignalVariable;
SignalVariable { Length 5; }
SignalVariable;
SignalVariable { Length 5; }
MacroDefs {
mac_a {
C { sig_a[1..5] = #; sig_b[1..5] = #; grp_c = #; sig_d = #;}
V { sig_aa[1..5] = 'sig_a[1..5]'; }
V { sig_bb[1..5] = 'sig_b[5,3,1,2,4]'; }
//
V { sig_bb[3,4,2,5,1] = 'sig_b[1..5]'; } // alternate stmt
C { grp_c[5,4,3,2,1] = grp_c; }
Shift {
V { sig_cd = 'sig_d[1..5]' 'grp_c[1..5]' ; }
//
V { sig_cd = 'sig_d[1..5]' 00000 ; } // alternate stmt
//
V { sig_cd = 00000 'grp_c[1..5]' ; } // alternate stmt
}
65


}
}
Include pattern.stil;
===================== pattern =====================
Header {
Ann {* clause B.3 - pattern include file *}
}
Pattern pat_a {
Macro mac_a {
sig_a[1..5] = 10101;
sig_b[1..5] = 11011;
grp_c = 01010;
sig_d = 00100;
}
}
66

Annex C
Using Logic Expressions with Signals
This example illustrates the following capabilities:

1.
2.
3.
logic expression using & (and) operation

logic expression made up of signals
application of a logic_expr to define a ScanEnable condition

Header {
Ann {* clause C *}
}
Signals {
sig1 In;
sig2 In;
}
ScanStructures struct1 {
ScanChain chain1 {
ScanLength 10;
ScanCells cell[1..10];
ScanEnable sig1 & sig2;
}
}
67

Annex D
Using Boolean Expressions (boolean_expr) (informative)

1. use of parameters on a Macro (or Procedure)
2. use of logic expression in conditional-If/Else statements in a pattern
3. use of parameters in logic expression to create WaveformCharacter data in a vector
grp_1
sig_1
sig_2
sig_3
sig_4
grp_2
sig[5]
sig[6]
sig[7]
sig[8]
sig[9]
sig[10]
grp_3
sv_1
Figure 7Representation of Signal Groups for a Design

Header {
Ann {* clause D *}
}
Signals {
sig_1 In; sig_2 In; sig_3 In; sig_4 In;
sig[5..10] In;
}
SignalGroups {
grp_1 = sig_1 + sig_2 + sig_3 + sig_4;
grp_2 = sig[5..10];
grp_3 = grp_1 + grp_2;
sv_1 = SignalVariable { Length 4; }
}
Pattern pat_1 {
Macro mac_1 { sig_1 = 1; sig_2 = 0; }
Macro mac_2 { grp_1 = 1100; sv_1 = 0011; }
}
MacroDefs {
mac_1 {
C { sig_1 = #; sig_2 = #; }
If sig_1 == 1 { V { sig_3 = A; }}
If (sig_1 == 1) & (sig_2 == 0) { V { sig_3 = B; }}
}
mac_2 {
C ( grp_1 = #; sv_1 = #; }
If grp_1 == 1100 {
V { grp_3 = sv_1 111111; }
}
Else {
V { grp_3 = sv_1 000000; }
68


}
}
}
69

Annex E Using Variables and Expressions in Algorithmic Patterns

(informative)
1.
Use of Loop Data block.
2.
Using integer logic expression to control looping of patterns.
3.
Using integer logic expressions to create algorithmic data on signals and groups.

Header {
Ann {* clause E *}
}
Variables {
loop_cnt Integer;
h1 Integer;
h2 Integer;
}
Signals {
abus[8..1] In;
bbus[8..1] Out;
clk_a In; clk_b In; clk_c In;
}
SignalGroups {
grp_a = abus[8..1]{ Base Hex LH; }
grp_b = bbus[8..1]{ Base Hex LH; }
clocks = clk_a + clk_b + clk_c;
all_sigs = grp_a + grp_b + clocks;
}
MacroDefs {
mclk_sig {
Loop Data {
V { clk_a = #; clk_b = #; clk_c = #; } // loop until all data consumed on #
}
}
mclk_grp {
Loop Data {
V { clocks = #; } // loop until all data consumed on #
}
}
mloop {
C { loop_cnt = #; }
Loop loop_cnt != 0 {
V { clk_a = P; loop_cnt = loop_cnt-1;}
}
}
mloop2 {
70


C { loop_cnt = #; }
Loop loop_cnt = loop_cnt-1 {
V { clk_a = P;}
}
}
mdata {
C { h1 = #; h2 = #; }
V { grp_a = 00001111; grp_b = 11110000; }
V { grp_a = h1; }
V { grp_b = h2; }
}
} // end MacroDefs
Pattern P1 {
C { all_sigs = X; }
// the following macro call generates 6 vectors
Macro mclk_sig { clk_a = PP0000; clk_b = 00PP00; clk_c = 0000PP; }
Macro mclk_grp { clocks { P00; P00; 0P0; 0P0; 00P; 00P; } }
Macro mclk_grp { clocks { P00P000P00P000P00P; } }
Macro mloop { loop_cnt = 100; }
Macro mloop2 { loop_cnt = 100; }
Macro mdata { h1 = FF; h2 = 0C; }
}
71

Annex F
Chaining Scan Chains with STIL (informative)
This example takes two existing modules with one scan chain each and integrate them at the chip level by creating a
single scan chain. The resulting chip could be a module itself and hence the STIL at the chip level is of special interest.
Chip
Chip_clk
SI12
Chip_SE
C1
si1
se1
C2
so1
abc
ABC
si2
se2
so2
SO12
xyz
XYZ
Figure 8Design chaining two scan chains together

The two modules being integrated are module C1 and module C2 and the final result is Chip12. module C1 has a scan
chain with scanin si1 and scanout so1 that is controlled by the clk1 clock and the scan enable se1. module C1 also has
some broadside inputs abc. module C2 has a similar configuration as module C1 and the naming convention should
be self explanatory.
module C1 comes with STIL to define the operation of the scan chain and the vectors that use the scan chain. For this
example, module C1 has a Macro to operate the scan chain and some patterns that use the macro.
Header {
Ann {* clause F *}
}
Macro_Scan_C1 {
W W1;
C { se1 = 1;}
Shift { V{ si1=#; so1=#; clk1=P;} }
V { abc = #; }
}
Pattern P1 {
Macro_Scan_C1 { si1=101010; so1=LLHHLL; abc=000;}
}
Similarly, module C2 has a macro that operates the scan chain and patterns that use the macro.
Macro_Scan_C2 {
W W2;
C { se2 = 1;}
Shift { V{ si2=#; so2=#; clk2=P;} }
72


V { xyz = #;}
}
Pattern P2 {
Macro_Scan_C2 { si2=1111; so2=LHLH; xyz=101;}
}
At the chip level it is necessary to have a new macro written to operate on the new larger scan chain and reuse the patterns that are in the files that come with the modules. The following is the outcome of the system integration task.
WBoth {
Inh W1;
Inh W2;
}
SignalGroups {
ABC = a+b+c;
XYZ = x+y+z;
}
Include file_P1;
Include file_P2;
MacroDefs D1 {
Macro_Scan_C1 {
W W1;
C { Chip_SE = 1;}
Shift { V {SI12 = \r6%\r6#; SO12 = \r6%\r6# ; Chip_clk=P;}}
V { ABC = #;}
}
}
MacroDefs D2 {
Macro_Scan_C2 {
W W2;
C { Chip_SE = 1;}
Shift { V{SI12 = \r6#\r6%; SO12 = \r6#\r6% ; Chip_clk=P;}}
V { XYZ = #; }
}
}
Pattern Burst {
P1 {MacroDefs D1;}
P2 {MacroDefs D2;}
}
}
F.1
Aliasing Problem:
Let us consider the situation where both modules are the same. That is we only have one set of pattern data.
Macro_Scan_C1 {
W W1;
C { se1 = 1;}
Shift { si1=#; so1=#; clk1=P;}
73


V { abc = abc;}
}
Pattern P1 {
Macro_Scan_C1 { si1=101010; so1=LLHHLL; abc=000;}
}
At the chip level we need to join the two patterns sets of the two instances of the same module.
Include file_P1;
MacroDefs D1 {
Macro_Scan_C1 {
C { Chip_SE = 1;} // Common Scan Enable on the Chip
Shift {
V { SI12 = %%%%%%######; SO12 = ######%%%%%%; Chip_clk = P; }
}
V { ABC = abc;}
}
}
MacroDefs D2 {
Macro_Scan_C1 {
C { Chip_SE = 1;} // Common Scan Enable on the Chip
Shift {
V { SI12 = ######%%%%%%;SO12 = %%%%%%######;Chip_clk = P; }
}
V { XYZ = xyz;}
}
}
Pattern Burst {
// LockStep is satisfied here

// with identical Pattern sets
P1 {MacroDefs D1;}
P1 {MacroDefs D2;}
}
}
74

Annex G
Vector data mapping using \m (informative)
This is and example of the user of the signal mapping operation. Refer to Vector data mapping and joining - \m and
\j on page 40 for the definition of syntax and semantic.
G.1
Use Case #1
Inversion of a signal is a common reason for using the map function. The characteristics of the inverted waveform can
be completely defined in the new waveform definition that is to replaced the one originally called for. The following
is a table of the typical transformation that would caused the waveform inversion:
D -> U
U -> D
L -> H
H -> L
l -> h
h -> l
Z -> N
T -> X
t -> X
N -> N
X -> X
ForceDown -> ForceUp

ForceUp -> ForceDown
CompareLow -> CompareHigh
CompareHigh -> CompareLow
CompareLowWindow -> CompareHighWindow
CompareHighWindow -> CompareLowWindow
ForceOff -> ForceUnknown
CompareOff -> CompareUnknown
CompareOffWindow -> CompareUnknown
ForceUnknown -> ForceUnknown
CompareUnknown -> CompareUnknown
The following example demonstrates this usage:

Header {
Ann {* clause G.1 *}
}
Signal {
A[0..15] In;
B[0..15] Out;
Xsigs[0..15] InOut;
}
SignalGroups { X = Xsigs[0..15; }
Pattern pat {
V { A = 1111000011110000; B = 0000111100001111; }
V { X = A[0..7] \mB[8..15]; }
V { X = A[0..7] XXXX \mA[8..11] XXXX; }
V { X = 11110000 \m1100 1100;
}
G.2
Use Case #2
In certain scan test styles it is necessary to measure the output of the DUTs bidis in one cycle and then drive the same
logical values on the same bidis from the tester in the next cycle, while also turning the internal bidi drivers off. A test
patterns thus has the following format:
(1) load scan chains
(2) force values on primary inputs (all clocks are off, bidis are driven by DUT)
(3) measure primary outputs and bidis (all clocks are off)
75


(4) force values on primary inputs (values are the same as in cycle 2, except the internal bidi drivers are turned off
by de-activating a bidi_control input), force values on bidis (same logical values as measured in previous
cycle)
(5) pulse capture clock
(6) unload scan chains
Turning off the internal bidi drivers in cycle 4 avoids possible contentions that can result in cycle 5 due to capturing
new data into the state elements. A bidi contention arises if the internal driver and the tester drive opposite logical values on the same bidirectional pin. The additional data to be applied on bidis in cycle 4 is redundant (can be computed
from the data of cycle 3.) This test style needs to be supported without adding extra data to the STIL patterns and
without changing the WaveformCharacters in the patterns. Also, ATPG rules checking can verify the correctness of
the patterns (e.g., the internal bidis are turned off in cycle 4) before actually generating test data.
Even if ATPG generated patterns are contention-free on all bidis, both pre- and post-capture (cycle 5) the above protocol may be required for test flows already designed with this protocol or if timing-related glitches that may temporarily cause contention on the bidis are to be avoided.
It is important that the bidi_control input turns off ALL internal bidi drivers in cycle 4 above. Otherwise, a contention-free pattern could be transformed into a pattern with contentions by the very protocol that attempts to avoid bidi
contentions! For example, consider the following example, where BIDI1 and BIDI2 are bidis, and BIDI_CTRL is an
input that, when 0, turns off the internal driver of BIDI1, but not of BIDI2:
ATPG generated, contention-free pattern:
(2) force values on primary inputs and bidis (force BIDI_CTRL=1; BIDI1 = Z; BIDI2 = Z;)
(3) measure primary outputs and bidis (measure BIDI1=L; BIDI2=H;)
(4) pulse capture clock (this has the effect of switching the internal drivers such as now both the BIDI1 and BIDI2
internal drivers are driving 0. There is no contention, because the tester continues to drive Z on both bidis, as
in cycle 2.)
The pattern above will be changed, after it has been generated, to match the LNI protocol:
(2) force values on primary inputs and bidis (force BIDI_CTRL=1; BIDI1 = Z; BIDI2 = Z;)
(3) measure primary outputs and bidis (measure BIDI1=L; BIDI2=H;)
(4) force values on primary inputs (force BIDI_CTRL=0; BIDI1=0; BIDI2=1;)
(5) pulse capture clock (this has the effect of switching the internal drivers such as now both the BIDI1 and BIDI2
internal drivers are driving 0. This causes a contention on BIDI2: its internal driver, not turned off, drives 0
while the tester drives 1, as in cycle 4!)
Example
Header {
Ann {* clause G.2 *}
}
Signals { a In; ck In; bidi_enable In; b Out; q1 InOut; q2 InOut; }
SignalGroups {
_io =q1+q2 {
WFCMap {
L->0; H->1; T->Z; X->N;
76


}
}
}
PatternBurst "_burst_" {
PatList {"_pattern_"}
}
Procedures procdomain {
"capture_sysclk" {
W myWFT; // where all WaveformCharacters are defined
"cycle 2": V { a=#; ck=0; bidi_enable=1; b=X; _io=ZZ ; }
"cycle 3": V { b=#; _io=%%; }
"cycle 4": V { bidi_enable=0; b=X; _io=\m ##; }
"cycle 5": V { ck=P; }
}
}
Pattern "_pattern_" {
W myWFT;
"cycle 1": Call "load_unload" { ... }
Call "capture_sysclk" { a=0; b=H; _io=HL; }
}
In this example, the vectors are labeled to correspond to the cycles above. Cycle 3 uses the arguments passed in for
_io first (HL), then cycle 4 uses them again, this time mapped to (10), which remain in effect for cycle 5 as well.
77

Annex H
Vector data joining using \j (informative)
The Join function allows to have multiple WaveformCharacters against the same signal in one vector. This annex is
an application of this capability. Refer to Vector data mapping and joining - \m and \j on page 40 for details of the
syntax and semantics.
H.1
Example
The following is an example usage of the join function.

Header {
Ann {* clause H.1 *}
}
Signals {
b InOut {
WFCMap {
0x -> k;
// The 2 source WFCs are not order-sensitive.
// The above could also be written as: { x0 -> k; }
}
}
}
PatList {p}
}
Pattern p {
V { b = \j 0; b = \j x; }// Using mapping above, this is: V{b = k;}
V { b = \j 1; } // This is: V{b = 1;}
}
While any signal or signalgroup may be mapped, it is more common to use the \j mapping to control WaveformCharacter assignment to bidirectional (InOut) signals or signalgroups. This enables structuring of STIL patterns using Pro-
Table 9Example of "two data" conditions on an InOut Signal

Force
Measure
0, 1, Z, N
L, H, T
H, T
H, T
cedures, as shown in the example later in this clause.

For instance, take the case where two SignalGroups have a common element in them (signal 'b'):
78


_pi = '...+b';
_po = '...+b';
A procedure may join these two groups in a vector:
proc { cs { V { _pi= \j #; _po= \j #; }}}

Signal 'b' needs to be resolved based on the combinations of WaveformCharacters that may be seen by these two
groups. It might have a WFCMap declaration (in the definition of b), like:
WFCMap { 0x -> 0; 1x -> 1;}

This mechanism provides for the explicit resolution of joined data without creating new combinations of waveforms on-the-fly.
H.2
Usage Example
Consider a design with one input, one output and two bidis, declared as follows:
Header {
Ann {* clause H.2 *}
}
Signals { i In; o Out; b1 InOut; b2 InOut; }
Signalgroups are also defined:
Signalgroups {
"_pi" = 'i + b1 + b2';
"_po" = 'o + b1 + b2';
_io = b1 + b2;
}
Patterns are written out using capture procedures defined as follows:
Procedures {
"capture" {
V { "_pi"=### ; "_po"=###; }
}
}
Consider an automatically-generated (ATPG) test pattern that includes the following cycle:
force_all_pis { i=0; b1=Z; b2=1; }
measure_all_pos ( o=H; b1=H; b2=X; }
In STIL, this would be written as:
Call capture { "_pi"=0Z1; "_po"=HHX; }
Understanding how STIL is interpreted by the consumer of the patterns, the actual arguments are substituted for the
formal arguments # in the body of the procedure, and the signalgroups _pi and _po are expanded to their signals,
resulting in:
79


V { i=0; b1=Z; b2=1; o=H; b1=H; b2=X; }
However, multiple WaveformCharacters assigned to the same signal in a given vector create ambiguity. Thus, the
above vector becomes:
V { i=0; /* b1, b2 ambiguous */ o=H; }
The 1450.1 solution is very simple and general: Provide a mapping to explicitly explain what to do with the two
WaveformCharacter assignments. Thus, the 1450.1 procedure would be written as:
Procedures {
"capture" {
V { "_pi"= \j ### ; "_po"= \j ###; }
}
}
Notice the addition of the "join" modifier \j. The \j refers to the WFCMap mapping table that could be defined as:
SignalGroups {
_pi= ... {
WFCMap {
0X -> 0;
ZL ->
}
}
_po= ... {
WFCMap {
0X -> 0;
ZL ->
}
}
}
1X -> 1; ZX -> Z; NX -> N; // bidi as input

L; ZH -> H; ZT -> T; // bidi as output
1X -> 1; ZX -> Z; NX -> N; // bidi as input

L; ZH -> H; ZT -> T; // bidi as output
This provides an unambiguous interpretation of the above:

Call capture { "_pi"=0Z1; "_po"=HHX; }
to the desired:
force_all_pis { i=0; b1=Z; b2=1; }
measure_all_pos ( o=H; b1=H; b2=X; }
80

Annex I
Block Data Collection (informative)
This annex describes a usage scenario that combines several capabilities defined in this standard to provide complete
support for returning tester information for evaluation or review by CAD tools. While this example is oriented around
returning information for diagnostic applications, this functionality is not constrained to this application. This scenario can also be applied to the general notion of "learn-mode" tester operation, where the test provides the stimulus
only and the response is "learned" by reporting the behavior from testing known-good devices. Integration of the
return values in this mode of operation into a new test program is the responsibility of the CAD environment interpreting the returned data.
To support the return of test values from a STIL test program, several constructs need to be present in the program.
This example assumes a scenario where the desired return information is a subset of both the set of signals in the
design (that is, only one Signal needs to be evaluated), and a subset of the test vector sequence (that is, there is a specific region of the test where this information is needed). This scenario presents the "worst-case" application of these
constructs; see the Note at the end for a discussion about the consequences of generalizing these restrictions.
I.1
Step 1 - Identifying Signals
The set of signals that return response data are identified by defining a new Waveform for those signals. This Waveform contains an "S" or CompareSubstitute event for the region where the value needs to be checked. Typically, the
timing of the S event will coincide with the timing for CompareLow and CompareHigh checks also defined (but may
not be used) for that Signal. For example, if the original waveforms on Signal A1 were defined as:
Header {
Ann {* clause I.1 *}
}
Timing {
WaveformTable A {
Period '20ns';
Waveforms {
A1 { 01X { '14ns' l/h/x; '18ns' X; }}
}
}
}
Then the additional Waveform could be defined as follows:
Timing {
WaveformTable A {
Period '20ns';
Waveforms {
A1 { 01XC { '14ns' l/h/x/s; '18ns' X; }}
}
}
}
If the timing of the compare-low check does not match the timing of the compare-high check, a decision is made on
how to define the timing of the waveform containing the S event. Typically, the S event would be defined in a waveform that defined the overlapping region of both the low strobe and the high strobe, in order to return the correct value
if either of these states was detected during the test execution.
I.2
Step 2 - Identifying Response Waveforms
There may be several Waveforms defined on a Signal that have the same or similar characteristics to the Waveform
81


containing the S event. To support explicit designation of a desired WaveformCharacter to represent a return value
from a waveform containing an S event, the WFCMap construct is used to specify an "inverse mapping" relationship.
This would be specified for this context on Signal A1 as:
Header {
}
Signals {
A1 Out { WFCMap { C -> 01X; } }
}
Remember that the order of WaveformCharacter references in the mapped output side (the right or "to_wfc" side) is
important: the first reference represents the compare-low state, the second reference represents the compare-high
state, the third value represents the compare-unknown state (which represents a test value that is not high, low, or
changes during the measurement interval), and the forth value represents the compare-off (high-impedance) state, if
the output supports this operation and the tester can return this state during execution of the test.
If there are multiple Waveform definitions, each with S events for this Signal, each different Waveform (with a unique
WaveformCharacter reference) can specify a unique set of Waveform response mappings. This allows for differentiation of the response data if desired or needed for evaluation/review purposes.
I.3
Step 3 - Pattern Reference
The final step is to identify the desired pattern location where response data is desired. This is indicated by the application of the WaveformCharacter that contains an S event, in the Pattern data. One example of this is:
Header {
}
Pattern diag_one {
...
"Pattern17": Loop 200 { V { clk=P; A1=C; } }
...
}
This will enable the response-return for all Vectors inside this single Loop construct (in this example, for the 200 Vectors contained in this Loop).
I.4
Step 4 - Tester Response Return
The return format for this information is tester-dependent, but a recommended format using STIL constructs would
be to return this data following the diagnostic information return for failing data as shown in annex M. For example,
the return data for this scenario could look like:
Header {
}
Signals {
A1 Out { WFCMap { C -> 01X; } Base Hex 01; }
82


}
PatternBurst feedback {
PatList { diag_one; }
}
PatternExec {
PatternBurst feedback;
}
Pattern diag_one {
X "Pattern17";
Loop Data { V { A1= 0000000000 0000000000 0000000000
01AAAAFFBA AAAFC44000; } }
}
Note: This is the complete returned data. The return environment mapped the response data into a one-bit hex context
(all device responses were either high or low, so the X value was not used), and defined the Base Hex for these two
WaveformCharacters in the declaration of A1. The 50 hex characters above define all 200 expanded WaveformCharacter references for this signal.
The return environment also made use of the Loop Data construct to return all these values under a single statement
for this set of Vectors. This construct is applicable in contexts where the set of return vectors are adjacent (as was generated by the original Loop that contained the 'C' WaveformChar), and provides for compact representation of this
information.
Note: While the normal operation of this facility is expected to be applied for a limited set of signals, over a limited
range of test vectors, it is straightforward to generalize this behavior to all signals/all vectors. By replacing all compare events across all Signals in all WaveformTables with S values, all Vectors will see a "Substitute" event for each
output compare operation and will return detected event behavior when this test is executed.
83

Annex J Signal constraints using Fixed and Equivalent statements

(informative)
This annex shows an example application using the Fixed and Equivalent statements. Refer to Vector data constraints - Fixed and Equivalent on page 44 for the definition of syntax and semantics.
J.1
Example: Signal Constraints
Following is an example of Fixed and Equivalent statements used in Pattern cpat. For the first two vectors, signals a
and b must be 0 and signals c and d must be either 0 and 1, or 1 and 0 or have both WaveformCharacters other
than 0 and 1.
Header {
Ann {* clause J.1 *}
}
Signals { a In; b In; c In; q Out;
d In {
WFCMap { 0->1; 1->0; }
}
}
SignalGroups { cinputs a+b; }
Timing {
WaveformTable myWFT {
Period '10ns';
Waveforms {
cinputs+c+d { 01ZN { '0ns' D/U/Z/N; } }
q { LHTX { '0ns' X; '4ns' L/H/T/X; } }
}
}
}
PatList { cpat }
}
Pattern cpat {
W myWFT;
Fixed { cinputs=00; }
Equivalent c \m d;
V { c=0; q=H; } // equivalent to V { a=0; b=0; c=0; d=1; q=H; }
V { c=1; q=L; } // equivalent to V { a=0; b=0; c=1; d=0; q=L; }
V { d=1; } // equivalent to V { a=0; b=0; c=0; d=1; q=L; }
Fixed { c=0; }// implies also Fixed { d=1; }
V {}
// equivalent to V { a=0; b=0; c=0; d=1; q=L; }
}
J.2
Example: Constraints in a Scan Design
The following is an example of a test_mode signal, typical in a scan design, that needs to be constraint when applying
values on primary inputs, but not during load/unload of the scan chains. The Fixed statement is active in procedure
"capture_sysclk", but not in procedure "load_unload". Also, the design has differential scan inputs si1 and si1b, thus
the Equivalent statement is active in procedure "load_unload", but not in "capture_sysclk".
84


Header {
Ann {* clause J.2 *}
}
Signals { test_mode In; si1 In;
si1b In {
WFCMap { 0->1; 1->0; }
}
}
PatList { "_pattern_" }
}
Procedures {
"capture_sysclk" {
W functionalWFT;
F { test_mode=0; }
"force PI": V {...}
"measure PO": V {...}
"pulse clock" : V {...}
}
"load_unload" {
W scanWFT;
E si1 \m si1b;
Shift { V { ... }}
}
}
Pattern "_pattern_" {
W myWFT;
Call "capture_sysclk" { ... }
}
85

Annex K
Independent Parallel Patterns (informative)
The ParallelPatList as defined in the PatternBurst block is fine for the case where the user wants a tightly coupled execution of patterns. This might be the case for testing a dual port access memory where the timing is asynchronous, but
the patterns are associated.
A different, but related application is where there are two independent sets of signals, timing, and patterns on a device
that are to be tested independently, with no regard for each other. Consider the following example, which assumes the
name Test to represent the collection of all entities necessary to execute this operation:
DUT signals
port_A signals
tmg_A
port_B signals
brst_A
tmg_B
exec_A
brst_b
exec_B
program
flow
test(n-1)
test(n)
test(n+1)
Figure 9Representation of a complete Test Program

Header {
Ann {* clause K *}
}
SignalGroups port_A { a1 In; a2 In; ... }
SignalGroups port_B { b1 In; b2 In; ... }
Test xyz {
// something new from 1450.4 (flow syntax standard)
PatternExec exec_A;
PatternExec exec_B;
}
PatternExec exec_A {
PatternBurst brst_A;
Timing tmg_A;
}
PatternBurst brst_A {
SignalGroups port_A;
PatList { ... }
}
// similar for exec_B, brst_B, tmg_A, tmg_B
86

Annex L
ScanStructures using complex scan cells (informative)
The ScanStructures block is extended to include additional information required for efficient simulation of scan patterns, i.e., eliminating the need to serially simulate load/unload cycles. Refer to clause ScanStructure extensions for
the syntax definition. The ScanStructures block is optional in a STIL pattern file because the data is tester-ready.
However, the ScanStructures block may be used by a simulator to more efficiently simulate the load/unload of scan
chains by loading and unloading scan cells in parallel.
L.1
Example: inversion inside a scan cell
To use the tester-ready, serial data for parallel load/unload, the simulator must know the input and output inversions
for every scan cell with respect to the scan-input and scan-output pins of the scan chain. In STIL, these inversions are
represented by ! characters in the ScanCells list. However, this notation cannot unambiguously represent both input
and output inversions for all scan cells if one or more cells have internal inversions, as in the following example:
external inversion
internal inversion
scan_in
a1
a2
ScanCells !
a1
a2 !
a3; // wrong a2 output
ScanCells !
a1
a2
a3; // wrong a3 input
a3
scan_out
Figure 10Example of scan chain including a cell with internal inversion
In this example, scan cell a2 has an internal inversion: the value scanned out of a2 is inverted with respect to the value
scanned into a2.
In the first ScanCells statement the inversion between a2 and a3 implies that the output of cell a2 is inverted at the
scan_out pin, which is incorrect. The second ScanCells statement correctly represents the output of cell a2 (noninverted at scan_out), but incorrectly shows the input of a3 inverted with respect to the scan_in pin, whereas in reality
the two inversions cancel each other out and make the input of a3 non-inverted with respect to scan_in. There is no
correct representation of this scan chain using this limited ScanCells notation.
Using the extensions to the ScanStructures block, the above example can be correctly represented as follows:
ScanCells { !; a1; a2 { CellOut ! } a3; }

L.2
Example: scan cells with multiple state elements
In the following example, chain c1 is defined with 4 scan cells, cell a3 having a more complex definition. All inversions have been marked with a comment in the form /*invn*/ to facilitate explanations. Cell a3 resembles an LSSD
cell, with the master shift clock being ACLK and the slave shift clock being BCLK. The other scan cells would typi-
87


cally have the same configuration as a3, but only a3 is detailed here for brevity.
inv1
inv2 inv3
inv4
inv5
a3
scan_in
a1
a2
master
slave
a4
scan_out
shadow
Figure 11Example of scan chain including a cell with multiple state elements and
internal inversions
This scan chain is defined as follows:
Header {
Ann {* clause L.2 *}
}
Variable {
}
ScanStructures G1 {
ScanChain c1 {
ScanIn c1_in;
ScanOut c1_out;
ScanCells { ! /*inv1*/; a1; a2; ! /*inv2*/;
a3 {
If scanmode > 0
CellIn ! /*inv3*/ master shadow ! /*inv4*/ slave;
if scanmode == 2
CellOut slave;
if scanmode == 1
CellOut master ! /*inv4*/;
}
a4; ! /*inv5*/; }
}
}
The simulation-only variable scanmode is declared as follows:
Variables {
scanmode {
Usage SimOnly;
InitialValue 2;
}
}
The variable scanmode controls simulation. The load/unload procedures are setting this variable as follows:
Procedures {
skewed_load {
88


scanmode = 0; // no parallel simulation
V { c1_in = #; ACLK = P; } // pulse A-clock
scanmode = 2; // reset
}
load_unload {
// uses current
Shift { c1_in
scanmode = 2;
}
master_observe {
scanmode = 1;
V { BCLK = P;
}
value of scanmode
= #; c1_out = #; ACLK = P; BCLK = P; }
// reset
// master_observe mode
} // pulse B-clock
}
The pattern block need not be concerned with the details of the scan chain and does not explicitly change the variable
scanmode.
Pattern scan {
pattern 1: Call load_unload { c1_in = 0001; } // scanmode==2
Call skewed_load { c1_in = 0; } // sets scanmode to 0, then 2
V { ... }
Call master_observe; // scanmode==1
pattern 2: Call load_unload { c1_out = 1110; } // scanmode then 2
V { ... }
pattern 3: Call load_unload { c1_out = 1110; } // scanmode==2
}
In the pattern shown, the first vector (labeled pattern 1) calls the load_unload procedure. The simulator can
execute a fully parallel load of { c1_in = 0001; } because scanmode==2 (from its InitialValue in the PatternBurst). The first three bits applied on c1_in are 0, the last bit is 1. This results in the following values being
loaded:
a1 is the cell closest to the scan input c1_in and is thus loaded with the last value (1) of the 0001 string,
inverted as indicated by the ! /*inv1*/, thus a1=0.
a2 is the next cell, loaded with the next-to-last value (0), also inverted /*inv1*/, thus a2=1.
a3 is loaded with 0 inverted twice /*inv1*/ /*inv2*/; within a3 master has yet another inversion /
*inv3*/, thus a3/master=1 and a3/shadow=0.
a4 is the cell closest to the scan output c1_out and is thus loaded with the first value (0) inverted twice /
*inv1*/ /*inv2*/: a4=0.
Next, the skewed_load procedure is called in the Pattern block. The { c1_in = 0; } in this procedure must
be serially simulated because scanmode is set to 0, and will affect the values just loaded into the scan cells. At the
end, procedure skewed_load sets scanmode back to 2.
The following vector is also simulated. Next, the master_observe procedure is called. This procedure has no parameters, and only affects how the following call to load_unload (data { c1_out = 1110; } and labeled pattern 2) is to be interpreted, by setting scanmode to 1:
a4 is the cell closest to the scan output c1_out and is unloaded with the first value (1) of the 1110 string,
inverted as indicated by the ! /*inv5*/, thus a4=0.
a3 is the next cell, unloaded with the second value (1), also inverted /*inv5*/. Within a3, when scanmode==1,
the master is unloaded with yet another inversion /*inv4*/, thus a3/master=1;
a2 is the next cell, unloaded with (1) inverted twice /*inv2*/ /*inv5*/, thus a2=1;
a1 is the cell closest to the scan input c1_in and is unloaded with the last value (0) inverted twice /*inv2*/ /
*inv5*/, thus a1=0.
89

Next, load_unload is again called (label pattern 3). This time, scanmode is 2 (set at the end of the previous
load_unload). The same unload data { c1_out = 1110; } is now interpreted differently for cell a3:
a3 is the next cell, unloaded with the second value (1), also inverted /*inv5*/. Within a3, when scanmode==2,
the slave is unloaded, thus a3/slave=0;
L.3
Example: Complex and Multi-bit scan cells defined with hierarchical scan
The hierarchical scan construct allows common sub-elements of a scanchain to be defined once and instantiated as a
complete scanchain definition. This allows complex scan cell information to be represented once for a type of cell,
and also supports the notion of a multi-bit scan cell if the users perspective considers a single element of a scanchain to contain more than one scan state. Be aware in the example below, that the LSSD_MSS cell, while containing
2 state elements in the scan path, is always clocked such that only a single scan state is ever contained in these elements as discussed in the previous example.
LSSD_MSS
a1
ma
sl
LSSD_MSS
a2
ma
sl
_4_BIT_CELL LSSD_MSS
a3
a4
s1 s2
s3 s4
ma
sl
_4_BIT_CELL
a5
s1 s2
c1_in
s3 s4
c1_out
sh
sh
sh
Figure 12Example of hierarchical scan chain

Header {
Ann {* clause L.3 *}
}
ScanStructures LSSD_MSS {
ScanChain "A" {
ScanIn "scan_in";
// pinname of the LSSD_MSS scanin
ScanOut "scan_out";
// pinname of the LSSD_MSS scanout
ScanInversion 0;
ScanCells {
it {
// one and only one scan state in here
If scanmode > 0 CellIn ! ma sh ! sl;
If scanmode == 2 CellOut sl;
If scanmode == 1 CellOut ma ! ;
}
}
}
}
ScanStructures _4_BIT_CELL {
ScanChain "B" {
ScanIn "scan_in";
// pinname of the _4_BIT_CELL scanin
ScanOut "scan_out";
// pinname of the _4_BIT_CELL scanout
ScanInversion 0;
ScanCells { s1; s2; s3; s4; } // scanchain state elements (4 bits)
}
}
90


ScanStructures G1 {
ScanModule LSSD_MSS {
Instance a1 a2 a4;
}
ScanModule _4_BIT_CELL {
Instance a3 a5;
}
ScanChain c1 {
ScanIn "c1_in";
ScanOut "c1_out";
ScanInversion 1;
ScanLength 11;
// This is the cumulative length

// including subchain elements
ScanCells { !; a1."A"; a2."A"; !; a3."B"; a4."A"; !; a5."B"; }
}
}
}
91

Annex M Fail data feedback from ATE using STIL (informative)

VLSI testing requires diagnostic analysis to understand and correct design and/or processing flaws. In addition, Diagnostics are also used to analyze and improve yield learning.
Diagnostics requires identifying a failure to a source vector, such as with functional patterns, or to a simulation reference, such as with ATPG patterns. This may be simple, such as when each STIL vector is mapped into a single tester
cycle. However, this may be complex, such as when a simulator pattern results in multiple STIL vectors (e.g. scan), or
when a STIL vector requires multiple tester cycles (e.g. complex timing), or when multiple STIL vectors are combined into a single tester cycle.
A Mechanism is therefore required to tag vectors with source references, and to have failures identified relative to
the appropriate tag.
EDA Software
Simulator
/ ATPG
- Patterns w/ Simulator References
STIL
STIL
Translator
STIL
Feedback
ATE Software
Tool / User Software
Failures relative to
Simulator References -
Datalog
Results
Vector to
Simulator Reference
Correlation
Tester Specific
Vectors
TESTER
Figure 13STIL-Design Extension Usage Model (Simulator Feedback)

The Simulator Feedback usage model illustrates that STIL patterns are generated with embedded tags (any reference which is meaningful to the simulator) in the vector data.
Each vector could have an associated X statement. However, this may require significant data volume for a large Pattern. Alternatively, only key cross-references need be specified, and failures shall be associated relative to the last
92


defined cross-reference. Key location considerations include:
At the start of a set of Parallel Vectors. Parallel Vectors typically have a one-to-one correlation to an ATPG vector
(i.e. each ATPG vector gets converted to a single tester vector).
At the start of a set of Scan Vectors. Scan Vectors all relate to a single ATPG vector. The failure offset from the
start of the Scan operation is typically the failing latch location.
Complex simulator vector. These vectors typically require multiple tester vectors to be implemented.
Only for measure vectors. Since the intent is report failures, only those vectors which perform measures need
cross-reference correlation.
The STIL patterns are then translated to a specific tester. During the translation process, an internal correspondence
table is generated to correlate specific tester addresses to the imbedded tags. After applying the tests and datalogging failures, this internal correspondence table shall be used to report the failures, relative to the original imbedded
tags, in STIL format.
The translation from the original simulator STIL file(s) to specific tester vector file(s) may occur using a combination
of user created software, 3rd party software tools, and/or ATE software. This software shall maintain the original
tags, and potentially modify them during their processing (e.g. duplicate a tag when splitting a complex vector
into multiple vectors). This software shall also create a cross reference table to correlate each tag to its associated
tester vector address.
Different types of Diagnostics require different information. For example, IDDq diagnostics only requires knowing
which vector failed. Scan based diagnostics requires the shift chain and latch position (as determined by the simulator, based on the offset from a tag). The most complex is Stuck Fault diagnostics, which requires the failing state.
Stuck Fault ATPG create patterns which subsume faults into optimal patterns. For example, it is common to test a net
for a stuck at 0 and stuck at 1. Both of these faults may be tested simultaneously by measuring high impedance.
However, when the measure high impedance fails, the simulator needs to know what was measured (low or high) for
it to know the stuck at value.
M.1
Fail data feedback in STIL
A STIL file containing Fail Data Feedback shall appear very similar to a STIL file containing Test Patterns. Namely,
it will contain:
A Signals and/or SignalGroups blocks to identify the signals used to convey the failing pins. These blocks shall
be derived from the original STIL file.
A Timing block to identify the waveform characters used to convey failing state. This block may be derived from
the original STIL file and/or it may be created by the STIL Feedback software. The Timing block may define
new waveform characters which werent in the original STIL file. For example, a Pattern may consist of only
measure 0s, but the resultant testing may result in measure 1s or measure high impedance, requiring new
waveform characters to be added. The Timing block may also define waveforms consisting of only a fail event
without timing. Specification of the timing may not be required in performing the diagnosis.
A PatternExec block to associate the PatternBurst with the Timings.
A PatternBurst block to identify the failing Pattern.
A Pattern block to identify the failing Vectors, relative to the X statements. The Vectors need only convey the
actual failing measurements.
M.2
Fail data feedback - example
The following example illustrates the complete flow from simulation to return failure feedback. It consists of three
scenarios:
1.
A Functional subset. This subset of vectors contain no simulation references, and illustrates how failures may be conveyed relative to the start of a Pattern.
2.
A Scan subset. This subset of vectors contains key simulation references, and illustrates how failures
may be conveyed relative to the start of a scan operation (scan out), relative within a block of parallel
93


vectors, and relative within a loop.
3.
A Complex Timing subset. This subset of vectors contains key simulation references, and illustrates
how vectors may be split into multiple tester cycles, and how the original simulator reference is maintained.
Simulator: Internal Perspective

Example has 5 pins, 3 PIs (001, 002 & 003), 2 POs
(004 & 005), and 10 latches (101-110) accessed
through a ScanIn (003) and a ScanOut (005).
stim(001:0, 002:0, 003:0) meas(004:X, 005:X);

pulse(001) meas(004:0);
pulse(001) meas(004:1);
pulse(001) meas(004:0);
Section 1: represents functional type pat terns (no 1.1.0 stim(001:0, 002:0, 003:1) meas(004:X, 005:X);
simulator references).
1.1.1 pulse(001) stim(002:1) stimlatch(101:0, 102:1,
103:1, 104:0, 105:0, 106:1, 107:1, 108:0, 109:0,
110:1);
1.1.2 pulse(001) stim(002:0) meas(004:0);
Section 2: represents scan type patterns (contain 1.1.3 pulse(001) meas(004:1);
1.1.4 pulse(001) meas(004:0);
simulator references).
1.1.5 pulse(001) meas(004:1);
Note: latches are defined in scan input to scan outloop 400
put order (i.e. latch 101 is connected to 003, latch 1.1.6 pulse(001) meas(004:1);
110 is connected to 005). Therefore, the scan data 1.1.7 pulse(001) meas(004:1);
appears inverted in STIL, since the first scan state 1.1.8 pulse(001) meas(004:0);
specified must be shifted completely through the scan
endloop
Simulator Write
chain.
1.1.9 pulse(001) stim(002:1) meas(004:X) measlatch(101:1, 102:0, 103:0, 104:1, 105:1, 106:0,
107:0, 108:1, 109:1, 110:0);
Section 3: represents a complex pattern which 1.2.0 stim(001:0, 002:0, 003:0) meas(004:X, 005:X;
1.2.1 pulse@10ns(001) stim@35ns(002:1)
requires multiple time-based events on one signal.
pulse@60ns(001) meas@80ns(004:1);
1.2.2 stim(001:0, 002:0) meas(004:X);
94

Simulator:
STIL Output
Signals { p001 In; p002 In; p003 In; p004 Out; p005 Out;}
SignalGroups { si=p003 {ScanIn 10;} so=p005 {ScanOut 10;}
pi=p001+p002+p003; po=p004+p005; }
Timing { WaveformTable simple { Period 100ns;
Waveforms { pi { 01 { 0ns D/U; }
P { 0ns D; 50ns U; 70ns D; } }
po { LHX { 90ns LHX; } } } }
WaveformTable complex { InheritWaveformTable simple;
Waveforms { p001 { Q { 0ns D; 10ns U; 20ns D;
60ns U; 70ns D; } }
p002 { Q { 35ns U; } }
p003 { Q { 80ns H; } } } }
} // Timing
complex timings
Procedures { scan { W simple;

Shift { V { p001=P; p002=1; p003=#; p004=X;
p005=#;} } }
} // Procedures
...
PatternExec feedback_example {
// Use global timings
PatternBurst feedback_example;
} // PatternExec
PatternBurst feedback_example {
PatList { samples; }
} // PatternBurst
Section 1:
functional vectors
Pattern samples {
W simple;
V { p001=0; p002=0; p003=0; p004=X; p005=X; }
V { p001=P; p004=L; }
V { p001=P; p004=H; }
V { p001=P; p004=L; }
95

Section 2: scan
first measure
loop association
scan unload
Section 3: complex
timings
complex vector
V { p001=0; p002=0; p003=1; p004=X; p005=X;}

Call scan { si=1001100110; }
X 1.1.2;
V { p001=P; p002=0; p004=L; }
V { p001=P; p004=H; }
V { p001=P; p004=L; }
V { p001=P; p004=H; }
X 1.1.6;
Loop 400 {
V { p001=P; p004=H; }
V { p001=P; p004=H; }
V { p001=P; p004=L; }
}
X 1.1.9;
Call scan { so=LHHLLHHLLH; }
W complex;
V { p001=0; p002=0; p003=0; p004=X; p005=X; }
X 1.2.1;
V { p001=Q; p002=Q; p004=Q; }
V { p001=0; p002=0; p004=X; }
} // Pattern sample
STIL Translator:
produces:
Timing sets
#Timing
T1 = cycle 100ns RZ 50/70ns, NRZ 0ns, strb 90ns
T2 = cycle 50ns, RZ 10/20ns, NRZ 35ns, strb 30ns
and
96

Vector Data
and
Vector to Simulator Cross-Reference
file (created/used locally by tester)
16 : 1.1.2
20 : 1.1.6
23 : 1.1.9
34 : 1.2.1
35: 1.2.1
#Vectors
#Addr/Timing
1/T1
2/T1
3/T1
4/T1
#
5/T1
6/T1
7/T1
8/T1
9/T1
10/T1
11/T1
12/T1
13/T1
14/T1
15/T1
16/T1
17/T1
18/T1
19/T1
LOOP 400
20/T1
21/T1
22/T1
ENDLOOP
23/T1
24/T1
25/T1
26/T1
27/T1
28/T1
29/T1
30/T1
31/T1
32/T1
#
33/T1
34/T2
35/T2
36/T1
p001
0
P
P
P
p002
0
0
0
0
p003 p004 p005

0
X
X
0
L
X
0
H
X
0
L
X
0
P
P
P
P
P
P
P
P
P
P
P
P
P
P
0
1
1
1
1
1
1
1
1
1
1
0
0
0
0
1
1
0
0
1
1
0
0
1
1
0
0
0
0
0
X
X
X
X
X
X
X
X
X
X
X
L
H
L
H
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
P
P
P
0
0
0
0
0
0
H
H
L
X
X
X
P
P
P
P
P
P
P
P
P
P
0
1
1
1
1
1
1
1
1
1
0
0
0
0
0
0
0
0
0
0
X
X
X
X
X
X
X
X
X
X
L
H
H
L
L
H
H
L
L
H
0
P
P
0
0
1
1
0
0
0
0
0
X
X
H
X
X
X
X
X
97

Assume the following tester failures:
Address
3
18
21
28
35
Loop
Iteration
141
Pin
p004
p004
p004
p005
p004
Measure
State
Z
H
Z
L
L
Post-test conversion of fail data to STIL:

STIL 1.0;
Signals { p001 In; p002 In; p003 In; p004 Out; p005
Out;}
SignalGroups { po=p004+p005; }
Timing { WaveformTable datalog {
Waveforms { po { LHZX { L/H/T/X; }}}}}
PatternExec feedback_example {
PatternBurst feedback_example;}
PatternBurst feedback_example {
PatList { samples; }}
Use datalog waveform characters
failed the 3rd vector relative to the start of the
pattern.
failed the 3rd vector of a parallel block relative
to reference 1.1.2.
failed 3rd vector of 141st iteration of loop relative to reference 1.1.6.
failed 6th vector of scan out relative to reference 1.1.9.
failed the vector associated to reference 1.2.1.
Pattern sample {
W datalog;
X { Offset=2; }
V { p004=Z; }
X 1.1.2 { Offset=2; }
V { p004=H; }
X 1.1.6 { Iteration=140; Offset=2; }
V { p004=Z; }
X 1.1.9 { Offset=5; }
V { p005=L; }
X 1.2.1;
V { p004=L; }
}
Simulation correlation of failing data,

using the original STIL pattern and the
returning STIL failures.
no associated reference to first fail.

1.1.4
004 1
1.1.8
004 z
141st iteration
1.1.9
105 0
1.2.1
004 0
98

Annex N
BreakPoints using MergedScan() function (informative)
STIL writers will primarily output STIL scan-based patterns using a merged format, being motivated by the test time
reduction savings. Typically, in a merged scan format, the unload operation of a scan pattern is merged in with the
load operation of the next subsequent scan pattern. This results in effectively cutting in half the number of vectors
applied.
As a result of outputting STIL patterns in merged format, there exists no convenient location in the STIL patterns to
place a STIL BreakPoint statement. For a BreakPoint statement to exist within STIL scan patterns which are in
merged format, it would typically need to exist between the two unload/load operations that have been merged
together. When processing large sets of patterns, there exists a need to break those patterns up into smaller, more
manageable, pattern segments. If the patterns being processed are merged scan patterns, then there is no standard way
of breaking them up into independent patterns segments.
STIL BreakPoint statements are used to segment the patterns into logical chunks by identifying the points in the patterns where they may be broken up. Breaking up STIL patterns at the BreakPoint statement will ensure that the resulting pattern segments will each function independently of each other, and that these segments may be applied as a
standalone entity to a tester or simulator.
By using the MergedScan() function, STIL writers can provide both merged and unmerged formats of scan patterns
within a single pattern instance. Usage of either the merged or unmerged formats is then left up to the STIL consumers to use on a pattern by pattern basis, depending upon their processing requirements and resources. An example of
this is shown below.
N.1
Example of merged and unmerged STIL scan patterns using MergedScan()
This example shows the usage of the MergedScan() function and how it may be applied in scan procedures or macros
containing shift blocks.
First the Signals and SignalGroups blocks defining the scanin and scanout signals and groups
Header {
Ann {* clause N.1 *}
}
Signals {
...
si1
In {ScanIn 8;}
si2
In {ScanIn 6;}
so1
Out{ScanOut 8;}
so2
Out{ScanOut 6;}
}
SignalGroups {
si = si1 + si2;
so = so1 + so1;
...
}
Next, a Procedures block defining a single scan procedure to be used for all scan operations, both merged and
unmerged. Note the If/Else logic based on the result of a call to the boolean function MergedScan(). This is the key
area of the STIL patterns which allows for either a merged or unmerged representation of scan patterns. The If/Else
constructs will ensure a mutually exclusive relationship between these two formats such that the STIL consumer will
always apply one and only one of the scan formats.
Procedures {
99

scan {
C { si=\r2 0; so=\r2 X; }
// If the STIL consumers environment allows for a merged scan operation
If 'MergedScan()' {
Shift { V { si=#; so=#; clk=P; } }
}
// Else...STIL consumers environment requires unmerged scan operation
//
which includes a BreakPoint
Else {
Shift { V {
so=#; clk=P; } }
// unload
BreakPoint;
// break patterns here
Shift { V { si=#;
clk=P; } }
// load
}
}
// end scan procedure
// end Procedures block
Finally, the scan procedure defined above is used within the Pattern block to apply all the scan patterns. The actually patterns themselves have no special coding depending on whether the merged or unmerged scan patterns will be
used. This is completely encapsulated within the defined scan procedure.
Pattern scanpat {
Call scan { si1=00100110; si2=100111; }
// load
V { clks=PPP; pi=10101000001; po=ZHXXXLHZZXX; }
Call scan { si1=01000111; si2=001110;
// load/unload
so1=HHLHLLXL; so2=HXXLHL; }
V { clks=PPP; pi=11110101000; po=ZLLLLHHZZXL; }
...more patterns not shown
Call scan { si1=11110010; si2=111100;
// load/unload
so1=LLLLHXLH; so2=LHHLLL; }
V { clks=PPP; pi=11111001001; po=HLHLLLLLXZL; }
Call scan { so1=XLLHLHHH; so2=HHLLXH; }
// unload
}
N.2
Processing of STIL scan patterns which utilize the MergedScan() function
The example above shows how STIL patterns can be written to allow representation of merged and unmerged scan
patterns within the same pattern instance. This clause describes how a STIL consumer may actually process the patterns above.
The MergedScan() function is a boolean function which returns true or false based on whether, when processing scan
patterns, the merged scan pattern format should be used. By default, this function return true. This would cause the
default behavior of all STIL consumers to output using merged format. During processing of patterns in some given
STIL consumer environment, it is determined by the STIL consumer that there exists a need to break the patterns due
to various factors relevant to that STIL consumer (e.g Tester Resources, Memory Limitations,...). At this point, the
STIL consumer switches the value returned by MergedScan() to be that of false.
The result of the MergedScan() function now returning false will cause the next subsequent procedure/macro call
which contains a call to MergedScan() to take the alternate path and generate patterns in unmerged format. As part of
the STIL consumer making the call to MergedScan() which returns false, the STIL consumer can then reset the
MergedScan() function back to its default of state of returning true for all subsequent calls.
In reality, a STIL consumer may not know when it needs to break the patterns up into a new pattern segment until it
has already processed to the point in the patterns where resource have been exhausted. In this case, the STIL consumer may need to buffer up STIL patterns and then when it determines it needs to break the patterns, it will break
them at that point and then re-process the buffered up patterns starting the new pattern segment at the beginning of the
100


most recent procedure call to a procedure containing an If/Else construct based on MergedScan(). This would prevent
the STIL consumer from having to know ahead of time, going into a scan procedure, whether the vectors from that
procedure will cause an overflow of the resources available.
101


p1450 1-D14

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

p1450 1-D14

Hochgeladen von

Copyright:

Verfügbare Formate

P1450.

1 Working-Draft 14, Aug 1, 2002

See "D14 Review Resolution Document" for summary of the changes.

Changed draft version ident to integer 12 to reflect WG circulations. Added

Copyright 2001 IEEE. All rights reserved.

P1450.1 Working-Draft 14, Aug 1, 2002

Made changes as agreed to at 8/16 phone call.

Added inherit-constructs ref to state-element and changed pat_expr to

Added BistStructures. Removed TestResult() per minutes of ITC 2K

Copyright 2001 IEEE. All rights reserved.

P1450.1 Working-Draft 14, Aug 1, 2002

Changed titles of tables 1,2,4-6 to include "Additions to", to indicate these

Removed ScanStructures block from Environment NameMaps and replaced

Changed WaveformChar to WaveformCharacter throughout doc (note:

tony taylor, greg

Changes to bring in line with CTL. Re-structured document as agreed at the

Copyright 2001 IEEE. All rights reserved.

P1450.1 Working-Draft 14, Aug 1, 2002

Definitions, acronyms, and abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Structure of this standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

STIL Syntax Description - Extensions to STIL0 Clause 6 . . . . . . . . . . . . . . . 9

Expression Constructs - Extensions to STIL0 Clause 6 . . . . . . . . . . . . . . . .11

Statement structure and organization of STIL information . . . . . . . . . . . . . . 19

STIL statement - Extensions to STIL0 clause 8 . . . . . . . . . . . . . . . . . . . . . . 20

UserKeywords statement - Extensions to STIL0 clause 11 . . . . . . . . . . . . . 21

Signals Block - Extensions to STIL0 clause 14. . . . . . . . . . . . . . . . . . . . . . . 23

SignalGroups Block - Extensions to STIL0 clause 15. . . . . . . . . . . . . . . . . . 25

PatternBurst Block - Extensions to STIL0 Clause 17 . . . . . . . . . . . . . . . . . . 28

Copyright 2001 IEEE. All rights reserved.

P1450.1 Working-Draft 14, Aug 1, 2002

Timing Block and WaveformTable Block - Extensions to STIL0 clause 18. . 34

ScanStructures block - Extensions to STIL0 clause 20 . . . . . . . . . . . . . . . . 35

Pattern Data - Extensions to STIL0 clause 21 . . . . . . . . . . . . . . . . . . . . . . . 39

Pattern Statements - Extensions to STIL0 clause 22 . . . . . . . . . . . . . . . . . . 41

Procedure and macro data substitution - Extensions to STIL0 clause 24.5. 49

Copyright 2001 IEEE. All rights reserved.

P1450.1 Working-Draft 14, Aug 1, 2002

Copyright 2001 IEEE. All rights reserved.

P1450.1 Working-Draft 14, Aug 1, 2002

Definitions, acronyms, and abbreviations

Copyright 2001 IEEE. All rights reserved.

P1450.1 Working-Draft 14, Aug 1, 2002

Acronyms and abbreviations

Automated Test Equipment

Built-In Self Test

Linear Feedback Shift Register

MISR Multiple Input Shift Register

Standard Test Interface Language

STUMPS Self-Test Using a Misr and a Parallel Shift-register

Structure of this standard

Copyright 2001 IEEE. All rights reserved.

P1450.1 Working-Draft 14, Aug 1, 2002

STIL Syntax Description - Extensions to STIL0 Clause 6

Additional reserved words

Table 1Additions to STIL Reserved Words

Additional reserved characters

Copyright 2001 IEEE. All rights reserved.

P1450.1 Working-Draft 14, Aug 1, 2002

Table 2Additions to STIL Reserved Characters

exclamation (NOT sign) is used as inversion operator in logical expressions

per-cent sign is used as the modulus in logical expressions.

parenthesis reserved in timing, logical and signal expressions

multiply in timing and logical expressions