This document is an unapproved draft of a proposed IEEE-SA Standard - USE AT YOUR OWN RISK. As suchdocument is subject to change. Permission is hereby granted for IEEE Standards Committee participants to rethis document for purposes of IEEE standardization activities only. Prior to submitting this document to anothedard development organization for standardization activities, permission must first be obtained from the MaStandards Licensing and Contracts, IEEE Standards Activities Department. Other entities seeking permisreproduce portions of this document must obtain the appropriate license from the Manager, Standards LicensContracts, IEEE Standards Activities Department. The IEEE is the sole entity that may authorize the use oowned trademarks, certification marks, or other designations that may indicate compliance with the materiatained herein.
IEEE Standards Activities DepartmentStandards Licensing and Contracts445 Hoes Lane, P.O. Box 1331Piscataway, NJ 08855-1331, USA
Table 1—History
Date By Comments
04/01/2002D14
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. Thdraft was finalized on March 21, 2002.
10/11/01D12
greg maston Changed draft version ident to integer 12 to reflect WG circulations. Add()+ around cell-ref hierarchical names in clause 6.3 as well as elaboratioon supported constructs for [ ] here. AddedSyncStart, Independent, andLockStep to Patburst ParallelPatSet andback into annex example. AddedScanEnable to ScanStructures. Removed annex C and changed ’reader’ ’consumer’ in annex N. Un-’musted’ the normative clause of the docume(removed all "must", changed generally to "shall"). Added Figure names diagrams missing; ran spellcheck. Added new annex C that uses ScanEable to show an example of a logic expression using signals.
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
r
can
ur-
gr",
-
defi-
Sig-
i-
en
-
oed.
8/21/01 to 10/10/01;0.98; D11
tony taylorgreg maston
Made changes as agreed to at 8/16 phone call.Annex M.3 changes, addednew clause 6 to elaborate on expression exten-sions to dot0 and to partition expression clauses formerly 5.4 and on intotheir own clause. Added enum elaboration. Changed copyright notice peIEEE. AddedMergedScan to functions andElse statement. Added a sen-tence to clause 14 (ScanStructs) to indicate that one scan cell uses one sbit of data. Removed LockStep and references to CTL from Annex F, andreferences to CTL except under the Environment block (lockstep is not crently defined and CTL is a dangerous reference in this spec, if the CTLspec references this one...). Added Annex O on MergedScan from DougSprague. Replaced occurrences of INTEGER withinteger_expr in state-ments and added Scanstruct statements withinteger_expr for Rohit.
8/15/01;0.97; D10
tony taylor Added Annex L.3 - complex scan cells and multibit scan cells defined usinhierarchical scan (by Greg Maston). Removed clause defining "engr_expas it is now considered another form of "real_expr". Added UserKeywordsUserFunctions and UserParameters to the STIL header block. Added filetype and file format keyword definitions. Added rules for formatting of integer values, and for truncation. Added Peter’s new definition of compare-substitute 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 nitions.
7/12/01; 0.95;D08
tony taylor Made changes as agreed to at 7/5 phone call.. Made adjustments to thenalGroup->Variable definitions.
6/23/01;0.94; D07
greg mastontony taylor
Added inherit-constructs ref to state-element andchanged pat_expr tological_expr in ScanStructures.Added integer_list definition and usage.Reversed order of history table. Made formatting changes. Changed Varable type name fromWFC to SignalVariable. Added new examples in theannex.Added definition in clause 5 for:boolean_expr, sigvar_expr,integer_expr, integer_list, real_expr, engr_expr. Added two more exam-ples to the annex -
4/27/01; draft0.93(b) 2001;D06
greg maston Added BistStructures. Removed TestResult() per minutes of ITC 2Kmeeting. Added 16.3, NameMaps example, by request from reviewer.Added AllNamesconstruct to NameMaps per reviewer request. Pushed thScanStructures syntax around quite a bit (cleaned up), and moved it up ilogical clause order (before Pattern Data).Added InheritScanStructuresper reviewer. Completed cellref_expr definition (clause 5.7) Added definition of STIL0 to point to 1450, and added variable "STIL0" to substitute forthe full reference -review the changes to the titles of the Clauses here.Added optional labels in front of the Pattern statements clause 14.1.AddedLoop Data construct. Cleaned up references to "conditional expression", treference "boolean expression" as appropriate. Pushed around and retitlclause 11.5, describing variable usage, to logical expressions, clause 5.5Added 13.1, Cyclized Data, to define the use of logical expressions insidepattern statements.
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
see
nn
(In-
nt
ary
ced-
r-ile.
f
nd.er-r,
e
ur-ilse
nt
t-.
ior
3/1/01;draft0.93(a) 2001;D05
greg maston Changed titles of tables 1,2,4-6 to include "Additions to", to indicate theare incremental definitions to dot0 data. Changed WFCMap attributes to bsingle-instance to be consistent with other attributes. Added statement othe scope of constants in the Signals block. Removed PatternBurst refs iBistStruct description in Table 5. Changed NonATEOnly to SimulationOnlyin SignalGroups clause. Added clause 5.3 to define support for constantsthink I was supposed to do this before and forgot). Added clause 15, "extesions to procedure and macro data substitution". Deleted some redundaclauses that repeated syntax definitions only (with no additional defini-tions), one in PatternBurst and two in Pattern statements. Added someexplanatory text to the Pattern statement definitions in clause 13.1.Removed all occurrences of Eval in the examples, and replaced as necesswith the C statement. Ran spellchecker for gross errors.
2/2/01...2/28/01; draft 0.922001; D04
greg maston Removed ScanStructures block from Environment NameMaps and replait with ScanCells block. Moved the Variables and Enum blocks into the SignalGroups and defined "Constant". Added a “Constant” declaration to theSignals, too. Added BistStructures block references in clause 5 and 6, inprep for Peter’s additions. Removed Enumeration and Variable block refeences in the PatBurst clause, and added consideration for the If and Whas an attribute construct rather than a keyword statement in the PatBurst
1/29/01; D03 greg maston ChangedWaveformChar to WaveformCharacter throughout doc (note:these changes not change-barred to avoid confusion). Moved definition oVariables andEnums from PatternBurst to their own new global clauses.Moved WFCMap declaration from PatternBurst to Signals and Signal-Groups (added new clauses to support these changes). Added table 3 aclause 5.4 to delineate Variables, Enumerations and Environment effectsAdded clause 7 and tables 5 and 6 to delineate impact of Variables, Enumations, and Environment placement in STIL files. Did a pass at spellchecketoo.
8/6/00..1/10/01; D02
tony taylor, gregmaston, peterwohl
Changes to bring in line with CTL. Re-structured document as agreed at thAugust working group meeting. Enhanced the Pattern Variable syntax.Added pat_expr clause. Defined TestResult function. Added Scope and Ppose from the PAR. Incorporated the changes from Doug Sprague on FaFeedback. Changes to WFCMap. Format changes for IEEE, Added claufor new reserved words and reserved characters. Started to changepat_exprto logical_expr, moved definition of logical variables clause earlier andadded elaboration. Added name_map option to NameMaps in Environmeper CTL discussion. Changed tables to incremental forms. ChangedNameMapInherit to InheritNameMap (match all Inherit keywords), addedwfc_expr and explanation of cellref_expr in clause 5. Corrected Annex letering. 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 prP1450.1 working groups.
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
erationdards,
ed as thetions,f over-of test
am-STIL
xpecta-
vicemily of
ro-ain dataing then pat-
sms.
d ins, and
forsimula-rn exe-.
aral-ecifica-
ey-
Thisd the
tion, effi-
ck to/vectorapture
P1450.1IEEE Standard Test Interface Language (STIL) forDigital Test Vector Data Design Extension
1. OverviewSTIL is an evolving standard being developed in support of various needs for interfacing between test gentools and test equipment. The IEEE Std. 1450-1999 (STIL.0) forms the basis for this evolution. New "dot" stanlike 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 viewaddition of advanced features to the STIL.0 base-line to allow for the usage of STIL in more complex applicawhile leaving the basic standard unchanged as a vehicle for transmitting basic test data. The following is a brieview of the new features in STIL.1 to support advanced applications such as: a) embedded cores, b) familiespatterns, c) mapping to ATE systems, d) mapping to simulation e) devices with advanced DFT.
Envir onment Mapping - Data for a device exists in many forms and in many other software environments. Exples are: a) simulation environment, b) static analysis environment, c) specific ATE system environment. The"Environment" block is a new mechanism to relate STIL data to these other environments. No assumptions, etions, or limitations are imposed on the other environments. This is just a way of relating one to the other.
ParameterizedData - Much of STIL data is declarative in nature (i.e., it defines various static attributes of a deor pattern set). The addition of "Constant" declarations allows a data set to be created that applies to a fadevices.
ComplexTestProtocolDefinition - Test protocol definitions are usually contained in STIL "Procedures" or "MacDefs" and are used to specify the application of a series of data values to a device. STIL.0 supports scan chpassing and simple WFC data passing via the "#" and "%" characters. STIL.1 enhances this capability by allowuse of data substitution from signal-variables, integer-expressions in loops and vectors, "If"/"While" decisions otern statements. These capabilities are needed for BIST, embedded cores, and various test access mechani
AdvancedScanAr chitecture - Advanced DFT techniques require additional capabilities beyond what is defineSTIL.0. This includes multi-state scan cells, hierarchical scan-chain definitions, re-configurable scan-chainscan-chain indexing.
Run Time Pattern Decisions- The "If", "While", "Loop Data" are new STIL.1 constructs that have been addedspecification of pattern activity. These statements are needed in the specification of patterns to be run in thetion environment. Although there is no standardization amongst ATE systems on run time instructions for pattecution, 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 plel, patterns running in "LockStep", and patterns that can be re-ordered. For parallel pattern execution, the sption for how the patterns fit together can be specified by using the "Fixed", "Extend", and "Wait" statements.
EnhancedUser Extensibility - The "UserKeyword" extensibility defined in STIL.0 has been extended to allow kwords to be defined on a per-block-type basis.
SignalRelationships- Additional syntax is provided to allow the specification of relationships between signals.is done via "\m" to map WFC’s to another WFC, \j to join WFC’s, "Extend" to define behavior of signals beyonbounds of a given pattern, and "Fixed" to restrict any further changes to signals within a pattern.
BIST Structur eDefinitions - A new "BISTStructures" block is added in STIL.1 to define the content and connecof a BIST block into a design. As with "ScanStructures" the primary purpose of the construct is to allow for fastcient simulation of patterns with BIST controllers.
Fail Feedback- Two new features are added to facilitate the processing of failure data from an ATE system badesign tools. The first is the "X" or cross-reference statement that allows the specification of where in a patternsequence a failure occurs. The second is the "S"/"s" timing event that allows for the specification of a data c
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
signaltypes tocks, and
cores)
and
xtend-te formments.
ntegratefining
o allow
rsededing pro-
escrip-
o thiss
vide
tiate
lity.
protocol for the purpose of capturing bulk fail data for processing.
1.1 ScopeDefine structures in STIL to support usage as semiconductor simulation stimulus; including: 1) mappingnames to equivalent design references, 2) interface between Scan and BIST, and the logic simulation, 3) datarepresent unresolved states in a pattern, 4) parallel or asynchronous pattern execution on different design blo5) 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., embeddedsuch 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 stimulusdesign data elements.
1.2 PurposeEnhance the STIL language definition to support the usage of STIL in the design environment. This includes eing the execution concept to support STIL as a stimulus language, to allow STIL to be used as an intermediaof data, and to allow STIL to capture design information needed to port simulation data to device test environ
In addition, define extensions to support the definition of sub element tests, and to define the mechanisms to ithose tests into a complete device test. This effort is to be done in conjunction with IEEE P1500 which is destandards for the definition and integration of embedded cores.
Finally, define the constructs necessary to correlate test failure information back to the design environment, tdebug and diagnosis operations to be performed based on failure information in STIL format.
2. ReferencesThis standard shall be used in conjunction with the following standards. When the following standards are supeby an approved version, the revision shall apply. These references are automatically updated during the editcess.
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 Dtion Language.
3. Definitions, acronyms, and abbreviations
3.1 DefinitionsFor the purposes of this standard, the following terms and definitions apply. Additional terminology specific tstandard is found in Annex A. IEEE Std 100-1996,The IEEE Standard Dictionary of Electrical and ElectronicTerms, 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 proadditional 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 differenit from all the STIL extensions (such as this standard).
System on Chip (SoC)An Integrated Circuit containing modules that represent separately-developed functiona
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
. 1450-
cumentin thismplete
.
ndatory
es. Theot met
g out-
ese char-
iguous".or the
3.2 Acronyms and abbreviationsATE 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 standardThis document is an adjunct to IEEE Std. 1450-1999. The conventions established and defined in IEEE Std1999 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 doand are so identified in the title. The Environment and BistStructures blocks are new constructs introduceddocument. All clauses in this document are normative. Example code is provided within each clause. More coexamples 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 marequirement varies for different readers of the standard:
— To developers of tools that process STIL (readers), shall denotes a requirement that the standard imposresulting implementation is required to enforce this requirement and issue an error if the requirement is nby the input.
— To developers of STIL files (writers), shall denotes mandatory characteristics of the language. The resultinput must conform to these characteristics.
— To the users of STIL, shall denotes mandatory characteristics of the language. Users may depend on thacteristics for interpretation of the STIL source.
The language definition clauses contain statements that use the phrase "it is an error", and "it may be ambThese phrases indicate improperly-defined STIL information. The interpretation of these phrases will differ f
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
use 4).
s:
riablesbles
equent
andard.viously
different readers of this standard in the same way that shall differs, as identified in the dashed list above (Cla
5. STIL Syntax Description - Extensions to STIL0 Clause 6All constructs and restrictions for IEEE Std. 1450-1999 Clause 6 are in effect here, with the following addition
— 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 vaSignalVariables, enumerations,andconstantsare defined, and extensions to real expressions and Spec variaare also defined. New types of expressionsboolean_expr, cellname_list, integer_expr, logical_expr, real_expr,sigvar_expr,and integer_list are also defined.
5.1 Additional reserved wordsTable 1 lists all STIL reserved words defined by this standard and not defined in IEEE Std. 1450-1999. Subsclauses in this standard identify the use and context of each of these additional reserved words.
5.2 Additional reserved charactersSeveral reserved characters identified in IEEE Std. 1450-1999 are applied in additional contexts for this stTable 2 lists additional STIL reserved characters defined in this standard as well as additional contexts of pre
Table 1—Additions to STIL Reserved Words
CellIn, CellOut, Constant
Data, Design
E, Else, Enumeration, Enumerations, Environment, Equivalent, Extend
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
using aed. See
emental
st or Pat-pec vari-Signals,a Pattern
identified reserved characters Boldface text identifies extended applications defined in this standard.
5.3 Extensions to STIL0 clause 6.10 - Signal and group name characteristicsAll constructs and definitions in IEEE Std. 1450-1999 clause 6.10 are in effect. In addition, signals expressedbracketed construct shall allow the use of previously declared constants where integer values are allowclause 6.1 for the definition of constants.
5.4 Additions to STIL0 clause 6.16 - STIL name spaces and name resolutionEnvironment and BistStructures blocks augment the STIL namespace as defined in table 3. This table is incrto 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 PatternBurtern blocks. This space also contains Signals, the current selected SignalGroups, and the current selected Sables defined for the context of that expression. Variable and Enumeration names shall be unique against allreferenced and unnamed SignalGroups, and Spec variable names defined for a PatternBurst or application of
Table 2—Additions to STIL Reserved Characters
Char Usage
! exclamation (NOT sign)is used as inversion operator in logical expressions
% per-cent signis 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 timinglogical 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 timingand logicalexpressions
> greater than in timingand logicalexpressions
<= less than or equal to in timingand logicalexpressions
>= greater than or equal to in timingand logicalexpressions
== equal to in timingand logicalexpressions
!= not equal to in timingand logicalexpressions
?: conditional selection in timingand logicalexpressions
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
in clausel variablemerationpes.
se 12. Inions andstants arenstructs names.
for Vari-ariables,
names ared Signal-
namedignal.
ger, Inte-nd integerdard andented inport a
referenced by that PatternBurst.
6. Expression Constructs - Extensions to STIL0 Clause 6IEEE Std. 1450-1999 defines Timing Expressions using Spec Variables and expression constructs presented6.13, and Signal Expressions in clause 6.14. This standard extends these expression contexts with additionatypes and corresponding expression constructs. clause 6.1 presents SignalVariables, Constants, and Enutypes, and clause 6.2 - clause 6.8 detail the additional expression constructs supported by these additional ty
6.1 SignalVariables, enumerations and constantsSignalVariables, enumerations, and constants are declared under the SignalGroups block as defined in clauaddition, constants may be declared in the Signals block as defined in clause 11. SignalVariables, enumeratconstants are used in logical or WaveformCharacter expressions as explained in clause 6.6 and 6.8, and conallowed in bracketed Signal or SignalGroup contexts as explained in clause 5.3. STIL user-defined naming codefined in IEEE Std. 1450-1999 subclause 6.10 are supported for SignalVariable, enumeration, and constant
Logical expressions may contain references to signals, groups, and spec variables. Therefore the name spaceables, Enumerations, and Constants includes the names in effect in these additional namespaces. SignalVenumerations, and constants follow the same name scoping constructs as SignalGroup names, that is: theseunique across items in this names, in referenced (named) SignalGroup blocks; names defined in an unnameGroup block are accessible without reference unless overridden by another definition of the same name in aand referenced SignalGroup block, and items with the same name as a Signal shall be used instead of that S
SignalVariables, Enumerations, and Constants are typed when they are declared. This standard defines IntegerEnum, and Constant variable types that may be used in boolean expressions as presented in clause 6.2, aexpressions as presented in clause 6.4. SignalVariable and SignalVariableEnum types are defined in this stanare used to supply WaveformCharacter expressions in assignments to Signal or SignalGroups as presclause 6.8. The context of Spec Variables is extended from the STIL0 definition of Timing expressions to sup
Table 3—Additions to STIL name spaces
STIL block Type of Name Domain restrictions
Environment Environment domainnames
Supports a single unnamed block and domainname blocks. Domain names shall be uniqueacross all Environment blocks.
BistStructures BistStructures domainnames and BistStruc-tures names
A single BistStructures block is optionally named.Multiple BistStructures blocks shall be uniquelynamed. BistStructures names shall be uniqueinside a BistStructures block.
Names are present in this space dependent on ref-erence statements in the PatternExec (for Specvariables) and the PatternBurst (for named Signal-Groups blocks). Signal names are present unlessoverridden by the same name from a named Sign-alGroups block as specified for SignalGroup reso-lution in IEEE Std. 1450-1999. Names in anunnamed SignalGroups block are present unlessoverridden by the same name in a named and refer-enced SignalGroup block. It is an error for definedEnumeration, Variable, and Constant names toconflict with Signals, SignalGroups, or Spec vari-able names accessible in the same context.
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
e 6.7.
are twothat is
ntativeare sup-ontain
les shalleclaredssigned
manipu-eEnum(<), andinteger
lean
ression
d as
n chainfrom all
ames,n
general engineering expression as defined in clause 6.6, and to support real expressions as defined in claus
Enumeration variables are defined to support declaration of variables that contain representative values. Theretypes of enumeration variables defined here: IntegerEnum variables, which contain a representative valueoptionally mapped to a specified integer value, and SignalVariableEnum variables, which contain a represevalue that is interpreted in a signal-assignment context as a WaveformCharacter list. Enumeration variablesported with a very limited set of expression constructs. SignalVariableEnum and IntegerEnum variables shall conly values defined under the enumeration values defined for that enumeration, and only enumeration variabcontain enumeration values defined for that enumeration. SignalVariableEnum variables shall be assigned denumeration values only, and shall be assigned to Signal references only. IntegerEnum variables shall be adeclared enumeration values only, and are allowed in conditional expressions and assignments, only whenlated with enumeration values supported by that enumeration type. Boolean expressions with SignalVariabland IntegerEnum variables support equals (==) and not-equals (!=) operators. Greater-than (>) and less-thanthe also-equals forms of these operations (<=, >=) are supported only for IntegerEnumerations with declaredvalues.
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 boooperation (using boolean operators defined in table 5) is 0 if the result isFalse, and 1 if the result isTrue. The resultof a bitwise operation (using bitwise operators defined in table 5) is the entire expression; that is, a bitwise expis maintained as defined and not otherwise evaluated.
Contexts that require boolean expression values interpret the value 0 and negative values asFalseand non-zero posi-tive values asTrue. All other types (bitwise logical or WaveformCharacter list values) shall be an error if providethe 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 scadefinitions (see clause 15). The names of scan cells and scan modules are separate and distinctother name spaces.
2. The operators allowed in a cellname_list are the bracket construct [ .. ] to define a series of cellnand the ! operator to to indicate inversion. Supported constructs within the brackets are defined iclause 6.5.
The following is an example containing a cellname_list:
6.4 Integer Expressions ( integer_expr )An integer_expr is logical expression that evaluates to integer. See the list of allowed operators in Table 4 on pThe 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 produceinteger value.
Integer expressions may contain integers, operators as previously indicated, Integer variables, and Constantslowing are examples of integer expressions and their usage:
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
llipsist ofis repre-quiv-
erlined
y logicalditional
es. Thexample
urrently
Pattern-
ants
the fol-
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 e“..” which specifies a range of integers. Aninteger_listmay contain either a single integer, a space-separated lisintegers or integer ranges. Previously defined Constants may appear in place of integers. An integer rangesented by 2 integers (or Constants) separated by “..”. For example, ’3..6’ is equivalent to ’3 4 5 6’ and ’4 .. 2’ is ealent to ’4 3 2’. Spaces are allowed between the integer or Constant, and the ".." operator. The following undcode are examples of integer lists:
6.6 Logical Expressions ( logical_expr )Logical expressions are enclosed in single quotes. The operator set and expression constructs supported bexpressions is the same as defined for IEEE Std. 1450-1999, Subclause 6.13 (Timing Expressions), with adbitwise 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 valuresult of the last operation executed in evaluating a logical expression is the result of a logical expression, for ethe 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 capplied in PatternBurst contexts.
— References to Signals, SignalGroups, or Spec Variables that are currently defined in the PatternBurst andExec context.
— Integers, real numbers, or exponential numbers.
— Expressions as described in IEEE Std. 1450-1999 clause 6.13 butnot including event labels nor time marks, andsupporting the set of operators defined in table 5.
— Expressions formed by algebraic combination of any of these as allowed regarding the unit of the combin(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. Considerlowing example definitions:
// 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 unitsC { ’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 bIf ’a < min (b,c)’ {} // use of the min functionC { ’e = Run’; } // set using enum definitionC { ’h = F8’; } // set hex variable to 1111 1000C { ’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
6.7 Real Expressions ( real_expr )A real expression is defined in a Spec table as defined in IEEE Std. 1450-1999. The termreal_expris used in the syn-tax definition to indicate where a real number is to be used. A real number can be expressed in one of two fo
A real number can be of the form: <number>e<+\-><number>. A real number can be used to represent valuesnot 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, ‘is a capacitance expression. This generic reference can be used whenever one of the standard unit definallowed.
The following are examples of real number expressions:
time = ’25ns’;wattage = ’25mw’;slewrate = ’1v/1ns’;realvar = ’25e-9’;
} // end Category} // end Spec
Pattern pat {C { ’time = 23.5ns + 1.5ns/2’; } // time expressionC { ’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’; } // where realvar is of type ’Real’C { ’realvar = 5e-3’; } // where realvar is of type ’Real’
} // end Pattern
6.8 SignalVariable Expression ( sigvar_expr )SignalVariable expressions are enclosed in single quotes. Variables declared to be of type SignalVariable areWaveformCharacter list values, and signal references are assigned the value of Variables of type SignalVaria
A WaveformCharacter list value results by direct assignment of a WaveformCharacter list, variable of type Sigriable, or variable of type SignalVariableEnum in a sigvar_expr. It is an error to manipulate a WaveformCharacwith operators or functions.
The application of signal variables is to hold signal data and to pass signal data from pattern vectors, macroprocedure 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
The following are examples of signal variable usage:
6.9 Expressions and Operator PrecedenceTable 4 describes the usage of each type of variable and expression and where each variable type is defined. Tdoes not have a corresponding table in IEEE Std. 1450-1999.
Table 4—Variable and Expression Usage
expr-type variable types where defined where used syntax examples
engr_expr- time_expr- voltage_expr- etc.
timeintegerreal@label
SpecSignalGroupsSpecTiming
Timing ‘23.0ns/2+16.5e-9-t2’‘t1/i + r - t2’
real_expr timeintegerreal@label
SpecSignalGroupsSpecTiming
Pattern Same as an engr_expr exceptthat it may be used in a non-engrunit context. e.g. volts/ns.
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
types,oleanor),
. 1364.rs withinoup have
Table 5 is expanded from Table 5 of IEEE Std. 1450-1999, to identify operator usage in additional expressionand to define the following operators not supported in IEEE Std. 1450-1999: % (modulus), ! (negation), && (boand), || (boolean or), ~ (tilde, bit-wise negation), & (bit-wise and), | (bit-wise inclusive or), ^ (bit-wise exclusiveand ^~, ~^ (bit-wise equivalence). Logical behavior of these operators is the same as defined in IEEE StdTable 5 defines the allowed operators on each type of variable. The table is ordered by precedence. Operatothe bold line are of equal precedence and are processed left to right. Operators in each bold line separated grhigher precedence that the groups below them and shall be processed first.
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
plied inEE Std.STILreturn a
s/pro-
se 20).
6.9.1 MergedScan functionThe MergedScan() function returns a boolean value which is used to determine if scan operations are to be apa merged or unmerged fashion. The behavior of merged and unmerged scan is described in clause 5.5 of IE1450-1999. The evaluation of this function shall be in the context of the STIL consumer environment. If theconsumer environment has no specific needs for altering the merged scan operation then this function shalldefault value ofTrue.
This construct in conjunction with the If and Else constructs allow the STIL producer to generate STIL patterncedures/macros which represent both merged and unmerged scan operations. See annex N for an example.
7. Statement structure and organization of STIL informationThis standard defines two additional top-level STIL blocks: Environment (clause 19), and BistStructures (clauThese blocks relate to the top-level blocks of IEEE Std. 1450-1999 as defined below.
+ 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
Table 5—Operators and functions allowed in expressions
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
IEEE9 andt). All
td.ated in
pplica-
, andE Std.
l con-ultipleents for
rn
ifta, Pat-
7.1 Top-level statements and required orderingThe BistStructures blocks, if present, have a required ordering with respect to other STIL clauses defined inStd. 1450-1999. This ordering is shown in table 6. This table is incremental to table 7 in IEEE Std. 1450-199indicates the required position of the BistStructures block is following the ScanStructures blocks (if presenother definitions and requirements specified in Table 7 of IEEE Std. 1450-1999 remain unchanged.
7.2 Optional top-level statementsEnvironment blocks, if present, do not have adefinedorder with respect to other STIL clauses defined in IEEE S1450-1999. Environment blocks may appear any place a top-level STIL statement is allowed. This is delinetable 7, which is provided to be complete with table 8 in IEEE Std. 1450-1999.
Some applications of the Environment block may place ordering constraints to satisfy issues specific to the ation of this data.
8. STIL statement - Extensions to STIL0 clause 8The STIL statement identifies the primary version of IEEE Std. 1450-1999 information contained in a STIL filethe presence of one or more standard Extension constructs. The primary version of STIL is defined in IEE1450-1999.
The extension to the STIL statement allows for a block containing extension identifiers that allow for additionastructs in the STIL file. There may be multiple Extension statements present, to identify the presence of mextension environments. The extension name and the extension statements are defined in the individual documthose standards.
All other constructs and restrictions for IEEE Std. 1450-1999 clause 8 are in effect here.
8.1 STIL syntaxSTIL IEEE_1450_0_IDENTIFIER { (1)
( EXT_NAME EXT_VERSION; )+ (2)} // end STIL
Table 6—Additions 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 areoptional. If there are multiple BistStructures blocks they shall be named. The Pattemay contain a reference to a named BistStructures. BistStructures blocks shall bedefined before the Pattern blocks.
Spec As defined in IEEE Std. 1450-1999.
Table 7—Additions to Optional top-level statements
Statement Purpose
Environment Defines relationships of STIL data to external environments. Environment blocks, referencing other STIL data, shall be defined after the blocks that define that STIL daunless those references are to information contained in MacroDefs, Procedures, ortern blocks, which are allowed to be forward-references.
9. UserKeywords statement - Extensions to STIL0 clause 11This clause defines additional locations in a STIL file where the UserKeywords statement is allowed to appea
The UserKeywords construct is expanded from IEEE Std. 1450-1999, to allow the UserKeywords statemendefined within STIL blocks. When a UserKeywords statement is defined within a STIL block, those definitionsapply only within that block and contained sub blocks. This allows Userkeywords to be "locally scoped" to a coing STIL block.
All other constructs and requirements for IEEE Std. 1450-1999 Clause 11 are in effect here.
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
lable toattern-
purposeto con-ned for
s. Thelcula-
ariablestions,
startup { allsignals;}}
}
10. Variables BlockThis clause defines variables and constants. If the block is unnamed then all definitions shall be globally avaiall other blocks in the STIL file. If the block has a name, then that name must be referenced by the Pattern or PBurst for the variables to be available.
This block should be considered in light of the Spec block that also can define constants and variables. Theand usage of these two blocks is sufficiently different to warrent their separation. The Spec block is intendedtain parametric data used in specifying device/test characteristics. The Spec block has special handling defiCategory, Min/Typ/Max/Meas, and Selector which are to facilitate a flexible definition of these test parameterSpec block is designed to contain primarily constant values with one exception (Meas) which is to allow re-cation 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 vis to control flow of exectuion, to provide ’aliasing’ of values to meaningful names with Constants and Enumeraand to provide run time parameters.
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
ef theset ofValues
eblocks.
theeclaredof theplied isination
um,t onefinition
variable
f type
heto all
ll beinatedby the
non-tions
mal4. This
changes)
tbd: (TT 8/1/2002- Thetwo Usage statementsaboveshouldbeconsistent.But there is anotherproposalto identifythe usage along with the application (AI Jim Tiesher)
(1) VAR_NAME < Integer | IntegerEnum INTEGER_ENUM >: Each variable has a name followed by a typdefinition. The type is one of: Integer or IntegerEnum. IntegerEnum shall be followed by the name oEnumeration definition, which shall be previously defined. This statement is terminated by a semicolon, or abraces defining optional attributes. Variables are differentiated from enumerations by the absence of theattribute on these declarations.
(2) UsageSTIL_BLOCK_NAME: This optional attribute allow to specify in which block types a variable is allowto be used. i.e., The statement ’Usage Pattern;’ restricts the usage of the variable to be allowed only in pattern
(3) InitialValue : This optional attribute allows the specification of the initial value that is to be assigned tovariable at the onset of execution of the first or highest-level PatternBurst that uses this Variable. Variables dwith no InitialValue shall contain an undefined value until they are assigned a value (written to). The valueexpression defined on the InitialValue statement is not established until a context where this variable is apinitiated. This occurs under a PatternBurst that references a SignalGroup that contains this variable, in combwith the PatternExec that invoked this PatternBurst.
(4) INTEGER_ENUM IntegerEnum: Each enumeration is identified by a name, followed by the type IntegerEnfollowed by a required block of information. That block shall contain a single Values block defining at leasenumerated value for this declaration. For enumerations of type Integer, the Values block present in this deshall contain at least oneENUM statement and an optional assignment of an explicit value for thisENUM. If no value isassigned to thisENUM, then values are assigned with no external visibility. If anyENUM statement in a Values blockcontains a value assignment, allENUM statements in that Values block shall have value assignments.
Values: This required block contains allENUM values that may be used for thisENUM_NAME. The Values blockshall be present once in eachENUM_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 aof this enumerated type.
DECIMAL_INTEGER: The integer value that is assigned to this enum name. A value is optional for enums. oIntegerEnum. SeparateENUM declarations may identify the same value;ENUM values do not have to be uniquewithin oneENUM_NAME.
(5) CONST_NAME Constant = DECIMAL_INTEGER : declaration of a named variable that is equivalent to tspecified integer value in all applications. Constants declared in the Signals block are globally accessiblelogical_expr expressions and bracketed signal name constructs.
(6) VAR_NAME < SignalVariable | SignalVariableEnumSIGNAL_ENUM >: Each variable has a name followedby a type definition. The type is one of: SignalVariable or SignalVariableEnum. SignalVariableEnum shafollowed by the name of the Enumeration definition, which shall be previously defined. This statement is termby a semicolon, or a set of braces defining optional attributes. Variables are differentiated from enumerationsabsence of the Values attribute on these declarations.
Usage SimulationOnly: This optional attribute indicates that the named variable is intended to be used inATE applications. Typical uses would be for interacting with a simulation process or for defining condiprocessed during the translation process.
Base<Hex | Dec> WFC_LIST : This optional attribute defines the mapping from WFC characters to/from decior hex integer values, as defined for the Base option of SignalGroups in IEEE Std. 1450-1999 Clause 1statement is allowed only for variables and enumerations of type SignalVariable.
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
h thellowed
ent is
iablewith nof the
plied isination
pelockValues
terBase
n explicit
variable
tring of
ities as
Alignment: This optional attribute is used to specify the mapping from integer to SignalVariable is to start witMSB or the LSB. The default is MSB to accommodate the convention used for scan data. This statement is aonly for variables of type SignalVariable.
Length: This optional attribute defines the number of bits that are to be used in the integer value. This statemallowed only for variables of type SignalVariable.
InitialValue : This optional attribute allows the specification of the initial value that is to be assigned to the varat the onset of execution of the first or highest-level PatternBurst that uses this Variable. Variables declaredInitialValue shall contain an undefined value until they are assigned a value (written to). The value oexpression defined on the InitialValue statement is not established until a context where this variable is apinitiated. This occurs under a PatternBurst that references a SignalGroup that contains this variable, in combwith the PatternExec that invoked this PatternBurst.
(7) SIGNAL_ENUM SignalVariableEnum: Each enumeration is identified by a name, followed by the tySignalVariableEnum, followed by a required block of information. That block shall contain a single Values bdefining at least one enumerated value for this declaration. For enumerations of type SignalVariableEnum, theblock present in this definition shall contain at least oneENUM statement with an assignment of WaveformCharacvalues for thatENUM. The value is specified either as a WaveformCharacter list or as an integer or hex value. If astatement is present, then the assigned value is interpreted as Base value by default unless overridden by a\w. The \r may be used to specify a repeated WaveformCharacter.
Values: This required block contains allENUM values that may be used for thisSIGNAL_ENUM. The Values blockshall be present once in eachSIGNAL_ENUM block.
ENUM: The name assigned to an enumerated value and to be used when associating this named value to aof 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 sWaveformCharacters, or an integer value that maps into a set of WaveformCharacters. SeparateENUM declarationsmay identify the same value;ENUM values do not have to be unique within oneSIGNAL_ENUM.
11. Signals Block - Extensions to STIL0 clause 14This clause defines additional statements supported within the Signals block. All statements and capabil
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
gnal or
applies
n this
erered to8” on
eLow (Lntifies aa fortht
theto
defined in IEEE Std. 1450-1999 clause 14 are unchanged.
A new attribute, WFCMap, allows mapping WaveformCharacter values to other WaveformCharacters on a sigroup 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 syntaxSignals { (1)
( SIG_NAME < In | Out | InOut | Supply | Pseudo > {( WFCMap { (2)
The WFCMap attribute is defined for both Signals and SignalGroups (clause 12). This attribute defined hereto both environments.
(1) Signals: Refer to IEEE Std. 1450-1999 for the definition of the Signals block and statements not defined iextension.
(2) WFCMap is an optional attribute block.
(3) FROM_WFC -> TO_WFC(TO_WFC)+ : identifies a set of waveforms to use when theFROM_WFC waveform
contains a Substitute character; theFROM_WFCwaveform referenced shall contain a Substitute character when this more than oneTO_WFC character present. This statement supports the reverse mapping of information requisupport the CompareSubstitute. See “Timing Block and WaveformTable Block - Extensions to STIL0 clause 1page 35 for information about the CompareSubstitute event. The order of characters in theTO_WFC list is important:the first WaveformCharacter represents the waveform reference to use when the S state identifies a Comparevent) state, the second WaveformCharacter represents the waveform reference when the S state ideCompareHigh (H event) state, the third WaveformCharacter represents a CompareUnknown (X event), andWaveformCharacter represents a CompareOff (T event) state. A minimum of twoTO_WFC characters shall be presenin 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 tosame signal, one usingFROM_WFC1 and the other one usingFROM_WFC2, should be interpreted as having assignedthe WaveformCharacter valueTO_WFC instead. The two WaveformCharactersFROM_WFC1 andFROM_WFC2 need notbe separated by whitespace and are not order sensitive.
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
oo morely one
y onces not
Map is
to benged. IfWFC-
ilities as
. Addi-
iableE-presentedppears
d to thection of
E sys-efined
s not
01->x;//two-WFC mapping (requires presence of \j)}
}}
11.3 Application of WFCMap constructsTo use the mapping of a signal or signalgroup, two new flags are added to the cyclized pattern data:\m indicates thatthe defined mapping from a single FROM_WFC should be used;\j indicates that the defined mapping from twFROM_WFC1 FROM_WFC2 should be used. When \j is used, both assignments shall be preceded by \j. Nthan two \j-assignments to the same sigref_expr may occur in the same vector or condition. If there is onassignment 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 onli.e., the mapped TO_WFC is not subject to further mapping. If \m or \j are used for a sigref_expr which doedefine a WFCMap, then the components of sigref_expr are descended until the first corresponding WFCfound.
If the vector mapping \m is used but no WFCMap has been defined for the WaveformCharacter FROM_WFCmapped (for sigref_expr or its components), then the same WaveformCharacter FROM_WFC is used unchathe vector mapping \j is used for two assignments of FROM_WFC1 and FROM_WFC2 then the correspondingMap shall be defined.
12. SignalGroups Block - Extensions to STIL0 clause 15This clause defines additional statements supported within the SignalGroups block. All statements and capabdefined 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 blocktional 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, SignalVarnum, IntegerEnum, or Constant. These variables, once defined, may appear in appropriate expressions, asin clause 6. Variable declarations are differentiated from SignalGroup declarations by the type keyword that aimmediately after the name.
Be aware that Spec variables, defined in IEEE Std. 1450-1999 clause 19, have different functionality comparevariables defined here. Spec variables may be referenced in logical expressions, but the value applied is a funthe 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 ATtem, in general most ATE systems will be able to support only a limited sub-set of the design capabilities dherein. The full capabilities are intended for use by simulation applications or pattern translation tools.
// 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 valueThe WFCMap attribute, if not present on a declaration, is undefined for that signal or signalgroup reference. Iping is required for every use of a signal, all SignalGroups that contain that signal need a WFCMap that definmapping required for that signal.
13. PatternBurst Block - Extensions to STIL0 Clause 17This clause defines additional statements supported within the PatternBurst block. All statements and capabdefined in IEEE Std. 1450-1999 Clause 17 are unchanged.
Two new pattern grouping structures are defined - the ParallelPatList and the PatSet. Also, the Fixed, ExteWait 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.
} )* // end pat_name_or_burst_name} )* // end ParallelPatList
(1) PatternBurst: Refer to IEEE Std. 1450-1999 for the definition of the PatternBurst block and statementdefined in this extension.
(2) Variables: This statement allows reference to a named block of variables to by allowed by all patternpattern 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 statestatement may be associated with a pattern or burst within a PatList, PatSet, or ParallelPatList. It requires thaof signals in the sigref_expr not be used in the associated patterns, but remain fixed in the state that they are dprior 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 differenthe scope. The Fixed statement within a pattern is in effect from its occurrence to the end of the pattern, wherFixed 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 rephere to show the new optional statements that are allowed within a pattern list, namely the If and While attrib
(5) If : This attribute defines a conditional requirement on the execution of thePAT_OR_BURST_NAME; this blockwill execute only if theboolean_expris True. The expression is evaluated at the point this reference would staexecute in the sequence defined.
The If statement determines whether the statements within the block are to execute or not. The statements witblock have the same effect and scope as if they were to be executed outside of the block - i.e., the statement "{ 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 thePAT_OR_BURST_NAME; this referencewill be executed repeated times as long as theboolean_expris True. The expression is evaluated each time threference would start to execute; pattern sequencing iterates on this reference until the expression returnsFalse.
(7) PatSet: This block defines a set ofPAT_OR_BURST_NAME that have no requirement on the order of executioof each reference. This construct is intended primarily for defining data in an interim format prior to being pres
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
esented
erpret-grator isfined in
uired isequiredguity of
lapping.arallel-
yof the
in a
ontain
onship
ations havetest (forat haves limitedge 31..
rn to
tion of
ing in
. If thely until
als shall
to a tester, to identify a set of Patterns that have no external constraints on order of execution. If this data is prto 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 inting them. The difference is that the PatSet does not imply any sequencing requirements. Thus, the system intefree to take that Patterns and use them in any sequence desired. All of the optional statements that are deSTIL.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 reqdone within the pattern and not dependent on the execution of a prior pattern. Also, because there is no rordering of Patterns in this block, If and While statements are not supported for these blocks because of ambiexpression evaluation.
The PatSet is not used to do implicit parallel patterns, even if the set of signals between patterns are non-overTo do this, you need to define two bursts that contain PatSets, and reference them in a higher level with a PPatList.
(8) ParallelPatList ( SyncStart | Independent | LockStep ): This block defines a set ofPAT_OR_BURST_NAMEthat are to be executed in parallel. Execution of this set of Patterns is controlled by optional argumentsSyncStart,Independent, or LockStep, as well as the optional statementsWait andExtend. Parallel patterns do not necessarilrun synchronously or finish together. If no arguments are specified to ParallelPatList then the default operationPatterns isIndependent. All of the optional statements that are defined in STIL.0 for PatList also are availableParallelPatList block.
SyncStart: this keyword, if present, requires that allPAT_OR_BURST_NAME present in the ParallelPatList blockshall start executing at the same moment. During execution, pattern behavior may diverge if patterns cdifferent Vector counts or different periods in the Vectors.
Independent: this keyword, if present, allows eachPAT_OR_BURST_NAME present in the ParallelPatList blockto start as convenient. This option indicates that the set of patterns executing in parallel have little or no relatibetween each other and can be executed independently.
LockStep: This keyword is used to specify parallel testing of cores (sub designs) that require synchronizthroughout the pattern execution. A lockstep application may be used for situations where parallel corecommon access constructs that require maintaining the same state on a set of signals for the cores duringinstance, common wrapper control logic around cores). Lockstep may be used for parallel testing of cores thserially connected scan chains. Lockstep can also be used to map patterns onto test equipment that hatiming flexibility that prevents true independant execution. See “LockStep Explanation and Example” on pa
(9) Wait : This statement signifies that all other patterns that are running in parallel are to wait for this patteterminate.Wait is incompatible withLockStep; it is an error to specifyWait in a PAT_OR_BURST_NAME blockunder a ParallelPatList block that definesLockStep.
Extend: This statement signifies that the last vector of this pattern may be extended in order to wait for compleother parallel patterns. The behavior of Signals during Extend is described in clause 13.4.Extend is incompatiblewith LockStep; it is an error to specifyExtend in a PAT_OR_BURST_NAME block under a ParallelPatList blockthat definesLockStep.
If the Extend statement is not used, then the last cycle shall “tile” exactly with any other patterns that are runnparallel.
The behavior of the Signals during the Extend period is determined by the last STIL statement in the Patternlast statement in the Pattern is a "BreakPoint;" then all Signals will maintain the last asserted state indefinitethe parallel set of Patterns is complete. If the last statement is “BreakPoint { V { ...} }”, then the Vectors present inthis 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 Signbe maintained indefinitely as if a "BreakPoint;" statement was present in the Pattern.
13.3 LockStep Explanation and ExampleThis sub-clause explains in detail the semantics of the LockStep operation.
timing andsequencing - Each pattern in the ParallelPatList shall start executing at the same time, each vectorpattern shall start executing at the same moment in time, and each vector shall have the same period. Whenis defined for a set of parallel patterns, these patterns shall enter and exit all data-dependent pattern construcallel as long as the patterns are executing in parallel. In particular, lockstep patterns shall enter a shift blockdata block at the same point in the execution sequence, and shall finish executing these blocks at the samesupport this behavior, the definition of normalizing the length of data for each of these blocks is extended as
-- For all shift blocks in parallel, the length of the scan data is defined as the longest data length of all signals"#" across all shift blocks. To facilitate this determination, it is required of the integration process that the sgroup definitions be adjusted such that the ScanIn/ScanOut-integer attribute defines the length to which eachgroup is to be padded, and this value shall be used rather than padding to the longest scan chain length of anual pattern.
-- For all loop-data blocks in parallel, the length of the loop data is defined as the longest loop required by anypatterns. All other patterns shall pad additional passes through the loop using the default state.
shift orderingon serial scansignals - When there are serially connected scan signals, the scan data is comaccording to the following rules. The data assigned to each scan signal in common in each shift block executedallel across all patterns in the parallelPatList, is the concatenation of the scan data for each reference to this seach of the shifts executed in parallel. The data is concatenated in the order that the patterns are referenced inallelPatList block. The first pattern in the list is the first to shift in and the first to shift out. Please see the exbelow.
shift paddingon serialscansignals - When there are serially connected scan signals, the scan data padding isaccording to the following rules (consistent with the rules as defined in IEEE Std. 1450-1999). Scan shift paddone by first concatenating each serial scan signal. Then the length of each scan signal is determined by theeach segment. Then the shorter combined scan signals are padded to the same length as the length of the larbined scan signal. Please see the example below.
procedures,macros,andshifts - All patterns in the lock-step group shall have the same procedure and macro ac
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
All pro-at the
ere ares share asame.lved inxception
or L as
eduresall oflled pro-d abovegroup
by theof thellel pat-
de onthat istep, thet are toe lock-at inter-
d. 1450-
- i.e., procedure/macro calls shall occur at the same point in each pattern and shall be of the the same length.cedures/macros in the lock-step group shall have the same shift-block activity - i.e., shift-blocks must occursame vector position in the procedure/macro.
signaloverlap - In general, parallel patterns should operate on separate disjoint sets of signals. However, thcases where the same signal appears in two or more patterns. Such may be the case where two identical corecommon input sigal. The basic rule of signal overlap is that the WFC and the WFT that resolves it shall be theOne exception to the WFC rule is when the ’N’ event is used, in which case a shared input signal may be resofavor to the pattern that has a required state (i.e., N can be interpreted as either U or D as needed). The other eto the WFC rule is when the ’X’ event is used on an output signal (i.e., the X event can be interpreted as a Hrequired).
procedureconsiderations - In the case where parallel patterns call procedures, it is a requirement that the procbe called in parallel. The set of signals in all of the called procures shall, in combination, define the activity forthe signals. In general, it is expected that there be a one to one relation between the calling pattern and the cacedure, but this is not always the case. If there is overlap in the signals, then the signal overlap rules defineapply. If there are any missing signals, then they follow the normal default to the state defined in the Signalsblock, else the initial default state.
setupmacro - Each pattern is required to define in the initial V or C statement the set of signals that are usedpattern. This is typically done in a setup macro. This setup macro should limit the definition to only the signalspattern and not the entire signal width of the design. Note: Defining signal states that are used in other paraterns will preclude the use of the lock step operation, and indeed, any parallel pattern operation.
scanchainlengthdetermination - When patterns are executing in lock-step mode, an additional constraint is mathe normalizing of scan chain data in that the scan chain length is determined by the decimal integer valuespecified in the ScanIn/ScanOut statement. In the process of preparing multiple patterns to execute in lock-slength of the longest scan chain (for the specific device or pattern set) is to be specified for all scan chains thabe loaded/unloaded in parallel. If the length specified for one device or pattern set is shorter than others in thstep group, then the shorter scan chains shall be normalized to the length of the longer chains. The process thprets/loads the scan data shall pad the scan chains to the length specified according to the rules of IEEE St1999.
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 {
13.4 Pattern Tiling and SynchronizationPattern tiling is the process of connecting patterns together end-to-end in time and side-to side by signal. Forpose of specifying the desired actions when a PatternBurst contains patterns that may be run in parallel, the fostatements 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 cla
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 paExtending means that the state of all signals at the end of the last vector of the pattern can be heldtively 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 ve
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
or Pat-
he Pat-Vari-
ck. All
areSub-rovidednvi-
pat_c.
13.5 If and while statementsConditional PatternBurst statements If and While defined here allow selective execution of a complete PatternternBurst based on the evaluation of a boolean expression.
The following example defines two Pattern Variables whose scopes are the pattern burst named “with_vars”. Ttern Variablecounter has an initial value determined by evaluating the expression ‘t_Per / 25ns’. The Patternablefailure is initially given an undefined value.
} // 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.
14. Timing Block and WaveformTable Block - Extensions to STIL0clause 18This clause defines additional constructs supported within the waveform statement of a WaveformTable blostatements 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 CompstituteWindow. This event is used to resolve event data with actual response during test generation, and is pprimarily to support returning diagnostic information as presented in “Diagnostic Information in "non-failure" Eronments (informative)” on page 76.
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
o Table
turn the, but an
ubsti-e or the
Wave-s whatte. If no
or thisd with
onality(Shift)
gic and
ate ele-nally. Aned by
ne scanned. Sta-ationgle scanunload
lue
14.1 Additional waveform event definitionsThe following table defines the additional Compare character CompareSubstitute. This table is incremental t10 of IEEE Std. 1450-1999.
14.2 CompareSubstitute OperationThe CompareSubstitute event allows stimulus to be defined for device test, and supports a mechanism to redevice response to this stimulus. How this response information is returned is outside the scope of this effortexample is provided in annex I.
The CompareSubstitute event is expected to be found only once in a waveform definition. If multiple CompareStute characters are present in one waveform definition, then all Compare operations shall return the same valuCompareUnknown state shall be returned.
The CompareSubstitute event is expected to be defined in conjunction with a WFCMap definition for eachformCharacter that represents a waveform containing the CompareSubstitute event. The WFCMap defineWaveformCharacter values are returned for each of the supported state values returned by CompareSubstituWFCMap is defined, or a WaveformCharacter for a specific Compare value is not defined in the WFCMap fwaveform, then the return information is not mapped to waveform references, but explicit \e events are returnethe Vector data, as defined in Clause 13.3.
15. ScanStructures block - Extensions to STIL0 clause 20Simulation of scan patterns outside the test-pattern generator is often performed to verify timing, design functior the library used to generate the patterns. The speed of the simulator is limited by simulating the load/unloadoperation of scan chains. Optimal simulation performance is achieved with no shifts, bypassing scan chain loasserting/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 stment that is loaded/unloaded by a single element of the scan chain data, but may contain multiple states interrelated operation is that of loading multiple state elements from multiple elements of a scan chain which is defiusing the ScanModule statement.
A scan cell may contain one or more state elements in various configurations. All state elements defined in ocell access a single scan bit value; one scan bit in the data stream is allocated to each scan cell construct defibility and capture ability are identified for each state element in the scan cell, in addition to the inversion informwith respect to both scan input and output by scan-oriented test pattern generators. For example, loading a sinbit may require setting values in several state elements. Additionally, there may be extra cycles in the load or
Table 8—Compare events
Identifier Icon Definition
S CompareSubstitute Perform a Compare operation at this time, and return the vaof the resulting operation as a CompareHigh, CompareLow,CompareUnknown, or CompareOff value.
s CompareSubsti-tuteWindow
Perform a Compare operation over a period of time, and returnthe value of the resulting operation as a CompareHigh, Com-pareLow, CompareUnknown, or CompareOff value. Terminatedby a CompareOff event.
— 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 scaterns, i.e., eliminating the need to simulate load/unload (Shift) cycles. Additional constructs are defined on theCell statement inside the ScanChain block. In addition, an ScanModule statement is added in the ScanStblock to support referencing previous ScanChain definitions from other ScanStructure blocks.
All other constructs and requirements for STIL0 clause 20 are in effect here.
(1) ScanStructures: Refer to IEEE Std. 1450-1999 for the definition of the ScanStructures block and statemendefined in this extension.
(2) ScanLength integer_expr : As defined in IEEE Std. 1450-1999, with the extension to support inteexpressions.
(3) ScanOutLength integer_expr: As defined in IEEE Std. 1450-1999, with the extension to support inteexpressions.
(4) ScanEnable logical_expr: This optional statement allows designation of a single Signal or a compexpression to represent the design constraints, if any, necessary to allow access to the scan shift operationscan chain. See example usage in Annex C.
(5) ScanCells: This statement shall appear at most once in a ScanChain block. It shall contain a combinationscan cell names as defined in IEEE Std. 1450-1999, b)cellname_listas defined in clause 6.3, c) scancell block, ora 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 sequencurrently being defined scan cell list. The scan segment is defined as follows:
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
e
nced.
ee
by
ructure
ssible
her
r
er
whereSCANSTRUCTis the name of a ScanStructure block,SCANCHAIN is the name of the desired chain in th
ScanStructure block, andINSTANCE is a username that is assigned to each instance of the chain being refereSee example below for more detail.
(6) (If boolean_expr): Optional conditional clause on the CellIn and CellOut statements. The value ofboolean_expris evaluated during pattern operation. WhenTrue, the following CellIn or CellOut statements are applied. Sclause 6.6 for information aboutboolean_expr.
STATE-ELEMENT is a name andSTATE-ELEMENT-LIST is a list of names of state elements separated
whitespace. State elements are internal design nets ofCELLNAME. Inversion is indicated by inserting the “!”character before or after names. When CellIn and CellOut constructs are inherited through InheritScanStconstructs, the names of all inherited state elements are prefixed with theINST_NAME (and a period) to identifyspecific instances of these state element names.
CellIn : This is an optional statement indicating that the nets inSTATE-ELEMENT-LIST are to be loaded with thedata 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 followsthe “!” then the inversion is inside the cellCELLNAME, between the cell input and the state element.
CellOut: This is an optional statement indicating that, when the boolean_expr is true, the netSTATE-ELEMENT isto be unloaded (into the cellname-ref) with the data value corresponding to the current scan cell, with poinversion as indicated by a “!” character. A “!” indicates inversion between the name preceding the “!” and theoutput of the scan cell. If no name precedes the “!” then the inversion is inside the cellCELLNAME, between thestate element and the cell output.
BothCellIn andCellOut statements may be qualified by Ifboolean_expr. This indicates that the nets in theCellInandCellOut statements are only to be considered in a pattern where theboolean_expris True. The following casesare all valid forCellIn :
The following cases are all valid forCellOut:
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, otloads use their corresponding CellIn statement.
Both simple CellIn andboolean_expr CellIn statements
No load operations are to be simulated. Load operations when allboolean_expr areFalse use the simple CellIn statement, other loads use theicorresponding CellIn statement.
No CellOut statement All unload operations are to be simulated.
CellOut statement No unload operations are to be simulated.
boolean_expr CellOut state-ments
Only unload operations when all pat_exprs are false are to be simulated, othunloads use their corresponding CellOut statement.
Both simple CellOut andboolean_expr CellOut state-ments
No unload operations are to be simulated. Unload operations when allboolean_expr areFalse use the simple CellOut statement, other unloads usetheir corresponding CellOut statement.
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
nals andn cells
ss theseviron-
poratedequire-follow-
hain for
15.2 Example indexed list of scan cellsThe ScanCell naming constructs allow cells to be expressed as a list using the same notation defined for SigSignalGroups in STIL0 clause 6.10. An example is shown below. Note that the presence of inversion betweerequires multiple sets of cellnames to be present to represent the inversion at the correct point in the list:
/* Once a scan chain is defined as an indexed list, then it can be referenced in statements that need to accecells, as shown in the following example. Note: This example is taken from 1450.6, but since it is within an Enment 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 ScanStructuresThe ScanModule block is used when a previous ScanChain found under one ScanStructures block, is incorinto another ScanStructures block. This mechanism allows for hierarchical scanchain declaration, with the rment that the previous ScanCell declaration be precisely maintained in this new ScanStructures context. Theing 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 scancmodule Custom1. The following ScanStructures supports this representation:
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
E Std.
r in two
ype. This
ractersed any-gainst
ge 24,-signalt wave-
ScanChain A {Scancells {
CPUX:A:INSTANCE_A;// use ScanChain A with label INSTANCE_A from CPUXCPUX: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 21This clause defines additional formatting capabilities for defining pattern data. All statements as defined in IEE1450-1999 clause 21 are unchanged.
16.1 Cyclized DataThe cyclized data construct is expanded to support the use of logical expressions. Logical expressions appeacontexts under cyclized data:
sigref_expr= logical_expr;logical_expr;
When assigned to asigref_expr, the logical expression shall be asigvar_expr, or of type Integer and thesigref_exprofBase Integer. When a logical expression is used as a complete statement, the expression is of any supported tform of statement is used to manipulate Variable values.
16.2 Vector data mapping and joining - \m and \jThe vector data mapping function allows for a new waveform definition to be selected for a given waveform chain a vector. This is most useful in the case of parameter passing to a macro or procedure, however can be uwhere a waveform character string is formed. The “Join” function allows to have two WaveformCharacters athe 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 paand “SignalGroups Block - Extensions to STIL0 clause 15” on page 26 is used to specify the mapping on a peror per-group basis. This data, in conjunction with the \m and \j in the pattern data, together specify the resultanform character to use in resolving a vector.
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
ters orse spe-
(inputown.lationChar-
ll
The \m and the \j operators may be used in a stream of pattern data which typically is a list of waveform characthings that resolve to a list of waveform characters. The following are examples of pattern data containing thecial characters:
Macro m {V { all = 1100 \m1100; } // map the second group of 4 wfc’sV { all = 1100 \m 1100; } // space after the \m is allowedV { all = \m 1100 1100; } // map only the first 4 wfc’s (i.e., up to the space delimiter)V { all = 1100 \m####; } // map wfc’s that are passed as parametersV { all = 1100 \m’varx’; } // map a signal variableV { sig=A; sig=\jB; } // sig is resolved by the joining of wfc-A and wfc-BV { sig=A; sig=\j\mX; } // sig is first mapped then joined with wfc-AV { sig=A; sig=\m\jB; } // ERROR - a map after a join is not allowed
}}
16.3 Specifying Event Data in a PatternWhen specifying data for simulation stimulus, it is often times the case that the desired level of a given pindrive or output compare) is known while the exact timing waveform which is appropriate for the cycle is not knThis, in many cases, is why simulation for test generation is done. The simulator (or STIL consuming co-simuengine) would use the raw data, and the conditions of the device under simulation to determine the WaveFormacter which will be included in the test pattern.
Syntax Definition:
The base override flag, “\e” shall be added to thevec_dataflags for specifying raw event data. The \e applies to acharacters that follow until the occurrence of a space or a semicolon. Raw data shall take the following form:
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
cters, sinceand
ions of
Example:
The following Pattern block indicates how data can be specified without first knowing which waveform charashould be used to reference to the WaveformTable. A WaveformTable reference is still made in a raw patternthe successful waveform will ultimately come from that table. This example also illustrates the ability to mix rawresolved data using the CLK signal.
17. Pattern Statements - Extensions to STIL0 clause 22This clause defines additional statements that are allowed within the Pattern block. All constructs and definitIEEE Std. 1450-1999 clause 22 remain in effect.
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
h 3 itniquence in
e
currentanner asnt.
mentsdefined in
s the
e set
xternalthis
ent, if
tor is
plieduch asd loop,ount is
ed)pattern
inceet is
oopslue untils in the
(1) If boolean_expr: defines a block ofPATTERN_STATEMENTS to be executed only if theboolean_expris True. Thevalue of boolean_expris determined at the point that execution reaches this statement. The optionalElse blockcontains pattern statement that are executed ifboolean_expr is False.
With regard to usage of If/Else within a Shift block, the following rule applies. In 1450-1999, p114, paragrapstates that "A particular sigref_expr shall appear only once in a Shift block. Consecutive shift blocks require usigref_exprs for each Shift statement". The rule shall now be that a particular sigref_expr shall appear only oa Shift block for any given execution path as governed by the If/Else conditions.
(2) While boolean_expr: defines a block ofPATTERN_STATEMENTS to be repeatedly executed as long as thboolean_expr isTrue. The value ofboolean_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 thevalue). Fixed statements do not define event sequences and are executed in zero-time, in the same mCondition statements defined in IEEE Std. 1450-1999. See clause 17.3 for complete definition of this stateme
(4) E(quivalent) : Statement to establish WaveformCharacter relationships between signals. Equivalent statedo not define event sequences and are executed in zero-time, in the same manner as Condition statementsIEEE Std. 1450-1999. See clause 17.3 for complete definition of this statement.
(5) ScanStructuresSCAN_NAME : The ScanStructures statement, when used within a pattern block, specifieset 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 thof 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 eapplication. The keyword "X" is intended to imply "cross-reference". See clause 17.4 for information onconstruct.
TAG. A user defined name (as defined in IEEE Std. 1450-1999 clause 6.8). For the block form of the X statemno 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 veccounted as vector number 1.
Iteration ITERATION_CNT. The number of iterations that the following vector being referenced has been apincluding the current iteration. This is associated with vectors which are surrounded by Loop constructs scan be defined with Loop, MatchLoop, and Goto statements. If the vector being referenced is within a nestethe iteration count will be the total iterations that the vector has been applied across all loops. The iteration calways a positive integer.
PatternOffset VECTOR_CNT. The number of vectors executed (not including the following one being referencsince the beginning of the pattern. The Offset vector count is a non negative integer. The first vector of theis counted as 1.
TagOffset VECTOR_CNT. The number of vectors executed (not including the following one being referenced) sthe last cross-referenceTAG was established. The Offset vector count is a non negative integer. If no offsspecified then the default is zero.
(8) Loop Data : The Loop construct is expanded to support the keyword Data. This construct is used only for Linside Macro and Procedure bodies. This Loop statement iterates, replacing each ’#’ parameter with a data vathere are no more data values defined. It is an error if all data values are not consumed by the ’#’ parameterLoop.
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
oop
equence.) or foral does
forma-
d of thecaller.ndantlydefine ant does
ivalencesion isplied.xpres-equiva-assign
nds the
(9) Loop integer_expr: The Loop construct is extended to allow a variable expression of type integer. The Lstatement iterates for the number of times indicated by the evaluation of the expression.
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 EquivalentStructured test patterns often have signals constrained to have a certain value or waveform during a pattern sThis may be required, for example, for ATPG scan rules checking (such as a test mode signal always activedifferential scan or clock inputs. These constructs help reduce pattern volume, as the value of a constraint signnot need to be specified explicitly in the pattern data. Also, ATPG rules checking requires signal constraint intion as input.
The "Fixed" statement is used to define stimulus and/or response fixed for all subsequent vectors, until the encurrent Pattern or Procedure. Every Procedure starts its own environment, not inheriting Fixed data from itsUpon return from a procedure, the Fixed values of the caller are re-instantiated. Subsequent vectors may redudefine the same WaveformCharacter assignments as in the Fixed statements; however, no vector is allowed toWaveformCharacter assignment in contradiction with the Fixed statements in effect. The Fixed pattern statemenot 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. Equimplies that the signals are assigned the same WaveformCharacter. Additionally, a signal or signal expresoptionally preceded by\m to indicate that the WaveformCharacter is to be mapped before the equivalence is apAll signal expressions in sig-expr-LIST shall have the same number of signals; the first signals of the signal esion are equivalent, the second signals of all signal expressions are also equivalent, etc. The scope of theselences extends for all subsequent vectors, until the end of the current Pattern or Procedure. Vectors mayWaveformCharacters to any non-empty subset of equivalent signals and the equivalence relationship exteassignment to the other signals in the equivalence class. For example, in:
/* SIG_NAME1 and SIG_NAME2 have the same WaveformCharacter; assigning a WaveformCharacter to onthese 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 andputs: */Pattern pat2 {
Every Procedure starts its own environment, not inheriting Equivalent data from its caller. Upon return from adure, the Equivalent values of the caller are re-instantiated. Subsequent vectors may redundantly define thWaveformCharacter assignments as in the Equivalent statements; however, no vector is allowed to define aformCharacter assignment in contradiction with the Equivalent statements in effect. The Equivalent pattern stadoes not result in a tester cycle, but constraints and sets values for all following cycles within its scope.
17.4 X (cross reference) statementThe X (Cross-Reference) statement may be used to “tag”, as well as refer to, positions within a STIL Pattern bbeing important cross-reference points. Any vector may be preceded by an X statement, thereby associatingtor to the given cross-reference “tag”. Unlike Labels, the cross-reference “tag” may be identical on multiple veThis 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 tX statement is used in two contexts. First, the STIL pattern block is augmented with X statements to “tag” key vduring test generation. Secondly, the failures collected, when applying the patterns at the tester, are logged aconverted into a STIL failure file. This failure file will contain X statement cross-references to correlate the faback 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-referencThe block form shall be used to refer to a cross-reference “tag” and to convey offset information relative to thatreference 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 block’s (i.e. mainline STIL file or procedure or macro block) current X statevalue. I think we would
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
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 examplesThe following are examples of X statement usage:
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
state-ents andhe Shiftp Data
In orthe
) a
ntain
X “inner_bist_33” { Iteration 5004; }V { refpin=L; }
} // end Pattern
17.6 Loop Data and Shift statementsThe Loop Data and the Shift statements perform similar functions - the will loop over a sequence of patternments; they may be used only in procedures or macros; they take parameters from the calling pattern statemapply the parameters to signals; they take signal-variable data and apply it to signals. The difference between tand Loop Data is that the Shift is specifically designed in support of scan load/unload operations, whereas Loois 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 ScanScanOut attribute in the Signal or SignalGroups block. This is as opposed to implying the shift frompresence of # characters.
2. Foreach ScanIn/ScanOut signal within a Shift block, the shift data can be defined in two ways: aparameter defined by # notation; b) an in-line series of wfc’s
3. Within a Loop Data construct at least one WaveformCharacter assignment inside this Loop shall coa ’#’ 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:
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
plies tosage:
V {si1 = 10101 ‘ABC’ 10101; // ABC is a SignalVariablesi2 = 10101 ‘ABC’ ‘DEF’ 10101; // ABD, DEF are two SignalVariable’ssi3 = 10101 ‘XYZ[1]’ 10101; // with indexed SignalVariablesi4 = 10101 ‘XYZ[11..20] 10101; // with multi-bits of a SignalVariablesi5 = ‘\w10101 ABC \w10101’; // illegalsi6 = 10101 ‘ABC DEF’ 10101; // illegal
} // end V} // end Shift
) // end shift_load} // end Procedures
Pattern run1 {Call variable_loop { sig1=010; } // Loop 3 times (’010’ is wfc-list)Call variable_loop { sig1=00000; } // Loop 5 times
} // end Pattern
Pattern run2 {Call shift_load {
ABC=1100;XYZ[1..20]=11111000001111100000;DEF=101;
} // end Call} // end Pattern
17.7 Loop Statement Using an Integer ExpressionThe Loop statement as defined in STIL0 is extended to allow the use of integer expressions. This extension apclause 22.6 "Loop statement" and to clause 22.7 "MatchLoop statement". The following are example of this u
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
lity to
name toher proce-the pro-
ocedure,erenceedure or
exam-speci-ific for
18. Procedure and macro data substitution - Extensions to STIL0clause 24.5All constructs and definitions of IEEE Std. 1450-1999 clause 24.5 remain in effect, with the additional capabipass 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 argumentreference that data, as was used to specify that data to that procedure. Data cannot be passed into anotdure or macro call using a different signal or groupname on that data than was used to pass that data intocedure.
— Data passed into another procedure or macro is considered to consume all data values passed into the prin that procedure or macro call. The procedure or macro calling another procedure or macro shall not refthe parameters passed to that called procedure or macro directly, except to pass them to the called procmacro.
An example of a proper environment to pass data through procedure or macro calls is:
19. Environment blockThe Environment block contains constructs to cross-reference STIL information with other environments, forple a simulation or layout netlist environment. The Environment block may be used by tools that operate in thefied Environment and access STIL data. The Environment block may also contain additional information specthe particular environment.
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
refer-STIL
eclaredallowedocks iss. Theseinfor-
ned
toerited,ment forherited
ed in
a
ockblock
e of the
Because the Environment block references information not contained in the STIL environment, no STIL blocksence the Environment block. The Environment block is self-contained, but internally may reference otherblocks 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 d(with a UserKeywords statement) before they appear in the Environment block. These undeclared blocks arewith the same restrictions as a UserKeyword block. It is expected that the definition of these undeclared blfound in association with an extension definition. See clause 8 on page 20 for extension reference constructblocks, when present, shall follow all STIL syntax requirements for UserKeyword blocks. These blocks containmation specific to an Environment context (in STIL syntax form).
Type file_type;Format file_format;Version “VERSION_NUMBER” ;
} )* // end FileReference(ENVIRONMENT_DEFINED_STATEMENTS)* (11)
} // end Environment
(1) Environment: Defines an Environment block.
ENV_NAME: Optional name of the Environment block. A single global Environment block may be defiwithout a name.
(2) InheritEnvironment ENV_NAME: Statement to reference a previously-defined Environment block,incorporate the definitions of that block as part of this block. Only statements with defined keywords are inhthat is: SignalGroups, NameMaps, and FileReference statements or blocks. See the InheritNameMap stateinformation on how NameMaps are inherited. If a FileReference block has the same name locally as an inFileReference, 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 definan external Environment. TheMAP_NAME is optional when a single NameMaps block is present; theMAP_NAME isrequired if multiple NameMaps blocks are present. TheMAP_NAME shall be unique across all NameMaps blocks insingle environment when present.
(4) InheritNameMap ENV_NAME(.MAP_NAME): Statement to reference a previously-defined NameMaps blinside a previously-defined Environment block, to incorporate the definitions of the NameMaps section of thatonly as part of this block. If an unnamed NameMaps block is referenced, then only theENV_NAME is required toreference that NameMaps block. If the referenced NameMaps block has a name, then a complete dotted namENV_NAME.MAP_NAME is required to reference that NameMaps block. A local definition of aCELLNAME,SIG_NAME, GROUP_NAME, VAR_NAME, or ANY_NAME will override any inherited definitions for those names.
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
runder a.
e
samedefined
l
cifySTIL,
are inanism
User
s for
n
theefined
ntainsfor any
(5) ScanCells: Block to contain ScanCell references. Required ifCELLNAME map information is provided.
CELLNAME “MAP_STRING”: Statement to map the STILCELLNAME defined in a ScanCells block undeScanStructures ScanChain, into the name used in the external Environment. All scancell names are definedsingle namespace; a reference to a specific ScanStructures block is not necessary to resolve these names
(6) Signals: Required ifSIG_NAME map information is provided.
SIG_NAME “MAP_STRING”: Statement to map the STILSIG_NAME defined in a Signals block, into the namused in the external Environment.
(7) SignalGroups: Required ifGROUP_NAME map information is provided.
GROUP_NAME “MAP_STRING”: Statement to map the STILGROUP_NAME defined in a SignalGroups block,into the name used in the external Environment.
(8) Variable: Required ifVAR_NAME map information is provided.
VAR_NAME “MAP_STRING”: Statement to map the STILVAR_NAME defined in a Category or Spec block, intothe name used in the external Environment.
(9) AllNames: This optional block supports an Environment that does not partition namespaces with thestructure as STIL, and supports mapping of names from additional STIL constructs (such as objects in user-blocks).
ANY_NAME “MAP_STRING”: Statement to map any STILNAME, into the name used in the externaEnvironment.
(10)FileReference“FILE_PATH_NAME” : The FileReference statement is used within an Environment block to spevarious other files associated information. The content and application of the referenced files is not specified inbut is the responsibility of the tool or application using the Environment block. For instance, if the patternsSTIL then they would be Included, but if the patterns were in WGL or some tester-specific format, this mechwould 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 elsefollowed 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 formatthe 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 informatioof theVERSION_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 followSTIL requirements, but do not require a UserKeyword statement to identify these blocks. The environment dstatement and semantics associate with the specification for the extension as identified in the STIL {} block.
19.2 "MAP_STRING" SyntaxThe target "MAP_STRING" is used to map STIL names into an external environment. If the target name coeither a double-quote or a back-slash, then the following syntax shall be used in the target string. It is an errorcharacter other than double-quote or back-slash to following a single back-slash.
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
ple of
-quote is
yntax
struct,
error: "blah_blah\blah_blah"
A typical useage of this back-slash notation is in mapping strings into Verilog names. The following is an examthis 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 doublepart of the name. The outer double-quotes are delimiters in both STIL and Verilog representations.
/* The following code is borrowed from 1450.6. Since it is within the Environment block it is also acceptable sfor 1450.1, although only a CTL parser would know how to interpret the syntax. */
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; IsEnabledBy In Signal B5 ForceUp;}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; IsEnabledBy In Signal B6 ForceUp;}s1 { IsConnected In InternalSignal CoreB d1; }s2 { IsConnected Out InternalSignal CoreB q0; }s3 { IsConnected Out InternalSignal CoreB q1; }
}}
} // end Environment
19.4 NameMaps ExampleThe NameMaps block relates STIL names to external environments. An example of an application of this con
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
(suchse theonnec-
their
ned.
the
r,
e the
l, not
lies tocond
20. BistStructures b loc k (to be removed from the document?)The BistStructures block allows CAD tools (such as ATPG and simulators) to check BIST-related design rulesas X-propagation) and to compute BIST signatures. The simulation of BIST functions is very efficient becauinternal gates of the BIST registers do not need to be simulated once the function of the BIST register and its ctions are known to the simulator.
(1) BistStructures: Block to define BIST structures i.e., a group of BistRegisters that operate in parallel, andcommon attributes.
BIST_NAME: Optional name of this BistStructures block. Required if multiple BistStructures blocks are defi
(2) BistRegister: Block to define a single BIST register. Multiple BIST registers may be defined inBistStructures 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 generatoSignatureAnalyzer 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 andLFSRExternal for linear-feedback shift registers with the XOR gates between the cells (instream) and outsidcells (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 functionaa scan clock.
(7) TapPositions: Identifies how the cells of the BIST register are connected to each other. The first format appall bits of the BIST register and identifies which bit positions are XORed to form the tapped input. In the seformat,Positionsinteger_listindicates to which bits of the BIST registerTapFrom integer_listapplies. Refer to Seeclause 6.5 on page 14 for definition ofinteger_list.
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
is) Forndth-1.into
st,cell 0,
typeiven
on. Anyd for auence of
d 0
ing this
notength.ample,value;value
thefault
e valuer, then
ISTd pulseength
ogic-Scan
For LFSR-type BIST registers, theinteger_list is a list of non-negative integer positions, 0 being the bit thatshifted out first (the bit at the opposite end as the XOR in a LFSRExternal-type input BIST register.LFSRInternal BIST registerinteger_list indicates cells whose output is XORed with the feedback of cell 0 ainput to the neighboring cell. In a LFSRInternal BIST register the output of cell 0 is always input to cell LengFor LFSRExternal BIST registerinteger_listindicates cells whose outputs are XORed to provide the feedbackcell Length-1.
For CA-type BIST registers, theinteger_listis a list of integer positions, 0 being the current cell, -1 its nearemore significant neighbor and +1 its nearest, less significant neighbor, such as neighbor -1 shifts out beforewhich shifts out before neighbor +1. The cells identified byinteger_listare 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 ofPatternGenerator, ifinteger_listincludes more than one position, all positions are XORed and connected to the gsignal. For a SignatureAnalyzer BIST register, the indicated signal fans out to all positions ininteger_list; if morethan one signal thus connect to the same position, all signals are XORed and connected to the given positiconnection to/from a signal may be optionally inverted. Any number of Connection constructs may be includeBistRegister. The order of Connection statements should not be changed because it may represent a seqconnections in a BIST environment.
(9) Seed: Optional field identifying the initial value of the BIST register. If not given, the initial value is considerefor all bits.
(10)BistCells: This statement references the name of a scan-chain that defines the list of scan-cells comprisBistRegister. The scan-chain shall contain a list of cells equal to the number defined in theLength 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. Ifgiven, the BIST register is considered to continue cycling i.e., the default NextstateOffset offset is BistcycleLHowever, in some BIST architectures, after BistcycleLength cycles, the BIST register is moved back. For exNextstateOffset 0 implies that every BistcycleLength cycles the BIST register is reset to its SeedNextstateOffset 1 implies that every BistcycleLength cycles the BIST register is moved back to itsBistcycleLength-1 cycles ago.
(13)FirststateOffset: Optional field identifying the offstate of the BIST register after the first BistcycleLengcycles. If not given, the BIST register is considered to start clocking as soon as the first BIST cycle i.e., the dFirststateOffset offset is BistcycleLength. For example, FirststateOffset 0 implies that the BIST register has thSeed after the first BistcycleLength cycles. If both FirststateOffset and NextstateOffset are given and they diffeFirststateOffset 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 Bpattern. For example, a logic-BIST architecture may require BistcycleLength cycles to load the scan chains ancapture clocks. All inputs to a SignatureAnalyzer BistRegister are considered to be 0 for the first BistcycleLcycles; 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 lBIST architecture. The default value is 0, i.e., the BIST register is not clocked during capture cycles (if any).chain loads thus require BistcycleLength-CaptureCycles cycles.
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
cellulare Tap-
cell 0),1, 0, 1).eclarescells to
omial
mial
20.2 BIST Structures ExampleThe example defines a BIST registers: "cella_prpg" used as pattern generator. The register is an array ofautomata (Type CA). The Length field specifies the number of bits and the Seed specifies the initial value. ThPositions fields describe the structure of the BIST register: For CAs, the tabs are relative to the current cell (thus "cella_prpg" has the odd bits (1, 3, 5, ...) connected to their two nearest neighbors and to themselves (-Meanwhile, the even bits (0, 2, 4, ...) are only connected to their nearest neighbors (-1, 1). The Clock field dthe signal ck1 that advances the BIST register. The Connection fields list the connections of BIST register bitpoints in the netlist. Bits 0, 1 and 2 are XORed and connected toprpg_sig1 ; bit 4 is connected toprpg_sig2 ,etc.
}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, JohnWiley & Sons, 1987.
20.4 BistStructure-ScanStructure Interaction ExampleCommonly, BIST registers will also be connected and accessed as a scan chain, to support observability andlability operations. The BistCell statement of the BistStructure block is used to identify the relationship of theregisters to the ScanStructure block. This is shown in the example below, which references only the LFSR andregisters of the previous example, and identifies only the scanchain connection for these elements.
0123
3 2 1 0
B1_soB1_si
B2_so
B2_so
L3 L2 L1 L0
M3 M2 M1 M0
PRPGLFSR
MISR LFSR
design tested
Figure 5—Scanchains in the BIST sequential elements
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
-
See
d in
fer-
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 expressionthat 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 expressionthat 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. Seeclause 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 con-taining 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 con-taining 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 definethe current WaveformTable.
A.10 WaveformCharacter list: A list or series of alphanumeric characters, each character representing a reence to a Waveform defined in the current WaveformTable.
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
0-1999arameters
veformrs to bepression
Annex B Signal Mapping Using SignalVariables ( informative )
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. 145clause 21.2). Using pattern expressions, the same parameter passing mechanism also can be applied to the pto a Macro or a Procedure. An example of this is:
Vector data is passed from vectors to Macros or Procedures by means of signal group oriented strings of wacharacters. A new capability in MacroDefs or Procedures allows the waveform characters from the parametemapped onto other signal groups as required by the core test design interface. An example of a vector data exis:
B.3 A more complete example of parameters and signal variable expressions
1. definition of SignalVariables in a SignalGroups block2. use of parameters in a Macro (or Procedure call)3. use of # to update the parameter values4. application of parameters in a Macro (or Procedure)5. use of logic expressions (logic_expr) with signal variables in a Macro (or Procedure)6. process of re-using signal groups (un-mapped) as signal variables (mapped)
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
Annex D Using Boolean Expressions (boolean_expr) ( informative )This example illustrates the following capabilities:1. use of parameters on a Macro (or Procedure)2. use of logic expression in conditional-If/Else statements in a pattern3. use of parameters in logic expression to create WaveformCharacter data in a vector
Figure 7—Representation of Signal Groups for a Design
STIL 1.0 { Design 2001; }Header {
Source "P1450.1 Working-Draft 14, Aug 1, 2002";Ann {* clause D *}
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
eating al inter-
s a scanalso hasshould
For this
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 crsingle scan chain. The resulting chip could be a module itself and hence the STIL at the chip level is of speciaest.
Figure 8—Design chaining two scan chains together
The two modules being integrated are module C1 and module C2 and the final result is Chip12. module C1 hachain with scanin si1 and scanout so1 that is controlled by the clk1 clock and the scan enable se1. module C1some broadside inputs abc. module C2 has a similar configuration as module C1 and the naming conventionbe self explanatory.
module C1 comes with STIL to define the operation of the scan chain and the vectors that use the scan chain.example, module C1 has a Macro to operate the scan chain and some patterns that use the macro.
STIL 1.0 { Design 2001; }Header {
Source "P1450.1 Working-Draft 14, Aug 1, 2002";Ann {* clause F *}
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
the pat-task.
.
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 reuseterns that are in the files that come with the modules. The following is the outcome of the system integration
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 = #;}
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
m and
rm canwing
e sameA test
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 - \\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 wavefobe completely defined in the new waveform definition that is to replaced the one originally called for. The follois a table of the typical transformation that would caused the waveform inversion:
D -> U ForceDown -> ForceUpU -> D ForceUp -> ForceDownL -> H CompareLow -> CompareHighH -> L CompareHigh -> CompareLowl -> h CompareLowWindow -> CompareHighWindowh -> l CompareHighWindow -> CompareLowWindowZ -> N ForceOff -> ForceUnknownT -> X CompareOff -> CompareUnknownt -> X CompareOffWindow -> CompareUnknownN -> N ForceUnknown -> ForceUnknownX -> X CompareUnknown -> CompareUnknown
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]’ \m’B[8..15]’; }V { X = ‘A[0..7]’ XXXX \m‘A[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 DUT’s bidis in one cycle and then drive thlogical values on the same bidis from the tester in the next cycle, while also turning the internal bidi drivers off.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)
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
ed offus
turingcal val-mputedns andess of
ve pro-mpo-
ten-id bidiis an
IDI2dis, as
IDI2
(4) force values on primary inputs (values are the same as in cycle 2, except the internal bidi drivers are turnby de-activating a bidi_control input), force values on bidis (same logical values as measured in previocycle)
(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 capnew data into the state elements. A bidi contention arises if the internal driver and the tester drive opposite logiues on the same bidirectional pin. The additional data to be applied on bidis in cycle 4 is redundant (can be cofrom the data of cycle 3.) This test style needs to be supported without adding extra data to the STIL patterwithout changing the WaveformCharacters in the patterns. Also, ATPG rules checking can verify the correctnthe 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 abotocol may be required for test flows already designed with this protocol or if timing-related glitches that may terarily 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 contion-free pattern could be transformed into a pattern with contentions by the very protocol that attempts to avocontentions! For example, consider the following example, where BIDI1 and BIDI2 are bidis, and BIDI_CTRLinput that, when 0, turns off the internal driver of BIDI1, but not of BIDI2:
ATPG generated, contention-free pattern:
(1) load scan chains(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 B
internal drivers are driving 0. There is no contention, because the tester continues to drive Z on both biin cycle 2.)
(5) unload scan chains
The pattern above will be changed, after it has been generated, to match the LNI protocol:
(1) load scan chains(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 B
internal drivers are driving 0. This causes acontention on BIDI2: its internal driver, not turned off, drives 0while the tester drives 1, as in cycle 4!)
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
ed in forll.
}}
}
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; }
In this example, the vectors are labeled to correspond to the cycles above. Cycle 3 uses the arguments pass_io first (HL), then cycle 4 uses them again, this time mapped to (10), which remain in effect for cycle 5 as we
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
nex isf the
Char-g Pro-
Annex H Vector data joining using \j ( informative )The “Join” function allows to have multiple WaveformCharacters against the same signal in one vector. This anan application of this capability. Refer to “Vector data mapping and joining - \m and \j” on page 40 for details osyntax and semantics.
H.1 Example
The following is an example usage of the join function.
0x -> k;// The 2 source WFCs are not order-sensitive.// The above could also be written as: { x0 -> k; }
}}
}PatternBurst "_burst_" {
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 Waveformacter assignment to bidirectional (InOut) signals or signalgroups. This enables structuring of STIL patterns usin
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'):
Table 9—Example of "two data" conditions on an InOut Signal
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
ese two
ave-
for thesignals,
_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 thgroups. 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 wforms on-the-fly.
H.2 Usage Example
Consider a design with one input, one output and two bidis, declared as follows:
Understanding how STIL is interpreted by the consumer of the patterns, the actual arguments are substitutedformal arguments # in the body of the procedure, and the signalgroups _pi and _po are expanded to theirresulting in:
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
us, the
two
as:
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. Thabove 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 theWaveformCharacter assignments. Thus, the 1450.1 procedure would be written as:
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
completeoundsce-timulusof theinter-
rogram.ls in theis a spe-
f theses.
Wave-ally, thet may
de onwave-t value
aveform
Annex I Block Data Collection ( informative )This annex describes a usage scenario that combines several capabilities defined in this standard to providesupport for returning tester information for evaluation or review by CAD tools. While this example is oriented arreturning information for diagnostic applications, this functionality is not constrained to this application. Thisnario can also be applied to the general notion of "learn-mode" tester operation, where the test provides the sonly and the response is "learned" by reporting the behavior from testing known-good devices. Integrationreturn values in this mode of operation into a new test program is the responsibility of the CAD environmentpreting the returned data.
To support the return of test values from a STIL test program, several constructs need to be present in the pThis example assumes a scenario where the desired return information is a subset of both the set of signadesign (that is, only one Signal needs to be evaluated), and a subset of the test vector sequence (that is, therecific region of the test where this information is needed). This scenario presents the "worst-case" application oconstructs; see the Note at the end for a discussion about the consequences of generalizing these restriction
I.1 Step 1 - Identifying Signals
The set of signals that return response data are identified by defining a new Waveform for those signals. Thisform contains an "S" or CompareSubstitute event for the region where the value needs to be checked. Typictiming of the S event will coincide with the timing for CompareLow and CompareHigh checks also defined (bunot be used) for that Signal. For example, if the original waveforms on Signal A1 were defined as:
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 mahow to define the timing of the waveform containing the S event. Typically, the S event would be defined in aform that defined the overlapping region of both the low strobe and the high strobe, in order to return the correcif 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 W
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
n valuenship.
side) ispare-high, low, orstate, if
niquerentia-
e appli-
0 Vec-
wouldmple,
containing the S event. To support explicit designation of a desired WaveformCharacter to represent a returfrom a waveform containing an S event, the WFCMap construct is used to specify an "inverse mapping" relatioThis would be specified for this context on Signal A1 as:
Remember that the order of WaveformCharacter references in the mapped output side (the right or "to_wfc"important: the first reference represents the compare-low state, the second reference represents the comstate, the third value represents the compare-unknown state (which represents a test value that is not highchanges during the measurement interval), and the forth value represents the compare-off (high-impedance)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 uWaveformCharacter reference) can specify a unique set of Waveform response mappings. This allows for diffetion 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 thcation of the WaveformCharacter that contains an S event, in the Pattern data. One example of this is:
..."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 20tors 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 constructsbe to return this data following the diagnostic information return for failing data as shown in annex M. For exathe return data for this scenario could look like:
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
contextese twomChar-
atementas gen-of this
itedl com-r each
} 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(all device responses were either high or low, so the X value was not used), and defined the Base Hex for thWaveformCharacters in the declaration of A1. The 50 hex characters above define all 200 expanded Waveforacter references for this signal.
The return environment also made use of the Loop Data construct to return all these values under a single stfor this set of Vectors. This construct is applicable in contexts where the set of return vectors are adjacent (as werated by the original Loop that contained the 'C' WaveformChar), and provides for compact representationinformation.
Note: While the normal operation of this facility is expected to be applied for a limited set of signals, over a limrange of test vectors, it is straightforward to generalize this behavior to all signals/all vectors. By replacing alpare events across all Signals in all WaveformTables with S values, all Vectors will see a "Substitute" event fooutput compare operation and will return detected event behavior when this test is executed.
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
ta con-
gnals aother
pplyingcedureb, thus
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 dastraints - 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, siand b must be ’0’ and signals c and d must be either ’0’ and ’1’, or ’1’ and ’0’ or have both WaveformCharactersthan ’0’ and ’1’.
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 avalues on primary inputs, but not during load/unload of the scan chains. The Fixed statement is active in pro"capture_sysclk", but not in procedure "load_unload". Also, the design has differential scan inputs si1 and si1the Equivalent statement is active in procedure "load_unload", but not in "capture_sysclk".
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
led exe-ous, but
devicemes the
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 coupcution of patterns. This might be the case for testing a dual port access memory where the timing is asynchronthe patterns are associated.
A different, but related application is where there are two independent sets of signals, timing, and patterns on athat are to be tested independently, with no regard for each other. Consider the following example, which assuname “Test” to represent the collection of all entities necessary to execute this operation:
Figure 9—Representation of a complete Test Program
STIL 1.0 { Design 2001; }Header {
Source "P1450.1 Working-Draft 14, Aug 1, 2002";Ann {* clause K *}
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
n pat-ns” for-ready.of scan
ersionsions areth inputle:
e value
d at the2 (non-reality
re is no
s:
ver-LSSDtypi-
Annex L ScanStructures using complex scan cells ( informative )The ScanStructures block is extended to include additional information required for efficient simulation of scaterns, i.e., eliminating the need to serially simulate load/unload cycles. Refer to clause “ScanStructure extensiothe syntax definition. The ScanStructures block is optional in a STIL pattern file because the data is testerHowever, the ScanStructures block may be used by a simulator to more efficiently simulate the load/unloadchains 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 invfor every scan cell with respect to the scan-input and scan-output pins of the scan chain. In STIL, these inversrepresented by ‘!’ characters in the ScanCells list. However, this notation cannot unambiguously represent boand output inversions for all scan cells if one or more cells have internal inversions, as in the following examp
In this example, scan cell a2 has an internal inversion: the value scanned out of a2 is inverted with respect to thscanned into a2.
In the first ScanCells statement the inversion between a2 and a3 implies that the output of cell a2 is invertescan_out pin, which is incorrect. The second ScanCells statement correctly represents the output of cell ainverted at scan_out), but incorrectly shows the input of a3 inverted with respect to the scan_in pin, whereas inthe two inversions cancel each other out and make the input of a3 non-inverted with respect to scan_in. Thecorrect 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 follow
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 insions have been marked with a comment in the form /*invn*/ to facilitate explanations. Cell a3 resembles ancell, with the master shift clock being ACLK and the slave shift clock being BCLK. The other scan cells would
a1 a2 a3scan_in scan_out
external inversion internal inversion
ScanCells ! a1 a2 ! a3; // wrong a2 output
ScanCells ! a1 a2 a3; // wrong a3 input
Figure 10—Example of scan chain including a cell with internal inversion
In the pattern shown, the first vector (labeled“pattern 1” ) calls the load_unload procedure. The simulator cexecute a fully parallel load of{ “c1_in” = 0001; } because scanmode==2 (from its InitialValue in the PaternBurst). The first three bits applied on c1_in are 0, the last bit is 1. This results in the following valuesloaded:
— a1 is the cell closest to the scan input c1_in and is thus loaded with the last value (1) of the “0001” stringinverted 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 mustbe serially simulated because scanmode is set to 0, and will affect the values just loaded into the scan cellsend, 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 pters, and only affects how the following call to load_unload (data{ “c1_out” = 1110; } and labeled“pat-tern 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” stringinverted 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.
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
us
ated as aof cell,
scan-taining
-
Next, load_unload is again called (label“pattern 3”). This time, scanmode is 2 (set at the end of the previoload_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 instanticomplete scanchain definition. This allows complex scan cell information to be represented once for a typeand also supports the notion of a “multi-bit” scan cell if the user’s perspective considers a single element of achain to contain more than one scan state. Be aware in the example below, that the LSSD_MSS cell, while con2 state elements in the scan path, is always clocked such that only a single scanstate is ever contained in these elements as discussed in the previous example.
ScanChain "A" {ScanIn "scan_in"; // pinname of the LSSD_MSS scaninScanOut "scan_out"; // pinname of the LSSD_MSS scanoutScanInversion 0;ScanCells {
it { // one and only one scan state in hereIf ’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 scaninScanOut "scan_out"; // pinname of the _4_BIT_CELL scanoutScanInversion 0;ScanCells { s1; s2; s3; s4; } // scanchain state elements (4 bits)
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
, Diag-
refer-le testeran), orcom-
tive to
y refer-
rge Pat-the last
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 additionnostics 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 simulationence, such as with ATPG patterns. This may be simple, such as when each STIL vector is mapped into a singcycle. However, this may be complex, such as when a simulator pattern results in multiple STIL vectors (e.g. scwhen a STIL vector requires multiple tester cycles (e.g. complex timing), or when multiple STIL vectors arebined into a single tester cycle.
A Mechanism is therefore required to “tag” vectors with source references, and to have failures identified relathe appropriate “tag”.
Figure 13—STIL-Design Extension Usage Model (Simulator Feedback)
The Simulator Feedback usage model illustrates that STIL patterns are generated with embedded “tags” (anence 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 latern. Alternatively, only key cross-references need be specified, and failures shall be associated relative to
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
ector
m the
need
ondencedatalog-edded
ationriginalectorociated
wingsimula-state.st a netdance.igh) for
mely,
s shall
fromnenly
newvent
the
three
fail-
iluresallel
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 v(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 frostart 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 cross-reference correlation.
The STIL patterns are then translated to a specific tester. During the translation process, an internal corresptable is generated to correlate specific tester addresses to the imbedded “tags”. After applying the tests andging failures, this internal correspondence table shall be used to report the failures, relative to the original imb“tags”, in STIL format.
The translation from the original simulator STIL file(s) to specific tester vector file(s) may occur using a combinof user created software, 3rd party software tools, and/or ATE software. This software shall maintain the o“tags”, and potentially modify them during their processing (e.g. duplicate a “tag” when splitting a complex vinto multiple vectors). This software shall also create a cross reference table to correlate each “tag” to its asstester vector address.
Different types of Diagnostics require different information. For example, IDDq diagnostics only requires knowhich vector failed. Scan based diagnostics requires the shift chain and latch position (as determined by thetor, based on the offset from a “tag”). The most complex is Stuck Fault diagnostics, which requires the failingStuck Fault ATPG create patterns which subsume faults into optimal patterns. For example, it is common to tefor a “stuck at 0” and “stuck at 1”. Both of these faults may be tested simultaneously by measuring high impeHowever, when the measure high impedance fails, the simulator needs to know what was measured (low or hit 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. Nait will contain:
— A Signals and/or SignalGroups blocks to identify the signals used to convey the failing pins. These blockbe derived from the original STIL file.
— A Timing block to identify the waveform characters used to convey failing state. This block may be derivedthe original STIL file and/or it may be created by the STIL Feedback software. The Timing block may definew waveform characters which weren’t in the original STIL file. For example, a Pattern may consist of o“measure 0’s”, but the resultant testing may result in “measure 1’s” or “measure high impedance”, requiringwaveform characters to be added. The Timing block may also define waveforms consisting of only a “fail” ewithout 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 actual failing measurements.
M.2 Fail data feedback - example
The following example illustrates the complete flow from simulation to return failure feedback. It consists ofscenarios:
1. A Functional subset. This subset of vectors contain no simulation references, and illustrates howures 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 famay be conveyed relative to the start of a scan operation (scan out), relative within a block of par
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
tesain-
vectors, and relative within a loop.
3. A Complex Timing subset. This subset of vectors contains key simulation references, and illustrahow vectors may be split into multiple tester cycles, and how the original simulator reference is mtained.
Example has 5 pins, 3 PIs (001, 002 & 003), 2 POs(004 & 005), and 10 latches (101-110) accessedthrough a ScanIn (003) and a ScanOut (005).
Section 1: represents “functional” type pat terns (nosimulator references).
Section 2: represents “scan” type patterns (containsimulator references).
Note: latches are defined in “scan input” to “scan out-put” order (i.e. latch 101 is connected to 003, latch110 is connected to 005). Therefore, the scan dataappears inverted in STIL, since the first scan statespecified must be shifted completely through the scanchain.
Section 3: represents a “complex” pattern whichrequires multiple time-based events on one signal.
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
#Vectors#Addr/Timing p001 p002 p003 p004 p005 1/T1 0 0 0 X X 2/T1 P 0 0 L X 3/T1 P 0 0 H X 4/T1 P 0 0 L X# 5/T1 0 0 1 X X 6/T1 P 1 1 X X 7/T1 P 1 0 X X 8/T1 P 1 0 X X 9/T1 P 1 1 X X 10/T1 P 1 1 X X 11/T1 P 1 0 X X 12/T1 P 1 0 X X 13/T1 P 1 1 X X 14/T1 P 1 1 X X 15/T1 P 1 0 X X 16/T1 P 0 0 L X 17/T1 P 0 0 H X 18/T1 P 0 0 L X 19/T1 P 0 0 H X LOOP 400 20/T1 P 0 0 H X 21/T1 P 0 0 H X 22/T1 P 0 0 L X ENDLOOP 23/T1 P 0 0 X L 24/T1 P 1 0 X H 25/T1 P 1 0 X H 26/T1 P 1 0 X L 27/T1 P 1 0 X L 28/T1 P 1 0 X H 29/T1 P 1 0 X H 30/T1 P 1 0 X L 31/T1 P 1 0 X L 32/T1 P 1 0 X H# 33/T1 0 0 0 X X 34/T2 P 1 0 X X 35/T2 P 1 0 H X 36/T1 0 0 0 X X
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; } }
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
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
t timeith theectors
rns toare inerged
ler, morendard way
he pat-result-
lied as a
atternsnsum-ample of
macros
ed andhe keyIf/Elseer will
Annex N BreakPoints using MergedScan() function ( informative )STIL writers will primarily output STIL scan-based patterns using a merged format, being motivated by the tesreduction savings. Typically, in a merged scan format, the unload operation of a scan pattern is merged in wload operation of the next subsequent scan pattern. This results in effectively cutting in half the number of vapplied.
As a result of outputting STIL patterns in merged format, there exists no convenient location in the STIL patteplace a STIL BreakPoint statement. For a BreakPoint statement to exist within STIL scan patterns whichmerged format, it would typically need to exist between the two unload/load operations that have been mtogether. When processing large sets of patterns, there exists a need to break those patterns up into smalmanageable, pattern segments. If the patterns being processed are merged scan patterns, then there is no staof breaking them up into independent patterns segments.
STIL BreakPoint statements are used to segment the patterns into logical chunks by identifying the points in tterns where they may be broken up. Breaking up STIL patterns at the BreakPoint statement will ensure that theing pattern segments will each function independently of each other, and that these segments may be appstandalone entity to a tester or simulator.
By using the MergedScan() function, STIL writers can provide both merged and unmerged formats of scan pwithin a single pattern instance. Usage of either the merged or unmerged formats is then left up to the STIL coers to use on a pattern by pattern basis, depending upon their processing requirements and resources. An exthis 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 orcontaining shift blocks.
First the Signals and SignalGroups blocks defining the scanin and scanout signals and groups
Next, a Procedures block defining a single scan procedure to be used for all scan operations, both mergunmerged. Note the If/Else logic based on the result of a call to the boolean function MergedScan(). This is tarea of the STIL patterns which allows for either a merged or unmerged representation of scan patterns. Theconstructs will ensure a mutually exclusive relationship between these two formats such that the STIL consumalways apply one and only one of the scan formats.
Finally, the “scan” procedure defined above is used within the Pattern block to apply all the scan patterns. Thally patterns themselves have no special coding depending on whether the merged or unmerged scan patternused. This is completely encapsulated within the defined “scan” procedure.
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 unmergpatterns within the same pattern instance. This clause describes how a STIL consumer may actually processterns above.
The MergedScan() function is a boolean function which returns true or false based on whether, when processpatterns, the merged scan pattern format should be used. By default, this function return true. This would cadefault behavior of all STIL consumers to output using merged format. During processing of patterns in someSTIL consumer environment, it is determined by the STIL consumer that there exists a need to break the patteto various factors relevant to that STIL consumer (e.g Tester Resources, Memory Limitations,...). At this poiSTIL 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/mawhich contains a call to MergedScan() to take the alternate path and generate patterns in unmerged format. Athe STIL consumer making the call to MergedScan() which returns false, the STIL consumer can then reMergedScan() function back to it’s 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 segmenthas already processed to the point in the patterns where resource have been exhausted. In this case, the Ssumer may need to buffer up STIL patterns and then when it determines it needs to break the patterns, it withem at that point and then re-process the buffered up patterns starting the new pattern segment at the beginn
This is an unapproved IEEE Standards Draft, subject to change.
P1450.1 Working-Draft 14, Aug 1, 2002
preventm that
most recent procedure call to a procedure containing an If/Else construct based on MergedScan(). This wouldthe STIL consumer from having to know ahead of time, going into a scan procedure, whether the vectors froprocedure will cause an overflow of the resources available.
