CTL FOR TEST INFORMATION OFDIGITAL ICs

This page intentionally left blank

CTL FOR TEST INFORMATION OFDIGITAL ICs

byRohit KapurSynopsys, Inc.

KLUWER ACADEMIC PUBLISHERSNEW YORK, BOSTON, DORDRECHT, LONDON, MOSCOW

eBook ISBN: 0-306-47826-9Print ISBN: 1-4020-7293-7

2002 Kluwer Academic PublishersNew York, Boston, Dordrecht, London, Moscow

Print 2003 Kluwer Academic Publishers

All rights reserved

No part of this eBook may be reproduced or transmitted in any form or by any means, electronic,mechanical, recording, or otherwise, without written consent from the Publisher

Created in the United States of America

Visit Kluwer Online at: http://kluweronline.comand Kluwer's eBookstore at: http://ebooks.kluweronline.com

Dordrecht

to my family

This page intentionally left blank

TABLE OF CONTENTS

CHAPTER 1

HELLO CTL1.11.21.3

1.3.11.3.2

CHAPTER 2

USES OF CTL2.12.22.32.42.5

CHAPTER 3

DESIGN PHILOSOPHY OF CTL3.13.23.3

3.3.13.3.2

3.43.53.6

INTRODUCTIONCONVENTIONS USED IN THIS BOOKCTL - BY EXAMPLE

ATPG-FSBasic Design Information needed by ATPG-FS

USED AS AN INTERFACE BETWEEN THE USER/DFT AND ATPG-FSUSED IN SOC METHODOLOGIES TO DESCRIBE CORESUSED AS AN INTERFACE BETWEEN THE DESIGN AND THE ATEUSED AS INTERFACE BETWEEN DIFFERENT TEST AUTOMATION TASKSUSED AS AN HIERARCHICAL DFT LANGUAGE

WORDS THAT MAKE-UP SENTENCESEXTENDABILITY OF THE LANGUAGELEVERAGING EXISTING STANDARDS

Design Constructs and CTLSequence and Pattern Information in CTL

HIERARCHY AND CTLPURPOSE OF CTL (IEEE 1450.6) AS DEFINED BY THE STANDARDSCOPE OF CTL (IEEE 1450.6) AS DEFINED BY THE STANDARD

CHAPTER 4

SIMPLIFIED VIEW OF CTL4.14.2

THE ENVIRONMENT AND ASSOCIATED INFORMATIONEXAMPLE: ENHANCED ATPG-FS INFORMATION

1

1

l2223

7

77899

10

12

12

1213141415171717

18

181820

viii

CHAPTER 5 25

25CTL SYNTAX AND SEMANTICS: DESIGN ENTITIES5.15.2

READING CTL SYNTAXUSER DEFINED NAMES IN CTL

5.2.15.2.25.2.3

5.3

Construction of NamesScope of NamesEntity Names in Domains and CoreInstances

DESIGN ENTITIES RECOGNIZED IN CTL

252828293031325.3.1

5.3.25.3.3

Signals and Signal GroupsScanStructures and ScanCellGroupsCore Instances

3638

CHAPTER 6 44

CTL SYNTAX AND SEMANTICS: TOP LEVEL VIEW6.16.26.36.4

TEST MODES OF DESIGNSTYPES OF TESTMODESLAYOUT OF TEST MODESCATEGORIES OF INFORMATION IN EVERY TEST-MODE:

CHAPTER 7

CTL SYNTAX AND SEMANTICS: TEST MODE CONSTRUCTS IN THEENVIRONMENT

7.17.27.3

DOMAINREFERENCES

44

474951

56

53

56

566063

RELATIONINTERNAL

7.3.17.3.27.3.37.3.47.3.57.3.67.3.77.3.87.3.9

7.47.57.6

7.6.1

65667173778586

ElectricalPropertyDataTypeInputProperty and OutputPropertyDriveRequirements and StrobeRequirementsIsConnectedLaunchClock and CaptureClockWrapperIsDiabledBy and DisableStateScan Style

SCANINTERNALCOREINTERNALEXTERNAL

ConnectTo Statement

899091939597

ix

7.6.27.7

7.7.17.7.27.7.37.7.4

AlowSharedConnection statementPATTERNINFORMATION

Timing : WaveformsProtocols : Macros and ProceduresPatternsSchedule : PatternExec and PatternBursts

9899

101106117122

128

CTL SYNTAX AND SEMANTICS: SHORTCUTS

CHAPTER 8

8.18.28.3

INCLUDENAMEMAPSINHERIT

128128128130

CHAPTER 9

EXAMPLES DESCRIBING TEST INFORMATION IN CTL9.19.29.39.4

ATPG OUTPUT IN CTLDESCRIBING CORES IN CTLINTEGRATING A CORE IN AN SOCINTEGRATING MULTIPLE CORES IN A SOC

137

137

138143152161

TABLE OF FIGURESFigure 1:Figure 2:Figure 3:

Figure 4:

Figure 5:

A sample design that is to be run through an ATPG-FS toolCTL describing design information as input to ATPG-FSSoC test methodology showing the use of CTL information instead of the

netlist of the corresponding coresCTL used as the mechanism to pass information between the tester and

design environmentCTL used to communicate intermediate information between the analysis

engine and the implementation engine of the DFT tasksFigure 6:Figure 7:Figure 8:Figure 9:

A recursive design flow for testCTL information corresponding to the design boundaryCTL for a portion of the netlist that needs to be representedCTL syntax structure as it leverages IEEE 1450, IEEE 1450.1 standards

Figure 10:Figure 11:Figure 12:Figure 13:Figure 14:Figure 15:Figure 16:

High level view of a CTL descriptionPatterns and Sequences as it relates to the EnvironmentDesign entities recognized by CTLDesign with a scan-chain consisting of five scan-elementsA Design for which CTL is being written that is reusing coresDesign to show the construction of a hierarchical scan-chainTop level information of CTL in the Environment and the links to

constructs external to the environmentFigure 17:Figure 18:Figure 19:

Overall structure of CTL information as it relates to test modesCategories of information in CTL as it related to the designDomainReferences mechanism to link the SignalGroups into a test mode

Figure 20:Figure 21:Figure 22:Figure 23:Figure 24:

Design embedded in a larger netlistTemporal view of a TestMode showing three sectionsFlip-flop examples to show clock data typesExample timing relationship between two signals waveformsExample connection of an input and output of the design being

represented in CTL to an internal scan cell of the design

37

8

9

1011141516182032374042

464854

5762686975

8288

98101

Figure 25:Figure 26:

Examples of two wrapper-cell implementationsIntegrating the pass/fail signal of two BISTed cores that are tested in

parallelFigure 27:Figure 28:

Overall pattern information structureA possible breakup of a sequence (scan test pattern) composed of three

types of phasesFigure 29:Figure 30:Figure 31:Figure 32:

Schedule of patterns as they relate to the test modesExample design repeated from Chapter 1 on page 3Core integrated into the SoCTwo instance of the same core being integrated in a SoC. The internal

scan chains of the two cores are daisy-chained

105123137153

162

PREFACECTL (proposed standard as IEEE 1450.6, Core Test Language) is a languagethat has many possible applications in the area of test. The language reusessyntax defined by IEEE 1450 and IEEE 1450.1 and was created primarily forthe proposed IEEE 1500 standard. As it can be seen, CTL is a language witha conglomeration of concepts that is spread thin across multiple documents.As a result I saw a need to put the basic concepts of CTL in a single location.

CTL has been created by a small team of experts who work for differentcompanies in test-technology and test-automation. They created the languageover a span of about three years as a company-sponsored volunteer activity.The author would like to acknowledge the contributions these people andtheir associated companies have made to the language.

This book should be read by anyone who is interested in testing integratedcircuits. The contents of this book are especially relevant to the segment ofthe industry that is developing cores and/or using cores in system-on-chipmethodologies.

Note: The CTL introduced in this book reflects the latest syntax of thelanguage at the time this book was published. The reader should understandthat CTL has not been standardized as yet and the language could change.

This page intentionally left blank

Chapter 1Hello CTL

1.1 INTRODUCTIONICs have been designed, manufactured, tested and used in a larger system formany years. The technology has improved by leaps and bounds over theyears to allow for putting millions of transistors on a single chip. This hasallowed for the creation of large designs that can no longer be created fromscratch in a limited time. IC design methodologies are changing to rely onreuse methodologies, where smaller designs (cores) are reused in a largerdesign called a SoC (System-on-Chip). Reuse of designs is forcing theunderstanding of hierarchy in design methodologies. New mechanisms arebeing put in place to support the communication needs of the various partiesinvolved in the creation of the single design (now called a SoC). CTL is theoutcome of the need to solve the communication between multiple parties tocreate a successful test set for the SoC which involves testing the reusedembedded design called a core, and testing the logic of the SoC around thecore in the presence of the core.

CTL is a language that is used to represent test information. It is beingdeveloped as a standard within the IEEE framework. The proposed standardIEEE 1450.6 namely the Core Test Language (CTL) has its beginnings in theproposed IEEE 1500 standardization activity as the language to represent testinformation about a core. Hence the name Core Test Language. While thename has remained the same, the language has been designed to be generallyapplicable for a number of activities in digital IC testing. This book isfocused on describing CTL. Though various examples different applicationsof CTL are described. CTL is shown as in input language to ATPG-FS toolsand a language to communicate test information about a core. It is alsoshown how CTL can be used in the integration process of cores in SoCs.These should not be construed as the only ways CTL can be used by the testcommunity.

To begin with CTL concepts are used in a simple example to introduce thelanguage as a whole. After the introductory example the uses and designphilosophy of the language is described. Once the reader has become familiarwith the general way of thinking in CTL, an overview of the languagestructure is provided before larger examples and more refined concepts ofCTL are described. This book is an example-oriented book on CTL that iswritten with the goal of getting the reader to think like the creators of CTL.Most of the explanations are limited to very simple examples so that thenetlist (design) can be drawn out for better visualization of the concepts.

2Once that is achieved the reader should be able to use CTL in ways notdescribed in this book or the standard itself.

There are two types of example CTL syntax in this book. Examples thatexplain the use of CTL and examples that describe syntax and semantics ofthe language as it is being introduced. The examples explaining the syntaxare incomplete examples of CTL with the goal of explaining the associatedconstructs. CTL syntax and examples are provided with line numbers forcross-reference in the text throughout this book. Bold letters in the codehighlight keywords of the CTL language that have specific meaning and aredefined in the standard document (IEEE 1450, 1450.1 and 1450.6). Whilethese keywords are explained in this book, no effort is made to replicate theexact definitions of the keywords that are available in the standard. Non-boldtext typically is a user-defined entity. Comments are in italics.

CTL is a language to describe test information. Depending upon the contextof the information the examples use different portions of the capabilitiesprovided by the language. In this section it is assumed that CTL is being usedas an input language to an Automatic Test Pattern Generator FaultSimulator (ATPG-FS).

If the IC manufacturing process were perfect every IC made would work asdesigned and no testing would need to be performed. However, this is not thecase. Defects are introduced in the multi-step IC fabrication-process andcause ICs to operate incorrectly. IC testing is performed to remove suchfailing product from the manufactured lot and prevented from being used inthe next level of the system integration. Testing of these ICs is performedusing test equipment to apply stimulus to the ICs and observe the responses.These tests are typically determined by ATPG-FS tools (software) that run onthe design which is represented by primitives such as AND/NAND gates,OR/NOR gates, exclusive-OR gates, inverters, flip-flops, latches,RAM/ROMs, tri-states and others. This level of the design is an abstractrepresentation of the actual implementation where the defects occur. At thislevel of design abstraction, tests are created against an abstract representationof the defects known as faults. These faults are assumptions about possiblefailures in the design that help in generating and evaluating the tests.

1.3 CTL BY EXAMPLE

1.2 CONVENTIONS USED IN THIS BOOK

1.3.1 ATPG-FS

3Commonly known fault models used in the industry are the Stuck-At faultmodel, the Transition fault model and the Pseudo-Stuck-At fault model. Allthese fault models assume that a single location of the design is faulty at anygiven time.

The search algorithm to generate a test for a fault has to explore all thepossible states of the design for all possible input combinations. This couldbe very time consuming and some modifications are typically made to thedesign to facilitate the automation of the test creation process. Thismodification of the design is commonly known as Design-for-Test (DFT). Anumber of DFT methods have been explored which make ATPG-FS muchmore efficient. The most common DFT solution puts memory elements ofthe design into a shift register configuration (scan-chain) in a shift mode,which is used to reduce the sequentiality of the ATPG-FS problem. Theprocess of doing this is commonly called scan-insertion. Other DFT methodsinclude RAM isolation with scan chains and test point technology to assistthe ATPG-FS tasks.

For the DFT that is put in the design to be recognized by ATPG-FS somedescription about the design needs to be provided. This description is thegenesis of CTL concepts. CTL provides a mechanism to represent testinformation of the design in a concise way.

1.3.2 Basic Design Information needed by ATPG-FSLet us consider the example design of Figure 1 (constructed to describeconcepts) with regard to the information needed by ATPG-FS.

The design has a single bit scan chain that is shiftable when input e is set to alogic-1. The scan chain (shift register) created in this configuration has aninput s, an output o and the shift operation occurs when the clock c is pulsed.This is a design in which scan-insertion has been performed.

ATPG-FS expects the user or the tool creating the scan chain in the design todefine the interface signals of the scan chain. ATPG-FS would then simulatethe information in a Design Rule Checking (DRC) step to extract the bits ofthe scan chain for use in its subsequent operations. This user-specifiedinformation to ATPG-FS tools is an abstract description of the relevant testconstructs of the design. CTL is used in the example below to represent suchtest related abstract information about the design.

1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.

4

STIL 1.0 {CTL ThisBook;

}Header {

Title CTL for input to ATPG-FS;Date 2002;

}

Signals {a In;b In;c In;s In;e In;o Out;

}

Environment inputToAtpg {CTL {

Internal {c { DataType TestClock ScanMasterClock

MasterClock {AssumedInitialState ForceDown;}}

s { DataType TestData ScanDataIn; }e { DataType TestControl ScanEnable

{ ActiveState ForceUp;AssumedInitialState ForceDown;}}

o { DataType TestData ScanDataOut; }

529.30.31.

The above CTL statements define information that the ATPG-FS wouldtypically use as input. ATPG-FS is looking for the interface of the design andcertain special characteristics of the signals. The example begins with twoblocks of statements that describe the version of the syntax used (1 to 3) anda header for the file (4 to 7).

The Signals block of statements defines all the signals of the design and thedirection associated with the signals. In this example, a, b, c, s, e are inputs(In) of the design and o is identified to be an output (Out) of the design (9 to16). All information about the signals is defined in an Environment (18 to31) block of statements in an embedded CTL (19 to 30) block. Informationabout the signals is provided with the following convention.

Internal {Signal_Name {

//Statements describing information// associated with the signal called// Signal_Name.

}}

The descriptions of the signals are provided in the Internal (20 to 29) blockof statements. Using the DataType statement the characteristics of the signalare specified.

In our example, signal c is a clock signal to be used by the test patterns(TestClock). It is also used as a clock that operates the scan chain(ScanMasterClock) and it is also the functional clock (MasterClock) of thedesign (21, 22). ATPG-FS tools also associate a stable state with clocks. Thisis the state that ATPG would keep the clocks at during most of the testoperations. This is specified using the AssumedInitialState statement andgiven a value ForceDown or a logic-0 in the example (23).

Signal s is identified as an input that would get test data (TestData). In thisexample, the test data that would be applied to s is stimulus for the scan

}}

}

6chain (ScanDataIn) (24). Similarly, signal o is identified to be a scan out(28).

Signal e is identified as a scan chain configuration (ScanEnable) signal,which is a special type of test control signal (TestControl) (25). ATPG-FStools typically expect to know the state of scan enable signals to allow foroperation of the scan chain. The state of the scan enable signal that enablesthe shift operation is specified with the ActiveState statement (26). In thisexample, the scan chain is configured when signal e has a logic-1 (ForceUp)applied to it. Scan enable signals are typically assumed to be in the state thatis not configuring the scan chains into a shift register. Thus theAssumedInitialState of the scan enable signals is ForceDown.

In a later section the output of the ATPG-FS tool is provided in CTL for thetool that would have taken the above as input (section 9.1 page 138).

Chapter 2Uses of CTLWithout knowing all the details about CTL let us assume that a human-readable and tool-readable language exists that can describe all theinformation about a design that are needed for applications in test. The goalof this chapter is to understand what all can be done with such capabilities.

2.1 USED AS AN INTERFACE BETWEEN THEUSER/DFT AND ATPG-FS

The example of the previous chapter actually showed how information isdescribed in CTL as an input to an ATPG-FS tool. The creator of thisinformation could be a User or the DFT tool that puts in the relevant teststructures in the design.

Figure 2 shows that ATPG-FS tools need the design description as a netlisttypically at the gate level to perform the test generation and fault simulationtasks. Special constructs of the design are recognizable through a descriptionthat is provided in CTL. ATPG-FS typically takes this input to extractnecessary information about the design that is typically not part of the netlist.ATPG-FS also takes in parameters or constraints from the user. Theseconstraints effect the operation of the test generation and fault simulation

algorithms. With these three inputs ATPG-FS is able to perform its functionand test patterns can be created.

CTL was primarily designed to support an SoC design flow such that testinformation could be represented for cores and consumed by the next level ofthe design (SoC) that is integrating the core.

Figure 3 shows how CTL information about a core is taken in as a substituteof the netlist information of the cores to enable the protection of intellectual

8

2.2 USED IN SOC METHODOLOGIES TO DESCRIBECORES

9property for the test related activities in the SoC. As a result the systemintegration task which may involve adding scan wrappers around the cores,scheduling and mapping of the test patterns of the cores and test generationof the user defined logic outside the cores can be performed in the presenceof the cores. The final result of such an activity is the creation of a test set forthe SoC.

2.3 USED AS AN INTERFACE BETWEEN THE DESIGNAND THE ATE

ATE hardware has traditionally been a tool with a lot of under ultilizedcapabilities. This is because the ATE environment does not have access toinformation that could lead it to do smarter things. CTL provides aninformation rich environment, which includes test patterns, that it couldpossibly be used as an interface between the design environment and theATE for the ability to create a smarter ATE environment (as shown in Figure4).

2.4 USED AS INTERFACE BETWEEN DIFFERENTTEST AUTOMATION TASKS

Test automation contains many sub-steps that are known to the typical testuser. These steps include activities like identification of test points,extraction and/or validation of scan-chains, test schedules in a SoC flow etc.In most cases the tools that perform this task allow the user to preview theresults of an analysis and possibly manipulate it. CTL could play a role inproviding this information.

10

2.5 USED AS AN HIERARCHICAL DFT LANGUAGEJust by the fact that CTL represents all test-information of a design as areplacement of the netlist (in the case for cores) allows it to be a mechanismto support a hierarchical (or recursive) DFT flow.

Figure 6 shows a flow where a design is being created that incorporates asub-design whose test information is described in CTL (ctl). If CTL iscreated for the top design the same flow can be repeated to achieve acomplete hierarchical methodology.

Figure 5 shows how CTL can be used as the communication mechanismbetween a DFT analysis process and the actual implementation of thestructures. Since the communication is through CTL other analysis toolscould plug in easily into such a flow.

While this flow is very similar to that of SoCs, the tasks and their associatedinformation needs in this flow are different. In a true hierarchical DFT flowthe information needed in CTL is to support the needs for processes likeDRC that check for feedback loops in the design as opposed to the SoC flowwhich is focused on the reuse of test patterns that come with the core. DRCwould have to look at information in the CTL of the sub-design (ctl in thefigure) to find feedback loops that were not present in the sub-design or thetop-level design itself. The same would be true for race conditions and otherchecks made by typical DRCs.

11

Chapter 3Design Philosophy of CTLCTL is designed for abstracting test information of designs forcommunication in an automation-friendly format or human-readable format.The language is specially designed for an environment that allows for reuseof designs as cores in System-on-Chip (SoC) designs. In this environment,the consumer of this information could be a test automation tool thatintegrates cores into the SoC, or a person integrating the core. The goal ofCTL is to describe test information for any core without restricting the testmethodology used in the core. As a result CTL is a general language that isnot tied to any given test architecture. It is the intent of this book to describethe flexibility of the language that enables CTL to support a number of otherneeds in the representation of test information.

It is not possible for this book to cover all the possible uses of CTL. Thelanguage forms a basis for the development of applications that have notbeen possible in the past. For example this language could be used to providea richer interface between ATE and test automation tools than the existingtest pattern interface. With a CTL interface ATE software will have a moreinformation rich environment available to it that will allow for many morevalue added features (for example debug related capabilities).

To handle the vast variety of pieces of test information that need to bedescribed CTL is designed as a language that constitutes keywords thatrepresent small but crisp concepts. These are the words of the testinformation of the design. These words can be put together in numerousways to describe complete concepts in test which are true to the mechanismsin the design. This can be best understood by looking at a construct that hasbeen introduced in a previous chapter.

WORDS THAT MAKE-UP SENTENCES3.1

Let us take the simple construct called DataType. This statement allows forinformation to be described about the special types of signals that exist in adesign as applicable to test. There are many different types of special signalsin the design. For example, there could be a signal that is an asynchronousreset signal that needs to be held constant during the application of testpatterns. Under DataType each characteristic has a special keywordassociated with it. These keywords when combined for this signal would

convey this information. Thus in this example, the signal would be attributedas DataType Asynchronous Reset TestMode.

13

CTL keywords are selected such that they are as close to the meaning of thedefinition as possible. Abbreviations are avoided as much as possible.Furthermore, across the syntax of CTL the attributes are always given anidentifier to classify the category of information. In the example, DataTypeis the identifier or keyword for the list of attributes that define thecharacteristics of signals.

CTL has numerous constructs in the language. Different usage scenarios ofCTL would use subsets of these constructs. Thus when a construct is notused in the CTL implementation no information is to be interpreted withregard to that construct, unless some default is identified for it.

EXTENDABILITY OF THE LANGUAGE3.2The value of CTL is in the keywords that are defined. It is the standardizedkeywords that allow for interoperability between different tools andenvironments. The CTL created by one environment should be readable byanother environment without any glitches or misinterpretations. To highlightthis concept a bit more, a keyword in CTL fixes the expectation of theparsers on the way information is going to appear. DataType spelled indifferent ways would not be able to work across different parsers. CTLattempts to be exhaustive with the keywords where ever possible. However,it is acknowledged that this is an impossible task and the language shouldallow for user defined extensions. This will allow for new concepts and toolsthat are developed in the future to leverage CTL.

Extensions for existing statements are provided through user definedattributes. Continuing with the DataType example, there is the ability to adddata types to the statement as User mydatatype. Use of user defined datatypes should be minimized as the interoperability of the CTL is at risk. If thelanguage is deficient and user defined keywords are used the industry shouldlook towards creating an extension of the standard to standardize theconcepts with formal attributes.

Extensions that require completely new statements in the language arepossible through user keywords (UserKeywords).

14

3.3 LEVERAGING EXISTING STANDARDSOne of the design philosophies of CTL has been to leverage off existingstandards as much as possible. CTL has been designed to co-exist with otherdesign description languages and pattern description languages such that theinformation provided by CTL is complimentary. Thus if an existing languageprovides certain syntax and semantics CTL tries to reuse it as much aspossible without intrusion.

STIL reuse deserves special mention on this subject. Some portions of theCTL syntax requires test pattern like constructs that exist in STIL (IEEE Std.1450-1999). Thus STIL syntax is reused. However, CTL did not exist at thetime STIL was created some enhancements were needed to the test patternsfor STIL to work for CTL. To minimize CTLs intrusion on STIL thefeatures required by CTL were rolled into the STIL standard as an extensionto STIL which is being called IEEE 1450.1.

3.3.1 Design Constructs and CTLCTL is written to a single boundary of the design. The design boundaryrepresented by CTL is identified in the Signals block of statements. In thetrivial case this statement means that there is one CTL description that goeswith a design that describes aspects of the design to its outer boundary asshown in Figure 7.

Figure 7 depicts a CTL description for a design, in which there is a one-to-one correspondence between the design terminals and the signals to whichCTL is provided. While this is going to be the typical way CTL is used this is

15

the most restrictive configuration. If it turns out that the netlist is the bestway to convey information about a portion of the design then one should nottry to replicate the design netlist into CTL. Instead CTL should be used in aconfiguration as shown in Figure 8.

The oval in Figure 8 represents the portion of the netlist that is beingdescribed in CTL. The terminals of this sub-netlist are the three inputs of themultiplexor m0, m1 and me, the clock input to the flip-flop (ffc) and theoutput of the flip-flop (ffo).

CTL is architected in such a way that within reason, any boundary could beselected in a design netlist to represent information. The boundary should notsplit primitives (for example, a tap controller of IEEE 1149.1 or a LinearFeedback Shift Register is considered as a primitive) of the design.

3.3.2 Sequence and Pattern Information in CTLTest information for a design includes test patterns that exercise the designwhen it is manufactured. There already exists a standardized representationof test patterns as STIL (IEEE 1450-1999 or also commonly called 1450.0)and was thus leveraged to the fullest extent. However, STIL was created inan environment that was oblivious to the goals of CTL. Reusable test patternsare different from just plain test patterns. Thus, for CTL to leverage STIL itneeded to limit STILs flexibility or extend STIL to add features for reuse. Aspart of the CTL activities STIL was analyzed and the necessaryenhancements were proposed as an extension to STIL in the form of theIEEE 1450.1 extension. Thus, CTL actually uses STIL patterns that havefeatures defined by IEEE 1450-1999 and IEEE 1450.1.

16

In addition to test patterns CTL needed to describe sequence information(events to be applied in a particular order) for test operations. For example asequence could be representative of the operation to scan-in and scan-outvalues from a scan chain. Instead of inventing new syntax for sequenceinformation, it was recognized that as part of STIL this was available andcould be reused. With the heavy reliance on STIL constructs, the mostnatural syntax for CTL became a STIL like syntax. This allowed forcomplete reuse of STIL as needed in CTL information. Figure 9 depicts theportions of the complete CTL syntax as it relates to the reuse of existingconstructs defined by STIL.

As a result of reuse of STIL the CTL syntax is spread across three documentsnamely, IEEE 1450-1999, IEEE 1450.1 and IEEE 1450.6-CTL. The syntaxof CTL is partitioned in such a way such that the syntax unique to CTL iswritten in a block called Environment. The Environment is a blockprovided by STIL for user defined information. Whenever the CTLinformation, written in the Environment block, needs to reuse STILconstructs the constructs are written outside the Environment block andreferenced in the Environment.

While CTL only allows for its protocols to be described in STIL formats, itrecognizes for the many uses of CTL the test pattern format may not beSTIL. It is possible to link other formats for test patterns into CTL. For moreinformation the reader should look at section 7.7.3 statements 883 to 890 andthe associated explanations.

17

3.4 HIERARCHY AND CTLDesigns and in particular SoC designs contain hierarchy that is created byreuse of cores. CTL represents the information about the hierarchy in aflattened manner. A single representation of CTL is used to represent all thehierarchies that need to be described. That is, a hierarchical design wouldhave a single CTL to represent it and not be constructed out of hierarchicallyconnected CTLs of the sub-designs.

3.5 PURPOSE OF CTL (IEEE 1450.6) AS DEFINED BYTHE STANDARD

The following text is taken from the PAR for the proposed standard.

To develop a language which will provide a sufficient description of a core tosupport reuse of test data developed for that core after integration into SoCenvironments, and to enable the creation of test patterns for the logic on theSoC external to the core.

3.6 SCOPE OF CTL (IEEE 1450.6) AS DEFINED BY THESTANDARD

The following text is taken from the PAR for the proposed standard.

SoC test requires reuse of test data and test structures developed forindividual cores (designs) when integrated into larger integrated circuits(SoCs). This activity will define language constructs sufficient to representthe context of a core and of the integration of that core into a SoC, tofacilitate reuse of test data previously developed for that core. This activitywill also define constructs that represent the test structures internal to thecore, for reuse in the creation of the tests for the logic outside the core.Semantic rules will be defined for the language to facilitate interoperabilitybetween different entities (the core provider, the system integrator, and theautomation tool developer) involved in the creation of a SoC.

The constructs in the language are to support a vast variety of cores anddifferent test methodologies with particular support for the IEEE 1500activity that is creating a wrapper-architecture.

Chapter 4Simplified View of CTLThe CTL syntax is partitioned into blocks of statements that represent certainconcepts. The Environment brings the information together. Thus theprimary informational entity in CTL is the Environment.

4.1 THE ENVIRONMENT AND ASSOCIATEDINFORMATION

Within the Environment information is partitioned into sub-blocks thatrepresent a configuration of the design that is to be represented. Eachconfiguration of the design is a CTL block of statements.

The configurations describe information about:

(a) the internals of the design (in the Internal, ScanInternal, CoreInternaland Relation block of statements).

19

(b) the external environment of the to be embedded design (in the Externalblock of statements).

Signals {c In;

}Environment {

CTL {Internal {

c { DataType MasterClock; }}

}}

The PatternInformation block deserves special mention. It also operateslike the design entities with respect to its contents, which are patterns,sequences and waveforms. All pattern-like information is defined outside theEnvironment and referenced in the Environment to give information aboutthe pattern construct. Figure 11 shows the location of definitions of patterninformation (Waveforms, Macros and Patterns) which are referenced in theEnvironments PatternInformation block of statements.

Figure 10 shows how the Environment is structured relative to the designentities that are defined in the CTL. The following is an example of adefinition of a clock signal of the design and a reference made to the signal inthe Environment to describe that it is a clock.

Most of the information is described on design entities such as signals, scancells or signals on internal cores of the design. To describe information onthese design entities the associated design construct should be first defined ina block of statements outside the Environment and then referred to in theEnvironment block of statements.

(c) pattern information (in the PatternInformation block of statements) ofthe design that is being described.

20

The structure of the CTL language can be best seen with an expansion of theexample in Chapter 1.

4.2 EXAMPLE: ENHANCED ATPG-FS INFORMATION

STIL 1.0 {CTL ThisBook;

}Header {

Title CTL for enhanced ATPG-FS Info;Date 2002;

}

Signals {a In;b In;c In;s In;

Some ATPG-FS tools allow the user to constrain the type of sequences thatcan be used by the test generation algorithms. The sequences to be used bythe test patterns would have to be supplied to the ATPG-FS tool in additionto the information provided in the example shown in Chapter 1. Thus theexample of Chapter 1 can be enhanced to be as follows.

32.33.34.35.36.37.38.39.40.41.42.43.44.

21

e In;o Out;

}Variables {

SignalVariable func_out;SignalVariable scan_val;

}Timing {WaveformTable time {Period 100ns;Waveforms {

a+b+c+s+e {01PX {

0ns D/U/D/N;60ns D/U/U/N;70ns D/U/D/N;

}}o{01X{0ns X;40ns 1/h/X;55ns X;}}

}}

}MacroDefs {

test_sequence {W time;C { e=l; o=X;}Shift { V { s=#; c=P;}}V { c=0; e=0; a=#; b=#; o=func_out; }V { c=P; o=X;}C { e=1;}Shift { V { o=scan_val; c=P;}}C { c=0; e=0; o=X; }

}}Environment inputToAtpg {CTL {

Internal {c { DataType TestClock ScanMasterClock

MasterClock {AssumedInitialState ForceDown;}}

s { DataType TestData ScanDataIn; }

45.46.47.48.49.50.51.52.53.54.55.56.57.58.59.60.61.62.63.64.65.66.67.68.69.70.71.72.73.74.75.76.77.78.79.80.81.82.83.84.85.

e { DataType TestControl ScanEnable{ ActiveState ForceUp;AssumedInitialState ForceDown;}}

o { DataType TestData ScanDataOut; }}PatternInformation{

Macro test_sequence {Purpose DoTest;

}}

}}

22

Most of the CTL code is repeated from the previous example to give thereader an idea of how the example would look with the augmentedinformation. First let us focus in on the pieces of the example and relate it tothe discussion of the previous section. The primary block of information thatis being written is the Environment block of statements (79 to 97). Todescribe information about the signals of the design the Environment needsa support block of statements called Signals. The signals of the design aredefined in statements 40 to 47. They are referenced in the Environment andinformation is provided about each signal. In this example, the primaryinformation being provided is the data type of the signal and someinformation about its state. In this example some sequence information isalso provided to the ATPG-FS tool. The sequence is a Macro. As explainedearlier, the sequence is defined outside the Environment (67 to 78) andreferenced in the Environments PatternInformation block of statements(91 to 95).

This is nearly all the information that was relevant to the discussion in thischapter. For completeness the new syntax constructs added to the exampleare described below.

The sequence information is described in four new blocks of information,namely PatternInformation (91 to 95) MacroDefs (67 to 78), Timing (52to 66) and SignalGroups (48 to 51). These blocks of information have beenadded to the example in a particular order. The order in which theinformation is to occur in CTL is determined by looking for which blockreferences information in which other blocks. A block is only allowed toreference information that has been defined earlier. In this example,

86.87.88.89.90.91.92.93.94.95.96.97.

PatternInformation references MacroDefs and MacroDefs referencesTiming.

At the highest level the sequence that ATPG-FS is being constrained to isidentified in the PatternInformation block of statements (91 to 95). In ourexample a single sequence (Macro) is identified (92). This sequence is givenan arbitrary name called the test_sequence (92) and identified to be asequence that is to be used to apply the test patterns (DoTest) using thePurpose statement (93). The actual Macro test_sequence is definedseparately.

The Macro is defined in a MacroDefs block of statements that represents acollection of sequences (67 to 78). However, only one sequence(test_sequence) is defined in this example, test_sequence (68 to 77) is madeup of vector statements (V) and scan operations (Shift) which define howvalues are applied to Signals. The values are characters defined in theTiming block that represent data associated with time that is relative to aclock period. The Macro references the WaveformTable in the Timingblock (69) and uses the characters defined in it. In our example, W stands forWaveformTable. The name of the waveform table that is relevant totest_sequence is time. The test sequence requires three different characters(0, 1 P and X) to apply stimulus to the inputs and measure values at outputs.0 is used to represent a logic-0, 1 is used to represent a logic-1, P is used torepresent a pulse and X is used to represent a dont-care. test_sequenceperforms the following steps.

In the Macro, C represents a Condition statement, which defines stimulus orresponses to be set up, but deferred from being performed until a Vectorstatement is defined. The # symbol assigned to signals represents data that ispassed to the test_sequence by the patterns that the ATPG-FS would create.The Shift block of statements represents a looping construct of Vectors that

test_sequence {Setup for the scan operation (70)Scan In Stimulus for the FFs (71)Get out of Scan Mode (72, e=0)Apply Stimulus to Inputs, Measure Outputs (72)Pulse the Capture Clock (73)Setup for scan operation (74)Scan Out Responses in the FFs (75)

}

23

24

shift one value into or out of the scan chain. The number of shifts isdetermined by the data provided by the invocation of the Macrotest_sequence, which in our example is a one-bit data, as the chain length isone.

The Macro test_sequence is designed to have two parameters passed to it forthe output o. To avoid any aliasing problems of which parameter getsassigned which value that is passed in for signal o, a # was not used. Insteadsignal variables (func_val and scan_out) were used to define the parameters.In this example the signal variables are defined in the Variables block ofstatements (48 to 51).

The waveform characters that are used in the Macro are defined in aWaveformTable (53 to 65). The waveform characters are associated withsignals and defined using a syntax that describes formal events that occur atcertain times. In this example D represents drive low event, U representsdrive high event, N represents drive unknown event, I represents thebeginning of a compare low window event, h represents the beginning of acompare high window event and X represents a do not compare event. Shorthand notations allow for a one-to-one correspondence between the series ofwaveform characters and the events associated with them. Consider thewaveform characters for signals a, b, c, s, e represented as a groupa+b+c+s+e (56). Four waveform characters (0,1, P and X) are defined forthese signals (57). 0 is defined to drive a logic-0 across the complete periodstarting at 0ns (Ons D; 60ns D; 70ns D;) (58, 59, 60). 1 is defined todrive a logic-1 across the period starting at 0ns (0ns U; 60ns U; 70nsU;) (58, 59, 60). P is defined to be a pulse signal that begins low, goes highat 60ns for 10ns and then goes low at 70ns to remain low for the rest of theperiod (0ns D; 60ns U; 70ns D;) (58, 59, 60). X is defined to be a dont-care value starting at 0ns (0ns N; 60ns N; 70ns N;). Similarly threewaveform characters are defined for signal o (63) to compare values since itis an output signal.

Chapter 5CTL Syntax and Semantics: Design EntitiesCTL syntax and semantics is spread across multiple documents of the IEEE1450 dot series of standards. The purpose of this book is to give the reader afair idea of the constructs in the language. The syntax is described at a higherlevel of abstraction where the exact use and meaning of individual keywordsis not covered. For fine details and completeness of the syntax and semanticsthe reader should refer to the standard documents.

5.1 READING CTL SYNTAXCTL syntax is defined in a variant of BNF to describe how the statements areto be used while writing CTL. Let us take an example of the syntax anddescribe aspects of it that will help readers understand the language.

Environment { CTL (CTL_NAME) {Internal {

(sigref_expr {(DataType ( data_type_enum ) + ;)(DataType ( data_type_enum ) + {

(ActiveState (Weak);)

(DataRateForProtocol INTEGER ;)

(AssumedInitialState (Weak);)

(ScanDataType ()+; )

(ValueRange INTEGER INTEGER; ) *})*

})+

100.101.102.103.104.105.106.107.108.109.110.111.112.113.114.115.116.117.118.119.120.121.

98.99.

26

}}}data_type_enum =

27

occur zero or more times. < > is used to indicate a multiple choice amongstthe information between the angular brackets. Default values are underlined.

Thus if we were to now read the example syntax and use it to write aDataType statement, it can be seen that it is necessary for the statement to beembedded in the Environment and CTL block of statements as there are no( ) around the syntax (98, 122). Similarly, the Internal block of statements isnecessary as there does not exist any ( ) around it (99, 122). Data types aredefined on signals (sigref_expr) of the associated design being representedwhich are defined in the Signals block of statements in CTL (not shownhere). The signal is cross-referenced to define its DataType (100). While thiscross-reference is shown as optional, since we are focused in on DataTypethere has to be a signal whose data type needs to be described if one has towrite a DataType statement (101, 102). There are two ways of specifying aDataType of a signal. In the first way, the statement allows for thespecification of one or more data types (101) from a list provided in anenumeration (123 to 148). In the second format (102 to 120), the statementallows the specification of one or more data types of a signal as selected fromthe enumerated types specified by data_type_enum and some morestatements (103, 107, 109, 113, 119) associated with the DataType.

The active values (ActiveState) of the input/output signal when used asthe data type corresponding to it.

The values assumed by the test data on signals at the start of every testprotocol (AssumedInitialState).

The scan chain type (ScanDataType) if the signal is a scan input/output.

The rate at which data is changing at the signals on a per protocol basis(DataRateForProtocol) outside of values that are targeted for internalscan elements.

The range of values allowed on a group of signals (ValueRange).

In either format of expressing the DataType information there is never thesituation that the DataType statement is allowed with no enumerated typesselected from the set specified in the data_type_enum. This should be notedfrom (data_type_enum)+.

Statements 21 to 28 on page 4 is an example usage of the syntax (re-iteratedbelow with minor changes).

28

Environment inputToAtpg {CTL {

Internal {c { DataType TestClock ScanMasterClock

MasterClock{AssumedInitialState U;}}

s { DataType TestData ScanDataIn; }e { DataType TestControl ScanEnable

{ ActiveState U;AssumedInitialState D;}}

o { DataType TestData ScanDataOut; }}

}}

It should be noted that the drive-values and expect-values specified in thesyntax have short hand descriptors. ForceUp can be replaced by U,ForceDown can be replaced by D, ForceOff can be replaced by Z,ExpectLow can be replaced by R, ExpectHigh can be replaced by G andExpectOff can be replaced by Q, without any violation of the syntax definedin CTL.

There is no particular ordering between statements within a block ofstatements in CTL syntax. However, there is a single global rule thatminimizes the forward references in the syntax of a valid CTL file. Withsome exceptions (around pattern data), all entities that are used should bedefined prior to its use. By this rule the typical CTL Environment blockwould appear close to the end of a file containing all the CTL information,though it is the top level block in the syntax. Forward references are onlyallowed to Patterns.

5.2 USER DEFINED NAMES IN CTL

5.2.1 Construction of NamesBefore going into the details of the syntax and semantics of CTL statementsone must understand the basics behind names and their scope. CTL hasplaceholders for names in numerous locations in the syntax. These names areexpected to follow certain rules.

Ignoring the flexibility available in the construction of names in CTL, allnames are a concatenation of case-sensitive alphanumeric characters orunderscores with the first character being an alphabet or an underscore and amaximum string length of 1024. If a name exceeds 1024 characters aconcatenation operator . is used to create larger names. Quotes aroundnames are used to encapsulate most of the complexities in names. For detailsthe reader should refer to the standard documents.

5.2.2 Scope of NamesNames are defined for different entities in their associated blocks ofstatements. For example, signal names are defined in the Signals block ofstatements or Macros and their associated names are defined in theMacroDefs block of statements in CTL. Most of the blocks where entitiesare defined could be named or unnamed blocks. The names of blocks arecommonly referred to as domain names in CTL.

Consider the following example of one unnamed block and two namedblocks of information using a generic name for the block (BlockType).

BlockType {Entity_global;

}BlockType domain_name_1 {

Entity_1;}BlockType domain_name_2 {

Entity_2;}

The first block is an unnamed block of information of type BlockType. Theother two blocks of statements are named blocks of BlockType. The namesdomain_name_1 and domain_name_2 are domain names. Entities are definedwithin these blocks. Entities defined in unnamed blocks are considered to beglobally accessible across CTL. Thus Entity_global can be referencedanywhere else in the CTL syntax. While entities in named blocks areaccessible only when the named block is brought into the scope (SeeDomainReferences for more information in section 7.1 on page 56). Nameclashes are allowed between entities of the same type in different namedblocks. In the above example unique entity names Entity_1 and Entity_2were used.

29

30

Examples of blocks that have domain names in CTL are, Environment {},CTL {}, SignalGroups {}, Variables {}, MacroDefs {}, Procedures {},ScanStructures {}.

5.2.3 Entity Names in Domains and CorelnstancesWhile it may be too premature to go into the details of individual types ofentity names or aspects about Core-Instances, all names in CTL areconstructed with a simple rule.

The true name (unique name or canonical name) of a CTL entity is ahierarchical concatenation of names of the core-instance, domain and theentity, separated by : or ::. When appropriate the core instance name isused and it is ended with a :. Domain names when used are terminated witha ::. Thus the unique name for CTL entities would be

CORE_INSTANCE_NAME:DOMAIN_NAME::ENTITY_NAME

All names need not be associated with a core-instance or domain in whichcase the true name does not include it. Thus the true name of a signal groupeg_signals, defined in a signal group eg_group, would beeg_group::eg_signals. If the signal group were defined as part of thedefinition of a core instance say eg_core, then the true unique name of thesignal group would be eg_core:eg_group::eg_signals.

The true name of an entity provides a unique signature for the name.Depending upon the type of CTL being written the entity or core-instance-entity name may itself be unique across CTL. In such cases CTL allows foromitting the domain name in which the entity is defined. By default it isassumed that all entity or core-instance-entity names are unique and somedeclarative statements allow for the addition of the domain name. Theoptional domain name concept will be addressed in the description of theDomainReferences block of statements (7.1 on page 56).

Names in non-pattern related constructs of CTL are true to the abovedescription. Since pattern data is sequential in nature another mechanismallows for use of short cuts in the names as they relate to the domain name.Some pattern constructs define a domain name prior to the use of entities inthe domain. Thus there is no ambiguity in the entity name within the scope ofthe pattern construct. Regardless of this use of the entity name, it should bebrought into the scope of the test mode through the DomainReferencesblock of statements. The name would follow the rules of the names as the

31

DomainReferences statement defines it to be (with or without the domainname) for use in parts of CTL that are not sequential in nature. While it is tooearly to give examples of this concept here, the adventurous reader can seean example of this concept in section 9.4 on page 161.

5.3 DESIGN ENTITIES RECOGNIZED IN CTLCTL information is divided into blocks of statements based upon someaffinity of the information being described. At the top level of CTL theEnvironment block of statements describes test information about thedesign. This is the most important block of statements in CTL and is theprimary block that is written. A number of support blocks are defined outsidethe Environment, which are linked in to the Environment block ofstatements through the DomainReferences block and follow the scopingrules of section 5.2.2 on page 29. In this section the support block thatrepresent design entities are introduced.

Before addressing the design entities recognized in CTL one would first wantto know which designs entities are being represented in CTL. This isaccomplished through the FileReference statement in the Environment.

Environment (ENV_NAME) {(FileReference FILE_PATH_NAME {

Type ;Format ;Version VERSION_NUMBER ;

})* // incomplete keywords shown.}

The FileReference statement allows for a pointer to the file which includesthe path name (150). One of the file types allowed in CTL is the Design file(151) which the reader would typically find in a VHDL or Verilog format(152). The version of the design-file for which CTL is created is identified bythe Version statement (153). While to this level of discussion these may bethe only relevant keywords of the syntax, one should be made aware of thepossibility of referencing Design files in which the design information isprovided in CTL. That is the design being referenced is another core.

Figure 12 shows the design entities recognized in CTL. They include signalsof the design, scan cells within the design and hierarchical cores that are

149.150.151.152.153.154.155.

Signals and Signal Groups

Signals {(SIGNALNAME ;)*(SIGNALNAME {

(DefaultState ;)(ScanIn (integer_expr);)(ScanOut (integer_expr);)(WFCMap {

(FROM_WFC - > TO_WFC (TO_WFC)+;)*})

})* // incomplete syntax shown}

5.3.1CTL is written to correspond on a boundary of the design. This boundary isdescribed as Signals in the language. Only one signals block is allowed in aCTL file, which limits the way CTL files can be packaged together fordifferent design descriptions.

32

reused in the design. All these entities are required to have unique (whereappropriate hierarchical) names.

156.157.158.159.160.161.162.163.164.165.166.

33

The Signals block (156 to 165) is needed to describe information in theEnvironment. Signals of the design are defined in the Signals block ofstatements and referenced in other blocks in locations of the syntax thatallow for a SIGNALNAME or sigref_expr. Signals can be grouped together insigref_expr (signal expressions) using a syntax that adds or subtracts namesfrom a sequential list. For example a sigref_expr of signals could bea+b+c+d. The signals a, b, c and d are grouped together. Furthermorea+b+c+d-a represents a grouping of signals b, c and d.

Signal names (SIGNALNAME) in the Signals block are user-defined nameswith the ability to define indexes in square brackets (157, 158). Thusmy_signal_name, mySignal are valid names for single signals andaddress_bus[0.. 7], address_bus[7..0] are valid signal names for the signalsaddress_bus[0], address_bus[1], ..., address_bus [7] with the difference thatthe Most Significant Bit (MSB) is the leftmost signal in the group. If aconstant integer is defined using the IntegerConstant statement (179 onpage 35), the signal definition is definable using the named constant(CONST_NAME). Thus if n is defined as a constant of value 7, theaddress_bus[0..7] could be defined as address_bus[0..n]. This concept hasvalue when CTL is being written to a generic parameterizable design whoseparameters are to be determined later in the flow.

Signals are definable as inputs (In), outputs (Out), bi-directional (InOut),supply (Supply) or as internal signals of the design (Pseudo) (157, 158).There are two ways to define signals. In one method some more informationis defined on the signal. Default states (DefaultState) of the signals arespecifiable for use when no value is provided in the sequence or patterninformation in CTL (159). Through the statement on ScanIn (160) andScanOut (161), the scan data associated with the scan inputs and outputs ofthe design can be assigned default lengths. Signals are typically assignedwaveform characters that represent logic states with timing information.While most of this information is defined in WaveformTables (to bedescribed later in section 7.7.1 on page 101), a WFCMap statement (162,163, 164) allows for specification of an alternate mapping of waveformcharacters (from_wfc to to_wfc) defined for the signal. This statement couldbe used to reflect inversions in values (see section 7.7.2 on page 106).Statements 9 to 16 in Chapter 1 on page 4 (reiterated below) providesexample syntax for the signals defined for the associated design netlist.

Signals {a In; b In; c In; s In; e In; o Out ; }

34

The above definition of signals could be augmented for default states andpadding definitions for the scan data.

Signals {a In {DefaultState Z;}b In {DefaultState Z;}c In {DefaultState Z;}e In {DefaultState Z;}s In {DefaultState Z; ScanIn 1;}o Out {ScanOut 1;}

}

Signals can be grouped together and the group can be named in aSignalGroups block using the following syntax.

SignalGroups (DOMAIN_NAME) {(GROUPNAME = sigref_expr;)*(GROUPNAME = sigref_expr {

(ScanIn (integer_expr);)(ScanOut (integer_expr);)(WFCMap {

(FROM_WFC - > TO_WFC (TO_WFC)+;)*})

})* // incomplete syntax shown} // incomplete syntax shown

The GROUPNAME has similar flexibilities in the naming conventions ofsignals. Signal group names do not directly represent design entities. Thesenames are referred to in the syntax as GROUPNAME that can be used in asigref_expr. The true name (unique name) of a signal group is a hierarchicalconcatenation of the DOMAIN_NAME and the GROUPNAME defined inside thenamed SignalGroups block and would be referred to asDOMAIN_NAME::GROUPNAME. This name is used in the Environment blockof statements in CTL. For the unnamed SignalGroups block theGROUPNAME is the complete name of the group. However, if the groupnames are unique across the CTL block where it is used the group name canbe used without the concatenation of the domain name to the group name.The use of the domain-name is determined by UsePrefix-DomainNamestatement, of the DomainReferences block of statements, in theEnvironment (297 on page 57).

167.168.169.170.171.172.173.174.175.176.

35

Through SignalGroups-GROUPNAME all the signals of the netlist can begrouped into a bused entity called grpAll[0..n], or inputs can be groupedtogether to be called grpIns[0..n], and outputs can be grouped asgrpOuts[0..n]. The signal assignments are made using a signal expression(sigref_expr). There should be a one-to-one mapping between the groupedsignal names and the signals that are assigned to the group through thesigref_expr. This means that one cannot assign multiple signals to a groupname without any [ ]. The following example syntax shows the definition ofsome groups for the example signals defined earlier.

SignalGroups {grpAll[0..5] = a+b+c+s+e+o;grpAll = a+b+c+s+e+o; // Not allowed.grpOuts = o;grpIns[0..4]=grpAll[0..5]-grpOuts;

// a+b+c+s+e}

SignalGroups can be assigned ScanIn (170) and ScanOut (171) statementssimilar to the capability allowed for signals. Alternate waveforms can bedefined for individual groups similar to the capabilities on Signals.

Coupled to signals are SignalVariables. These are carriers of informationthat would reside on signals. The following syntax shows the definition ofSignalVariables.

Variables (DOMAIN_NAME) {(SignalVariable VARIABLENAME;)*(IntegerConstant CONST_NAME=DECIMAL_INTEGER;)*

} // incomplete syntax shown

Signal variables are assigned waveform characters that are to be interpretedby the waveform table of the recipient signal. An example usage ofSignalVariables is provided in section 4.2 on page 21. This capabilitybecomes useful for translating test data from the boundary of a core to theboundary of a SoC. The above syntax also allows for the definition ofconstants (179) to be used in other parts of CTL.

177.178.179.180.

36

5.3.2 ScanStructures and ScanCellGroupsThough scan structures scan-signal-names can be defined as scan cells. Thesescan cells should correspond to design entities and CTL information isprovided for the same. The following syntax defines the named(domain_name) scan structures block of statements.

ScanStructures (DOMAIN_NAME) {(ScanChain CHAINNAME {

ScanLength integer_expr;(ScanCells CELLNAME-LIST;)(ScanEnable logical_expr;)(ScanIn SIGNALNAME;)(ScanOut SIGNALNAME;)(ScanMasterClock SIGNALNAME-LIST;)(ScanSlaveClock SIGNALNAME-LIST;)(ScanInversion ;)

})+} // incomplete syntax shown

The ScanStructures block (181 to 192) represents a complete/contiguous-segment of a scan chain using the ScanChain block of statements (182 to191). The cells in the scan chain are represented as a list of scan-cells(CELLNAME-LIST, 184) that have ah implied order where the leftmost scancell is closest to the scan in and the rightmost cell is the closest to the scanout. The cell names can be used in the syntax wherever CELLNAME andcellref_expr are allowed. Just like sigref_expr, cellref_expr can containmultiple scan cells combined with the + and - operator. Inversions aredescribed between cells using a ! in the list of scan cells (184). The scancells are expected to have a one-to-one correspondence with the scan flip-flops of the design being represented and are unique across the name space ofCTL. That is, if the same cell name appears in two scan chains, it is the samecell. The names of scan-cells are also unique with the chain_names. Thisallows for chain names to be used to embed a segment of a scan chain withina larger chain without listing out all the cells individually.

Shorter names for scan cells (such as c[0..99]) can be used in the scanstructures if the names of the scan cells in the design are very long. To usethis feature, a mapping of the names could be provided to the real names ofthe cells in the design using the NameMaps construct in the Environmentblock (section 8.2 on page 128).

181.182.183.184.185.186.187.188.189.190.191.192.

37

The information about the scan chain, is completed with the definition of thescan-in (ScanIn, 186) and scan-out (ScanOut, 187). The syntax for scandefinitions allows for complex scan-enables where the enabling condition isa logic expression of signals (ScanEnable, 185). Clocks that effect the scanchain are specified by the ScanMasterClock and ScanSlaveClockstatements (188, 189). Inversion parity in the scan chain between the scan-inand scan-out is specified through the Inversion statement (190). While thescan chain links together the different elements of the design that are relatedto the scan chain the user should not rely on this construct for theidentification of the associated functions of the signals. That is, the fact that asignal is a scan-in or a scan-clock should be obtained from the DataTypestatement of the Environment.

Figure 13 shows an example scan chain that is to be described in CTL. Thescan chain definition for this design would look as follows.

ScanStructures {ScanChain design_chain {

ScanCells d[0..2] c[0..l];ScanLength 5;ScanIn di;ScanOut do;

}}// ORScanStructures {

ScanChain small_chain {ScanLength 2;ScanCells c[0..1];

38

}ScanChain design_chain {

ScanCells d[0..2] small_chain;ScanLength 5;ScanIn di;ScanOut do;

}}

Cells of the scan chain are referred to in the Environment block ofstatements and can carry information that can be grouped together basedupon some inherent properties. Similar to Signals and SignalGroups,ScanCells has its equivalent construct called ScanCellGroups.

ScanCellGroups (DOMAIN_NAME) {(CELLGROUPNAME = cellref_expr;)+

} // incomplete syntax shown

The one-to-one entity map between the GROUPNAME and the signals assignedto the group is not put on CELLGROUPNAME. As a result any grouping of cellscan be created and named without forcing [ ] in the name. For example,consider a the situation where a design implemented hierarchically hasc[0..1] part of a sub-design. These cells can be grouped together as thesub_designs_vals using ScanCellGroups { sub_designs_vals = c[0..1];}.While this may look similar to the creation of a chain segment, grouping ofscan cells does not require that the scan-cells be part of the same segment.

5.3.3 Core InstancesThis block of information provides the ability to identify an entity internal tothe design as a core. The core typically would have some inputs and outputsand scan chains.

{CoreType CORE_TYPE_NAME {(CoreEnvironment CORE_ENV_NAME;)(InheritCoreType CORE_TYPE_NAME {

(Instance (CORE_INST_NAME)+;)+})*

196.197.198.199.200.

193.194.195.

39

(Signals {core_signals_definitions

})(SignalGroups (DOMAIN_NAME) {

core_signal_group_definitions})*(ScanStruetures (DOMAIN_NAME) {

scan_chain_definitions})*

})*(Corelnstance CORE_TYPE_NAME {

((CORE_INST_NAME)+;)( CORE_INST_NAME

{ PatternBurst (BURST_NAME)+;})*})*

There could be numerous cores reused in the design for which CTL is beingwritten. Furthermore, there could be multiple instances of the same core.Each of these cores of type CORE_TYPE_NAME is identified with a name(CORE_INST_NAME) in the CoreInstance (211 to 215) statement. Details ofthese cores are defined in the CoreType statement (196 to 210).

The cores instantiated in the design have certain constructs that are visible tothe CTL Environment being written. These constructs (Signals,SignalGroups and ScanStructures) are defined in the core type definition.These entities of the cores are similar in syntax and function to theircounterparts in the top-level designs CTL. The signals define the boundary ofthe core, the signal groups perform logical groupings of the signals of thecore and scan structures define the scan chains in the core. Once defined allthese entities are available for the informational needs of the top-leveldesigns CTL. The respective entities are identifiable with a unique namethat is created with a concatenation of the CORE_INST_NAME to the entityname with a : separator. The signals of the core-instances are identifiablein the remainder of CTL by the concatenation of theCORE_INST_NAME:SIGNALNAME or CORE_INST_NAME:GROUPNAME. Thedomain name can be optionally added to the name to resolve name conflictssuch as those between group names of different groups defined in the coreinstances. Thus the true (unique) name would beCORE_INST_NAME:DOMAIN_NAME::ENTITY_NAME.

201.202.203.204.205.206.207.208.209.210.211.212.213.214.215.

40

Cores that are described as core-instances would have come with CTL. TheCTL could have multiple environments of which one is selected for theinstance being referred to in CoreInstance. This Environment isidentifiable through the CoreEnvironment statement (197).It is also recognized that cores are hierarchical entities and a core of thecurrent design could have also instantiated other cores. The hierarchy of thecores is available through the inheritance of cores types (InheritCoreType)(198, 199, 200) within the CoreType block of statements. The sub-cores thatbecome available through this statement are given instance names in theinheritance construct (199) and are referred to by the hierarchical nameachieved by the concatenation delimited with : of the names of the core-instances in the hierarchy.

Consider a conceptual hierarchical design, which reuses multiple cores asshown in Figure 14. There are two cores of type A namely InstAl and InstA2and one hierarchical core of type B that is instantiated as InstBl. InstBl has asub-core of type A named InstA3 that would have a name InstBl:InstA3when referred to in CTL. The above would be described in CTL syntax asfollows.

CoreType A {Signals {

41

i [0. .1] In; o[0. .3] Out;}

}CoreType B {

InheritCoreType A { Instance InstA3;}Signals {

i [0..1] In; o[0..3] Out;}

}CoreInstance A { InstAl InstA2;}CoreInstance B { InstBl;}

The signal names of the instances of the core InstA1 are referred to asInstA1:i[0..1] and InstA1:o[0..3] and the signal names of the sub-core ofInstB1 called InstA3 are referred to as InstB1:InstA3:i[0..1] andInstB1: InstA3 :o[0..3].

Core instances in the design may have scan structures within them. They aredefinable in the CoreType block with the same mechanisms for the names asdefined for Signals and SignalGroups of the inherited cores. The scan celllist can be included as segments of scan chains defined in theScanStructures of the top level CTL to construct larger scan-chains.

42

Figure 15 shows a scan chain of the design that includes a segment of thescan chain of the core InstC1. The scan chain of the core is defined in thescan structures shown in the figure. The following code is the example ofhow the scan chain of the design is defined using the definition of the scan-chain of core.

ScanStructures Design {ScanChain design_chain {

ScanLength 5;ScanCells d[0..2] InstC1:core_chain;ScanIn di;ScanOut do;

}

43

}

While this section is only focussed on design constructs core instances inthis case, it is also recognized that cores could come with test patterns. Thetest patterns that come with cores are included by reference in the coreinstance statement (213, 214). Since they are not defined here they do notfollow the naming conventions for names of entities within cores that wasdiscussed in this section.

Chapter 6CTL Syntax and Semantics: Top Level ViewThe Environment block of CTL provides the bulk of the CTL information.This named block of statements is the one being written to describe all thetest information and hence is not optional for CTL. Though multipleEnvironment blocks are allowed with CTL information in it, each namedenvironment is to be considered a complete description of the testinformation of the design. The skeleton syntax of the Environment block isshown below.

(Environment ( DOMAIN_NAME ) {(NameMaps (MAP_NAME) { })*(InheritEnvironment DOMAIN_NAME;)(FileReference FILE_PATH_NAME {

Type ;Format ;Version VERSION_NUMBER;

})* // incomplete keywords shown.(CTL (CTL_NAME) {

(CoreInternal { })(DomainReferences (CORE_INST_NAME) { })*(External { })(Family (NAME)+;)(Focus () { })*(InheritCTL CTL_NAME;)(Internal { })(PatternInformation { })(Relation { })(ScanInternal { })(< TestMode (test_mode_enum)+;| TestMode (test_mode_enum)+ {

AlternateMode (CTL_NAME)+;}>)(TestModeForWrapper TEST_MODE MODE_CODE;)(Vendor (NAME)+;)

216.217.218.219.220.221.222.223.224.225.226.227.228.229.230.231.232.233.234.235.236.237.238.239.240.241.

// Top level CTL block of statements.

242.243.244.245.246.247.248.249.250.251.252.253.

45

(Wrapper ;)

})*})*test_mode_enum = // incomplete enumerated type

//Following statements are some other blocks in CTL// that physically reside outside the environment// block of statements.

// Statements to support ENV attributes attached to// design objects and pattern data.254.255.256.257.258.259.260.

(Signals { })(SignalGroups (DOMAIN_NAME) { })*(ScanStructures (DOMAIN_NAME) { })*(ScanCellGroups (DOMAIN_NAME) { })*(CoreType CORE_TYPE_NAME { })*(CoreInstance CORE_TYPE_NAME { })*(Variables (DOMAIN_NAME) { })*

// Information about CTL file content.261.262.263.264.265.266.

(Header {(Title TITLE_STRING ;)(Date DATE_STRING ;)(Source SOURCE_STRING ;)

})STIL IEEE_1450_0_IDENTIFIER { CTL EXT_VERSION; }

// Information related to information for the// PatternInformation block of statements.267.268.269.270.

(PatternExec (EXEC_NAME) { })*(PatternBurst PAT__BURST_NAME { }) *(Pattern PATTERN_NAME { })*(Timing (DOMAIN_NAME) { })*

46

The information in the Environment is partitioned into multiple blocks ofstatements (216 to 245). These statements are the sentences of the test-storythat is to be described in CTL about the design. In the chapters describing thesyntax, the words that form the sentences and the sentences themselves willbe described. The test-stories will be covered in examples in the followingchapter.

Some of information in the Environment is physically written in blocks ofstatements outside the Environment and linked to the Environment withstatements within it.

The statements that exist outside the Environment block are also shown instatements 254 to 272. Of these external statements the design entities (254to 259) defined in CTL have already been introduced in Chapter 5. Theseentities are linked to the Environment through the DomainReferencesstatement (226) as shown in Figure 16. The details of the link itself will bedescribed in section 7.1 on page 56.

271. (MacroDefs (DOMAIN_NAME) { })*272. (Procedures (DOMAIN_NAME) { })*

47

CTL-test information about the design is descriptive in nature as opposed toprescriptive. Most of the information (outside of the information in theExternal block (227) of statements) in the design is describing existing test-related features of the design. The CTL information is linked to the designthrough the FileReference mechanism where a file of Type Design isreferenced in the Environment (219 to 223, also shown in Figure 17 on page48). FileReference is also described in section 5.3 on page 31. The CTL forthis design may be associated with a Family of designs or a particularVendor, which can be identified in the syntax (228, 241). The family nameor vendor name is a user-defined entity in the CTL syntax.

The remainder of this chapter describes at a high level the various blocks ofstatements allowed in the Environment in the CTL block of statements.Details will be presented in the following chapter on the syntax.

6.1 TEST MODES OF DESIGNSThe design typically operates in multiple configurations. Each configurationcalled a test-mode has its own test-information. Thus CTL in theEnvironment (216 to 245) is structured along the concept of CTL blocks fortest-modes (224 to 244). Figure 17 is a pictorial representation of the modespecific structure in CTL.

48

Multiple CTL blocks of statements (224 to 244) can be defined in theEnvironment each reflecting a test-mode of the design as identified by theTestMode statement (236). These CTL blocks are user-defined namedentities (CTL_NAME, 224), with the ability to have one unnamed CTL block,which acts as a block of common information for all test-modes. Thisunnamed CTL block cannot be assigned a TestMode statement within it(236).

The test-modes can contain configuration information, or pattern informationas appropriate for the applications. While most modes are created to describenew configurations, some modes define exactly the same information(alternative information) as another mode using a different configuration. Forexample there could be two different ways to test the design. In oneconfiguration the tests are applied through a serial interface and in the other

49

configuration the same tests could be applied through a parallel interface.The two modes that are defined for these configurations are alternatives ofeach other and are identifiable through the AlternalteMode statement (238).Though the example figure shows a symmetric relationship between alternatemodes the relationship need not be symmetric.

One of the basic DFT methods in SoCs use wrappers constructed forisolating the cores from the SoC logic. These wrappers have a controlregister also called an instruction register which contains a code that controlsdesign constructs to achieve different configurations. The codes in theinstruction register are called instructions and correspond to the test modes inCTL. To acknowledge this standard DFT technique two special statementsare defined in the CTL block of statements. The Wrapper statement (242,243) allows for the identification that the design being described contains awrapper. The IEEE1500 wrapper is specially identified with a keyword. Theinstructions and their codes are connected to the test mode being describedthrough the TestModeForWrapper statement (240). Through this statement,the instruction name as defined by the standard and the code as constructedout of a sequence of 1s, 0s and Xs is provided along with the CTL testmodes.

6.2 TYPES OF TESTMODESA number of different predefined types of configurations exist in designs.Some commonly know configurations of the design are identified in CTLwith keywords (246 to 252).

ByPass test mode constitutes a configuration of the design thatallows for the by-pass of certain logic in the design. While mostassociate this term to IEEE 1149.1s ByPass Instruction, thatconfiguration is just an example of the configuration identified bythis keyword.

Debug test mode constitutes a configuration of the design that ismade available for debug purposes. Different designs may providedifferent types of access available in the configuration available fordebug.

ExternalTest test mode constitutes configurations of the design thatallow for the test of the logic external to the design when the designis embedded in a SoC. For designs with scan wrappers this wouldtypically mean that the wrapper is put in a configuration that allows

50

for data at the inputs of the design to be captured and observed in thewrapper scan chain. This configuration would also allow for valuesto be provided to the logic external to the design on the output sidethrough the wrapper scan chain. The configuration does not implyhow many signals of the design have the properties to assist externaltest. That information is available in the details of the syntax in thetest mode.

ForInheritOnly test mode constitutes configuration information ofthe design that is not complete. It is to be used as part of the testmode configuration of another CTL test mode description.

InternalTest test mode constitutes configurations of the design thatallows for the internal test of the design. The configuration does notimply any type of test methodology or the amount of logic that canbe tested in the design.

Isolate test mode constitutes configurations in which the design isde-coupled from external effects on one or more of its signals. Thisconfiguration would prevent the internal logic of the design to beaffected by changes on its inputs and similarly the outputs are putinto states that would minimize any effect of the design on logicexternal to it in an embedded environment.

Normal test mode constitutes the configuration of the design thatallows for the functional operation of the design. While this is not aconfiguration for test purposes, the test tools sometimes need toknow information about the functional operation of the designs.

PowerOff test mode constitutes the configuration of the design inwhich minimum power is being consumed.

PowerOn test mode constitutes the configuration of the design thatis available when the design is powered up.

Quiet test mode constitutes the configuration of the design thatminimizes the quiescent current of the design.

Transparent test mode constitutes the configuration of the designthat lets data pass through the design between a subset of the inputsand the outputs. A typical use of this configuration is for externaltest, thus one can expect this test mode to also be classified as anexternal test mode.

51

A CTL description of a design can have many different test modes definedfor it. Some of the test modes can be of the same type and some of the testmodes can be alternatives of each other. If a test mode of a certain type is notavailable in the CTL description no configuration information of the missingtest mode type can be interpreted. It could be that the design has theconfiguration but the CTL provider intentionally did not want to provide it tothe user. It could also be that the configuration does not exist. Since amissing test mode does not convey any information, if the CTL were todescribe the non-existence of a configuration of a certain type then theEnvironment block should contain an named CTL block with the associatedTestMode statement and no other information. This CTL block is theequivalent of an empty CTL block.

It should be noted that a single configuration of the design could servemultiple purposes. That is multiple test mode types can be assigned to asingle CTL block of statements. For example, the PowerOn mode of thedesign can be the same as the ByPass mode of the design. The associatedTestMode statement of the configuration would have both keywords.

6.3 LAYOUT OF TEST MODESA number of configurations of a flat design can exist. However the designitself is a hierarchical entity composed of smaller entities such as cores. Testmodes can be constructed to separate these entities in CTL information. TheFocus statement associates the test modes of the design to the its hierarchies.

273.274.275.276.277.278.279.280.281.282.283.284.285.286.287.

Environment (DOMAIN_NAME) {CTL (CTL_NAME) {

(Focus(Top) (CoreInstance (CORE_INST_NAME)+) {

(TestMode (test_mode_enum)+;)(Usage ()+;)

(PatternTypes (

52

| User USER_DEFINED>)+;)(PatternBurst (PAT_OR_BURST_NAME)+;)(CTL CORE_INST_NAME CTL_NAME;)*

})*}

}

Consider the example design that incorporates two cores namely C1 and C2with some glue logic. The InternalTest mode of this design may bepartitioned across multiple modes according to these structural partitions.Some example partitioning can be as follows.

A single InternalTest mode is constructed with all tests for the threecomponents.

Environment {CTL c1c2top {

TestMode InternalTest;Focus Top CoreInstance C1 C2 {

TestMode InternalTest;}

}}

Two test modes are constructed. One test mode tests cores C1 and C2with top level logic acting as a conduit for the test data and another modeconfigures the cores C1 and C2 in ExternalTest and to test the top levelglue logic. The Focus statement of the two modes would look as follows.

Environment {CTL c1c2 {

TestMode InternalTest;Focus CoreInstance C1 C2 {

TestMode InternalTest;}Focus Top {

TestMode Transparent;}

}CTL top {

TestMode InternalTest;

288.289.290.291.292.293.

53

In the above examples the TestMode statement (277) within the Focusstatement is used to identify the configuration of the instances identified(276). Partitioning of the test modes need not be based upon structure. In thatcase no attribute is used with the Focus statement (Focus {}). Thepartitioning of the different modes may be based upon the types of testpatterns being run (282), or on the different usage scenarios (278).

Cores come with patterns that are reused in CTL. The CoreInstancestatement allows for the identification of all the patterns that come with acore (214 on page 39). However, all patterns may not be used in the currenttest mode. Through the Focus block, the patterns of the core that are used areidentifiable (289). Other portions of the CTL syntax yet to be introduced(namely the schedule portion of the PatternInformation, section 7.7.4 onpage 122) actually bring the pattern into the set of tests that are executed inthe test mode.

The Focus block also allows for the identification of the original test modesin the CTL of the cores that are incorporated (290). While this information isnot useful to the current CTL it provides a trace back to the originalinformation that led to the creation of the current information.

6.4 CATEGORIES OF INFORMATION IN EVERYTEST-MODE:

Consider the generic design of Figure 18 that is to be represented in CTL,The configurations of this design are represented in the test mode blocks ofCTL. In this sub-section the categorization of information within a test modeis described.

Focus Top {TestMode InternalTest;

}Focus CoreInstance C1 C2 {

TestMode ExternalTest;}

}

54

Information in CTL is written with reference to design entities such asSignals, ScanCells and CoreInstance-Signals of the design (see section 5.3on page 31). Information about this design from the signals inwards is put inthe Internal block of statements (232 on page 44). If one were to traverse thedesign inwards from the signals one would encounter scan chains and coresthat act as informational black boxes for the Internal block of statements andthe shadow of these black boxes cannot be represented. Thus CTL has twoother blocks of statements to represent the information that cannot berepresented in the Internal block.

1.

2.

The ScanInternal block of statements (235 on page 44) represents thedesign's test-information as it relates to the scan cells in the directionaway from the inputs and outputs of the design.

The CoreInternal block of statements (225 on page 44) represents thedesign information in the shadow of the cores away from the scan chainsand top level signals.

55

In the Internal block of statements information is assigned to signals definedin the Signals block. A similar mechanism is available in the ScanInternalblock by using its equivalent to the Signals block called ScanStructures(256 on page 45) where ScanCells act as the signals. The equivalentmechanism for the core signals is CoreInternal where information is definedon the terminals of the cores.

The region outside the design is covered by the External block of statements(227 on page 44). This category of information describes aspects of theenvironment that the design would be embedded in. By definition theseconstructs do not exist and the information is to be used as guidance for thelogic that is to be created.

Signals on the design being described typically are associated in some formof relationship depending upon the internal use in the design. For example,some inputs are differential signals where they are logical opposites of eachother. Such pieces of information are categorized in the Relation block ofstatements (234 on page 44).

CTL is created to represent a vast variety of design styles. It does this byusing a flexible mechanism based upon sequences of operations typicallywritten to the signals of the design. Such sequence information for each test-mode is categorized in the PatternInformation block of statements (233 onpage 44).

Chapter 7CTL Syntax and Semantics: Test ModeConstructs in the EnvironmentInformation in CTL is partitioned in blocks that represent test modes (Figure17 on page 48). Each block contains information about the test aspects of thedesign that is categorized as shown in Figure 18 on page 54. There arenumerous statements that make up the contents of a test mode. All statementsneed not be used for every test mode.

In this chapter all the statements of the test mode are described.