1、IEEE Std 1450.6-2005IEEE Standard Test Interface Language (STIL) for Digital Test Vector DataCore Test Language(CTL)I E E E3 Park Avenue New York, NY10016-5997, USA5April 2006IEEE Computer SocietySponsored by theTest Technology Standards CommitteeIEEE Std 1450.6-2005(R2011)IEEE Standard Test Interfa
2、ce Language (STIL) for Digital Test Vector DataCore Test Language (CTL)SponsorTest Technology Standards Committeeof theIEEE Computer SocietyApproved 17 November 2005IEEE-SA Standards BoardReaffirmed 16 June 2011IEEE-SA Standards BoardApproved 29 December 2005American National Standards InstituteReaf
3、firmed 26 July 2012American National Standards InstituteThe Institute of Electrical and Electronics Engineers, Inc.3 Park Avenue, New York, NY 10016-5997, USACopyright 2006 by the Institute of Electrical and Electronics Engineers, Inc.All rights reserved. Published 5 April 2006. Printed in the Unite
4、d States of America.IEEE is a registered trademark in the U.S. Patent +1 978 750 8400. Permission to photocopy portions of any individual standard for educational classroom use can also be obtained through the Copyright Clearance Center. iv Copyright 2006 IEEE. All rights reserved.IntroductionCTL st
5、arted as a language in the IEEE Std 1500TM-2005 standardization activity for core test. This activityprovided a representation mechanism for test information that exchanges hands between a core provider andthe system integrator. Thus, the language had a charter to provide a mechanism for reuse of te
6、st patterns andinformation that allows for successful design for test and automatic test pattern generator activities on theSoC. As part of IEEE Std 1500-2005, CTL was designed to represent details about the IEEE 1500 wrapper.As CTL and the wrapper technology matured, it became apparent that the two
7、 activities should be separatedinto two standard documents. As a result of this decision, CTL, the language, became IEEE Std 1450.6activity, and the information model for cores that uses CTL remained in IEEE Std 1500-2005. Notice to usersErrataErrata, if any, for this and all other standards can be
8、accessed at the following URL: http:/standards.ieee.org/reading/ieee/updates/errata/index.html. Users are 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.PatentsAt
9、tention is called to the possibility that implementation of this standard may require use of subject mattercovered 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 resp
10、onsible for identifyingpatents or patent applications for which a license may be required to implement an 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 CTL Workin
11、g Group: Rohit Kapur, Chair When the CTL Working Group approved this standard, it had the following short-term membership:Mike CollinsDouglas KayBrion Keller Maurice LousbergPaul ReuterBill Chown Yuhai MaThis introduction is not part of IEEE Std 1450.6-2005, IEEE Standard Test Interface Language (ST
12、IL) for DigitalTest Vector DataCore Test Language (CTL).Copyright 2006 IEEE. 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 stan
13、dard on 17 November 2005, it had the followingmembership:Steve M. Mills, ChairRichard H. Hulett, 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,
14、DOE RepresentativeAlan H. Cookson, NIST RepresentativeJennie M. SteinhagenIEEE Standards Project EditorKen-ichi AnzouLuis BastoSudipta BhawmikDwayne BurekChen-Huan ChiangKeith ChowBill ChownAntonio M. CicuLuis CordovaJason DoegeGeir EideGrady GilesAlan HalesPeter HarrodMitsuaki IshikawaRohit KapurJa
15、ke KarrfaltDouglas KayBrion KellerAdam LeyDennis LiaMaurice LousbergYuhai MaRyan MadronErik Jan MarinissenDenis MartinGregory MastonYinghua MinMehdi MohtashemiJames MonzelNarayanan MurugesanBenoit Nadeau-DostieCharles NgetheJim OReillyAdam OsseiranKlaus RapfPaul ReuterMike RicchettiGordon RobinsonGi
16、l ShultzDouglas E. SpragueTony TaylorTom WaayersGregg WilderT. W. WilliamsLi ZhangMark D. BowmanDennis B. BrophyJoseph BruderRichard CoxBob DavisJulian Forster*Joanna N. GueninMark S. HalpinRaymond HapemanWilliam B. HopfLowell G. JohnsonHerman KochJoseph L. Koepfinger*David J. LawDaleep C. MohlaPaul
17、 NikolichT. W. OlsenGlenn ParsonsRonald C. PetersenGary S. RobinsonFrank StoneMalcolm V. ThadenRichard L. TownsendJoe D. WatsonHoward L. Wolfmanvi Copyright 2006 IEEE. All rights reserved.Contents1. Overview 11.1 General. 11.2 SoC flow 21.3 Scope 41.4 Purpose. 41.5 Limitations of this standard . 41.
18、6 Structure of this standard . 52. Normative references. 53. Definitions, acronyms, and abbreviations 63.1 Definitions . 63.2 Acronyms and abbreviations . 64. CTL orientation and capabilities tutorial . 74.1 Introduction 74.2 CTL for design configurations. 84.3 CTL for structural information 164.4 C
19、TL for test pattern information 214.5 Beyond the examples . 265. Extensions to IEEE Std 1450-1999 and IEEE Std 1450.1-2005 . 275.1 STIL name spaces and name resolution 275.2 Optional statements of IEEE Std 1450-1999. 275.3 Restricting the usage of SignalGroup and variable names 275.4 Additional rese
20、rved words . 285.5 STIL statementextensions to IEEE Std 1450-1999, Clause 8 . 285.6 Extensions to IEEE Std 1450-1999, 17.1 and 23.1 295.7 Extensions associated with the LockStep construct of Clause 13 of IEEE Std 1450.1-2005 326. Design hierarchycores 366.1 CoreType block and CoreInstance statement
21、366.2 CoreType block syntax descriptions 366.3 CoreType block code example 377. Cell expression (cellref_expr) 388. Environment blockextensions to IEEE Std 1450.1-2005, Clause 17 398.1 General. 398.2 Definition of FileReference keywords. 398.3 Example of Environment block FileReference syntax 438.4
22、Extension to NameMaps 438.5 Extension to the inheritance of environment statements . 449. CTLMode block. 45Copyright 2006 IEEE. All rights reserved. vii9.1 General. 459.2 CTLMode syntax . 459.3 CTLMode blocksyntax descriptions 479.4 CTLMode block syntax example. 5310. CTLModeInternal block 5610.1 Ge
23、neral. 5610.2 Internal syntax 5610.3 Internal block syntax descriptions . 6010.4 Internal BlockSyntax examples . 7611. CTLModeScanInternal block 7911.1 General. 7911.2 ScanInternal syntax 7911.3 ScanInternal block syntax descriptions8111.4 ScanInternal block syntax example .8112. CTLModeCoreInternal
24、 block 8312.1 General. 8312.2 CoreInternal syntax 8312.3 CoreInternal block syntax descriptions8412.4 CoreInternal block syntax examples8413. CTLModeRelation Block 8513.1 General. 8513.2 Relation syntax 8513.3 Relation block syntax descriptions 8513.4 Relation block syntax example 8714. CTLModeScanR
25、elation block . 8914.1 General. 8914.2 ScanRelation syntax. 8914.3 ScanRelation block syntax descriptions 8915. CTLModeExternal block . 8915.1 General. 8915.2 External statement syntax 9015.3 External block syntax descriptions 9015.4 External block syntax example 9316. CTLModePatternInformation bloc
26、k 9316.1 PatternInformation syntax 9316.2 PatternInformation block syntax descriptions . 9616.3 PatternInformation block syntax example . 104Index . 109Copyright 2006 IEEE. All rights reserved. 1IEEE Standard Test Interface Language (STIL) for Digital Test Vector DataCore Test Language (CTL)1. Overv
27、iew1.1 GeneralThe Core Test Language (CTL) is a language created for a System-on-Chip flow (or SoC flow), where adesign created by one group is reused as a sub-design of a design created by another group. In an SoC flow,the smaller design embedded in the larger design is commonly called a core and t
28、he larger design iscommonly called the SoC. The core is a design provided by a core provider, and the task of incorporating thesub-design into the SoC is called Core System Integration.CTL is a language designed to be the transfer mechanism of test knowledge between a core provider and asystem integ
29、rator to allow for interoperability between the producer and the consumer of the information. Itfacilitates the reuse of test patterns provided for a core for application from the SoC boundary. Although thelanguage is general (the limitations of CTL are listed in 1.5) and can be used in many differe
30、nt ways, thisstandard is focused on the use of CTL for SoC designs. Thus, CTL allows fora) Representation of design constructs and characteristics that are needed to be made visible by thecore provider.b) Representation of test patterns that are to be reused for cores in an SoC test flow.CTL provide
31、s the language for communication of test information. An adjacent IEEE standard activity(IEEE Std 1500TM-2005)1defines the information requirements of the core provider that are required to berepresented in CTL. As a result of this relationship with IEEE Std 1500-2005, CTL has some constructs that1F
32、or information on references, see Clause 2.IEEEStd 1450.6-2005 IEEE STANDARD TEST INTERFACE LANGUAGE (STIL) FOR2 Copyright 2006 IEEE. All rights reservedare there to support IEEE Std 1500-2005s informational requirements for wrapped and unwrapped cores. Inan SoC flow (where cores are reused in SoCs)
33、, CTL represents all of the test information about the core suchthat the core can be successfully embedded in the SoC from a test perspective. CTL is a language thatprovides the information about the structures in the core that are to be reused at the next level of integration.Test reuse is also abo
34、ut the reuse of test patterns. As a result, CTL allows for the description of reusable testpatterns (portable tests). CTL leverages existing standard representations. The CTL language is the union ofthe syntax defined in IEEE Std 1450TM-1999, IEEE Std 1450.1TM-2005, IEEE Std 1450.2TM-2002, and thiss
35、tandard. CTL extends the definitions defined in IEEE Std 1450-1999 and IEEE Std 1450.1-2005 withextensions and exceptions defined in this standard. The reader is assumed to have knowledge of thesestandards, and their associated content is not repeated or explained in this standard. CTL has the follo
36、wing characteristics to support the SoC test:a) CTL can describe constructs to handle a wide variety of cores.b) CTL does not limit the test methodologies of the core provider.c) CTL can describe IEEE Std 1500-2005 wrapped and unwrapped cores. (Refer to the associatedstandard for details.)1) Unwrapp
37、ed cores can be described in CTL to aid in the creation of the wrapper.2) Wrapped cores can be described in CTL to allow for the reuse of the wrapper in theintegrated SoC.2) CTL describes the patterns of the wrapped or unwrapped core such that modifications can bemade to the core for application fro
38、m the SoC boundary.CTL handles this variety of needs by providing a test mode structure within which primitive concepts arepieced together to describe the test information. Several sets of keywords are provided that form thevocabulary of CTL. The keywords are put together to represent information th
39、at are sentences of testinformation. CTLs ability to handle different designs and their associated test methodologies comes from itsreliance on sequences. Predefined sequence types (EstablishMode and TerminateMode) are used to treat thedifferent design configurations (test modes) in a uniform way. S
40、equence information is leveraged fromIEEE Std 1450-1999 and IEEE Std 1450.1-2005 syntax, with the difference that the information is drivenfrom the CTL Environment and test modes.1.2 SoC flowAs mentioned, an SoC flow is the process in which a sub-design (core) is embedded in a larger design (SoC).Th
41、e major steps of this flow are shown in Figure 1. Let us assume that CTL exists and it can describeeverything needed for the core. Figure 1 shows three major steps in the process of designing the testingmechanism and the test patterns for embedded cores. The first step shows the “Core Design” work.
42、Thiswork is performed in such a manner that the resultant core can be reused in multiple designs with NO changerequired to either the core design or to the bulk of the test patterns information (data portion of the testpatterns) that are developed for testing the core. The first section in the diagr
43、am shows the core design process where the “IP core model” is represented(e.g., a Verilog or VHDL design). Along with the design, a set of “Core Test Patterns” in CTL syntax isgenerated (syntax from IEEE Std 1450-1999, IEEE Std 1450.1-2005, IEEE Std 1450.2-2002, and thisstandard). A complete CTL des
44、cription encompasses test patterns and its associated constructs and adescription of the various test modes of the core. Typical cores support multiple configurations that servedifferent purposes such as internal testing of the core and external testing of the logic outside the core. CTLinformation
45、is partitioned across these configurations (test modes). The entire description of CTL is centeredaround the Environment (this is the top-level block of statements in the language), which is shown inFigure 1. The information requirements for cores is defined by IEEE Std 1500-2005. The requirementsen
46、sure that enough information is present to create the test for the finished SoC.IEEEDIGITAL TEST VECTOR DATACORE TEST LANGUAGE (CTL) Std 1450.6-2005Copyright 2006 IEEE. All rights reserved. 3The second section of Figure 1 shows the System Integration process. In this process, the SoC integratormakes
47、 use of the CTL description of the core design to create the tests for the SoC. This process couldinvolve multiple activities depending on the design and test methodologies in use. The following are someactivities that the system integrator may perform:a) Wrapper Design: Wrapper technology represent
48、s isolation hardware at the boundary of cores for testpurposes. The wrapper isolates the testing of the core logic from the testing of the user-defined logicon the SoC. IEEE Std 1500-2005 defines such technology. Cores may or may not be provided withwrappers. If the test methodology relies on wrappi
49、ng cores, then the system integration step wouldlook for information in CTL of the core to determine whether a wrapper is provided with the core. Ifthe wrapper is not provided, the CTL information of the core would be used to determine thewrapper cells and other details of the wrapper technology.b) Test Access to Cores: The connections from the core boundaries to the top level of the SoC dependson the different cores embedded in the SoC. The design of the associated design entities depends onthe scheduling of the tests of the different cores, which is det
