1、IEEE Std 1450.3-2007IEEE Standard for Extensions toStandard Test Interface Language(STIL) (IEEE Std 1450-1999) forTester Target SpecificationIEEE3 Park Avenue New York, NY 10016-5997, USA7 September 2007IEEE Computer SocietySponsored by theTest Technology Standards Committee1450.3TMRecognized as anA
2、merican National Standard (ANSI)IEEE 1450.3-2007IEEE Standard for Extensions to Standard Test Interface Language (STIL) (IEEE Std 1450TM-1999) for Tester Target SpecificationSponsor Test Technology Standards Committeeof theIEEE Computer SocietyApproved 24 August 2007American National Standards Insti
3、tuteApproved 8 March 2007IEEE SA-Standards BoardThe Institute of Electrical and Electronics Engineers, Inc.3 Park Avenue, New York, NY 10016-5997, USACopyright 2007 by the Institute of Electrical and Electronics Engineers, Inc.All rights reserved. Published 7 September 2007. Printed in the United St
4、ates of America.IEEE is a registered trademark in the U.S. Patent +1 978 750 8400. Permission to photocopy portions ofany individual standard for educational classroom use can also be obtained through the Copyright ClearanceCenter.iv Copyright 2007 IEEE. All rights reserved.IntroductionSTIL is a col
5、lection of standards with the base standard being 1450 and the dotted extensions used to defineadditional syntax for addressing additional areas; i.e., this standard addresses tester rules.The extensions follow the same conventions as the base standard. The base and the extensions are developedso as
6、 to work together; i.e., STIL is a single language that is defined (and has been developed) as separateIEEE standards. Notice to usersErrataErrata, if any, for this and all other standards can be accessed at the following URL: http:/standards.ieee.org/reading/ieee/updates/errata/index.html. Users ar
7、e encouraged to check this URL forerrata periodically.InterpretationsCurrent interpretations can be accessed at the following URL: http:/standards.ieee.org/reading/ieee/interp/index.html.PatentsAttention is called to the possibility that implementation of this standard may require use of subject mat
8、tercovered by patent rights. By publication of this standard, no position is taken with respect to the existence orvalidity of any patent rights in connection therewith. The IEEE shall not be responsible for identifyingpatents or patent applications for which a license may be required to implement a
9、n IEEE standard or forconducting inquiries into the legal validity or scope of those patents that are brought to its attention.ParticipantsThe following is a list of participants in the STIL Working Group. Tony Taylor, ChairJohn V. CosleyDavid DowdingOleg ErlichYung D. FanDave GallagherBruce Kaufman
10、Ken MandlGregory MastonGary MurrayChris J. NelsonKen PossePaul J. ReuterJose M. SantiagoDoug SpragueAllen YeatsThis introduction is not part of IEEE 1450.3-2007, Standard for Extensions to Standard Test Interface Language(STIL) (IEEE Std 1450TM-1999) for Tester Target Specification.Copyright 2007 IE
11、EE. All rights reserved vThe following members of the individual balloting committee voted on this standard. Balloters may havevoted for approval, disapproval, or abstention. When the IEEE-SA Standards Board approved this standard on 8 March 2007, it had the followingmembership:Steve M. Mills, Chair
12、Robert M. Grow, Vice ChairDon Wright, Past ChairJudith Gorman, Secretary*Member EmeritusAlso included are the following nonvoting IEEE-SA Standards Board liaisons:Satish K. Aggarwal, NRC RepresentativeRichard DeBlasio, DOE RepresentativeAlan H. Cookson, NIST RepresentativeMichelle D. TurnerIEEE Stan
13、dards Program Manager, Document DevelopmentMichael D. KipnessIEEE Standards Program Manager, Technical Program DevelopmentKeith ChowTommy P. CooperJohn V. CosleySourav K. DuttaYung D. FanRandall C. GrovesKazumi HatayamaWerner HoelzlChi Tin HonDennis HorwitzHirofumi KamitokusariMark J. KnightSusan K.
14、 LandAdam W. LeyG. L. LuriGregory MastonTom MicekGary L. MichelYinghua MinChris J. NelsonMichael S. NewmanNoriaki OkumiyaUlrich PohlPaul J. ReuterRobert A. RobinsonJose M. SantiagoBartien SayogoRoger J. SowadaWalter StrupplerK. S. SubrahmanyamTony TaylorSrinivasa R. VemuruThomas M. WandeloskiGregg W
15、ilderOren YuenAlex GelmanWilliam R. GoldbachArnold M. GreenspanJoanna N. GueninJulian Forster*Kenneth S. HanusWilliam B. HopfRichard H. HulettHermann KochJoseph L. Koepfinger*John KulickDavid J. LawGlenn ParsonsRonald C. PetersenTom A. PrevostNarayanan RamachandranGreg RattaRobby RobsonAnne-Marie Sa
16、hazizianVirginia C. SulzbergerMalcolm V. ThadenRichard L. TownsendHoward L. Wolfmanvi Copyright 2007 IEEE. All rights reserved.Contents1. Overview 11.1 Scope 21.2 Purpose. 21.3 TRC limitations 32. Normative references. 33. Definitions . 34. Structure of this standard . 44.1 Formats from STIL.0 . 44.
17、2 Additional formatting conventions 54.3 Dependencies on IEEE Std 1450.1 55. STIL syntax description. 65.1 Additional reserved words . 65.2 Keywords used in a TRC block . 66. Statement usage and organization by flow 76.1 TRC usage for ATE constraint specification. 86.2 TRC usage for design/pattern c
18、onstraints 96.3 TRC usage for pattern reporting 96.4 TRC usage for tester targetting 107. STIL statement. 107.1 STIL syntax 117.2 STIL example 118. Variables block extensions 118.1 Variables block syntax. 118.2 Variables example 129. Resource statement 139.1 Resource statement syntax. 1310. TRC: Tes
19、tResourceConstraints block 1410.1 TRC syntax 1510.2 TRC example . 1810.3 TRC block sharing rules 1911. TRC: SignalAttributes . 1911.1 TRC: SignalAttributessyntax. 1911.2 TRC: SignalAttributesexamples 21Copyright 2007 IEEE. All rights reserved. vii12. TRC: DCResourceAttributes . 2212.1 TRC: DCResourc
20、eAttributessyntax. 2212.2 TRC: DCResourceAttributesexample 2413. TRC: PeriodAttributes . 2513.1 TRC: PeriodAttributessyntax. 2513.2 TRC: PeriodAttributesexamples 2614. TRC: WaveformAttributes 2614.1 TRC: WaveformAttributessyntax 2714.2 TRC: WaveformAttributesexamples . 3115. TRC: WaveformDescription
21、s 3215.1 TRC - WaveformDescriptionssyntax. 3215.2 TRC: WaveformDescriptionsexamples . 3416. TRC: PatternAttributes 3516.1 TRC: PatternAttributessyntax 3516.2 TRC: PatternAttributesexamples . 3817. TRC: NameChecks block 3917.1 NameChecks blocksyntax 3917.2 NameChecksexamples . 40Annex A (informative)
22、 Glossary . 42Annex B (informative) Fluid concepts in parameter specification 48Annex C (informative) Tester channel map 50Annex D (informative) Example of TRC for a simple tester model . 52Annex E (informative) Example of TRC used to define waveforms and timing 54Annex F (informative) Example of TR
23、C used for resource reporting. 58Annex G (informative) Example of tester targeting and tester loading. 61Annex H (informative) Example of vector memory checking 66Annex I (informative) Waveform generator model. 69Annex J (informative) File encryption. 75Annex K (informative) Regular expression refer
24、ence. 76Copyright 2007 IEEE. All rights reserved. 1IEEE Standard for Extensions to Standard Test Interface Language (STIL) (IEEE Std 1450TM-1999) for Tester Target Specification1. OverviewThe STIL environment supports transferring tester-independent test programs to a specific automated testingequip
25、ment (ATE) system. Although native STIL data are tester independent, the actual process of mappingthe test program onto tester resources may be critical, and it is necessary to be able to completely andunambiguously specify how the STIL programs and patterns are mapped onto the tester resources. TRC
26、(which stands for either tester resource constraints or tester rules checking, depending on the usage) is anextension to the STIL language to facilitate this operation. Figure 1 shows the usage model for tester targeting. The four ways that the TRC statements come into playin the flow of data from d
27、esign to test are indicated by the circled numbers in the diagram. These four usesare defined as follows:a) Tester rules checking: As early as possible in the process of inserting “Design for Test” logic andgeneration of test patterns, the rules of the target tester are identified by means of the TR
28、C filedefining the target tester.b) Tester resource reporting: As part of the pattern generation process, a report of resources requiredfor the pattern may be created in TRC format. This information is available for test planningpurposes, such as 1) when a pattern is for an embedded core to be integ
29、rated into a chip or 2) fortester scheduling purposes. Each resource report is associated with a particular STIL file/stream.The resource report data may be a separate file (as implied in the above diagram) or may be includedin the STIL pattern file.c) Tester resource targeting: The process of teste
30、r targeting is that of adding additional informationinto the STIL file/streams that specifies how the resources of a given tester are to be assigned. Notethe bars on the left side of the diagram, which indicate that this targeting operation can be done inone of three places: 1) by the EDA software t
31、hat generates the patterns, 2) by software created by thetest user, or 3) by the ATE sofware that loads the STIL patterns.d) Tester resource loading: The tester loader is a process that maps the device-oriented STIL data tothe resources of the tester. There may or may not be targeting information pr
32、ovided. If targetinginformation is not present, then the loader is expected to do the job of assigning resources. Iftargeting information is present, then it is to be used to direct the resource assignment.IEEEStd 1450.3-2007 IEEE STANDARD FOR EXTENSIONS TO STIL2 Copyright 2007 IEEE. All rights rese
33、rved.Note that the semantics of the various TRC statements change, based on which flow is being addressed;i.e., in a constraint flow, the TRC statements provide a set of rules that are to be applied to a set of data andan error shall be generated if the test pattern data does not conform to the rule
34、s; in a report flow, the sameTRC statements are providing a summary of test pattern data regardless of whether it conforms to any givenTRC constraints. Most TRC statements can be used in either context. The definitions in this standard arewritten from the constraint point of view.1.1 Scope Define st
35、ructures in STIL for the specification of resource mapping of ATE hardware architectures.An example of resource mapping is the assignment of tester resources to waveform characters thatare used in STIL vectors. Define structures in STIL for including ATE-specific instructions in-line with the STIL d
36、ata. Define structures in STIL that allow for “incremental processing” whereby, a set of STIL files maybe targeted to multiple ATE systems by allowing separately identified ATE data to coexist. Define structures in STIL for defining tester rules checks to ensure that the set of generated STILfiles c
37、onform to the selected resources on one or more ATE systems. Define structures in STIL for the specification of the resources required for the execution of a set ofSTIL files on a given ATE system.1.2 PurposeTransferring “tester independent” test program/pattern data as represented in STIL to a spec
38、ific ATE systemis a desired capability. It is required to be able to completely and unambiguously specify how the STILprogram/patterns are mapped onto a specific testers resources. Because of the various different use modelsfor the creation and consumption of test data, it is necessary to enable cer
39、tain operations (such as rulesFor eachtarget testerATE SoftwareUser Software- Generic- Device oriented- Generic- Device oriented- Tester directedModulescomprisinga test program- rules checking- resource mapping- data validity checking- resource loading- pattern generation- resource usage reportSimul
40、ator/ ATPGSTILTarget TesterLoaderCompilerTestertargetingTools234TRC(ate)- pattern generation- rules checking1TRC(pat)TRC(ate)TRC(pat)- report for each STIL file/stream- rules for each ATE systemFigure 1STIL.3 usage model (tester targeting)IEEEFOR TESTER TARGET SPECIFICATION Std 1450.3-2007Copyright
41、2007 IEEE. All rights reserved. 3checking) very early in the process. Likewise it is desirable to allow other operations (such as resourceallocation) to be done very late in the process. The STIL language extensions enable the user/creator astandard way of specifying and controlling the application
42、of test program/pattern data to specific ATEsystems to the extent necessary for each use model scenario.1.3 TRC limitationsIn setting the scope for any standard, some issues are identified and determined not to be defined. Thefollowing is a list of issues that are not in the scope of this standard:a
43、) Violations: The tester-targeting operation naturally leads to situations where a given set ofconstraints cannot be met. It is not in the scope of this standard to define the content or format ofsuch constraint rule violations.b) Completeness: The variations in architecture of various ATE systems m
44、akes it virtually impossibleto address all the nuances and corner cases of each design. It is the intent of this standard to providea common way of describing key common attributes. This standard is intended to address 80% ofthe issues involved with TRC operations, because the effort to address the
45、remaining 20% is toocomplex and would make the standard unwieldy to apply in general.2. Normative referencesThe following referenced documents are indispensable for the application of this Standard. For datedreferences, only the edition cited applies. For undated references, the latest edition of th
46、e referenceddocument (including any amendments or corrigenda) applies.IEEE Std 1450TM(STIL.0), IEEE Standard Test Interface Language (STIL) for Digital Test Vectors.1,2IEEE Std 1450.1TM(STIL.1), IEEE Standard for Extensions to Standard Test Interface Language (STIL)(IEEE Std 1450TM-1999) for Semicon
47、ductor Design Environments.IEEE Std 1450.2TM(STIL.2), IEEE Standard for Extensions to Standard Test Interface Language (STIL)(IEEE Std 1450TM-1999) for DC Level Specification.IEEE Std 1450.6TM(STIL.6), IEEE Standard IEEE Standard Test Interface Language (STIL) for Digital TestVector Data-Core Test L
48、anguage (CTL).3. DefinitionsFor the purposes of this standard, the following terms and definitions apply. The Authoritative Dictionary ofIEEE Standards Terms should be referenced for terms not defined in this clause. Additional terminologyspecific to this standard is found in Annex A. STIL.0: Refers
49、 to IEEE Std. 1450. This base STIL standard is commonly referred to as “dot 0”.1The IEEE standards or products referred to in this clause are trademarks of the Institute of Electrical and Electronics Engineers, Inc.2IEEE publications are available from the Institute of Electrical and Electronics Engineers, Inc., 445 Hoes Lane, Piscataway, NJ 08854, USA (http:/standards.ieee.org/).IEEEStd 1450.3-2007 IEEE STANDARD FOR EXTENSIONS TO STIL4 Copyright 2007 IEEE. All rights reserved.STIL.1: Refers to IEEE Std 1450.1. This extension to the STIL base standa
