1、BRITISH STANDARDBS IEC 62525:2007Standard Test Interface Language (STIL) for Digital Test Vector DataICS 25.040.01; 35.060g49g50g3g38g50g51g60g44g49g42g3g58g44g55g43g50g56g55g3g37g54g44g3g51g40g53g48g44g54g54g44g50g49g3g40g59g38g40g51g55g3g36g54g3g51g40g53g48g44g55g55g40g39g3g37g60g3g38g50g51g60g53g
2、44g42g43g55g3g47g36g58BS IEC 62525:2007This British Standard was published under the authority of the Standards Policy and Strategy Committee on 31 December 2007 BSI 2007ISBN 978 0 580 59313 0National forewordThis British Standard is the UK implementation of IEC 62525:2007. The UK participation in i
3、ts preparation was entrusted to Technical Committee GEL/93, Design automation.A list of organizations represented on this committee can be obtained on request to its secretary.This publication does not purport to include all the necessary provisions of a contract. Users are responsible for its corre
4、ct application.Compliance with a British Standard cannot confer immunity from legal obligations.Amendments issued since publicationAmd. No. Date CommentsIEC 62525Edition 1.0 2007-11INTERNATIONAL STANDARD Standard Test Interface Language (STIL) for Digital Test Vector Data IEEE 1450BS IEC 62525:2007I
5、EEE 1450-19991.1.11.22.3.3.13.24.5.5.15.25.35.45.55.65.75.85.96.6.16.26.36.46.56.66.76.86.97.7.17.27.3CONTENTS 2 BS IEC 62525:2007IEEE 1450-1999IEEE Introduction .7Overview.8Scope.10Purpose11References.11Definitions, acronyms, and abbreviations.11Definitions.11Acronyms and abbreviations.14Structure
6、of this standard 14STIL orientation and capabilities tutorial (informative).15Hello Tester.15Basic LS245. 20STIL timing expressions/”Spec” information 24Structural test (scan) 29Advanced scan . 33IEEE Std 1149.1-1990 scan . 39Multiple data elements per test cycle. 44Pattern reuse/direct access test.
7、 48Event data/non-cyclized STIL information . 52STIL syntax description. 62Case sensitivity 62Whitespace. 62Reserved words 62Reserved characters . 64Comments 65Token length 65Character strings 65User-defined name characteristics . 66Domain names . 666.10 Signal and group name characteristics.676.11
8、Timing name constructs. 676.12 Number characteristics. 676.13 Timing expressions and units (time_expr). 686.14 Signal expressions (sigref_expr) 706.15 WaveformChar characteristics. 716.16 STIL name spaces and name resolution. 72Statement structure and organization of STIL information . 74Top-level s
9、tatements and required ordering 66Optional top-level statements 68STIL files . 688.8.18.29.9.19.210.11.12.13.14.15.16.17. 3 BS IEC 62525:2007IEEE 1450-1999STIL statement. 77STIL syntax 77STIL example. 77Header block 78Header block syntax. 78Header example . 78Include statement . 7810.1 Include state
10、ment syntax 7910.2 Include example. 7910.3 File path resolution with absolute path notation 7910.4 File path resolution with relative path notation . 79UserKeywords statement . 8011.1 UserKeywords statement syntax 8011.2 UserKeywords example. 80UserFunctions statement 8012.1 UserFunctions statement
11、syntax 8112.2 UserFunctions example 81Ann statement 8113.1 Annotations statement syntax 8113.2 Annotations example . 81Signals block 8114.1 Signals block syntax 8214.2 Signals block example . 84SignalGroups block 8415.1 SignalGroups block syntax 8415.2 SignalGroups block example . 8515.3 Default att
12、ribute values 8515.4 Translation of based data into WaveformChar characters. 86PatternExec block 8716.1 PatternExec block syntax. 8816.2 PatternExec block example 88PatternBurst block 8817.1 PatternBurst block syntax 8917.2 PatternBurst block example . 9018.19.20.21.22.23.24. 4 BS IEC 62525:2007IEEE
13、 1450-1999Timing block and WaveformTable block 9018.1 Timing and WaveformTable syntax 9118.2 Waveform event definitions. 9418.3 Timing and WaveformTable example . 9618.4 Rules for timed event ordering and waveform creation. 9718.5 Rules for waveform inheritance. 100Spec and Selector blocks 10119.1 S
14、pec and Selector block syntax.10119.2 Spec and Selector block example .103ScanStructures block.10420.1 ScanStructures block syntax .10520.2 ScanStructures block example 106STIL Pattern data . 10721.1 Cyclized data 10721.2 Multiple-bit cyclized data 10821.3 Non-cyclized data 10921.4 Scan data 10921.5
15、 Pattern labels 110STIL Pattern statements. 11022.1 Vector (V) statement 11022.2 WaveformTable (W) statement 11122.3 Condition (C) statement. 11122.4 Call statement. 11222.5 Macro statement. 11222.6 Loop statement. 11322.7 MatchLoop statement. 11322.8 Goto statement . 11422.9 BreakPoint statements 1
16、1422.10 IDDQTestPoint statement 11422.11 Stop statement 11522.12 ScanChain statement 115Pattern block 11523.1 Pattern block syntax. 11523.2 Pattern initialization. 11623.3 Pattern examples 116Procedures and MacroDefs blocks. 11624.1 Procedures block 11724.2 Procedures example . 11824.3 MacroDefs blo
17、ck 11824.4 Scan testing 11824.5 Procedure and Macro Data substitution. 119 5 BS IEC 62525:2007IEEE 1450-1999Annex A (informative) Glossary . 123Annex B (informative) STIL data model. 124Annex C (informative) GNU GZIP reference . 129Annex D (informative) Binary STIL data format 130Annex E (informativ
18、e) LS245 design description 134Annex F (informative) STIL FAQs and language design decisions 136Annex G (informative) List of participants 140 IEEE StandardTest Interface Language (STIL) for DigitalTestVector DataSponsorTest Technology Standards Committeeof theIEEE Computer SocietyApproved 18 March
19、1999IEEE-SA Standards BoardAbstract: Standard Test Interface Language (STIL) provides an interface between digital test gen-eration tools and test equipment. A test description language is defined that: (a) facilitates the trans-fer of digital test vector data from CAE to ATE environments; (b) speci
20、fies pattern, format, andtiming information sufficient to define the application of digital test vectors to a DUT; and (c) sup-ports the volume of test vector data generated from structured tests.Keywords: automatic test pattern generator (ATPG), built-in self-test (BIST), computer-aided en-gineerin
21、g (CAE), cyclize, device under test (DUT), digital test vectors, event, functional vectors, pat-tern, scan vectors, signal, structural vectors, timed event, waveform, waveshape 6 BS IEC 62525:2007IEEE 1450-1999Standard Test Interface Language (STIL) was initially developed by an ad-hoc consortium of
22、 test equipmentvendors, computer-aided engineering (CAE) and computer-aided design (CAD) vendors, and integrated cir-cuit (IC) manufacturers, to address the lack of a common solution for transferring digital test data from thegeneration environment to the test equipment.The need for a common interch
23、ange format for large volumes of digital test data was identified as an overrid-ing priority for the work; as such, the scope of the work was constrained to those aspects of the test environ-ment that contribute significantly to the volume issue, or are necessary to support the comprehension of that
24、data. Binary representations of data were a key consideration in these efforts, resulting in a proposal to incor-porate the compression of files as part of this standard.Limiting the scope of any standards project is a difficult thing to do, especially for a room full of engineers.However, issues th
25、at did not impact the scope as identified were dropped from consideration in this versionof the standard. Subclause 1.1 covers, specifically, the capabilities that are not intended to be part of this firststandard.Early work in this consortium consisted of identifying the requirements necessary to a
26、ddress this problemand reviewing existing options and languages in the industry. All options proposed fell short of addressingthe requirements, and the consortium started to define a new language. This work was executed with heavyleverage from some existing languages and environments, and STIL owes
27、much to the groundwork estab-lished by these other languages.IEEE Introduction 7 BS IEC 62525:2007IEEE 1450-1999STANDARD TEST INTERFACE LANGUAGE (STIL)FOR DIGITAL TEST VECTOR DATA1. OverviewStandard Test Interface Language (STIL) is a standard language that provides an interface between digitaltest
28、generation tools and test equipment. STIL may be directly generated as an output language of a test gen-eration tool, or it may be used as an intermediate format for subsequent processing. Figure 1 shows STILusage in a “pipe” format. This is meant solely as a visual analogy to emphasize the high-vol
29、ume/high-throughput requirements. It is not meant to represent physical structures or implementation requirements.STIL is a representation of information needed to define digital test operations in manufacturing tests. STILis not intended to define how the tester implements that information. While t
30、he purpose of STIL is to passtest data into the test environment, the overall STIL language is inherently more flexible than any particulartester. Constructs may be used in a STIL file that exceed the capability of a particular tester. In some circum-stances, a translator for a particular type of te
31、st equipment may be capable of restructuring the data to sup-port that capability on the tester; in other circumstances, separate tools may operate on that data to providethat restructuring. In all circumstances, it is desirable to provide the capability to check the data against theconstraints of a
32、 tester. This capability is referred to as Tester Rules Checking and is the domain of tools thatoperate on STIL data. As such, Tester Rules Checking operations are outside the scope of this standard.Figure 2 shows how STIL fits into the data flow between computer-aided engineering (CAE)/simulation a
33、ndthe test environment. In this figure, STIL is shown as both the input and output of “STIL ManipulationTools.” STIL represents patterns as a series of cyclized waveforms that are executed sequentially. The wave-form representation can be as simple as a “print-on-change” set of events, or a complex
34、set of parameterizedevents. Hence, tools may be required to manipulate the data according to the requirements of a particularclass of device, simulation, or tester. The output of that manipulation is still represented in STIL.Another issue presented in Figure 2 is the need for data from the tester t
35、o be transmitted back to theCAE/simulation environment for the purpose of correlating simulation data to tester data. Although this isrecognized as an important aspect of testing digital devices, it does not represent the data volume that thepatterns themselves do, and is not specifically supported
36、in this version of the standard. 8 BS IEC 62525:2007IEEE 1450-1999S T I LFormatter ToolCAECAETest TranTest TranTest TranEditorsperl,Tester AdjustFigure 1A conduit for transporting data from CAE to ATESTILSTILManipulationToolsSimulatorsTarget testertranslator /compilerVector b) Specifies pattern, for
37、mat, and timing information sufficient to define the application of digital testvectors to a device under test (DUT);c) Supports the volume of test vector data generated from structured tests such as scan/automatic testpattern generation (ATPG), integral test techniques such as built-in self test (B
38、IST), and functionaltest specifications for IC designs and their assemblies, in a format optimized for application in ATEenvironments.In setting the scope for any standard, some issues are defined to not be pertinent to the initial project. Thefollowing is a partial list of issues that were dropped
39、from the scope of this initial project: Levels: A key aspect of a digital test program is the ability to establish voltage and current parame-ters (levels) for signals under test. Level handling is not explicitly defined in the current standard, asthis information is both compact (not presenting a t
40、ransportation issue) and commonly establishedindependently of digital test data, requiring different support mechanisms outside the current scopeof this standard. Termination values may affect levels. Diagnostic/fault-tracing information: The goal of this standard is to optimally present data that n
41、eedsto be moved onto ATE. While diagnostic data, fault identification data, and macro/design elementcorrespondence data can fall into this category (and is often fairly large), this standard is alsofocused on integrated circuit and assemblies test, and most debug/failure analysis occurs separatelyfr
42、om the ATE for these structures. Note that return of failure information (for off-ATE analysis) isalso not part of the standard as currently defined. Datalogging mechanisms, formatting, and control usually are not defined as part of this currentstandard. Parametric tests are not defined as an integr
43、al part of this standard, except for optional pattern labelsthat identify potential locations for parametric tests, such as IDDQtests or alternating current (AC)timing tests. Program flow: Test sequencing and ordering are not defined as part of the current standard except asnecessary to define colle
44、ctions of digital patterns meant to execute as a unit. Binning constructs are not part of the current standard. Analog or mixed-signal test: While this is an area of concern for many participants, at this pointtransfer of analog test data does not contribute to the same transportation issue seen wit
45、h digital data. Algorithmic pattern constructs (such as sequences commonly used for memory test) are not currentlydefined as part of the standard. Parallel test/multisite test constructs are not an integral part of the current environment. User input and user control/options are not part of the curr
46、ent standard. Characterization tools, such as shmoo plots, are not defined as part of the current standard. 10 BS IEC 62525:2007IEEE 1450-19991.2 PurposeThis standard addresses a need in the integrated circuit (IC)1test industry to define a standard mechanism fortransferring the large volumes of dig
47、ital test data from the generation environment through to test. Theenvironment today contains unique output formats of existing CAE tools, individual test environments of ICmanufacturers, and proprietary IC ATE input interfaces. As each of these three arenas solves individual prob-lems, together the
48、y have created a morass of interfaces, translators, and software environments that provideno opportunity to leverage common goals and result in much wasted efforts re-engineering solutions. Asdevice density increases, the magnitude of test data threatens to shift the test bottleneck from the generat
49、ionprocess to the processes necessary solely to maintain and transport this data. These two factors threaten toeliminate any productive work performed in this area unless a viable standard is defined.With a common standard for CAE and IC ATE environments, the generation, movement, and processing ofthis test data is greatly facilitated. This standard also allows for immediate access to test equipment support-ing this standard, which benefits both ATE and IC vendors reviewing this equipment.This standard also serves as a catalyst for the development of a set of s
