CTL FOR TEST INFORMATION OF DIGITAL ICs

This page intentionally left blank

CTL FOR TEST INFORMATION OF DIGITAL ICs

by

Rohit Kapur Synopsys, Inc.

KLUWER ACADEMIC PUBLISHERS

NEW YORK, BOSTON, DORDRECHT, LONDON, MOSCOW

eBook ISBN: Print ISBN:

0-306-47826-9 1-4020-7293-7

2002 Kluwer Academic Publishers New York, Boston, Dordrecht, London, Moscow Print 2003 Kluwer Academic Publishers Dordrecht 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: and Kluwer's eBookstore at: http://kluweronline.com http://ebooks.kluweronline.com

to my family

This page intentionally left blank

TABLE OF CONTENTS
CHAPTER 1 HELLO CTL INTRODUCTION 1.1 1.2 CONVENTIONS USED IN THIS BOOK 1.3 CTL - BY EXAMPLE ATPG-FS 1.3.1 1.3.2 Basic Design Information needed by ATPG-FS
1 1 l 2 2 2 3

CHAPTER 2 USES OF CTL

2.1 2.2 2.3 2.4 2.5

7 7 7 8 9 9 10

USED AS AN INTERFACE BETWEEN THE USER/DFT AND ATPG-FS USED IN SOC METHODOLOGIES TO DESCRIBE CORES USED AS AN INTERFACE BETWEEN THE DESIGN AND THE ATE USED AS INTERFACE BETWEEN DIFFERENT TEST AUTOMATION TASKS USED AS AN HIERARCHICAL DFT LANGUAGE

CHAPTER 3 DESIGN PHILOSOPHY OF CTL

3.1 3.2 3.3 3.3.1 3.3.2 3.4 3.5 3.6

12 12

WORDS THAT MAKE-UP SENTENCES EXTENDABILITY OF THE LANGUAGE LEVERAGING EXISTING STANDARDS Design Constructs and CTL Sequence and Pattern Information in CTL HIERARCHY AND CTL PURPOSE OF CTL (IEEE 1450.6) AS DEFINED BY THE STANDARD SCOPE OF CTL (IEEE 1450.6) AS DEFINED BY THE STANDARD

12 13 14 14 15 17 17 17

CHAPTER 4 SIMPLIFIED VIEW OF CTL

4.1 4.2

18 18

THE ENVIRONMENT AND ASSOCIATED INFORMATION EXAMPLE: ENHANCED ATPG-FS INFORMATION

18 20

viii CHAPTER 5 CTL SYNTAX AND SEMANTICS: DESIGN ENTITIES

5.1 READING CTL SYNTAX 5.2 USER DEFINED NAMES IN CTL 5.2.1 Construction of Names 5.2.2 Scope of Names 5.2.3 Entity Names in Domains and CoreInstances 5.3 DESIGN ENTITIES RECOGNIZED IN CTL 5.3.1 Signals and Signal Groups 5.3.2 ScanStructures and ScanCellGroups 5.3.3 Core Instances 25 25

25 28 28 29 30 31 32 36 38

CHAPTER 6 CTL SYNTAX AND SEMANTICS: TOP LEVEL VIEW

6.1 6.2 6.3 6.4

44 44

TEST MODES OF DESIGNS TYPES OF TESTMODES LAYOUT OF TEST MODES CATEGORIES OF INFORMATION IN EVERY TEST-MODE:

47 49 51 53

CHAPTER 7

56

CTL SYNTAX AND SEMANTICS: TEST MODE CONSTRUCTS IN THE ENVIRONMENT 56

7.1 DOMAINREFERENCES 7.2 RELATION 7.3 INTERNAL 7.3.1 ElectricalProperty 7.3.2 DataType 7.3.3 InputProperty and OutputProperty 7.3.4 DriveRequirements and StrobeRequirements 7.3.5 IsConnected 7.3.6 LaunchClock and CaptureClock 7.3.7 Wrapper 7.3.8 IsDiabledBy and DisableState 7.3.9 Scan Style 7.4 SCANINTERNAL 7.5 COREINTERNAL 7.6 EXTERNAL 7.6.1 ConnectTo Statement

56 60 63 65 66 71 73 77 85 86 89 90 91 93 95 97

ix

7.6.2 AlowSharedConnection statement PATTERNINFORMATION 7.7 7.7.1 Timing : Waveforms Protocols : Macros and Procedures 7.7.2 Patterns 7.7.3 Schedule : PatternExec and PatternBursts 7.7.4

98 99 101 106 117 122

CHAPTER 8 CTL SYNTAX AND SEMANTICS: SHORTCUTS

8.1 8.2 8.3

128 128
128 128 130

INCLUDE NAMEMAPS INHERIT

CHAPTER 9 EXAMPLES DESCRIBING TEST INFORMATION IN CTL

9.1 9.2 9.3 9.4

137 137
138 143 152 161

ATPG OUTPUT IN CTL DESCRIBING CORES IN CTL INTEGRATING A CORE IN AN SOC INTEGRATING MULTIPLE CORES IN A SOC

TABLE OF FIGURES
3 Figure 1: A sample design that is to be run through an ATPG-FS tool 7 Figure 2: CTL describing design information as input to ATPG-FS Figure 3: SoC test methodology showing the use of CTL information instead of the 8 netlist of the corresponding cores Figure 4: CTL used as the mechanism to pass information between the tester and 9 design environment Figure 5: CTL used to communicate intermediate information between the analysis 10 engine and the implementation engine of the DFT tasks 11 Figure 6: A recursive design flow for test Figure 7: CTL information corresponding to the design boundary 14 15 Figure 8: CTL for a portion of the netlist that needs to be represented Figure 9: CTL syntax structure as it leverages IEEE 1450, IEEE 1450.1 standards 16 18 Figure 10: High level view of a CTL description Figure 11: Patterns and Sequences as it relates to the Environment 20 Figure 12: Design entities recognized by CTL 32 37 Figure 13: Design with a scan-chain consisting of five scan-elements Figure 14: A Design for which CTL is being written that is reusing cores 40 42 Figure 15: Design to show the construction of a hierarchical scan-chain Figure 16: Top level information of CTL in the Environment and the links to constructs external to the environment 46 48 Figure 17: Overall structure of CTL information as it relates to test modes 54 Figure 18: Categories of information in CTL as it related to the design Figure 19: DomainReferences mechanism to link the SignalGroups into a test mode 57 62 Figure 20: Design embedded in a larger netlist Figure 21: Temporal view of a TestMode showing three sections 68 Figure 22: Flip-flop examples to show clock data types 69 Figure 23: Example timing relationship between two signals waveforms 75 Figure 24: Example connection of an input and output of the design being represented in CTL to an internal scan cell of the design 82 Figure 25: Examples of two wrapper-cell implementations 88 Figure 26: Integrating the pass/fail signal of two BISTed cores that are tested in parallel 98 Figure 27: Overall pattern information structure 101 Figure 28: A possible breakup of a sequence (scan test pattern) composed of three types of phases 105 Figure 29: Schedule of patterns as they relate to the test modes 123 Figure 30: Example design repeated from Chapter 1 on page 3 137 Figure 31: Core integrated into the SoC 153 Figure 32: Two instance of the same core being integrated in a SoC. The internal scan chains of the two cores are daisy-chained 162

PREFACE
CTL (proposed standard as IEEE 1450.6, Core Test Language) is a language that has many possible applications in the area of test. The language reuses syntax defined by IEEE 1450 and IEEE 1450.1 and was created primarily for the proposed IEEE 1500 standard. As it can be seen, CTL is a language with a 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 different companies in test-technology and test-automation. They created the language over a span of about three years as a company-sponsored volunteer activity. The author would like to acknowledge the contributions these people and their associated companies have made to the language. This book should be read by anyone who is interested in testing integrated circuits. The contents of this book are especially relevant to the segment of the industry that is developing cores and/or using cores in system-on-chip methodologies. Note: The CTL introduced in this book reflects the latest syntax of the language at the time this book was published. The reader should understand that CTL has not been standardized as yet and the language could change.

This page intentionally left blank

Chapter 1

Hello CTL
1.1 INTRODUCTION

ICs have been designed, manufactured, tested and used in a larger system for many years. The technology has improved by leaps and bounds over the years to allow for putting millions of transistors on a single chip. This has allowed for the creation of large designs that can no longer be created from scratch in a limited time. IC design methodologies are changing to rely on reuse methodologies, where smaller designs (cores) are reused in a larger design called a SoC (System-on-Chip). Reuse of designs is forcing the understanding of hierarchy in design methodologies. New mechanisms are being put in place to support the communication needs of the various parties involved in the creation of the single design (now called a SoC). CTL is the outcome of the need to solve the communication between multiple parties to create a successful test set for the SoC which involves testing the reused embedded design called a core, and testing the logic of the SoC around the core in the presence of the core. CTL is a language that is used to represent test information. It is being developed as a standard within the IEEE framework. The proposed standard IEEE 1450.6 namely the Core Test Language (CTL) has its beginnings in the proposed IEEE 1500 standardization activity as the language to represent test information about a core. Hence the name Core Test Language. While the name has remained the same, the language has been designed to be generally applicable for a number of activities in digital IC testing. This book is focused on describing CTL. Though various examples different applications of CTL are described. CTL is shown as in input language to ATPG-FS tools and a language to communicate test information about a core. It is also shown 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 test community. To begin with CTL concepts are used in a simple example to introduce the language as a whole. After the introductory example the uses and design philosophy of the language is described. Once the reader has become familiar with the general way of thinking in CTL, an overview of the language structure is provided before larger examples and more refined concepts of CTL are described. This book is an example-oriented book on CTL that is written 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 the netlist (design) can be drawn out for better visualization of the concepts.

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

1.2

CONVENTIONS USED IN THIS BOOK

There are two types of example CTL syntax in this book. Examples that explain the use of CTL and examples that describe syntax and semantics of the language as it is being introduced. The examples explaining the syntax are incomplete examples of CTL with the goal of explaining the associated constructs. CTL syntax and examples are provided with line numbers for cross-reference in the text throughout this book. Bold letters in the code highlight keywords of the CTL language that have specific meaning and are defined in the standard document (IEEE 1450, 1450.1 and 1450.6). While these keywords are explained in this book, no effort is made to replicate the exact definitions of the keywords that are available in the standard. Non-bold text typically is a user-defined entity. Comments are in italics.

1.3

CTL BY EXAMPLE

CTL is a language to describe test information. Depending upon the context of the information the examples use different portions of the capabilities provided by the language. In this section it is assumed that CTL is being used as an input language to an Automatic Test Pattern Generator Fault Simulator (ATPG-FS).

1.3.1 ATPG-FS
If the IC manufacturing process were perfect every IC made would work as designed and no testing would need to be performed. However, this is not the case. Defects are introduced in the multi-step IC fabrication-process and cause ICs to operate incorrectly. IC testing is performed to remove such failing product from the manufactured lot and prevented from being used in the next level of the system integration. Testing of these ICs is performed using test equipment to apply stimulus to the ICs and observe the responses. These tests are typically determined by ATPG-FS tools (software) that run on the 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 abstract representation of the actual implementation where the defects occur. At this level of design abstraction, tests are created against an abstract representation of the defects known as faults. These faults are assumptions about possible failures in the design that help in generating and evaluating the tests.

Commonly known fault models used in the industry are the Stuck-At fault model, the Transition fault model and the Pseudo-Stuck-At fault model. All these fault models assume that a single location of the design is faulty at any given time. The search algorithm to generate a test for a fault has to explore all the possible states of the design for all possible input combinations. This could be very time consuming and some modifications are typically made to the design to facilitate the automation of the test creation process. This modification of the design is commonly known as Design-for-Test (DFT). A number of DFT methods have been explored which make ATPG-FS much more efficient. The most common DFT solution puts memory elements of the design into a shift register configuration (scan-chain) in a shift mode, which is used to reduce the sequentiality of the ATPG-FS problem. The process of doing this is commonly called scan-insertion. Other DFT methods include RAM isolation with scan chains and test point technology to assist the ATPG-FS tasks. For the DFT that is put in the design to be recognized by ATPG-FS some description about the design needs to be provided. This description is the genesis of CTL concepts. CTL provides a mechanism to represent test information of the design in a concise way.

1.3.2 Basic Design Information needed by ATPG-FS

Let us consider the example design of Figure 1 (constructed to describe concepts) 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 a logic-1. The scan chain (shift register) created in this configuration has an input 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 to define the interface signals of the scan chain. ATPG-FS would then simulate the information in a Design Rule Checking (DRC) step to extract the bits of the scan chain for use in its subsequent operations. This user-specified information to ATPG-FS tools is an abstract description of the relevant test constructs of the design. CTL is used in the example below to represent such test 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.

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; }

29. 30. } 31. }

The above CTL statements define information that the ATPG-FS would typically use as input. ATPG-FS is looking for the interface of the design and certain special characteristics of the signals. The example begins with two blocks of statements that describe the version of the syntax used (1 to 3) and a header for the file (4 to 7). The Signals block of statements defines all the signals of the design and the direction 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 to 16). All information about the signals is defined in an Environment (18 to 31) block of statements in an embedded CTL (19 to 30) block. Information about 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) block of statements. Using the DataType statement the characteristics of the signal are 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 the design (21, 22). ATPG-FS tools also associate a stable state with clocks. This is the state that ATPG would keep the clocks at during most of the test operations. This is specified using the AssumedInitialState statement and given 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 this example, the test data that would be applied to s is stimulus for the scan

chain (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-FS tools typically expect to know the state of scan enable signals to allow for operation of the scan chain. The state of the scan enable signal that enables the shift operation is specified with the ActiveState statement (26). In this example, 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 that is not configuring the scan chains into a shift register. Thus the AssumedInitialState of the scan enable signals is ForceDown. In a later section the output of the ATPG-FS tool is provided in CTL for the tool that would have taken the above as input (section 9.1 page 138).

Chapter 2

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

2.1

USED AS AN INTERFACE BETWEEN THE USER/DFT AND ATPG-FS

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

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

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

2.2 USED IN SOC METHODOLOGIES TO DESCRIBE CORES

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

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

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

2.3 USED AS AN INTERFACE BETWEEN THE DESIGN AND THE ATE

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

2.4

USED AS INTERFACE BETWEEN DIFFERENT TEST AUTOMATION TASKS

Test automation contains many sub-steps that are known to the typical test user. 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 the results of an analysis and possibly manipulate it. CTL could play a role in providing this information.

10

Figure 5 shows how CTL can be used as the communication mechanism between a DFT analysis process and the actual implementation of the structures. Since the communication is through CTL other analysis tools could plug in easily into such a flow.

2.5

USED AS AN HIERARCHICAL DFT LANGUAGE

Just by the fact that CTL represents all test-information of a design as a replacement of the netlist (in the case for cores) allows it to be a mechanism to support a hierarchical (or recursive) DFT flow. Figure 6 shows a flow where a design is being created that incorporates a sub-design whose test information is described in CTL (ctl). If CTL is created for the top design the same flow can be repeated to achieve a complete hierarchical methodology.

11

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

Chapter 3

Design Philosophy of CTL

CTL is designed for abstracting test information of designs for communication in an automation-friendly format or human-readable format. The language is specially designed for an environment that allows for reuse of designs as cores in System-on-Chip (SoC) designs. In this environment, the consumer of this information could be a test automation tool that integrates cores into the SoC, or a person integrating the core. The goal of CTL is to describe test information for any core without restricting the test methodology used in the core. As a result CTL is a general language that is not tied to any given test architecture. It is the intent of this book to describe the flexibility of the language that enables CTL to support a number of other needs in the representation of test information. It is not possible for this book to cover all the possible uses of CTL. The language forms a basis for the development of applications that have not been possible in the past. For example this language could be used to provide a richer interface between ATE and test automation tools than the existing test pattern interface. With a CTL interface ATE software will have a more information rich environment available to it that will allow for many more value added features (for example debug related capabilities).

3.1 WORDS THAT MAKE-UP SENTENCES

To handle the vast variety of pieces of test information that need to be described CTL is designed as a language that constitutes keywords that represent small but crisp concepts. These are the words of the test information of the design. These words can be put together in numerous ways to describe complete concepts in test which are true to the mechanisms in the design. This can be best understood by looking at a construct that has been introduced in a previous chapter. Let us take the simple construct called DataType. This statement allows for information to be described about the special types of signals that exist in a design as applicable to test. There are many different types of special signals in the design. For example, there could be a signal that is an asynchronous reset signal that needs to be held constant during the application of test patterns. Under DataType each characteristic has a special keyword associated with it. These keywords when combined for this signal would

13

convey this information. Thus in this example, the signal would be attributed as DataType Asynchronous Reset TestMode. CTL keywords are selected such that they are as close to the meaning of the definition as possible. Abbreviations are avoided as much as possible. Furthermore, across the syntax of CTL the attributes are always given an identifier to classify the category of information. In the example, DataType is the identifier or keyword for the list of attributes that define the characteristics of signals. CTL has numerous constructs in the language. Different usage scenarios of CTL would use subsets of these constructs. Thus when a construct is not used in the CTL implementation no information is to be interpreted with regard to that construct, unless some default is identified for it.

3.2 EXTENDABILITY OF THE LANGUAGE

The value of CTL is in the keywords that are defined. It is the standardized keywords that allow for interoperability between different tools and environments. The CTL created by one environment should be readable by another environment without any glitches or misinterpretations. To highlight this concept a bit more, a keyword in CTL fixes the expectation of the parsers on the way information is going to appear. DataType spelled in different ways would not be able to work across different parsers. CTL attempts to be exhaustive with the keywords where ever possible. However, it is acknowledged that this is an impossible task and the language should allow for user defined extensions. This will allow for new concepts and tools that are developed in the future to leverage CTL. Extensions for existing statements are provided through user defined attributes. Continuing with the DataType example, there is the ability to add data types to the statement as User mydatatype. Use of user defined data types should be minimized as the interoperability of the CTL is at risk. If the language is deficient and user defined keywords are used the industry should look towards creating an extension of the standard to standardize the concepts with formal attributes. Extensions that require completely new statements in the language are possible through user keywords (UserKeywords).

14

3.3 LEVERAGING EXISTING STANDARDS

One of the design philosophies of CTL has been to leverage off existing standards as much as possible. CTL has been designed to co-exist with other design description languages and pattern description languages such that the information provided by CTL is complimentary. Thus if an existing language provides certain syntax and semantics CTL tries to reuse it as much as possible without intrusion. STIL reuse deserves special mention on this subject. Some portions of the CTL 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 the time STIL was created some enhancements were needed to the test patterns for STIL to work for CTL. To minimize CTLs intrusion on STIL the features required by CTL were rolled into the STIL standard as an extension to STIL which is being called IEEE 1450.1.

3.3.1

Design Constructs and CTL

CTL is written to a single boundary of the design. The design boundary represented by CTL is identified in the Signals block of statements. In the trivial case this statement means that there is one CTL description that goes with a design that describes aspects of the design to its outer boundary as shown in Figure 7.

Figure 7 depicts a CTL description for a design, in which there is a one-toone correspondence between the design terminals and the signals to which CTL 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 best way to convey information about a portion of the design then one should not try to replicate the design netlist into CTL. Instead CTL should be used in a configuration as shown in Figure 8.

The oval in Figure 8 represents the portion of the netlist that is being described in CTL. The terminals of this sub-netlist are the three inputs of the multiplexor m0, m1 and me, the clock input to the flip-flop (ffc) and the output of the flip-flop (ffo). CTL is architected in such a way that within reason, any boundary could be selected in a design netlist to represent information. The boundary should not split primitives (for example, a tap controller of IEEE 1149.1 or a Linear Feedback Shift Register is considered as a primitive) of the design.

3.3.2 Sequence and Pattern Information in CTL

Test information for a design includes test patterns that exercise the design when it is manufactured. There already exists a standardized representation of 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 in an environment that was oblivious to the goals of CTL. Reusable test patterns are different from just plain test patterns. Thus, for CTL to leverage STIL it needed to limit STILs flexibility or extend STIL to add features for reuse. As part of the CTL activities STIL was analyzed and the necessary enhancements were proposed as an extension to STIL in the form of the IEEE 1450.1 extension. Thus, CTL actually uses STIL patterns that have features 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 a sequence could be representative of the operation to scan-in and scan-out values from a scan chain. Instead of inventing new syntax for sequence information, it was recognized that as part of STIL this was available and could be reused. With the heavy reliance on STIL constructs, the most natural syntax for CTL became a STIL like syntax. This allowed for complete reuse of STIL as needed in CTL information. Figure 9 depicts the portions of the complete CTL syntax as it relates to the reuse of existing constructs defined by STIL.

As a result of reuse of STIL the CTL syntax is spread across three documents namely, IEEE 1450-1999, IEEE 1450.1 and IEEE 1450.6-CTL. The syntax of CTL is partitioned in such a way such that the syntax unique to CTL is written in a block called Environment. The Environment is a block provided by STIL for user defined information. Whenever the CTL information, written in the Environment block, needs to reuse STIL constructs the constructs are written outside the Environment block and referenced in the Environment. While CTL only allows for its protocols to be described in STIL formats, it recognizes for the many uses of CTL the test pattern format may not be STIL. It is possible to link other formats for test patterns into CTL. For more information the reader should look at section 7.7.3 statements 883 to 890 and the associated explanations.

17

3.4 HIERARCHY AND CTL

Designs and in particular SoC designs contain hierarchy that is created by reuse of cores. CTL represents the information about the hierarchy in a flattened manner. A single representation of CTL is used to represent all the hierarchies that need to be described. That is, a hierarchical design would have a single CTL to represent it and not be constructed out of hierarchically connected CTLs of the sub-designs.

3.5 PURPOSE OF CTL (IEEE 1450.6) AS DEFINED BY THE 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 to support reuse of test data developed for that core after integration into SoC environments, and to enable the creation of test patterns for the logic on the SoC external to the core.

3.6

SCOPE OF CTL (IEEE 1450.6) AS DEFINED BY THE STANDARD

The following text is taken from the PAR for the proposed standard. SoC test requires reuse of test data and test structures developed for individual cores (designs) when integrated into larger integrated circuits (SoCs). This activity will define language constructs sufficient to represent the context of a core and of the integration of that core into a SoC, to facilitate reuse of test data previously developed for that core. This activity will also define constructs that represent the test structures internal to the core, for reuse in the creation of the tests for the logic outside the core. Semantic rules will be defined for the language to facilitate interoperability between different entities (the core provider, the system integrator, and the automation tool developer) involved in the creation of a SoC. The constructs in the language are to support a vast variety of cores and different test methodologies with particular support for the IEEE 1500 activity that is creating a wrapper-architecture.

Chapter 4

Simplified View of CTL

The CTL syntax is partitioned into blocks of statements that represent certain concepts. The Environment brings the information together. Thus the primary informational entity in CTL is the Environment.

4.1 THE ENVIRONMENT AND ASSOCIATED INFORMATION

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

The configurations describe information about: (a) the internals of the design (in the Internal, ScanInternal, CoreInternal and Relation block of statements).

19

(b) the external environment of the to be embedded design (in the External block of statements). (c) pattern information (in the PatternInformation block of statements) of the design that is being described. Most of the information is described on design entities such as signals, scan cells or signals on internal cores of the design. To describe information on these design entities the associated design construct should be first defined in a block of statements outside the Environment and then referred to in the Environment block of statements. Figure 10 shows how the Environment is structured relative to the design entities that are defined in the CTL. The following is an example of a definition of a clock signal of the design and a reference made to the signal in the Environment to describe that it is a clock. Signals { c In; } Environment { CTL { Internal { c { DataType MasterClock; } } } }

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

20

4.2

EXAMPLE: ENHANCED ATPG-FS INFORMATION

The structure of the CTL language can be best seen with an expansion of the example in Chapter 1. Some ATPG-FS tools allow the user to constrain the type of sequences that can be used by the test generation algorithms. The sequences to be used by the test patterns would have to be supplied to the ATPG-FS tool in addition to the information provided in the example shown in Chapter 1. Thus the example of Chapter 1 can be enhanced to be as follows.

32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44.

STIL 1.0 { CTL ThisBook; } Header { Title CTL for enhanced ATPG-FS Info; Date 2002; } Signals { a In; b In; c In; s In;

21

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 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; }

22

e { DataType TestControl ScanEnable 86. { ActiveState ForceUp; 87. AssumedInitialState ForceDown;}} 88. o { DataType TestData ScanDataOut; } 89. 90. } PatternInformation { 91. Macro test_sequence { 92. Purpose DoTest; 93. 94. } 95. } 96. } 97. } Most of the CTL code is repeated from the previous example to give the reader an idea of how the example would look with the augmented information. First let us focus in on the pieces of the example and relate it to the discussion of the previous section. The primary block of information that is being written is the Environment block of statements (79 to 97). To describe information about the signals of the design the Environment needs a support block of statements called Signals. The signals of the design are defined in statements 40 to 47. They are referenced in the Environment and information is provided about each signal. In this example, the primary information being provided is the data type of the signal and some information about its state. In this example some sequence information is also provided to the ATPG-FS tool. The sequence is a Macro. As explained earlier, the sequence is defined outside the Environment (67 to 78) and referenced in the Environments PatternInformation block of statements (91 to 95). This is nearly all the information that was relevant to the discussion in this chapter. For completeness the new syntax constructs added to the example are described below. The sequence information is described in four new blocks of information, namely PatternInformation (91 to 95) MacroDefs (67 to 78), Timing (52 to 66) and SignalGroups (48 to 51). These blocks of information have been added to the example in a particular order. The order in which the information is to occur in CTL is determined by looking for which block references information in which other blocks. A block is only allowed to reference information that has been defined earlier. In this example,

23

PatternInformation references MacroDefs and MacroDefs references Timing. At the highest level the sequence that ATPG-FS is being constrained to is identified in the PatternInformation block of statements (91 to 95). In our example a single sequence (Macro) is identified (92). This sequence is given an arbitrary name called the test_sequence (92) and identified to be a sequence that is to be used to apply the test patterns (DoTest) using the Purpose statement (93). The actual Macro test_sequence is defined separately. The Macro is defined in a MacroDefs block of statements that represents a collection of sequences (67 to 78). However, only one sequence (test_sequence) is defined in this example, test_sequence (68 to 77) is made up of vector statements (V) and scan operations (Shift) which define how values are applied to Signals. The values are characters defined in the Timing block that represent data associated with time that is relative to a clock period. The Macro references the WaveformTable in the Timing block (69) and uses the characters defined in it. In our example, W stands for WaveformTable. The name of the waveform table that is relevant to test_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 to represent a pulse and X is used to represent a dont-care. test_sequence performs the following steps. 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) } In the Macro, C represents a Condition statement, which defines stimulus or responses to be set up, but deferred from being performed until a Vector statement is defined. The # symbol assigned to signals represents data that is passed 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

24

shift one value into or out of the scan chain. The number of shifts is determined by the data provided by the invocation of the Macro test_sequence, which in our example is a one-bit data, as the chain length is one. The Macro test_sequence is designed to have two parameters passed to it for the output o. To avoid any aliasing problems of which parameter gets assigned which value that is passed in for signal o, a # was not used. Instead signal variables (func_val and scan_out) were used to define the parameters. In this example the signal variables are defined in the Variables block of statements (48 to 51). The waveform characters that are used in the Macro are defined in a WaveformTable (53 to 65). The waveform characters are associated with signals and defined using a syntax that describes formal events that occur at certain times. In this example D represents drive low event, U represents drive high event, N represents drive unknown event, I represents the beginning of a compare low window event, h represents the beginning of a compare high window event and X represents a do not compare event. Short hand notations allow for a one-to-one correspondence between the series of waveform characters and the events associated with them. Consider the waveform characters for signals a, b, c, s, e represented as a group a+b+c+s+e (56). Four waveform characters (0,1, P and X) are defined for these signals (57). 0 is defined to drive a logic-0 across the complete period starting at 0ns (Ons D; 60ns D; 70ns D;) (58, 59, 60). 1 is defined to drive a logic-1 across the period starting at 0ns (0ns U; 60ns U; 70ns U;) (58, 59, 60). P is defined to be a pulse signal that begins low, goes high at 60ns for 10ns and then goes low at 70ns to remain low for the rest of the period (0ns D; 60ns U; 70ns D;) (58, 59, 60). X is defined to be a dontcare value starting at 0ns (0ns N; 60ns N; 70ns N;). Similarly three waveform characters are defined for signal o (63) to compare values since it is an output signal.

Chapter 5

CTL Syntax and Semantics: Design Entities

CTL syntax and semantics is spread across multiple documents of the IEEE 1450 dot series of standards. The purpose of this book is to give the reader a fair idea of the constructs in the language. The syntax is described at a higher level of abstraction where the exact use and meaning of individual keywords is not covered. For fine details and completeness of the syntax and semantics the reader should refer to the standard documents.

5.1 READING CTL SYNTAX

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

98. Environment { CTL (CTL_NAME) { 99. Internal { 100. (sigref_expr { (DataType ( data_type_enum ) + ;) 101. (DataType ( data_type_enum ) + { 102. (ActiveState <ForceUp | ForceDown 103. 104. | ForceOff|ForceValid|ExpectLow | ExpectHigh | ExpectOff 105. 106. | ExpectValid> (Weak);) 107. (DataRateForProtocol <Average | Maximum> INTEGER ;) 108. (AssumedInitialState <ForceDown 109. 110. |ForceUp| ForceOff | ForceValid |ExpectLow | ExpectHigh 111. 112. |ExpectOff|ExpectValid> (Weak);) (ScanDataType (<AddressGenerator 113. 114. | Boundary | ByPass | Counter | DataGenerator 115. | Instruction | Internal 116. | ResponseCompactor 117. | User USER_DEFINED>)+; ) 118. (ValueRange INTEGER INTEGER; ) * 119. 120. })* 121. })+

26

122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148.

}}} data_type_enum = <Asynchronous | CoreSelect | ClockEnable | Constant | Functional | In | InOut | Indicator | InOutControl | Oscillator | Out | OutDisable | OutEnable | MasterClock | MemoryAddress | MemoryData | MemoryRead | MemoryWrite | Programming | Regular | Reset | ScanDataIn | ScanDataOut | ScanEnable | ScanMasterClock | ScanSlaveClock | SlaveClock | Synchronous | TestAlgorithm | TestClock | TestControl | TestData | TestDone | TestFail | TestInterrupt | TestInvalid | TestMode | TestPortSelect | TestRun | TestWrapperControl | Unused | UnusedDuringTest | User USER_DEFINED>

The example taken is of the statement DataType. As mentioned in the introduction to CTL, bold words are keywords defined by the language with specific meaning attached to it with definitions in the standard document. Small cap text is used to specify user-defined data that has to follow conventions of the language. Italics is used to reference information that is selectable from an enumeration of keywords or is user defined with some special underlying type and syntax associated with it. ( ) around statements implies that the statement is optional and it can be used at most once in the block of syntax where it is occurs. If the statement is allowed multiple times, a + or * will appear. Thus ( )+ would mean that the statement is allowed to occur one or more times and ( )* would mean that the statement is allowed to

27

occur zero or more times. < > is used to indicate a multiple choice amongst the information between the angular brackets. Default values are underlined. Thus if we were to now read the example syntax and use it to write a DataType statement, it can be seen that it is necessary for the statement to be embedded in the Environment and CTL block of statements as there are no ( ) around the syntax (98, 122). Similarly, the Internal block of statements is necessary as there does not exist any ( ) around it (99, 122). Data types are defined on signals (sigref_expr) of the associated design being represented which are defined in the Signals block of statements in CTL (not shown here). The signal is cross-referenced to define its DataType (100). While this cross-reference is shown as optional, since we are focused in on DataType there has to be a signal whose data type needs to be described if one has to write a DataType statement (101, 102). There are two ways of specifying a DataType of a signal. In the first way, the statement allows for the specification of one or more data types (101) from a list provided in an enumeration (123 to 148). In the second format (102 to 120), the statement allows the specification of one or more data types of a signal as selected from the enumerated types specified by data_type_enum and some more statements (103, 107, 109, 113, 119) associated with the DataType. The active values (ActiveState) of the input/output signal when used as the data type corresponding to it. The values assumed by the test data on signals at the start of every test protocol (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 internal scan elements. The range of values allowed on a group of signals (ValueRange). In either format of expressing the DataType information there is never the situation that the DataType statement is allowed with no enumerated types selected from the set specified in the data_type_enum. This should be noted from (data_type_enum)+. Statements 21 to 28 on page 4 is an example usage of the syntax (re-iterated below 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 the syntax 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 and ExpectOff can be replaced by Q, without any violation of the syntax defined in CTL. There is no particular ordering between statements within a block of statements in CTL syntax. However, there is a single global rule that minimizes the forward references in the syntax of a valid CTL file. With some exceptions (around pattern data), all entities that are used should be defined prior to its use. By this rule the typical CTL Environment block would 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 only allowed to Patterns.

5.2 USER DEFINED NAMES IN CTL

5.2.1 Construction of Names

Before going into the details of the syntax and semantics of CTL statements one must understand the basics behind names and their scope. CTL has placeholders for names in numerous locations in the syntax. These names are expected to follow certain rules.

29

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

5.2.2 Scope of Names

Names are defined for different entities in their associated blocks of statements. For example, signal names are defined in the Signals block of statements or Macros and their associated names are defined in the MacroDefs block of statements in CTL. Most of the blocks where entities are defined could be named or unnamed blocks. The names of blocks are commonly referred to as domain names in CTL. Consider the following example of one unnamed block and two named blocks 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. The other two blocks of statements are named blocks of BlockType. The names domain_name_1 and domain_name_2 are domain names. Entities are defined within these blocks. Entities defined in unnamed blocks are considered to be globally accessible across CTL. Thus Entity_global can be referenced anywhere else in the CTL syntax. While entities in named blocks are accessible only when the named block is brought into the scope (See DomainReferences for more information in section 7.1 on page 56). Name clashes are allowed between entities of the same type in different named blocks. In the above example unique entity names Entity_1 and Entity_2 were used.

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 Corelnstances

While it may be too premature to go into the details of individual types of entity names or aspects about Core-Instances, all names in CTL are constructed with a simple rule. The true name (unique name or canonical name) of a CTL entity is a hierarchical concatenation of names of the core-instance, domain and the entity, separated by : or ::. When appropriate the core instance name is used and it is ended with a :. Domain names when used are terminated with a ::. 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 which case the true name does not include it. Thus the true name of a signal group eg_signals, defined in a signal group eg_group, would be eg_group::eg_signals. If the signal group were defined as part of the definition of a core instance say eg_core, then the true unique name of the signal 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-instanceentity name may itself be unique across CTL. In such cases CTL allows for omitting the domain name in which the entity is defined. By default it is assumed that all entity or core-instance-entity names are unique and some declarative statements allow for the addition of the domain name. The optional domain name concept will be addressed in the description of the DomainReferences block of statements (7.1 on page 56). Names in non-pattern related constructs of CTL are true to the above description. Since pattern data is sequential in nature another mechanism allows 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 in the domain. Thus there is no ambiguity in the entity name within the scope of the pattern construct. Regardless of this use of the entity name, it should be brought into the scope of the test mode through the DomainReferences block of statements. The name would follow the rules of the names as the

31

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

5.3 DESIGN ENTITIES RECOGNIZED IN CTL

CTL information is divided into blocks of statements based upon some affinity of the information being described. At the top level of CTL the Environment block of statements describes test information about the design. This is the most important block of statements in CTL and is the primary block that is written. A number of support blocks are defined outside the Environment, which are linked in to the Environment block of statements through the DomainReferences block and follow the scoping rules of section 5.2.2 on page 29. In this section the support block that represent design entities are introduced. Before addressing the design entities recognized in CTL one would first want to know which designs entities are being represented in CTL. This is accomplished through the FileReference statement in the Environment.

149. Environment (ENV_NAME) { (FileReference FILE_PATH_NAME { 150. 151. Type <Pattern|Design>; 152. Format <STIL|WGL|Verilog|VHDL|CTL>; Version VERSION_NUMBER ; 153. 154. })* // incomplete keywords shown. 155. }
The FileReference statement allows for a pointer to the file which includes the 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 by the Version statement (153). While to this level of discussion these may be the only relevant keywords of the syntax, one should be made aware of the possibility of referencing Design files in which the design information is provided in CTL. That is the design being referenced is another core. Figure 12 shows the design entities recognized in CTL. They include signals of the design, scan cells within the design and hierarchical cores that are

32

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

5.3.1

Signals and Signal Groups

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

156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166.

Signals { (SIGNALNAME <In|Out|InOut|Supply|Pseudo>;)* (SIGNALNAME <In|Out|InOut|Supply|Pseudo> { (DefaultState <U|D|Z>;) (ScanIn (integer_expr);) (ScanOut (integer_expr);) (WFCMap { (FROM_WFC - > TO_WFC (TO_WFC)+;)* }) })* // incomplete syntax shown }

33

The Signals block (156 to 165) is needed to describe information in the Environment. Signals of the design are defined in the Signals block of statements and referenced in other blocks in locations of the syntax that allow for a SIGNALNAME or sigref_expr. Signals can be grouped together in sigref_expr (signal expressions) using a syntax that adds or subtracts names from a sequential list. For example a sigref_expr of signals could be a+b+c+d. The signals a, b, c and d are grouped together. Furthermore a+b+c+d-a represents a grouping of signals b, c and d. Signal names (SIGNALNAME) in the Signals block are user-defined names with the ability to define indexes in square brackets (157, 158). Thus my_signal_name, mySignal are valid names for single signals and address_bus[0.. 7], address_bus[7..0] are valid signal names for the signals address_bus[0], address_bus[1], ..., address_bus [7] with the difference that the Most Significant Bit (MSB) is the leftmost signal in the group. If a constant integer is defined using the IntegerConstant statement (179 on page 35), the signal definition is definable using the named constant (CONST_NAME). Thus if n is defined as a constant of value 7, the address_bus[0..7] could be defined as address_bus[0..n]. This concept has value when CTL is being written to a generic parameterizable design whose parameters 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 information is defined on the signal. Default states (DefaultState) of the signals are specifiable for use when no value is provided in the sequence or pattern information in CTL (159). Through the statement on ScanIn (160) and ScanOut (161), the scan data associated with the scan inputs and outputs of the design can be assigned default lengths. Signals are typically assigned waveform characters that represent logic states with timing information. While most of this information is defined in WaveformTables (to be described later in section 7.7.1 on page 101), a WFCMap statement (162, 163, 164) allows for specification of an alternate mapping of waveform characters (from_wfc to to_wfc) defined for the signal. This statement could be 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) provides example 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 and padding definitions for the scan data. Signals { a In {DefaultState b In {DefaultState c In {DefaultState e In {DefaultState s In {DefaultState o Out {ScanOut 1;} } Z;} Z;} Z;} Z;} Z; ScanIn 1;}

Signals can be grouped together and the group can be named in a SignalGroups block using the following syntax.
167. 168. 169. 170. 171. 172. 173. 174. 175. 176.

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 of signals. Signal group names do not directly represent design entities. These names are referred to in the syntax as GROUPNAME that can be used in a sigref_expr. The true name (unique name) of a signal group is a hierarchical concatenation of the DOMAIN_NAME and the GROUPNAME defined inside the named SignalGroups block and would be referred to as DOMAIN_NAME::GROUPNAME. This name is used in the Environment block of statements in CTL. For the unnamed SignalGroups block the GROUPNAME is the complete name of the group. However, if the group names are unique across the CTL block where it is used the group name can be used without the concatenation of the domain name to the group name. The use of the domain-name is determined by UsePrefix-DomainName statement, of the DomainReferences block of statements, in the Environment (297 on page 57).

35

Through SignalGroups-GROUPNAME all the signals of the netlist can be grouped into a bused entity called grpAll[0..n], or inputs can be grouped together to be called grpIns[0..n], and outputs can be grouped as grpOuts[0..n]. The signal assignments are made using a signal expression (sigref_expr). There should be a one-to-one mapping between the grouped signal names and the signals that are assigned to the group through the sigref_expr. This means that one cannot assign multiple signals to a group name without any [ ]. The following example syntax shows the definition of some 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) statements similar to the capability allowed for signals. Alternate waveforms can be defined for individual groups similar to the capabilities on Signals. Coupled to signals are SignalVariables. These are carriers of information that would reside on signals. The following syntax shows the definition of SignalVariables.

177. 178. 179. 180.

Variables (DOMAIN_NAME) { (SignalVariable VARIABLENAME;)* (IntegerConstant CONST_NAME=DECIMAL_INTEGER;)* } // incomplete syntax shown

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

36

5.3.2

ScanStructures and ScanCellGroups

Though scan structures scan-signal-names can be defined as scan cells. These scan cells should correspond to design entities and CTL information is provided for the same. The following syntax defines the named (domain_name) scan structures block of statements.

181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192.

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 <0|1>;) })+ } // incomplete syntax shown

The ScanStructures block (181 to 192) represents a complete/contiguoussegment of a scan chain using the ScanChain block of statements (182 to 191). 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 scan cell is closest to the scan in and the rightmost cell is the closest to the scan out. The cell names can be used in the syntax wherever CELLNAME and cellref_expr are allowed. Just like sigref_expr, cellref_expr can contain multiple scan cells combined with the + and - operator. Inversions are described between cells using a ! in the list of scan cells (184). The scan cells are expected to have a one-to-one correspondence with the scan flipflops of the design being represented and are unique across the name space of CTL. That is, if the same cell name appears in two scan chains, it is the same cell. The names of scan-cells are also unique with the chain_names. This allows for chain names to be used to embed a segment of a scan chain within a larger chain without listing out all the cells individually. Shorter names for scan cells (such as c[0..99]) can be used in the scan structures if the names of the scan cells in the design are very long. To use this feature, a mapping of the names could be provided to the real names of the cells in the design using the NameMaps construct in the Environment block (section 8.2 on page 128).

37

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

Figure 13 shows an example scan chain that is to be described in CTL. The scan 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; } } // OR ScanStructures { 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 of statements and can carry information that can be grouped together based upon some inherent properties. Similar to Signals and SignalGroups, ScanCells has its equivalent construct called ScanCellGroups.

193. 194. 195.

ScanCellGroups (DOMAIN_NAME) { (CELLGROUPNAME = cellref_expr;)+ } // incomplete syntax shown

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

5.3.3

Core Instances

This block of information provides the ability to identify an entity internal to the design as a core. The core typically would have some inputs and outputs and scan chains.

196. 197. 198. 199. 200.

{CoreType CORE_TYPE_NAME { (CoreEnvironment CORE_ENV_NAME;) (InheritCoreType CORE_TYPE_NAME { (Instance (CORE_INST_NAME)+;)+ })*

39

201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212. 213. 214. 215.

(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 being written. 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 of these cores are defined in the CoreType statement (196 to 210). The cores instantiated in the design have certain constructs that are visible to the 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 their counterparts in the top-level designs CTL. The signals define the boundary of the core, the signal groups perform logical groupings of the signals of the core and scan structures define the scan chains in the core. Once defined all these entities are available for the informational needs of the top-level designs CTL. The respective entities are identifiable with a unique name that is created with a concatenation of the CORE_INST_NAME to the entity name with a : separator. The signals of the core-instances are identifiable in the remainder of CTL by the concatenation of the CORE_INST_NAME:SIGNALNAME or CORE_INST_NAME:GROUPNAME. The domain name can be optionally added to the name to resolve name conflicts such as those between group names of different groups defined in the core instances. Thus the true (unique) name would be CORE_INST_NAME:DOMAIN_NAME::ENTITY_NAME.

40

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

Consider a conceptual hierarchical design, which reuses multiple cores as shown in Figure 14. There are two cores of type A namely InstAl and InstA2 and one hierarchical core of type B that is instantiated as InstBl. InstBl has a sub-core of type A named InstA3 that would have a name InstBl:InstA3 when referred to in CTL. The above would be described in CTL syntax as follows. 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 as InstA1:i[0..1] and InstA1:o[0..3] and the signal names of the sub-core of InstB1 called InstA3 are referred to as InstB1:InstA3:i[0..1] and InstB1: InstA3 :o[0..3]. Core instances in the design may have scan structures within them. They are definable in the CoreType block with the same mechanisms for the names as defined for Signals and SignalGroups of the inherited cores. The scan cell list can be included as segments of scan chains defined in the ScanStructures 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 the scan chain of the core InstC1. The scan chain of the core is defined in the scan structures shown in the figure. The following code is the example of how the scan chain of the design is defined using the definition of the scanchain 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 in this case, it is also recognized that cores could come with test patterns. The test patterns that come with cores are included by reference in the core instance statement (213, 214). Since they are not defined here they do not follow the naming conventions for names of entities within cores that was discussed in this section.

Chapter 6

CTL Syntax and Semantics: Top Level View

The Environment block of CTL provides the bulk of the CTL information. This named block of statements is the one being written to describe all the test information and hence is not optional for CTL. Though multiple Environment blocks are allowed with CTL information in it, each named environment is to be considered a complete description of the test information of the design. The skeleton syntax of the Environment block is shown below. // Top level CTL block of statements. 216. (Environment ( DOMAIN_NAME ) { (NameMaps (MAP_NAME) { })* 217. (InheritEnvironment DOMAIN_NAME;) 218. (FileReference FILE_PATH_NAME { 219. Type <Pattern | Design>; 220. Format <STIL|WGL|Verilog|VHDL|CTL>; 221. Version VERSION_NUMBER; 222. })* // incomplete keywords shown. 223. (CTL (CTL_NAME) { 224. (CoreInternal { }) 225. (DomainReferences (CORE_INST_NAME) { })* 226. (External { }) 227. (Family (NAME)+;) 228. (Focus (<Top | 229. Corelnstance (CORE_INST_NAME)+>) { })* 230. (InheritCTL CTL_NAME;) 231. (Internal { }) 232. (PatternInformation { }) 233. (Relation { }) 234. (ScanInternal { }) 235. (< TestMode (test_mode_enum)+; 236. 237. | TestMode (test_mode_enum)+ { 238. AlternateMode (CTL_NAME)+;} 239. >) (TestModeForWrapper TEST_MODE MODE_CODE;) 240. (Vendor (NAME)+;) 241.

45

242. 243. 244. 245. 246. 247. 248. 249. 250. 251. 252. 253.

(Wrapper <IEEE1500 |None |User USER_DEFINED> ;)

})* })* test_mode_enum = <ByPass | Debug | ExternalTest | ForInheritOnly | InternalTest | isolate | Normal | PowerOff | PowerOn | Quiet | Transparent | User USER_DEFINED> // 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. (Signals { }) 255. (SignalGroups (DOMAIN_NAME) { })* 256. (ScanStructures (DOMAIN_NAME) { })* 257. (ScanCellGroups (DOMAIN_NAME) { })* 258. (CoreType CORE_TYPE_NAME { })* 259. (CoreInstance CORE_TYPE_NAME { })* 260. (Variables (DOMAIN_NAME) { })*
// Information about CTL file content. 261. (Header { (Title TITLE_STRING ;) 262. (Date DATE_STRING ;) 263. (Source SOURCE_STRING ;) 264. 265. }) 266. STIL IEEE_1450_0_IDENTIFIER { CTL EXT_VERSION; }

// Information related to information for the // PatternInformation block of statements. 267. (PatternExec (EXEC_NAME) { })* 268. (PatternBurst PAT__BURST_NAME { }) * 269. (Pattern PATTERN_NAME { })* 270. (Timing (DOMAIN_NAME) { })*

46

271. 272.

(MacroDefs (DOMAIN_NAME) { })* (Procedures (DOMAIN_NAME) { })*

The information in the Environment is partitioned into multiple blocks of statements (216 to 245). These statements are the sentences of the test-story that is to be described in CTL about the design. In the chapters describing the syntax, the words that form the sentences and the sentences themselves will be described. The test-stories will be covered in examples in the following chapter. Some of information in the Environment is physically written in blocks of statements outside the Environment and linked to the Environment with statements within it.

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

47

CTL-test information about the design is descriptive in nature as opposed to prescriptive. Most of the information (outside of the information in the External block (227) of statements) in the design is describing existing testrelated features of the design. The CTL information is linked to the design through the FileReference mechanism where a file of Type Design is referenced in the Environment (219 to 223, also shown in Figure 17 on page 48). FileReference is also described in section 5.3 on page 31. The CTL for this design may be associated with a Family of designs or a particular Vendor, which can be identified in the syntax (228, 241). The family name or vendor name is a user-defined entity in the CTL syntax. The remainder of this chapter describes at a high level the various blocks of statements 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 DESIGNS

The design typically operates in multiple configurations. Each configuration called a test-mode has its own test-information. Thus CTL in the Environment (216 to 245) is structured along the concept of CTL blocks for test-modes (224 to 244). Figure 17 is a pictorial representation of the mode specific structure in CTL.

48

Multiple CTL blocks of statements (224 to 244) can be defined in the Environment each reflecting a test-mode of the design as identified by the TestMode statement (236). These CTL blocks are user-defined named entities (CTL_NAME, 224), with the ability to have one unnamed CTL block, which acts as a block of common information for all test-modes. This unnamed CTL block cannot be assigned a TestMode statement within it (236). The test-modes can contain configuration information, or pattern information as appropriate for the applications. While most modes are created to describe new configurations, some modes define exactly the same information (alternative information) as another mode using a different configuration. For example there could be two different ways to test the design. In one configuration 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 of each other and are identifiable through the AlternalteMode statement (238). Though the example figure shows a symmetric relationship between alternate modes the relationship need not be symmetric. One of the basic DFT methods in SoCs use wrappers constructed for isolating the cores from the SoC logic. These wrappers have a control register also called an instruction register which contains a code that controls design constructs to achieve different configurations. The codes in the instruction register are called instructions and correspond to the test modes in CTL. To acknowledge this standard DFT technique two special statements are defined in the CTL block of statements. The Wrapper statement (242, 243) allows for the identification that the design being described contains a wrapper. The IEEE1500 wrapper is specially identified with a keyword. The instructions and their codes are connected to the test mode being described through the TestModeForWrapper statement (240). Through this statement, the instruction name as defined by the standard and the code as constructed out of a sequence of 1s, 0s and Xs is provided along with the CTL test modes.

6.2 TYPES OF TESTMODES

A number of different predefined types of configurations exist in designs. Some commonly know configurations of the design are identified in CTL with keywords (246 to 252). ByPass test mode constitutes a configuration of the design that allows for the by-pass of certain logic in the design. While most associate this term to IEEE 1149.1s ByPass Instruction, that configuration is just an example of the configuration identified by this keyword. Debug test mode constitutes a configuration of the design that is made available for debug purposes. Different designs may provide different types of access available in the configuration available for debug. ExternalTest test mode constitutes configurations of the design that allow for the test of the logic external to the design when the design is embedded in a SoC. For designs with scan wrappers this would typically 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 the wrapper scan chain. This configuration would also allow for values to be provided to the logic external to the design on the output side through the wrapper scan chain. The configuration does not imply how many signals of the design have the properties to assist external test. That information is available in the details of the syntax in the test mode. ForInheritOnly test mode constitutes configuration information of the design that is not complete. It is to be used as part of the test mode configuration of another CTL test mode description. InternalTest test mode constitutes configurations of the design that allows for the internal test of the design. The configuration does not imply any type of test methodology or the amount of logic that can be tested in the design. Isolate test mode constitutes configurations in which the design is de-coupled from external effects on one or more of its signals. This configuration would prevent the internal logic of the design to be affected by changes on its inputs and similarly the outputs are put into states that would minimize any effect of the design on logic external to it in an embedded environment. Normal test mode constitutes the configuration of the design that allows for the functional operation of the design. While this is not a configuration for test purposes, the test tools sometimes need to know information about the functional operation of the designs. PowerOff test mode constitutes the configuration of the design in which minimum power is being consumed. PowerOn test mode constitutes the configuration of the design that is available when the design is powered up. Quiet test mode constitutes the configuration of the design that minimizes the quiescent current of the design. Transparent test mode constitutes the configuration of the design that lets data pass through the design between a subset of the inputs and the outputs. A typical use of this configuration is for external test, thus one can expect this test mode to also be classified as an external test mode.

51

A CTL description of a design can have many different test modes defined for it. Some of the test modes can be of the same type and some of the test modes can be alternatives of each other. If a test mode of a certain type is not available in the CTL description no configuration information of the missing test mode type can be interpreted. It could be that the design has the configuration but the CTL provider intentionally did not want to provide it to the user. It could also be that the configuration does not exist. Since a missing test mode does not convey any information, if the CTL were to describe the non-existence of a configuration of a certain type then the Environment block should contain an named CTL block with the associated TestMode statement and no other information. This CTL block is the equivalent of an empty CTL block. It should be noted that a single configuration of the design could serve multiple purposes. That is multiple test mode types can be assigned to a single CTL block of statements. For example, the PowerOn mode of the design can be the same as the ByPass mode of the design. The associated TestMode statement of the configuration would have both keywords.

6.3 LAYOUT OF TEST MODES

A number of configurations of a flat design can exist. However the design itself is a hierarchical entity composed of smaller entities such as cores. Test modes can be constructed to separate these entities in CTL information. The Focus statement associates the test modes of the design to the its hierarchies. 273. Environment (DOMAIN_NAME) { CTL (CTL_NAME) { 274. (Focus 275. (Top) (CoreInstance (CORE_INST_NAME)+) { 276. (TestMode (test_mode_enum)+;) 277. (Usage (<Production 278. | Characterization 279. 280. | Diagnostic | User USER_DEFINED>)+;) 281. (PatternTypes (<AtSpeed 282. | ChainContinuity 283. | IDDQ | LogicBIST 284. | MemoryBIST | Parametric 285. | Scan 286. | Endurance | Retention 287.

52

288. 289. 290. 291. 292. 293.

| 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 C2 with some glue logic. The InternalTest mode of this design may be partitioned 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 three components. Environment { CTL c1c2top { TestMode InternalTest; Focus Top CoreInstance C1 C2 { TestMode InternalTest; } } } Two test modes are constructed. One test mode tests cores C1 and C2 with top level logic acting as a conduit for the test data and another mode configures the cores C1 and C2 in ExternalTest and to test the top level glue 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;

53

Focus Top { TestMode InternalTest; } Focus CoreInstance C1 C2 { TestMode ExternalTest; }

}
In the above examples the TestMode statement (277) within the Focus statement is used to identify the configuration of the instances identified (276). Partitioning of the test modes need not be based upon structure. In that case no attribute is used with the Focus statement (Focus {}). The partitioning of the different modes may be based upon the types of test patterns being run (282), or on the different usage scenarios (278). Cores come with patterns that are reused in CTL. The CoreInstance statement allows for the identification of all the patterns that come with a core (214 on page 39). However, all patterns may not be used in the current test mode. Through the Focus block, the patterns of the core that are used are identifiable (289). Other portions of the CTL syntax yet to be introduced (namely the schedule portion of the PatternInformation, section 7.7.4 on page 122) actually bring the pattern into the set of tests that are executed in the test mode. The Focus block also allows for the identification of the original test modes in the CTL of the cores that are incorporated (290). While this information is not useful to the current CTL it provides a trace back to the original information that led to the creation of the current information.

6.4 CATEGORIES OF INFORMATION IN EVERY TEST-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 of CTL. In this sub-section the categorization of information within a test mode is described.

54

Information in CTL is written with reference to design entities such as Signals, ScanCells and CoreInstance-Signals of the design (see section 5.3 on page 31). Information about this design from the signals inwards is put in the Internal block of statements (232 on page 44). If one were to traverse the design inwards from the signals one would encounter scan chains and cores that act as informational black boxes for the Internal block of statements and the shadow of these black boxes cannot be represented. Thus CTL has two other blocks of statements to represent the information that cannot be represented in the Internal block.
1. The ScanInternal block of statements (235 on page 44) represents the design's test-information as it relates to the scan cells in the direction away from the inputs and outputs of the design. 2. The CoreInternal block of statements (225 on page 44) represents the design information in the shadow of the cores away from the scan chains and top level signals.

55

In the Internal block of statements information is assigned to signals defined in the Signals block. A similar mechanism is available in the ScanInternal block by using its equivalent to the Signals block called ScanStructures (256 on page 45) where ScanCells act as the signals. The equivalent mechanism for the core signals is CoreInternal where information is defined on 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 the environment that the design would be embedded in. By definition these constructs do not exist and the information is to be used as guidance for the logic that is to be created. Signals on the design being described typically are associated in some form of relationship depending upon the internal use in the design. For example, some inputs are differential signals where they are logical opposites of each other. Such pieces of information are categorized in the Relation block of statements (234 on page 44). CTL is created to represent a vast variety of design styles. It does this by using a flexible mechanism based upon sequences of operations typically written to the signals of the design. Such sequence information for each testmode is categorized in the PatternInformation block of statements (233 on page 44).

Chapter 7

CTL Syntax and Semantics: Test Mode Constructs in the Environment

Information in CTL is partitioned in blocks that represent test modes (Figure 17 on page 48). Each block contains information about the test aspects of the design that is categorized as shown in Figure 18 on page 54. There are numerous statements that make up the contents of a test mode. All statements need not be used for every test mode. In this chapter all the statements of the test mode are described.

7.1

DOMAINREFERENCES

All the information in a mode is not physically written in the CTL block of statements used to describe the mode in the Environment. These blocks outside the Environment are tied to the test mode through the DomainReferences block of statements (226 on page 44). Figure 19 shows an example of this concept for SignalGroups defined in CTL. Two signal groups are defined namely G1 and G2. G1 and G2 are also referred to as domain names. Named blocks need to be brought into the scope of the Environment with the DomainReferences statements. In this example, the information in CTL mode1 only has access to groups defined in G1 and information in CTL mode2 only has access to groups defined in G2.

57

By default all unnamed domains are available to the test mode as they act as global information. The named domains can be selectively included as shown in the syntax below.
294. 295. 296. 297. 298. 299. 300. 301. 302.
Environment (ENV_NAME) {

CTL (CTL_NAME) { (DomainReferences ( CORE_INST_NAME ) * { (UsePrefix DomainName;) (Timing (DOMAIN_NAME) +;) (MacroDefs (DOMAIN_NAME) +;) (Procedures (DOMAIN_NAME) +;) (ScanCelIGroups (DOMAIN_NAME ) + ;) (ScanStructures (DOMAIN_NAME) +;)

58

303. 304. 305. 306. 307.

(SignalGroups (DOMAIN_NAME)+;) (Variables (DOMAIN_NAME)+;)

})*

} }

With this syntax, scan-cell groups (301), the scan-cells (302), signal group definitions (303) and variables (304) described in Chapter 5 are linked to the test mode description in CTL. As described earlier a pointer to these entities in the DomainReferences makes the associated contents of these entities visible for reference in the test mode. Not introduced as yet the protocols of the test mode that are defined in named blocks of MacroDefs (299), Procedures (300) and Timing (298) of sequences can be linked to the test mode in DomainReferences. The discussion in section 5.2 on page 28 describes how the names of entities such as Signals, ScanCells, Macros and Procedures in the scope of the test mode are determined. By default an entity within the scope of the CTL testmode is identified by the concatenation of the CORE_INST_NAME (when appropriate) and the entity name separated by a :.
CORE_INST_NAME:EntityName

In most situations these names of entities are unique and inclusion of multiple domains in DomainReferences does not create any ambiguity. However, there is always the possibility of names clashing. For example, there could be two named SignalGroups defined with the same group name within it. To make the names unique the domain name can be added to the name to create a longer unique name:
CORE_INST_NAME:DOMAIN_NAME::EntityName

This mechanism is enabled with the UsePrefix (297) statement that optionally allows the DOMAIN_NAME to be used to remove any ambiguity. The following example describes the names of different entities in CTL.
Signals { I1 In; O1 Out; } SignalGroups {

59

All [0. .1]=I1+O1 ;

} CoreType C { Signals { I1 In; O1 Out; } SignalGroups Gl { All[0..1] = I1+O1; } SignalGroups G2 { All[0] = I1; } } Corelnstance C InstC1 InstC2; Environment { CTL model { DomainReferences InstC1 InstC2 { UsePrefix DomainName; SignalGroups G1 G2; }

// // // // // // // //
} }

Signals of design: I1, O1 Signal grps of design: All[0..1] InstC1 signalnames: InstC1:I1, InstC1:O1 InstC1 grpnames: InstC1:G1::All[0..1], InstC1:G2::All[0] InstC2 signalnames: InstC2:I1, InstC2:O1 InstC2 grpnames: InstC2:G1::All[0..1], InstC2:G2::All[0]

The Signals and SignalGroups at the top level are unnamed entities. As a result they are available for reference in all the test modes that are defined. Two instances of core-type C are instantiated in the design (InstC1, InstC2). The names of the signals of these two cores are unique because the name includes the core-instance name. Since Signals is an unnamed block of the CoreInstance it is available in the CTL mode being defined. However, SignalGroups of the cores are named blocks. They are specifically included if needed to construct the information of the test mode. In this example, the

60

signal groups of the cores are included with the UsePrefix statement to avoid conflicts in the group names. If both signal groups were not needed in the same mode then the domain name would not have been needed.

7.2 RELATION
Signals of a design could be related to each other in numerous ways. The relationships are definable in the block of statements called Relation.
308. 309. 310. 311. 312. 313. 314. 315. 316. 317. 318. 319. 320. 321. 322. 323. 324. 325. 326. 327. 328. 329. 330.

Environment (ENV_NAME) { CTL (CTL_NAME) { ( Relation { (Common sigref_expr;)* (Corresponding sigref_expr;)* (Differential sigref_expr (sigref_expr);)* (Equivalent sigref_expr (sigref_expr);)* (Independent sigref_expr (sigref_expr (Set));)* (InOutSet SIGNALNAME SIGNALNAME (SIGNALNAME);)* (MuxSet SIGNALNAME sigref_expr sigref_expr;)* (OneCold sigref_expr;)* (OneHot sigref_expr;)* (Port sigref_expr (INTEGER);)* (ZeroOneCold sigref_expr;)* (ZeroOneHot sigref_expr;)* }) } }

A commonly known example of a relationship between two signals is the differential relationship where two signals have opposite values to each other at all times. This kind of relation is specified in the Relation block of statements in CTL using the Differential statement (313). The following example code shows different uses of the differential statement assuming that signals a, b, c and d, are defined in the Signals/SignalGroups block of statements.

61

Environment { CTL { Relation { Differential a b; // (i) Differential a+c; // (ii) Differential a+c b+d; // (iii) } } } The first statement of the example (i), describes the situation that signal a and signal b are differential and have opposite values to each other. The second statement of the example (ii), describes the situation that signals a and c are differential signals of the design. However, the signals they have the opposite value relationship with are not defined by this statement. The third statement (iii), describes all four signals a, b, c, d to be differential with a one-to-one correspondence between the signals defined in the two sets. That is, a is defined to have opposite values to b and c is defined to have opposite values to d. Since multiple differential statements are allowed, the information across all the statements with respect to a single signal is expected to be consistent. As the syntax shows there can be a number of relationships defined for signals of the design. Equivalent (315, 316) is the opposite of differential where two signals have exactly the same values and its syntax follows the format of the differential statement. OneHot (324) describes the case where a set of signals ( sigref_expr ) can/will only have one signal at a logic-1 at any given time and at least one signal in the set is at a logic-1. ZeroOneHot (327) allows for the case where all the signals could be at a logic-0, or can be OneHot. OneCold (323) and ZeroOneCold (326) are the corresponding statements to the OneHot and ZeroOneHot statements for a logic-0. Common, Corresponding and Independent refer to relationships between signals as they pertain to the logic external to the design. Common (311) is used to define the condition that the two signals are to originate from a common source external to the design. All the signals mentioned in the sigref_expr of the statement have this relationship. Independent (317, 318) is the opposite of common, where the signals identified in the statement are to be kept separate. To prevent an explosion of descriptions using this statement, there are three different ways of defining independence between signals. Independent sigref_expr; is used to define the independence between signals where all the signal that are part of sigref_expr need to be kept separate. Independent sigref_expr sigref_expr; is used to define two

62

groups of signals with equal number of signals in each group and the independence is defined as a one-to-one correspondence between the signals of each group in the order in which they appear. Independent sigref_expr sigref_expr Set; defines the independence between all signals of the first set of signals with all signals in the second set. Corresponding (312) defines the relationship that all signals defined in the statement are connected external to the design to constructs with similar characteristics. Meaning if one of the signals is connected to an input then all the signals in the statement should be connected to an input. Though it may be possible to connect the signals to a scan element of the netlist external to the design.

To highlight the use of the Independent statement in CTL, consider the design that is to be embedded in a larger design as shown in Figure 20. The design being reused has two scan-chains (si1-so1, si2-so2). If no constraints are described on these signals in the CTL for the design being reused, then the integrated design could combine the two scan chains of the original design into a single scan chain as shown in the figure. However, let us say that the two scan chains need to be kept separate for what ever reason and putting the two chains together will not work. Then the constraints can be described in CTL using the Independent statement in the Relation block. Signals {

63

si1 In; si2 In; so1 Out; so2 Out;

} Evironment { CTL { Relation { Independent si1+si2 so1+so2 Set; } } }

The above example syntax describes the constraint that any scan-in signal of the design cannot be connected to any scan-out signal of the design thus, if the next level of integration stays true to the description, the two scan chains would be kept separate. Some signals have more of a structural relationship between them. For example, three signals of the design may be part of an unimplemented bidirectional port. Or three signals could be part of a multiplexor relationship. For both these constructs there exist corresponding relationship statements that allow for the definition of the three components of the relation. Thus, InOutSet (319) allows for the definition of the enable signal, the output signal and an optional input signal. A MuxSet (321, 322) statement allows for the definition of the enable signal and the two sets (in case of buses) of inputs that are connected to the zero selection input of the mux and the one selection input of the mux. Ports of memories group signals in a very unique manner that is identified by the Port statement (325). In addition, the port can be identified with a number. It should be noted that there exists a relationship between signals that are part of a scan chain that is not covered by the Relation block of statements. This relationship is available in the scan-chain definitions in the ScanStructures and hence a second mechanism to describe the same is not created.

7.3 INTERNAL
This block allows for the description of the details of the design from the signals inwards. A single Internal block exists in a CTL test mode definition. 331. Environment (ENV_NAME) {

64

332. 333. 334. 335. 336. 337. 338. 339.

CTL (CTL_NAME) { Internal { sigref_expr { // Information about a signals } } }

As described earlier, the Signals and SignalGroups are defined in their corresponding blocks of statements and available in the test modes for reference. The scope of these entities is defined by the DomainReferences. For each signal or signal group defined within the scope of the test mode, a signal or group can only appear once in the internal block. The following example shows the flexibility of the syntax.
Signals { A In; B In; C Out; D Out;

} SignalGroups { inputs [0..1] = A+B; outputs[0..1] = C+D; allSigs[0..3] = inputs[0..1]+outputs[0..1]; } Environment { CTL correct1 { A { // info on A } B { // info on B } inputs[0..1] { // info on A and B } C+D { // info on C and D } outputs[0..1] { // info on C and D } allSigs[0..3] { // info on A, B, C, D } } CTL error1 { A { // info on A } A+B { // info on A and B } C { // info on C } C { // info on C } } CTL error2 { inputs[0..1]+C { // info on A, B, C }

65

inputs[0..1] { // info on A, B }
} }

In the example syntax three CTL test modes are defined namely, correct1, error1 and error2. correct1 shows the correct references made to the signals and signal groups to define information while error1and error2 show incorrect references to the signals and signal groups. In correct1, information is provided for signal A in three locations, since A is part of inputs[0..1] and allSigs[0..3]. The information about A when it is defined on the signal reference of A should not conflict with the information about A in the groups which in this example are inputs[0..1] and allSigs[0..3]. Information is allowed to conflict across the group names inputs[0..1] and allSigs[0..3], but both are to be consistent with information on A. In error1, information is provided on A in two locations. Since A+B is a group created on the fly, it is not a named entity and the signals in it are treated as the signals themselves. This is not allowed in CTL. Similarly, C appears twice in error1, and is also incorrect CTL. In error2, information is provided twice for the named group inputs[0..1]. This is an error in CTL. Now let us understand what kind of information can be described in the Internal block for these signals and signal groups.

7.3.1 ElectricalProperty
The first version of CTL that is being developed is not applicable to analog designs. However, the signals and their electrical characteristics need to be identified to partition the signals.
340. 341. 342. 343. 344. 345.

Environment (ENV_NAME) { CTL (CTL_NAME) { Internal { (sigref_expr { (ElectricalProperty <Digital | Analog Ground> (ELECTRICAL_PROPERTY_ID);) 346.

Power

66

347. 348. 349. 350.

}) + }

} }

Signals can be identified as digital, analog, power or ground signals with the option of providing a user defined identifier to qualify the signals electrical property. If this statement is not used on a signal in the Internal block the default of Digital is to be assumed.

7.3.2 DataType
Signals in a mode behave in a certain way and/or may have some standard use within the test mode. The behavior of signals is defined using the DataType statement. The syntax for DataType was used as an example for explaining how to read CTL syntax in the beginning of Chapter 5 on page 25. It is reiterated below.
351. 352. 353. 354. 355. 356. 357. 358. 359. 360. 361. 362. 363. 364. 365. 366. 367. 368. 369. 370. 371. 372. 373.

Environment { CTL (CTL_NAME) { Internal { (sigref_expr { (DataType ( data_type_enum )+;) (DataType ( data_type_enum )+ { (ActiveState <ForceUp | ForceDown | ForceOff|ForceValid|ExpectLow | ExpectHigh | ExpectOff | ExpectValid> (Weak);) (DataRateForProtocol <Average|Maximum> INTEGER ;) (AssumedInitialState <ForceDown |ForceUp| ForceOff | ForceValid |ExpectLow | ExpectHigh |ExpectOff|ExpectValid> (Weak);) (ScanDataType (<AddressGenerator | Boundary | ByPass | Counter | DataGenerator | Instruction | Internal | ResponseCompactor | User USER_DEFINED>) +;) (ValueRange INTEGER INTEGER;)* })*

67

374. 375. 376. 377. 378. 379. 380. 381. 382. 383. 384. 385. 386. 387. 388. 389. 390. 391. 392. 393. 394. 395. 396. 397. 398. 399. 400. 401.

}>+ }}} data_type_enum = <Asynchronous | CoreSelect | ClockEnable | Constant | Functional | In | InOut | Indicator | InOutControl | Oscillator | Out | OutDisable | OutEnable | MasterClock | MemoryAddress | MemoryData | MemoryRead | MemoryWrite | Programming | Regular | Reset | ScanDataIn | ScanDataOut | ScanEnable | ScanMasterClock | ScanSlaveClock | SlaveClock | Synchronous | TestAlgorithm | TestClock | TestControl | TestData | TestDone | TestFail | Testlnterrupt | TestInvalid | TestMode | TestPortSelect | TestRun | TestWrapperControl | Unused | UnusedDuringTest | User USER_DEFINED>

Though this statement signals can be assigned multiple data types.

7.3.2.1

Data Change Information in Data Type

The temporal view of a test mode can be sub-categorized into phases as shown in Figure 21.

68

A test mode is composed of three sections. The first section (establish test mode) represents the initialization of the design to get into the test mode. The second section is the state in which activities occur that needs the particular configuration of the design. The third section (terminate test mode) represents the process of getting out of the test mode. The region represented by , covers all three sections of the test mode. Data on the signals may be Unused or Constant across this region (399, 377). The region represented by covers the section of the test mode where the bulk of the activity is performed. A signal may be unused (UnusedDuringTest, 400), constant (TestMode, 397), changing few times (TestControl, 394) or changing frequently (TestData, 395) during this section.

7.3.2.2

Control Signals in Data Type

There are numerous control signals in the design that need to be identified for the different needs in test. Control signals can be Synchronous (392) or Asynchronous (376), of type Reset, to cover set, reset and clear type of signals (387). There are numerous clock control signals based upon the use as a functional clock or as a scan clock. The clocks are highlighted for some memory elements (flip-flops) in Figure 22.

69

Four flip-flop examples are shown in Figure 22. The first two figures are non scan flip-flops and the second two are scan flip-flops. The first and third flipflops are edge triggered while the others are level sensitive. The labeling on the respective clocks of the flip-flops is shown in the figure. The clocks used to capture functional values are called MasterClock (383) and SlaveClock (392) and the scan counterparts are prefixed with the word Scan to be ScanMasterClock and ScanSlaveClock (390, 391).

70

Other control signals in designs include signals that control the direction of bi-directional pins (InOutControl, 380), the enabling signals of scan chains (ScanEnable, 389), or enabling and disabling signals for outputs of the design (OutEnable, OutDisable, 383, 382).

7.3.2.3

Scan Related Information in Data Type

Scan information has its own set of data types. The clocks and the enable signal used in scan have been introduced under the test control signals. In addition to ScanMasterClock, ScanSlaveClock and ScanEnable, scan chains have the scan-in (ScanDataln) and scan-out (ScanDataOut) signals (388 to 391).

7.3.2.4

Specialized Information in Data Type

Signals fall under two basic categories, those that are part of the function of the design and those that are part of test. The functional signals are identified by the Functional (378) keyword in DataType and the test signals are identified by the associated Test* (TestMode, TestControl, TestData (397, 394, 395)) keyword depending on the activity on the signal. Typically, all signals of the design are both Functional and used in test (Test*). However, in some few cases the signals are dedicated test signals that were not part of the function. While most keywords can be used with the basic Functional or TestControl or TestData keywords one would only expect to see the specialty signals such as CoreSelect, Indicator, TestDone, TestFail, TestInterrupt, TestInvalid, TestWrapperControl or TestRun only used to further describe the capabilities of the TestControl or TestData signal. The same is true for the Scan* keywords that are special test signals. The names of these keywords are self explanatory to a large extent.

7.3.2.5 Memory (RAM/ROM) Information in Data Type

Memories in the design have always been treated differently in design and test methodologies. The special signals of the memory are identifiable with DataType keywords. Address signals are identified as MemoryAddress, data signals are identified as MemoryData, read signals as MemoryRead, write signals as MemoryWrite (384, 385).

7.3.2.6

Data Type Related Information

When a signal behaves with the characteristics described by DataType, some more information can be provided that is associated with that characteristic. For example, input signals such as test-mode signals and enable signals are associated with a logic value when used. This logic value called the

71

ActiveState specifies the state of the signal for the intended function as meant by the DataType of the signal (356 to 359). The ActiveState of a scan enable signal is the state in which the scan operation is possible. Through keywords the state of an input signal is specified to be a logic-0, logic-1, a valid logic value (0/1) or a high impedance state. Output signals are associated with equivalent expect states. The drive strength of the signal by default is assumed to be strong. Weak values can be identified in the statement explicitly as Weak. Test pattern generators use the stable state of the clocks for determining the controllability and observability of the memory elements. This state is typically the assumed state of the clock at the start of every test protocol. The assumed state is specified through the AssumedInitialState statement to be either a logic-0, logic-1, valid logic state or high impedance (362 to 365). The DataRateForProtocol of the signals is specifiable though keywords that allow for the specification of the number of non-scan drive and compare events that occur per protocol (360, 361). It is recognized that many different protocols may be executed in a test mode. This statement allows for the specification of an average value or maximum value for the data rate. Scan-ins and scan-outs feed scan chains that may have some characteristics. The scan chain characteristics are identifiable through a ScanDataType statement (366 to 371). Through this a scan input/output can be identified to be connected to a Boundary scan chain, Internal scan chain, a scan chain that Bypasses the design, a scan chain that scans a Counter, a DataGenerator (LFSR), and AddressGenerator (LFSR), a ResponseCompactor (MISR), or an Instruction register. Some DataTypes like addresses on memories have a valid range of values. This is specifiable through the ValueRange statement that allows for the specification of a minimum and maximum value as an integer for the signals (372). The relationship of the values to signals on which it is defined is sensitive to the MSB-LSB positioning of the signals in the group.

7.3.3 InputProperty and OutputProperty

Signals of the design exhibit certain properties that are described with the InputProperty and OutputProperty statement. A clock that feeds edgetriggered memory-elements would be identified with an Edge property. While a clock that feeds level-sensitive memory-elements has a Window property. Edge and Window are used for describing strobe requirements on

72

output signals. The syntax for the different properties of signals is given below.
402. 403. 404. 405. 406. 407. 408. 409. 410. 411. 412. 413. 414. 415. 416. 417. 418. 419. 420. 421. 422. 423. 424. 425. 426. 427. 428. 429.

Environment (ENV_NAME) { CTL (CTL_NAME) { Internal { (sigref_expr { (InputProperty (<Edge | GlitchFree PullDown | PullUp Relation relation_enum ScanStable | ScanUnstable SynchFF | SynchLatch Transitions INTEGER Window | User USER_DEFINED>)+;) (OutputProperty (<Edge | PullDown PullUp | Relation relation_enum ScanStable | ScanUnstable SynchFF | SynchLatch ThreeState | TwoState0Z TwoState1Z Transition INTEGER Window | User USER_DEFINED> )+;) }) + } } } relation_enum = <Common | Corresponding | Differential | Equivalent | Independent | InOutSet | MuxSet | OneCold | OneHot | ZeroOneHot | ZeroOneCold | User USER_DEFINED>

Using the above syntax signals or signal-groups can be with multiple properties. GlitchFree is used to describe the need for glitch free data for an input signals (406). ScanStable describes the stability of the signal during the scan operation (409, 415). If defined as an input property it describes the need for a stable value on signals during scan operations that occur external to the design. As an output property it describes the characteristics of the values appearing on the signals during the scan operation of the design. PullUp and PullDown are used to describe the existence of such a design

73

entity on the associated signals (407, 413, 414). A very common design methodology on the scan path is to use synchronizing flip-flops or latches to resolve timing problems between different clock domains. SynchFF and SynchLatch define the existence of the associated design entity on the signal it is connected to (410, 416). Through the Transition keyword an integer can be defined to describe the number of critical transitions per test pattern unit that are in the test data or the design is capable of providing at an output signal if used in the external test mode (411, 419). Tri-state signals or open collector constructs are described through keywords that describe the type of values possible on the signal. ThreeState0Z, TwoState0Z and TwoState1Z describe these special capabilities of the output signals (417, 418). A signal can be part of numerous relationships with other signals as described by the Relation block of statements. Though the Relation in the Input/Output property statement the relations that a signal is involved in can be enumerated (408, 414).

7.3.4 DriveRequirements and StrobeRequirements

Given any design and its associated test data there exists certain timing relationships between the signals that need to be highlighted. CTL allows for describing the flexibilities and rigidness of timing requirements through the DriveRequirements and StrobeRequirements statements (434 to 441). Timing information of a signal can be separated into two categories: Timing relationships of events on signals that are relative to the period (448 to 452). Timing relationships of events on signals relative to events on another reference signal (453 to 461). When the timing of the signal relates to the period one can specify the ability to move or change the timing of the edge within the period. When related to a reference edge of another signal, timing relationships describe the needs for events to occur before or after events on the reference signal. The syntax is described below.
430. 431. 432. 433. 434.
Environment (ENV_NAME) { CTL (CTL_NAME) { Internal { (sigref_expr { (DriveRequirements

74

435. 436. 437. 438. 439. 440. 441. 442. 443. 444. 445. 446. 447. 448. 449. 450. 451. 452. 453. 454. 455. 456. 457. 458. 459. 460. 461. 462.

(TimingNonSensitive;) (TimingSensitive { })
}) (StrobeRequirements { (TimingNonSensitive;) (TimingSensitive { }) }) }> +

} } } // TimingSensitive Statements for (436 & 440) TimingSensitive { (Period <Min|Max> time_expr;)* (Pulse <High|Low> <Min|Max> time_expr;)* (Precision time_expr;) (EarliestTime time_expr;) (LatestTime time_expr;) (Reference sigref_expr { (SelfEdge <Leading | Trailing | LeadingTrailing> INTEGER;) (ReferenceEdge <Leading | Trailing | LeadingTrailing> INTEGER;) (Precision time_expr;) (Setup time_expr;) (Hold time_expr;)
}>*

The syntax for timing exists in the Environment-CTL-Internal block of statements on signals and signal groups identified by the sigref_expr. Due to formatting reasons the details of the TimingSensitive block are given outside this hierarchy of statements (447 to 462). A signal can be identified to have no timing restrictions by using the TimingNonSensitive statement (435, 439). In such cases it is assumed that the events of the signal can be moved around anywhere within the period that is described by the waveforms used in the test mode. However, if any restrictions exist for the timing they are to be described under the TimingSensitive statements (436, 440).

75

Consider the example of Figure 23 to understand the timing relationships that can be described. There are two signals Clk and Enable. Clk is a clock that is stable at a logic-1 with a single negative pulse described in the period. A pulse is comprised of a LeadingEdge and a TrailingEdge. The leading edge takes the clock out of the stable state and the trailing edge puts the clock back into the stable state. Let us say that the clock period used by the tests in the current test-mode is 100ns. However, we would also like to convey the information that the period can be varied between 80ns to 120ns and the test data would still be valid for the design. Let us assume that the Enable signal has two critical timing relationships with the leading edge and the trailing edge of Clk. The Enable signal has to change state at least 5ns after the leading edge of Clk and at least 3ns before the trailing edge of Clk.

While the test data and the sequences that operate these signals would already satisfy the criteria, the flexibility of the system can be described in the following statements for the example. Environment { CTL { Internal { Clk { DriveRequirements { Period Min 80ns; Period Max 120ns; } }

76

Enable { DriveRequirements { Reference Clk { ReferenceEdge Leading 1; Hold 5ns; } Reference Clk { ReferenceEdge Trailing 1; Setup 3ns; } } }
} } }

The example uses the Period statement (448) to describe the flexibility of changing the period of the signal that is used in the waveforms for the test mode. Through this statement a minimum and maximum period is specifiable as a time_expr which allows for the specification of time within single quotes. 5ns, 5.0ns, 15.0ns/3 or 1/200MHz all convey the information needed for the example and are legal in CTL. The example also shows the time relationship between the Enable signal and the Clk signal with the Clk as the reference edge. Two relationships are defined. The ReferenceEdge statement (456, 457) allows for the identification of the edge number of type Leading, Trailing or LeadingTrailing (to include both types) relative to the beginning of the period. In this example all edges of the Enable signals waveform have this restriction. Hence the SelfEdge statement (454, 455) which allows for the identification of the Enable signals edge among the multiple possible edges was not needed. The Setup statement (459) defines the latest possible time the Enable signals events can occur before the reference edge of the Clk. A negative number would change the event to be after the reference edge. The Hold statement (460) is used to define the earliest the Enable signal can change after the reference edge of the Clk in this example. A negative number is used to define the change to occur before the reference edge. Though the example does not cover the use of the statements Precision and Pulse, CTL allows for the definition of the accuracy of the edges and the pulse width (or duty cycle) restrictions through these statements (450, 458, 449).

77

7.3.5 IsConnected
Configurations of the design may enable certain connections between design entities (signals, scan cells and cores) recognized by CTL. In the Internal block the connections are between the top-level signals of the design and all possible entities that are definable in CTL. The intent of this statement is to define the end points of the connection that is established in the test mode. Thus one end of the connection is the signal (or set of signals) identified by the sigref_expr (466), and the other end of the connection is either a single (or multiple of a single type) Signal, a state element like a ScanCell, or CoreInstance-Signal (471 to 474). If the connection is established between sets of entities the connection is assumed to be a bus, where the two sets of end points have a one-to-one correspondence between the individual signals of the sets. The syntax for the connection definition part of the IsConnected statement is given below.
463. 464. 465. 466. 467. 468. 469. 470. 471. 472. 473. 474. 475. 476. 477. 478. 479. 480. 481. 482. 483.

Environment (ENV_NAME) { CTL (CTL_NAME) { Internal { (sigref_expr { // one-end of connection (IsConnected <In|Out> (Direct|Transitive>) { // the other-end of the connection (Signal (sigref_expr);) (CoreSignal (sigref_expr);) (StateElement <Scan|NonScan> (cellref_expr);)

// Statements to describe aspects // of the connection not-shown

})* // incomplete syntax shown }> +
} } }

Incomplete syntax for the IsConnected statement is shown to highlight aspects of the connection. Syntax to describe attributes of the connection will

78

be introduced later in this sub-section. It is important to remember that the DataType of a signal is assumed to be consistent for the two ends of the connection. That is if the connection is described for a data input of the design to an internal scan cell, then it should be assumed that the connection goes to the data input of the state element. Similarly, if the connection is described for a clock input of the design to an internal scan cell, then it should be assumed that the connection goes to the clock input of the state element. The connection by default is assumed to be of type Direct (468), meaning that a logic value at one end of the connection directly corresponds to a logic value at the other end of the connection. In addition to the ability to connect to the design entities described in other CTL constructs, the connection can be made to a non-scan state element with a name optionally identified in the cellref_expr, but not part of any scan cells identified in the ScanStructures statements. It is also recognized that scan-ins and scan-outs have connections to scan cells and the connection is already defined in the ScanStructures. To avoid redundant specifications of this connection, if the other-end of the connection is not specified a scan connection is to be assumed and found in the ScanStructures active in the test mode. The In and Out keywords on the connection (468) are used to correspond to the direction of the signals defined in the sigref_expr on which the IsConnected is being defined. While the connection statement is to be mostly used to describe direct connections, there is the possibility of describing indirect connections through logic with no logic value correspondence between the end points. Transitive is used to describe this characteristic (468). The syntax for IsConnected allows for the specification of multiple connections for the signal ( sigref_expr , 466) that is being described. Each connection definition is independent of the other. Meaning both connections could be active at the same time depending upon the enabling characteristic of the connections that is yet to be discussed (491 to 498). A number of things can be associated with a connection. The connection that is a logic-value link between two points may be subject to some transformation. The connection may have some enabling conditions. When one uses the connection the logic-value that is internal to the design would either need to be controlled or observed. The mechanism to access the value would need to be described. And last but not least, if the connection is to a state element the clocking and the effect on the value in the state element is of interest in some applications of CTL. All this can be described within the IsConnected block of statements using the following syntax.

79

484. 485. 486. 487. 488. 489. 490. 491. 492. 493. 494. 495. 496. 497. 498. 499. 500. 501. 502. 503. 504. 505. 506. 507. 508. 509. 510. 511. 512.

IsConnected <In|Out> (<Direct|Transitive>) { // statements describing the connection (Transform { (WaveformTable (WFT_NAME) +;) (WFCMap FROM_WFC->TO_WFC; ) * (Invert;) }) (IsEnabledBy Logic logic_expr { (LOGICSIGNAME { Type <Signal | StateElement Scan | StateElement NonScan | CoreSignal>; Name <SIGNALNAME | CELLNAME | SYMBOLNAME>; }) + }>* (IsEnabledBy <Macro|Procedure> NAME;)* (TestAccess (<Control|Observe | User USER_DEFINED>)+ <Macro|Procedure> NAME;)* (<LaunchClock | CaptureClock> SIGNALNAME { (<LeadingEdge | LevelSensitive | TrailingEdge>;) (<Direct | Transitive>;) (StateAfterClock <ExpectLow | ExpectHigh | ExpectUnknown | ExpectValid | Hold | Invert | ShiftState | Connection | User USER_DEFINED>;)
})*

The logic value between two points of a connection could be transformed. The most common transformation is an inversion caused as a result of an odd number of inversions in the path of the connection. This characteristic is defined through the Transform-Invert statement (489). However, this is a special case of the possible transformations. In general any waveform (logic values associated with time) can be transformed into another waveform. While the WaveformTable and waveforms are yet to be introduced in the syntax, let us assume that there exists a location called WaveformTable where all the waveforms associated with a signal are given names called waveform characters. The transform statement (486 to 490) allows for the

80

ability to define a waveform character mapping through WFCMap between a waveform (waveform character) on the signal at one end of the connection to a waveform (waveform character) on the other signal (488). Most connections are not direct. The two ends of the connection are typically connected to each other through some simple combinational logic. For the connection to be enabled some signals need to be primed to some logic value such that the path of the connection is enabled. This condition is specifiable through the IsEnabledBy statement (491 to 497). The enabling signals could be any of the recognized design constructs in CTL. The type and name is linked to a symbolic name (LOGICSIGNAME) in the IsEnabledBy block of statements. Then through a logic function (that uses Verilog syntax for binary operations) the enabling condition is specified with LOGICSIGNAMES. The condition is specified using positive logic. An example of the syntax of the logic expression is Where x, and y are symbols that are linked to either signal names, names of state elements or core signals. For simplicity, let us say that symbols x and y are tied to signal names e and b correspondingly (e and b are defined in the Signals block of statements). The logic expression used in the example would express the connection to be enabled when signal b is at a logic-1 and signal e is at a logic-0. This example can be seen in syntax form later on in this sub-section. If the enabling condition requires a non-scan element then the cell name used is a symbolic name of the entity that is not defined anywhere else in the CTL syntax. If the enabling condition requires a sequential operation to occur for the connection to be established, then the enabling sequence is specifiable through a Macro or Procedure (498) concepts that are to be introduced later in the syntax. If one looks at the IsEnabledBy syntax carefully it should be noted that multiple enabling conditions can be specified for a connection. When multiple IsEnabledBy statements are provided within the same IsConnected statement the order in which they are specified denotes the preference of the enabling conditions. That is the enabling condition that is described first is the preferred condition over the ones that follow. The multiple enabling statements need not be exclusive of each other. For example the first enabling condition could be the single preferred condition and the second one could describe all possible enabling conditions that includes the preferred enabling condition. The enabling condition makes the state at one end of the connection available at the other end of the connection. The portion of the connection that is inside

81

the design being described in CTL needs to be accessible if the connection is to be of any use. The test access is usually a sequential operation and is definable using a Macro or Procedure (the mechanism for defining sequences). Though the TestAccess sequence the internal value of the connection can be accessed (499 to 501 on page 79). The sequence may need to perform multiple types of operations, which can be highlighted in the syntax. The Control and Observe operation is the mechanism to get a value into and out of the end point of the connection and is the typical keyword that would be used to encompass all the smaller tasks needed to achieve access to the state of the memory element. Observe test access sequence where appropriate could mean the capture of the value from the connection into the memory element (Capture), the transfer of the value from the memory element to a scan path (Transfer), and shift operation to get the observed value to an observation point (ShiftOut). Control test access sequence where appropriate could mean the logicvalue could initially be obtained through a shift operation (ShiftIn), then an update operation may be required (Update) to set values in the memory element off the shift path. Multiple test access sequences can be written to describe the individual operations required to Control and Observe the logic value of the connection. Each sequence could be identified with the individual keyword to describe the operation. However, the relative sequencing between these operations is only achievable if a Control or Observe sequence is written that calls out the needed operations in the correct order. Before moving on to understand the last two syntax statements of the IsConnected block let us create an example that shows a connection.

82

Consider the example design of Figure 24. The connections to be described in CTL are highlighted with bold lines. Three connections need to be described.

1. Signal a is connected to a scan cell m when signal e is at a logic-0 and signal b is at a logic-1. 2. Signal a is connected to a scan cell n when signal e is at a logic-0. 3. Signal p is connected to scan cell m with no enabling condition.
The example design also shows the scan path in dotted lines for the scan chain that contains the scan cells m and n. This example will remain focused on the task of showing the highlighted connections. To set the stage for the complete CTL needed for the example, the signals of the design are defined in the Signals block of statements and the scan cells m and n are defined in the ScanStructures block of statements. Now the connections can be described. Environment { CTL { Internal { a {

83

// Connection 1. IsConnected In { StateElement Scan m; IsEnabledBy Logic ~x&y { x { Type Signal; Name y { Type Signal; Name } TestAccess Observe Macro } // Connection 2. IsConnected In { StateElement Scan n; IsEnabledBy Logic ~u { u { Type Signal; Name

e;} b;} scanob;

e;}

} TestAccess Observe Macro scanob; } } p { // Connection 3. IsConnected Out { StateElement Scan m; } TestAccess Control Macro scanco; } } } }

For the above example to be complete, scanob and scanco needs to be defined as a Macro. Since the associated syntax to describe a Macro has not been introduced it is ignored in this example. The example syntax follows the enumerated connections that are to be described. Signal a, has two IsConnected statements associated with it to describe the two connections. Since a is an input, the IsConnected statements have a keyword In on the statement. As a result of the connection a Direct path is established between the two ends of the connection. Since this is the default of the IsConnected statement syntax, the keyword is not used. The enabling condition is specified through a logic expression of symbols (x, y, u) that are tied to the signals in this example. The ability to

84

capture and observe the value at signal a in the scan cell m and/or n is described by the sequence of events (capture clock and scan operation) in the Macro scanob. The third connection is of type Out as signal p receives values from the internal scan cell. As a result the test access needs to describe the procedure to get a value into the scan cell m (Macro scanco). Last but not least the IsConnected block of statements allows for the specification of clocks with the state element internal to the design using the two statements LaunchClock and CaptureClock (502 to 511 on page 79). LaunchClock is used to describe clocks that control the state element internal to the design for the connection of type Out and CaptureClock is used to describe clocks that control the state element internal to the design for the connection of type In. This clock may be directly or indirectly connected to the state element. Connections that exist as a result of no gating between the clock (identified in the SIGNAME, 502) and the state elements of the connection are identifiable with the keyword Direct (505). If the clock is connected to the state element through some gating logic the connection is defined to be Transitive (505). The enabling condition for the clock signals is covered by the enabling conditions of the connection. All the clocks that effect the state of the memory element at the end of the connection can be described to be LevelSensitive, LeadingEdge or TrailingEdge depending on the sensitivity of the memory element to the clock waveform (503, 504). When the condition of the clock is met, the state of the memory element is subject to change. The next state is specifiable using the syntax of the StateAfterClock statement (506 to 510). The next state of the memory element could either be
1. a logic-0 (ExpectLow). 2. a logic-1 (ExpectHigh). 3. a logic-X (ExpectUnknown). 4. either a logic-0 or a logic-1 (ExpectValid). 5. the previous state of the memory element (Hold). 6. the opposite state of the previous state of the memory element (Invert). 7. a value from the scan cell that precedes the current memory element in a scan chain (ShiftState). 8. a value from the connection that is established (Connection).

85

9. a user defined entity that is not covered by existing keywords (User

USER_DEFINED).

7.3.6 LaunchClock and CaptureClock

Just like the LaunchClock and CaptureClock statements on a connection as described in the syntax of IsConnected (Section 7.3.5), CTL provides the ability to describe the same characteristic without the description of a connection. Certain portions of the LaunchClock and CaptureClock statements on the connection are not appropriate without the existence of the connection and are hence not available in the syntax of the LaunchClock and CaptureClock statements described here.
513. 514. 515. 516. 517. 518. 519. 520. 521. 522. 523. 524.

Environment (ENV_NAME) { CTL (CTL_NAME) { Internal {

(sigref_expr {
(<LaunchClock | CaptureClock> SIGNAME { (<LeadingEdge | TrailingEdge | LevelSensitive>)+; }>* }) +

} } }

Using this syntax the sensitivity of signals to clocks on the design can be described. For the example of Figure 24 let us assume that m and n are rising edge flip-flops and the clock cs stable state is logic-0. If the example were to ignore the direct connections between a and m/n then the following CTL would describe this condition. Environment {
CTL {

Internal {
a {

CaptureClock c { LeadingEdge; }
} } }

86

Similar to the syntax of the IsConnected-LaunchClock-CaptureClock the LaunchClock statement allows for the specification of clocks that control the state element internal to the design that is affecting the state on the signal that this statement is attached. The CaptureCIock statement allows for the specification of clocks on the state elements that have a data dependency on the signal on which this statement is attached.

7.3.7 Wrapper
One of CTLs objectives is to describe the IEEE 1500 boundary scan chain and the associated architecture. The Wrapper statement in the Internal block of statements allows for the description of the wrapper cells or standardized pin names. Though the syntax is biased towards the IEEE 1500 standard any standardized implementation of a wrapper could make use of this statement by defining their own keywords to be used.
525. Environment (ENV_NAME) { 526. CTL (CTL_NAME) { 527. Internal { (sigref_expr { 528. 529. (Wrapper 530. <IEEE1500 | None | User USER_DEFINED> 531. (<CellID cell_enum | 532. PinID USER_DEFINED>);) 533. }) + 534. } 535. } 536. } 537. cell_enum = 538. <WC_S<D|S>#(_C<I|O|B><I|O|U>)(_U<D|S>)(_S) 539. | User USER_DEFINED>

If this statement is missing on a signal no (None) wrapper cell exists internal to the signal (530). The syntax allows for the description of a wrapper name (530), information about a wrapper-cell internal to the design linked to the signal on which this statement exists (CellID, 531) or the ability to label the signal with as a special name (PinID, 532). Though the syntax allows for the ability to say Wrapper-None and also provide a CellID or PinID with it, this

87

combination is meaningless and should not be used. CellIDs are provided through a combination of characters and numbers to define the characteristics of the wrapper cell. PinIDs are special names defined by the standard document that is requiring the use of this statement. In IEEE 1500s case the special names of signals associated with the wrapper function are defined in the IEEE 1500 document. The cell names are created as a concatenation of characters and numbers to describe various capabilities and structure of the cell (537). All wrapper cells using CTLs syntax start with WC. A _S with a D or S character follows the initial WC to describe the shift path. D specifies that the cell is dedicated to the wrapper operation and a S specifies that the wrapper cell is shared with the functional operation of the design. The D or S character is then followed by a decimal number that specifies the number of storage elements of the wrapper-cell that is part of the shift path. The next field describes the capture mechanism of the wrapper cell. This field is identified with a _C. The first character following the _C describes the origin of the value to be captured. It could be the functional input of the wrapper cell (I), the functional output of the wrapper cell (O) or selectively both (B). The next character specifies the capture site of the wrapper cell. This could be I for the scan element close to the scan-in of the wrapper cell, O for the scan element closest to the scan-out of the wrapper cell and U for the update storage element of the wrapper cell. If the capture description is not provided for a wrapper cell, _CII should be assumed. Then comes the description of the update portion of the cell in the name beginning with a _U. It is qualified (after the _U) with the D or S character to indicate if it is dedicated to the wrapper operation or shared with the functional operation of the design. The last few characters allowed in the cell name are _S to indicate if the cell has a safe mode of operation. In the safe mode, a non-destructive logic-value is presented to the circuitry connected to the output of the cell. Two implementations of wrapper cells are shown in Figure 25 to explain the concept of a wrapper cell and the naming convention of the cells. The example is built on the example used for describing the IsConnected statement (Figure 24). The connections highlighted in the IsConnected example now seen as connections to scan wrapper cells with the following types. WC_SD1: Is a dedicated wrapper cell with one storage-element in the wrapper scan chain.

88

WC_SD1_UD_S: Is a single storage element that is part of a scan chain that is dedicated to the wrapper scan chain. That is, it was not part of the original function of the design. The cell has a dedicated storage element at the output of the shift-path. It gets it values from the scan-flip-flop through an update operation. The cell also drives a safe value to the logic driven by the cell.

It is possible to encounter designs where the IsConnected statement exists but the Wrapper-CellID statement does not apply. However, it should never be the case that there is no IsConnected statement and a Wrapper statement exists defining a CellID. The Wrapper-CellID statement adds to the IsConnected information but cannot be used as a replacement of the IsConnected information.

89

7.3.8 IsDiabledBy and DisableState

These statements allow for the specification of the disabling conditions of a signal. The disabling condition is achievable through a logic expression of multiple entities (signals, state elements) or through a sequence of operations. The syntax and semantics are similar to previously described syntax in the IsEnabledBy statement of the IsConnected block of statements (491 to 498 in section 7.3.5). When the disabling condition is met or the disabling sequence is executed the signal on which this statement is described typically goes to a certain logic state. This state is described by the DisableState statement (557 to 559).
540. 541. 542. 543. 544. 545. 546. 547. 548. 549. 550. 551. 552. 553. 554. 555. 556. 557. 558. 559. 560. 561. 562. 563.

Environment (ENV_NAME ) { CTL (CTL_NAME) { Internal { (sigref_expr { (IsDisabledBy <In|Out> Logic logic_expr { (LOGICSIGNAME { Type < Signal | StateElement Scan | StateElement NonScan | CoreSignal>; Name <SIGNALNAME | CELLNAME | SYMBOLNAME>;
})+ })*

(IsDisabledBy <In|Out> <Macro|Procedure> NAME;)* (DisableState <ExpectOff | ExpectLow | ExpectHigh | ExpectValid> (Weak);)
}) +

} } }

The IsDisabledBy statement (544) allows for an assignment of a direction for which the statement is applicable. In is used to describe the disabling condition of an input signal (543), Out is used to describe the disabling condition of an output signal (543). This is similar to the In and Out on the

90

IsConnected statement (468 of section 7.3.5). Multiple IsDisabledBy statements are allowed on any signal. These statements need not be exclusive of each other. The first one of the many such statements on a signal should be viewed as the preferred one for achieving the disable state. In most cases the disable condition is achieved through combinational logic. In the syntax this is specified with the logic_expr using character symbols to represent entities that are then bound to signals, scan cells, non-scan cells or core-instance-signals within the IsDisabledBy statement itself. Details of how the logic expression works are in section 7.3.5. Similar to the IsEnabledBy statement (498) the Macro or Procedure that achieves this referenced in a corresponding IsDisabledBy statement (555, 556). The DisableState (557 to 559) is a companion statement of the IsDisabledBy statement. It allows for an expected logic value when an output signal is disabled. Through this statement logic-1 (ExpectHigh), logic-0 (ExpectLow), high-impedence (ExpectOff) and a valid logic value of logic-1 or logic-0 (ExpectValid). Logic values can be labeled as Weak if they are no-problems in contention situations as may exist on signals that are connected on a bus.

7.3.9 Scan Style

If a scan chain follows a certain design style then the scan methodology can be described on the scan-in and scan-out signals of the scan chain using the ScanStyle statement (568 to 570). 564. Environment (ENV_NAME) { 565. CTL (CTL_NAME) { 566. Internal { 567. (sigref_expr { 568. (ScanStyle < MultiplexedData 569. | MultiplexedClock> 570. (LevelSensitive);) 571. })+ 572. } 573. } 574. } Scan chains constructed by multiplexing the scan data with the functional data are considered of type MultiplexedData (third flip-flop of Figure 22 on

91

page 69). Scan chains constructed with flip-flops that allow one of multiple clocks to capture data at any time are labeled as MultiplexedClock (fourth flip-flop of Figure 22 on page 69). If the flip-flops of the scan chain are constructed with the master and slave element controlled by independent clocks then the scan chain is said to be LevelSensitive (second and fourth flip-flop of Figure 22 on page 69). Thus through these keywords four different scan chain types can be described.

7.4

SCANINTERNAL

The ScanInternal block-of-statements are used to describe aspects of the design that go from the scan-cells inwards. This is visualized in section 6.4 on page 53. This block of information is a parallel of the Internal block of statements for the signals but applies to scan-cells. Hence the syntax and semantics of this block are similar to the Internal block-of-statements with fewer capabilities. 575. Environment (ENV_NAME) { 576. CTL (CTL_NAME) { 577. (ScanInternal { (cellref_expr { 578. 579. // type of data in the scan-cell. 580. // For data_type_enum see DataType 581. // syntax of the Internal block. 582. (DataType (data_type_enum)+;) 583. (DataType (data_type_enum)+ { 584. (ActiveState <ForceDown 585. | ForceUp | ForceOff 586. | ForceValid | ExpectLow 587. | ExpectHigh | ExpectOff 588. | ExpectValid>;) 589. 590. })* 591. // connections from the scan-cell 592. // to the internals of the design. 593. (IsConnected <In|Out> { 594. // connections to 595. (CoreSignal sigref_expr;) 596. (StateElement <Scan|NonScan> 597.

92

598. 599. 600. 601. 602. 603. 604. 605. 606. 607. 608. 609. 610. 611. 612. 613. 614. 615. 616. 617. 618. 619. 620. 621. 622. 623. 624. 625. 626. 627. 628. 629. 630. 631. 632. 633. 634. 635. 636. 637. 638.

(cellref_expr);) // Enabling conditions (IsEnabledBy Logic logic_expr { (LOGICSIGNAME { Type < Signal | StateElement Scan | StateElement NonScan | CoreSignal>; Name < SIGNALNAME | CELLNAME | SYMBOLNAME>; }) + })* (IsEnabledBy <Macro | Procedure> NAME;)* // Clock info. of connection. (<LaunchClock | CaptureClock> SIGNALNAME { (<LeadingEdge | TrailingEdge | LevelSensitive>;) (<Direct | Transitive>;) (StateAfterClock < Connection | ExpectLow | ExpectHigh | ExpectUnknown | ExpectValid | Hold | Invert | ShiftState | User USER_DEFINED>;) })* // Access to the internal value (TestAccess (<Control | Observe | User USER_DEFINED>)+ <Macro | Procedure> NAME;)*

// value manipulation across // the connection. (Transform { (WaveformTable (WFT_NAME) +;) (Invert;)

93

639. 640. 641. 642. 643. 644. 645.

(WFCMap

FROM_WFC

->

TO_WFC;)*

})* })*

})+ }) } }

Information in the ScanInternal is provided on scan-cells that are part of a ScanStructure in the scope of the CTL test mode being written. cellref_expr has the similar capabilities as its counterpart sigref_expr for signals. It is introduced in section 5.3.2 on page 36. The ScanInternal block of statements allows for two capabilities: The ability to specify a data type on scan-cells. The ability to specify a connection between the scan-cell and other scancells or core terminals. Since the syntax is the same as that of the syntax in the Internal block of statements the reader should look for the necessary descriptions of the syntax in section 7.3.2 on page 66 and section 7.3.5 on page 77.

7.5

COREINTERNAL

The CoreInternal block is used to describe information on cores and their connections to other cores. The syntax and capabilities are very similar to the ScanInternal block with the basic difference in the entity on which information is being provided. For completeness the syntax of the CoreInternal block is given below. 646. Environment (ENV_NAME) { 647. CTL (CTL_NAME) { 648. (CoreInternal { 649. (sigref_expr { 650. // type of data in the scan-cell. 651. // For data_type_enum see DataType 652. // syntax of the Internal block. 653. (DataType (data_type_enum)+;) 654.

94

655. 656. 657. 658. 659. 660. 661. 662. 663. 664. 665. 666. 667. 668. 669. 670. 671. 672. 673. 674. 675. 676. 677. 678. 679. 680. 681. 682. 683. 684. 685. 686. 687. 688. 689. 690. 691. 692. 693. 694. 695.

(DataType (data_type_enum)+ { (ActiveState <ForceDown | ForceUp | ForceOff | ForceValid | ExpectLow | ExpectHigh | ExpectOff | ExpectValid>;)
})*

// connections from the scan-cell // to the internals of the design. (IsConnected <In|Out> { // connections to (CoreSignal sigref_expr-,) // Enabling conditions (IsEnabledBy Logic logic_expr { (LOGICSIGNAME { Type < Signal | StateElement Scan | StateElement NonScan | CoreSignal>; Name < SIGNALNAME | CELLNAME | SYMBOLNAME>; })+ })* (IsEnabledBy <Macro | Procedure> NAME;)* // Access to the internal value (TestAccess (<Control | Observe | User USER_DEFINED>)+ <Macro | Procedure> NAME;)* // value manipulation across // the connection. (Transform { (WaveformTable (WFT_NAME)+;) (Invert;) (WFCMap FROM_WFC -> TO_WFC;)* })* })*

95

696. 697. 698. 699.

})+
})

} }

Explanations of the above syntax should be obtained from the corresponding explanations in the section describing the Internal block of statements. The only thing to note about this syntax is that the sigref_expr (649) consists of signals or combinations of signals of cores. The names include the core instance names. For example, a signal y on a core instance eg_core would be eg_core:y.

7.6

EXTERNAL

The External block of statements covers information external to the signals of the design being represented (see pictorial representation of Figure 18 on page 54). This information is about the environment that the design is to be embedded in. Typically the information required in the External block of statements should mirror the description of the signals and their characteristics in the Internal block of statements. For example, a scan enable signal of the design when integrated would come from a signal in the integrated design that should operate as a scan enable. Thus something described as a scan enable signal in the Internal block should have a ConnectTo statement to a scan enable signal in the External block. While the syntax does allow for such descriptions the CTL providing such information is redundant and does not display the real intent of the External block of statements. The External block should be used to describe value added information about integration of the associated signal. Scan-enable signals are typically controlled from an input of the SoC. Thus the External block of information of the design could come with the result of this knowledge to describe the need to connect the signal to an input of the SoC. The syntax of the external block of statements is given below (702 to 735). 700. 701. 702. 703. 704. 705. Environment (ENV_NAME) { CTL (CTL_NAME) { (External { (sigref_expr { (ConnectTo { (Core NAME sigref_expr;)

96

706. 707. 708. 709. 710. 711. 712. 713. 714. 715. 716. 717. 718. 719. 720. 721. 722. 723. 724. 725. 726. 727. 728. 729. 730. 731. 732. 733. 734. 735. 736. 737.

(Symbolic (SYMBOLIC_NAME)+;) (DataType (data_type_enum)+;) (WBR;) (Instruction;) (WIP;) (Wrapper <IEEE1500 | None | User user_defined> (< CellID cell_enum |PinID user_defined_pinid>);) (TAM;) (Termination <TerminateHigh | TerminateLow | TerminateOff | TerminateUnknown>;) (Safe;) (Fanout INTEGER;) (NoRebuffering;)
})*

(AllowSharedConnection { (Core NAME sigref_expr;)* (DataType (data_type_enum)+;) (Family (NAME)+;) (OutputFunction <And|Or|Xor>;) (Self sigref_expr;) (Vendor (NAME)+;) })* })+
})

} }

Two statements are defined in the External block. The ConnectTo statement (704 to 724) allows for the definition of the connection needs of signals of the design for which CTL is being written, to entities external to the design. The second statement AllowSharedConnection (726 to 733) defines the ability of sharing the external connection with other entities such that activities can be done in parallel. Sharing for serial purposes is always possible and need not be described.

97

7.6.1 ConnectTo Statement

Through the ConnectTo statement connections can be described to specific signals on other cores (705) or specific symbolic entities (706) that are global to the system using the information. If the connection is being described to an external core, that core must have a CTL associated with it and it should be linked in to the current CTL through the FileReference statement (150 to 154 on page 31). The NAME of the core corresponds to the FILE_PATH_NAME of the FileReference statement and the signals in the sigref_expr correspond to signals in the Signals block of the CTL file being pointed to. A more indirect connection is specifiable through characteristics described by all the DataTypes such as test mode signals, scan terminals, inputs, outputs etc. The complete list of data types allowed by the statement is the same as the ones in the Internal block (123 to 148 on page 26). The external connection may have some restrictions that the integrator would needs to ensure. For example some bi-directional signals (InOut) of the design may need to be directly to a bi-directional signal of the SoC without any buffers or gating logic. This characteristic is specifiable through the NoRebuffering keyword (723). Similarly, termination of a connection can be defined for signals (718 to 720). The number of connections that can be made to the signal (722) or the fact that the connections of the signal need to be made safe externally (721) such that no situation can arise where conflicting values are driven on the a net at the same time, can be specified. Wrappers are the most common way of integrating a design into a SoC. If the wrapper is expected to be implemented external to the design, the necessary connections to parts of the wrapper are specifiable. Wrappers usually consist of scan cells to apply values to signals through a scan-chain (WBR), special signals that control the wrapper ( WIP ) and an instruction register which contains values that configure the wrapper into modes (Instruction). The wrapper is then connected to the top level of the SoC through a test access mechanism (TAM). Connections can be specified to these pieces of the wrapper (709, 710, 711, 716). If the wrapper is expected to be an IEEE1500 wrapper the special signal names and exact boundary scan cell names of the expected connection can also be specified in the syntax (712 to 715). A ConnectTo statement allows multiple characteristics to be specified within the statement. Multiple characteristics defined using a single ConnectTo statement would mean that all the characteristics are to be achieved simultaneously (a logical AND condition). Thus one cannot have conflicting requirements in a single ConnectTo statement. For example, a ConnectTo

98

statement defined for a signal to an external core cannot have a connection also defined for an input of the SoC. Sometimes multiple external connections are possible for the signal but only one should be implemented. In that case multiple ConnectTo statements should be used to specify each independent possibility.

7.6.2 AlowSharedConnection statement

Typical designs that are integrated into SoCs as cores are not limited in the number of inputs and outputs by any form of packaging requirements. The sum of the inputs and outputs of all the designs with CTL (that are integrated as cores in a single SoC) may well exceed the total number of inputs and outputs on the SoC. Integrating these designs (cores) for test involves sharing of the SoC resources and limiting the test application time of the SoC by scheduling tests of the designs (cores) in parallel.

Figure 26 shows an example scenario of two core instances C1 and C2 (designs with CTL) tested by built-in self-test where an output signal goes to a logic-1 if the core fails the test. In a production test environment of the SoC it does not matter as to which core failed as long as the fail bits of the cores are monitored on the SoC. That is the fail bits of the two cores can be logically ORed together. The fact that this is allowed for the individual cores can be expressed in the CTL of the cores C1 and C2 using the AllowSharedConnection statement (726 to 733). Now the context of the example is the CTL for the design A, which when integrated would be coreinstance Cl. The CTL for design A would be as follows. Signals { failoutA Out;

99

} Environment { CTL bistpatterns { TestMode InternalTest; External { failout { AllowSharedConnection { Core B failoutB; OutputFunction Or; } } } }

Through the AllowSharedConnection statement the sharing of resources to enable parallel test is specifiable. Sharing can be identified with signals of other cores (NAME) (727), or to signals on the design itself for which CTL is being written (731). Sharing can be specified with entities having a certain DataType (728), that are part of a certain family of entities (729), or entities provided by certain vendors (732). Note that a CTL with a design can be tagged with a Family name or a Vendor name that is being referred to here (228, 241 on page 44). Every AllowSharedConnection statement contains the requirement as a logical AND of the statements within it. If the above example were to be augmented to say that the sharing of the failout signal can only be performed with cores of type B that are provided by my-favorite-vendor, then a Vendor statement would have to be added to the already existing syntax. Multiple possibilities of sharing are specified through multiple AllowSharedConnection statements. As the example shows the logic function that is allowed for the sharing is also specifiable in the syntax (730).

7.7

PATTERNINFORMATION

This block of information provides the necessary pattern/sequence information that is required for the test mode. The following pieces of information are conveyed.

100

Identification of the initialization and termination sequences of the test mode. Identification and description of the test schedule of the mode. Information about the test patterns that are part of the test schedule. Information about the special sequences and important events. Information about some important conventions used in the pattern data or the sequences in the test mode. The PatternInformation block is written on a per test mode basis. Figure 27 shows a very high level view of the information in the PatternInformation block. By the nature of the information, sequence data has many pieces to it that are linked to each other (seen in the dashed lines of the figure) to provide the complete timing, data and sequence of events. The top level Environment-CTL-PatternInformation being written ties the sequence information to the configuration through references as seen by the solid lines in the figure. Sometimes the pattern information plays a role of providing meta-information on the test pattern data that is already linked in to the PatternInformation block directly (through the solid lines) or indirectly (through the dashed links). The meta-data is written in the PatternInformation block of statements and associated with the entity for which the information is written through a reference to the entity (represented by solid lines in Figure 27). In the remainder of this sub-section the syntax associated with the constructs that make up PatternInformation are described. The description starts with the construct that does not reference other constructs to avoid forward references in the text. That is Waveforms are described before Macros and Patterns are described after Macros.

101

7.7.1 Timing : Waveforms

Values that are applied-to or observed-at signals as part of sequences are events associated with time. CTL supports multiple types of events for

102

applying values as stimulus and for measurement of responses. Some of the events supported are Drive events: These events are used to describe input stimulus. The events include, D (ForceDown or logic-0), U (ForceUp or logic-1), Z (ForceOff, high impedence), P (ForcePrior, last driven state), N (unknown value, logic-0 or logic-1). Compare events: These events are used to describe measurements of values on signals. The events include, L (CompareLow or logic-0), H (CompareHigh or logic-1), X (x, CompareUnknown or logic-X), T (CompareOff, a voltage level between the low and high threshold voltages), S (CompareSubstitute, perform a compare and insert the observed event in its place), V (CompareValid, logic-0 or logic-1). These events listed are all events that are associated with an edge. Equivalent events also exist that are representative of comparisons in a window or interval. l, h, t, v and s are the corresponding window events for L, H, T, V and S respectively. Window events are terminated by an X. Expect events: These events are used to describe values that appear on signals without the need for any measurement. The values include, R (ExpectLow or logic-0), G (ExpectHigh or logic-1), Q (ExpectOff or high impedance). Events are provided relative in time to the beginning of a period to describe waveforms. The following syntax is used to describe a waveform in a timing block of statements. 738. Timing (DOMAIN_NAME) { 739. (SignalGroups DOMAIN_NAME;)* 740. 741. (WaveformTable WFT { 742. (Period time_expr;) 743. Waveforms { 744. (sigref_expr { 745. (WFC { 746. ( (time_expr) (event);)* 747. })* 748. (WPC_LIST { 749. ((time_expr) 750. (<event_list | event>);)*

103

751. 752. 753. 754.

}>* } })* } // incomplete syntax shown.

The Timing block can have multiple waveform tables associated with it (741 to 753). Each waveform table associates waveform characters (WFC) with signals and signal-groups (744, 745). The waveform-characters are a short hand for a set of events associated with time relative to the period (745 to 747). Thus using this syntax a logic-1, logic-0 and a pulse can be described for a clock signal (clK), as shown below. Signals { clk In; } Timing { WaveformTable sample { Period 100ns; clk { 0 { 0ns D; } 1 { 0ns U; } P { 0ns D; 50ns U; 55ns D;} } } }

Using a period of 100ns in the example the waveform character 0 is used to specify a drive event D at the beginning of the period. Since no other events are specified after the D event, the clk remains D, for the remainder of the period. Similarly, 1 is specified to be a drive event U in the beginning of the clock period. P is defined to be a pulse of 5ns occurring 50ns into the period. A short hand mechanism to describe these waveform characters is to collapse multiple statements into a single one with / separators as shown below (using syntax 748 to 751). Signals { clk In; } Timing { WaveformTable sample { Period 100ns; clk { 01P { 0ns D/U/D; 50ns D/U/U;

104

55ns D/U/D;}
} } } In the short hand syntax there is a one-to-one correspondence between the waveform characters and the list of events defined with it.

Waveform tables and the associated waveform characters are created for a purpose and usually follow a certain convention. This is described in an associated construct in the Environment-CTL-PatternInformation with the syntax given below.
755. Environment (ENV_NAMK) { 756. CTL (CTL_NAME) { (PatternInformation { 757. 758. (WaveformTable (WFT)+ { (Purpose (<Shift | Data | Capture 759. | User USER_DEFINED>)+;) 760. 761. (WaveformChar WFC_LIST 762. (<Launch | Capture 763. 764. | LaunchCapture | Data>) 765. (<Level | Pulse | DoublePulse 766. | Complex | DontCare>) 767. (<Critical | NonCritical>) 768. (Measure);)* 769. })* 770. }) 771. } 772. }

All the waveform tables defined in the scope of the CTL block using the DomainReferences block of statements can be described using statements 758 to 769.

105

Waveform tables are primarily defined for use as part of sequences that have a format as shown in Figure 28. Waveform tables that are used by the scan operation are identified with the Shift keyword. Waveforms that are defined for the application of broadside stimulus to signals are identified as Data, and waveform defined for the application of capturing the response of data applied to signals is identified as Capture. While the purpose of the complete set of waveforms can be described using the Purpose statement (759, 760), individual waveform characters also can be identified to have certain characteristics (762 to 768). Waveform characters used for special purposes can be identified accordingly. For example, 0, 1 and P waveform characters of the waveform table example are defined with an underling convention. 0 and 1 stand for logic levels and P stands for a single pulse. The following syntax would be used to describe this convention. Environment { CTL { PatternInformation { WaveformTable sample { WaveformChar 01 { Level; } WaveformChar P { Pulse; } } } } }

106

Waveform characters can be used for many special cases. In a delay fault testing paradigm the Launch and Capture events can be highlighted if special waveform characters are used. If a WFC is used for both launch and capture then LaunchCapture is used. Finally, the Data keyword is used to describe events that are used to apply broadside stimulus to signals. As used in the example, the WFC could be used for apply Level values (like a logic-0 or logic-1) or could be used to provide a single pulse (Pulse) or double pulse (DoublePulse). Since values are sticky waveform characters are used to set the signals to logic-X or DontCare. A Measure keyword is specified if the waveform associated with the WFC contains a compare event. The Critical and NonCritical keywords are used to describe the ability to not-change or change the timing within the period of the events in the waveform. This allows for the differentiation of the fact that the time associated with the events was based upon the needs of the circuitry or an arbitrary selection from a variety of options was made.

7.7.2 Protocols : Macros and Procedures

A protocol is a sequence of events written as a function that is used to apply data through calls of the function with the data as parameters. There are two constructs namely Macros and Procedures that allow for the description of protocols. These constructs are similar in most aspects with minor differences when it comes to remembering the context in which the construct is invoked. Macros are to be treated as inline expansions of its contents where it is invoked. Thus the values of the signals prior to the call are recognized during the execution of the statements of the Macro. This is not true for Procedures. Values for all signals are redefined at the beginning of a Procedure. Both Macros and Procedures allow for numerous statements within it called PATTERN-STATEMENTS. Some of the PATTERN-STATEMENTS allowed are given below (776 to 796). 773. 774. 775. 776. 777. 778. 779. 780. 781.

// Begin Some Pattern Statements // (PATTERN-STATEMENTS)

(LABEL:) W(aveformTable) NAME; (LABEL:) V(ector) { (sigref_expr = value_variable_expr;)* } (LABEL:) C(ondition) { (sigref_expr = value_variable_expr;)*

107

782. 783. 784. 785. 786. 787. 788. 789. 790. 791. 792. 793. 794. 795. 796. 797. 798. 799. 800. 801. 802. 803. 804. 805. 806. 807. 808. 809. 810.

} (LABEL: ) X TAG; (LABEL:) ScanChain NAME; (LABEL:) Call PROCNAME; (LABEL:) Call PROCNAME { (sigref_expr = value_variable_expr;)* } (LABEL:) M(aero) MACRONAME; (LABEL:) M(acro) MACRONAME { (sigref_expr = value_variable_expr;)* } (LABEL:) Loop integer_expr { // all the pattern statements (V,C..) } (LABEL:) IDDQTestPoint; // End Some Pattern Statements
MacroDefs (DOMAIN_NAME) { (MACRONAME { (PATTERN-STATEMENTS)* (Shift { (PATTERN-STATEMENTS)+ })* })* } Procedures (DOMAIN_NAME) { (PROCNAME { (PATTERN-STATEMENTS)* (Shift { (PATTERN-STATEMENTS)+ })* })* }

One of the PATTERN-STATEMENTS allowed in a Macro or Procedure is called the WaveformTable or W statement. Through this statement (coupled with the Timing statement in the DomainReferences) the location of the details of the WFCs used in the protocol is referenced. Every protocol must have at least one such statement. The Vector or V statement represents one cycle of the protocol, which is equal to the period defined in the waveform table. The vector statement allows for WFCs to be applied to signals or signal-groups. An optional escape character \m allows for the alternate waveforms as defined by the mapping on the associated signal to be used (162 to 164 on page 32). The values on signals are sticky so that only value

108

changes are specified from Vector to Vector. Thus the following example would mean that the Macro named mymacro applies a D to signal a and clk in the first cycle, and then a 5ns pulse is applied to the clk signal 50ns into the next cycle. Signal a remains D in the next cycle. Signals { a In; clk In; } Timing { WaveformTable sample { Period 100ns; a+clk { 01P { Ons D/U/D; 50ns D/U/U; 55ns D/U/D;} } } } Macro mymacro { W sample; V { a = 0; clk = 0; } V { clk = P; } }

The Condition or C statement is used to specify waveform characters for signals as a setup that is deferred from being applied until the next Vector statement. The construction of the C statement is similar to the V statement except it provides background values of the signals. For example, a value of a scan-enable-signal is best specified through a C statement prior to the scan operation. The ScanChain PATTERN-STATEMENT allows for a reference to the scan chains defined in the ScanStructures within the scope of the statement. The IDDQTestPoint statement allows for the specification of quiescent current measure points in the protocols. The Loop statement allows for the definition of a repeated operation of the PATTERN-STATEMENTS within the loop based upon a count specified in the statement itself. Macros and Procedures also allow a specialized loop statement for the scan operation. This special loop statement is called the Shift statement (802 and 808). The number of iterations of this special shift loop is dependent on the amount of data that is provided to the scan input/output. The following

109

example shows the use of the Shift statement to scan-in and scan-out four values simultaneously. Signals { si1 In; so1 Out; clk In; se In; } Timing { WaveformTable sample { Period 100ns; si1+clk+se { 01P { Ons D/U/D; 50ns D/U/U; 55ns D/U/D;} } so1 { 01 { Ons X; 30ns 1/h; 40ns X;}} } } MacroDefs { myseq { W sample; C { se=1; } Shift { V { si1=\w1011; so1=\w0110; clk=P;}} } } The above example describes four signals, the scan-in, the scan-out, a scanenable signal and a clock signal. Waveforms are described for all these signals in the example and used in the Macro named myseq. The macro is defined in a MacroDefs block of statements. It begins with a reference to the waveform table with the W statement. The C vector is then used to define the value to be preconditioned on the scan-enable signal (se). The Shift statement that follows specifies a loop of the vector V until all the data is shifted into the scan-in and the values appear at the scan-out. Each iteration of the loop associates the values from left to right to the scan-in (sil) or scanout (sol). Thus the first value that is applied to the scan-in is the value that ends up in the scan-cell that is closest to the scan-out of the scan chain. The \w indicates waveform characters. Other pattern-statements include calls to Procedures and Macros with and without parameters (785 to 792). The parameter passing mechanism allows for the separation allows for the separation of the data and protocol. A call to a Macro or Procedure contains the name of the Macro or Procedure and a number of parameters. The Macro myseq written above did not take any

110

parameters. Macro myseq is re-written below in two ways as a parameterized Macro myseq1 and myseq2. MacroDefs { myseq1 { W sample; C { se=1;} Shift { V { Si1=#; S01=#; clk=P;}} } myseq2 { W sample; C { se=1;} Shift { V { si1=si1; so1=so1; clk=P;}} } } // The Macros are invoked with the following. Macro myseq1 { si1=1011; so1=0110; } Macro myseq2 { si1=1011; so1=0110; }

Both myseq1 and myseq2 are equivalent. The # waveform character is used to indicate that data needs to be substituted for the associated signal. The # character forces the need for an association between the parameter to the location where the value goes. That is, the parameter had to be named si1 and so1 as the signals where the parameters were to go were named accordingly. The # refers to a single bit (for every signal it is assigned to) incremental parameter data replacement. Meaning that the value once applied is consumed and the next value of the parameter becomes available the next time the parameter is used. A percent sign % defines a fixed parameter replacement where the data does not get consumed. The format used in the second sequence myseq2 does not rely on the association of the parameter name to the signal name. The values that are assigned through the syntax (for example with parameter names) to the signal work under an implicit #. Parameters could be grouped or ungrouped as needed by the Macros and Procedures. Let us consider an example call to a Macro shown below. MacroDefs { myseq3 { W sample; C { se=1;} Shift { V {

111

si1=a[0..1] b c ; so1=so1 ; clk=P ;

}}

} } // The Macros are invoked with the following. Macro myseq3 {a [0..1]=10; b=1; c=1; so1=0110;}

This example myseq3 shows a situation where different parameters are combined and applied to the scan-in si1. With bussed parameters (parameters with []) individual bits of the parameter can be indexed and combined as needed. No indexing is available for parameters that are not described to contain multiple entities. In myseq3 the parameter so1 cannot be indexed as so1 is considered different from so1[]. The parameter itself can be defined as a signal name, signal-group-name or signal-variable in the Signals block or the SignalGroups block of statements of CTL. Macros and Procedures represent protocols in CTL and are used in many different ways. In one of its usage scenarios protocols are called by test patterns that provide the data. Protocols are also used in CTL to describe ways of operating the design. For example a protocol can be defined to operate a scan chain in a test mode. This protocol may not be invoked by a test pattern. The different protocols are tied to the test mode and their purpose described in the PatternInformation block of the Environment (813 to 820). 811. Environment (ENV_NAME) { CTL (CTL_NAME) { 812. (PatternInformation { 813. (<Procedure | Macro> NAME { 814. (Purpose (proc_macro_enum)+;) 815. (UseByPattern (pat_burst_enum)+;) 816. (ScanChain (CHAINNAME)+;) 817. (Identifiers (pat_burst_enum)* {})* 818. 819. })* 820. }) 821. } 822. } 823. proc_macro_enum = < DoTest | DoTestOverlap | Control | Observe | ShiftIn | ShiftOut 824. | Capture | Transfer | Update 825. 826. | Instruction

112

827. 828. 829. 830. 831. 832. 833. 834. 835. 836. 837. 838. 839. 840. 841. 842. 843. 844. 845. 846. 847. 848. 849. 850.

| | | |

Operate | ModeControl MemoryPrecharge | MemoryRead MemoryWrite | MemoryReadModifyWrite MemoryRefresh | User USER_DEFINED>

Identifiers (pat_burst_enum)* { (Variable VAR_NAME (values)+;) (EventType <Capture | Control | Update | ControlObserve | Hold | Measure | Observe | Transfer | TestPatternUnit | DataFromPriorActivity | DataFromCurrentActivity | DataFromCurrentAndPriorActivity>{ (<Label | Xref> LABEL_ID { (<Prefix | Complete>;) (<Begin | During | End>;) (SeguenceNumber INTEGER;) (EventValue (time_expr)+;) })+
})*

Consider the design of Figure 1 on page 3. A typical test pattern for the design would involve the following operations. Scan In values into the scan chains. Apply stimulus to Inputs and Observe Outputs. Pulse the Capture Clocks. Scan Out values out of the scan chains. The protocol described represents a test pattern unit as identified by an ATPG tool to apply a test and observe the response of the same test. This is a non-overlapped protocol as the scan-in and scan-out operation of adjacent test pattern units are not overlapped to save time (DoTest). The corresponding CTL to describe this is repeated below from the example 6797 on page 21.

113

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; 0=X;} C { e-1;} Shift { V { o=scan_val; c=P;}} C { C=0; e=0; 0=X;} } } Environment inputToAtpg { CTL { PatternInformation { Macro test_sequence { Purpose DoTest;} } } }

The Environment block of statements in the example describes the existence of a Macro named test_sequence that is identified to be a protocol that represents a non-overlapped sequence for a test pattern unit. The protocol itself is defined in the MacroDefs block. This example shows how the two portions of the syntax together form the complete information. The syntax allows for the identification of many types of protocols. Through the Purpose statement (815) protocols (Macros and Procedures) can be identified to be used to apply non-overlapped test pattern units (DoTest) or overlapped test pattern units where the scan-in operation of one test patternunit is overlapped with the previous test pattern units scan-out operation (DoTestOverlapped). DoTest: The non-overlapped protocol for test patterns is a preferred format for reusable test pattern methodologies and is also the preferred format for CTL syntax. This method of applying tests allows for any re-sequencing of the protocols needed for the test to fall within the scope of the protocol itself. The overlapping of the scan operation of adjacent test patterns is deferred to the end of the test flow when the test patterns need to be optimized for application on the tester.

114

DoTestOverlapped: The protocol that overlaps the scan-in operation of one test pattern with an adjacent test pattern is difficult to manipulate in a reusable flow. Such protocols are required to take in redundant parameters for values of previous patterns output measures to allow for the possibility of scanning the values in the modified protocol. Some protocols perform smaller tasks than the protocols used by the test pattern unit (823 to 830). Capture: A protocol that allows for the functional data of the design to be captured into a memory elements. Transfer: A protocol that allows for the transfer of a value from a memory elements on a non-shift path to scan elements (shift path). Update: A protocol that allows for the transfer of a value from memory elements on the shift path to a memory elements not on the shift path. Control: A protocol that allows for test values to be applied to stimulus points. A ShiftIn is a special type of Control protocol. Observe: A protocol that allows for test values to be compared from a measurable location. A ShiftOut is a special type of Observe protocol. Other protocols that are identifiable in CTL through the Purpose statement include standard memory (RAM/ROM) operations such as MemoryRead, MemoryWrite, MemoryReadAccessWrite, MemoryPrecharge and MemoryRefresh. Special protocols that operate the instruction register of wrappers such as IEEE 1149.1 or IEEE 1500 are identified with the Instruction keyword. Protocols that are used by patterns that establish the modes (EstablishMode) or patterns that terminate the mode (TerminateMode) are called ModeControl sequences. Protocols that need to be executed to complete the functionality of the test mode are labeled Operate. The block of statements in the Environment that references the protocols (814 to 819) allows for the identification of the usage of the protocol by different patterns. Though the UseByPattern statement, the protocol can be identified to be used by test patterns that test the scan chain (ChainContinuity), IDDQ patterns, and all other kinds of test patterns that are identifiable in CTL. The reader should refer to the syntax and associated

115

explanations in the next section to get the details of different pattern types identifiable in CTL. All PATTERN-STATEMENTS allow for a LABEL on statements that can be used for many purposes. While the same LABEL name cannot be used for multiple statements, a second type of labeling mechanism exists through the X statement that allows for the statement following the X statement to be tagged with the same identifier (783). The labeling mechanism of the vectors can be used in conjunction with Identifiers to highlight information relative to activities occurring in the associated statement. Consider the example Macro of a test sequence that was used earlier in this section. This time some labels are added to the protocol and important events of the test pattern that uses the protocol are highlighted. MacroDefs { test_sequence { W time; C { e=1; o=X;} event_1 : Shift { V { s=#; c=P;}} event_4: V {c=0;e=0;a=#;b=#;o=func_out;} V { c=P; 0=X;} event_2 : C { e=1;} event_3: Shift { V { o=scan_val; c=P;}} C { c=0; e=0; 0=X; } } } Environment inputToAtpg { CTL { PatternInformation { Macro test_sequence { Purpose DoTest;} Identifiers { EventType Control { Label event_1 { Complete; During;} } EventType Capture { Label event_2 { Complete; During, } } EventType Observe { Label event_3 { Complete; During;} }

116

} } }
In this example, the statement associated with event_1 is identified to be the step during which values are controlled in the state elements (EventType Control). The label event_1 is the Complete label as opposed to being a Prefix of the possible labels and the event is defined to occur During the statement. Other options allowed being the event occurs at the beginning or end of the statement (845 on page 112). The example describes the statement associated with event_2 to be the Capture event and the statement associated with event_3 as the Observe event. The Identifier syntax allows for providing information about the labels and their associated statements with different type of test patterns. For example Iddq measures can be highlighted with labels. Let us say that for the above example we would want to add information to the fact that if you want to apply an Iddq measure for IDDQ patterns then take the measurement at this point. The following would have to be added to the above example. Identifiers IDDQ { EventType Observe { Label event_4 { Complete; End;} } } The sequence itself never contained the Iddq measure. Thus if the patterns just use the sequence as is the Iddq measure will not occur. The information in the Environment is providing information of where an Iddq measure could occur since the measure itself does not exist. The Identifier syntax (833 to 850 on page 112) allows for events to be associated with values (847), and global sequence numbers (846). The syntax can also be used to describe different values that a variable can take on (834). A number of different event types are supported by CTL. Some of the events are common to the type of purposes allowed for the protocols themselves and need no extra explanation. The Hold event type allows for the identification of points in the protocol where the protocol can be stopped and as long as the signals being used by the protocol are not changed the protocol can be resumed as though it was not interrupted. The TestPatternUnit event type is used to identify test patterns as units that detect faults (ATPG language of test patterns). The keywords

117

DataFromPriorActivity , DataFromCurrentActivity and DataFromCurrentAndPriorActivity allow for identifying statements that apply data of the current or prior test pattern. This is especially relevant for sequences that are used by test patterns that overlap the scan operation of adjacent test patterns.

7.7.3 Patterns
Patterns in CTL are the location where the data is specified for the sequences. Patterns invoke the protocols (Macros and Procedures) passing to them the necessary data as parameters. Thus the syntax of a pattern is very simple (851 to 863). Only calls to the sequences are allowed and the associated labeling mechanism is available.
851. Pattern PATTERN_NAME { 852. 853. // REDUCED-PATTERN-STATEMENTS 854. ((LABEL:) Call procname;)* 855. ((LABEL:) Call procname { 856. (sigref_expr = value_variable_expr;)* 857. })* 858. ((LABEL:) M(acro) macroname;)* 859. ((LABEL:) M(acro) macroname { 860. (sigref_expr = value_variable_expr;)* 861. })* 862. ((LABEL:) X TAG;)* 863. }

The syntax statements are a reduced sub-set of the statements allowed in protocols. The syntax of these statements are already introduced in the prior section. This structure of test patterns has significant benefits in pattern reuse. Test patterns consist of mainly two pieces of information namely, data and protocols. The test patterns typically use few different types of protocols but apply many different sets of data through them. This requirement on the patterns allows for modifications to protocols without the need to change the test patterns themselves. The following are some examples of Patterns that use the test_sequence protocol defined in the previous section. Details of the waveform characters are ignored.

118

MacroDefs { test_sequence { W time; C { e=1;o=X; } Shift { V { s=#; c=P;}} V { c=0; e=0; a=#; b=#; o=func_out; } V { c=P;} C { e=1;} Shift { V { o=scan_val; c=P;}} C { C=0; e=0; o=X; } } } Pattern P1 { Pat1: Macro test_sequence { a=1; b=0; s=1; func_out=1; scan_val=0; } Pat2: Macro test_sequence { a=0; b=1; s=1; func_out=1; scan_val=1; } // many more calls can be in the pattern. } In the example pattern P1 shows two test patterns that use test_sequence. For this example to be technically correct, all signals should have had default states defined for them in the Signals block or all the signals need to be initialized with a test vector as some of the signals are not defined for the first invocation of test_sequence. On the other hand the Macro test_sequence can be modified to have all the signals and their default values defined in the first C vector (C {e=1; s=X; a=X; c=0; b=X; o=X;}). The syntax may allow for the protocol to be split into multiple protocols one where the load of the scan chains occur, one where the capture occurs and one where the unload of the scan chains occur. However the semantics of keeping the protocol and the data separate does not allow the pattern to call the three protocols in sequence to describe the tests. This erroneous example is given bellow. MacroDefs { load { W time; C { e=1;o=X;}

119

Shift { V { s=#; c=P;}} V { e=0; a=#; b=#; o=func_out; }

} capture { V { c=P;o=X;} } unload { C { e=1;} Shift { V { o=scan_val; c=P;}} C { c=0; e=0; 0=X;} } } Pattern P_error { Macro load { a=1; b=0; s=1; func_out=1;} Macro capture; Macro unload { scan_val=1;}

// many more calls can be in the pattern.

}

The fact that the three activities have to occur in a given order is considered sequence information. All sequence information for a single test pattern unit (as needed for ATPG) is to be part of the protocol. Just like the mechanism in place for the protocols the Patterns can be referenced in the Environment and information can be provided for the patterns on a per mode basis. The syntax for doing this is provided below (866 to 892).

864. 865. 866. 867. 868. 869. 870. 871. 872.

Environment (ENV_NAME) { CTL (CTL_NAME) { (PatternInformation { (<Pattern | PatternBurst> NAME { (Purpose(<AtSpeed | ChainContinuity | IDDQ | LogicBIST | MemoryBIST | Parametric | Scan | Endurance | Retention

120

| EstablishMode | TerminateMode 873. | CompatibilityInformation 874. | User USER_DEFINED>)+;) 875. 876. (CycleCount integer;) 877. (Fault {})* 878. (Power power_expr 879. <Average | Maximum>;)* 880. (Identifiers (pat_burst_enum)* {})* 881. 882. 883. (ForeignPatterns { FileName NAME; 884. (BlockName NAME;) 885. (BeginLine INTEGER;) 886. (EndLine INTEGER;) 887. (BeginLabel LABEL;) 888. (EndLabel LABEL;) 889. 890. }) 891. })* 892. }) 893. } 894. } 895. 896. Fault { (Type <Toggle | StuckAt | StuckOpen 897. | Transition | Path | Bridge 898. | PseudoStuckAt | User USER_DEFINED>;) 899. (Boundary <Cell | Primitive>;) 900. 901. (FaultCount INTEGER;) (FaultsDetected INTEGER;) 902. 903. }

To begin with patterns can be given a purpose. Patterns can be applied through scan mechanisms (Scan) at a slower speed, or could be functional tests that are applied at speed (AtSpeed). Patterns could be used for IDDQ testing, Parametric testing, LogicBIST, MemoryBIST, or testing the continuity of the scan chains (ChainContinuity). Special patterns to test memories like Endurance patterns and Retention patterns are identified through the Purpose statement (868 to 875).

121

A very important concept for CTL is defined in the EstablishMode and TerminateMode patterns (873). These patterns describe the steps that need to be taken to get into the test mode and to get out of the test mode that is being described. By relying on such a mechanism, CTL has the ability to handle the needs of any type of digital design. Multiple EstablishMode and TerminateMode patterns can exist. The sequence between these patterns is determined by concepts described in the schedule (section 7.7.4). The last type of Purpose in the list is the CompatibilityInformation. This concept is more appropriate to the scheduling concepts in the next section. It allows for the identification of the ability to schedule patterns in parallel. That is, the compatibility of the patterns is specified. Similar to the mechanisms in place for protocols, Identifiers can be added to patterns. While the syntax allows for all the identifiers to be available for patterns, the one that is appropriate is the identifier for test pattern units (881). Test pattern units are a concept that ATPG tools call test patterns. In the CTL syntax Patterns are a different concept. Identifiers can be used to identify the boundaries of ATPG test patterns. This is shown below with the patterns defined in this section.
Pattern P1 { Pat1: Macro test_sequence { a=1; b=0; s=1; func_out=1; scan_val=0;

} Pat2: Macro test_sequence { a=0; b=1; s=1; func_out=1; scan_val=1; } // many more calls can be in the pattern. } Environment { CTL { PatternInformation { Pattern P1 { Identifiers { EventType TestPatternUnit { Label pat { Prefix; Begin;} } } } } }

122

Patterns can be associated with Fault information or Power information (878 to 880). With the Fault statement the patterns can be associated with different fault models and the coverage of the faults can be specified (896 to 903). Two mechanisms used in the test automation industry for accounting for faults are recognized (900). Faults can be on defined on the ATPG primitives (Primitive) or on the boundaries of the library elements of the design (Cell). Through the Power statement the average and maximum power dissipation of the patterns are specifiable (879, 880). The number of periods or cycles needed to execute the patterns is specified using CycleCount (877). CTL recognizes that test patterns may not be specified using its rules. More importantly for SoC flows there will always be a merging of different methodologies on a single SoC. To allow for a uniform interface and nonCTL flows for test patterns the ability to define a CTL name for a pattern exists and the contents of the pattern are considered Foreign (883 to 890). The foreign patterns in file (FileName, 884) is required to be linked in to the CTL through the FileReference statement in the Environment (149 to 155 on page 31). The subset of patterns that are appropriate are identifiable as a named entity, by labels or by line numbers. Foreign formats could be WGL, Verilog vectors, or even STIL vectors (ones that do not follow CTL syntax rules).

7.7.4 Schedule : PatternExec and PatternBursts

At the top level of the patterns is the schedule or the order in which the patterns are to be run. The patterns of a mode are in PatternBursts (909 to 926) that are brought together all under a PatternExec (904 to 907). A nuance of STIL allows only a single PatternBurst under a PatternExec (906). Thus the PatternBursts that are brought together are those within the single top level burst that is allowed. The PatternBursts are linked in to the CTL-modes in the PatternInformation block of statements of the Environment.

123

Figure 29 shows the framework of the links between the test patterns of the mode and the mode definition. There are two bursts (b1, b2) of test patterns in the mode (mode1) and they are run serially. Clearly the test sequences of the mode have to begin with the ones required to get the design into the mode (EstablishMode sequences) and the test sequences of the mode have to end with the sequences required to get out of the mode (TerminateMode sequences). The syntax for identifying which individual portion is part of these special sequences has been described in the previous section and seen in an example in section 9.3 on page 160 (1577 to 1579). The syntax allows for multiple PatternBursts to be arranged in any order (PatSet), serial order (PatList) or run in parallel (ParallelPatList). With the

ability to nest statements, any sort of ordering can be achieved for different
PatternBursts and Patterns. The syntax for this is given below (909 to

926).
904. 905. 906. 907. 908. 909. 910. 911. 912. 913. 914. 915. PatternExec (NAME) { (Timing NAME; ) (PatternBurst NAME;) } // incomplete syntax shown PatternBurst NAME { (SignalGroups DOMAIN_NAME;)* (MacroDefs DOMAIN_NAME;)* (Procedures DOMAIN_NAME;)* (Variables DOMAIN_NAME;)* (<PatList | PatSet |

124

916. 917. 918. 919. 920. 921. 922. 923. 924. 925. 926.

ParallelPatList (SyncStart | Independent | LockStep)>{ (PAT_NAME_OR_BURST_NAME;)* (PAT_NAME_OR_BURST_NAME { (SignalGroups DOMAIN_NAME;)* (MacroDefs DOMAIN_NAME;)* (Procedures DOMAIN_NAME;)* (Variables DOMAIN_NAME;)* })* // incomplete syntax shown })+ } // incomplete syntax shown

Parallel patterns have an additional attribute associated with it to describe the nature of the parallelism. SyncStart (917) defines the case where the multiple patterns within the construct are synchronized at the beginning. However, the patterns themselves are asynchronous to each other and may have different periods in the waveforms and different vector counts. The Independent attribute is used to indicate that the patterns within the construct have no relationship to each other and can be executed independently. The LockStep keyword is the most rigid construct. It indicates that the patterns run in parallel have the same types of sequences with the same period. Each vector is synchronized across the protocols that are run in parallel. The best way to describe this statement is that LockStep is a lazy way of merging the protocols of the patterns being executed in parallel. The equivalent protocol would be a single protocol where Vectors and Shift statements are written as a single entity. The following example shows a view of two protocols being put together with LockStep. // s1 and s2 are scan-ins MacroDefs set1 { seql { W time1; V { a=#; b=#; } Shift { V { s1=#; clk1=P;}} V { c=#;} } } MacroDefs set2 { seq2 { W time1;

125

V { u=#; v=#; } Shift { V { s2=#; clk2=P;}} V { w=#;} } } MacroDefs written_as_one { seq1_seq2_as_a_result_of_lockstep { W time1; V { a=#; b=#; u=#; v=#; } Shift { V { s1=#; s2=#; clk1=P; clk2=P;}} V { c=#; W=#;} } }
PatternBurst b1 { ParallelPatList LockStep { p1 { MacroDefs set1; } p2 { MacroDefs set2; } } } Pattern p1{Macro seq1{a=1; b=0; s1=1101; c=0;}} Pattern p2{Macro seq2{u=0; v=1; s2=111111; w=0;}} The example shows two patterns p1 and p2 that are invoked in a parallel lock-step schedule in PatternBurst b1. It should be noted how the set of protocols (MacroDef domains) are associated with the patterns in the PatternBurst b1. Pattern p1 uses the protocols defined in set1 and Pattern p2 uses the protocols defined in set2. Using the similar mechanism SignalGroups, Variables and Procedures can be associated with the patterns (919 to 924). The names of entities used from these domains need not use the DOMAIN_NAME due to the temporal nature of the information. The LockStep construct provides the same effect as the Macro seq1_seq2_as_a_result_of_lockstep would provide in a scenario where a unified pattern is written that invokes this protocol. While the example shows no conflicts in the signals for the merge, conflicts are allowed in the signal names in situations where the data is compatible for all the patterns being run in ParallelPatList LockStep. If the two protocols had clk1=P in the Shift statement the equivalent would be a single clk1=P in

126

the combined Shift. If the scan-ins were the same name then the equivalent circuitry to be assumed is a concatenation of the scan data of the two sequences as though the overall scan chain constructed is in the order in which the Patterns are invoked under the LockStep construct. Thus if the two scan-ins (s1 and s2) had the same name say s3, then the scan-data under LockStep of s3 would be s2 s1 (s3 = s2 s1;). Remember that the data furthest from the scan-in gets applied first. Similar to the pattern constructs in the previous section the PatternExecs and PatternBursts are tied in to the test modes with syntax in the PatternInformation block in the Environment (930 to 943).

927. Environment (ENV_NAME) { CTL (CTL_NAME) { 928. (PatternInformation { 929. (PatternExec NAME { 930. (Purpose (<Production 931. | Characterization | Diagnostic 932. 933. | User USER_DEFINED>)+;) 934. (PatternBurst (NAME)+;) 935. 936. (LockStep PROCNAME_OR_MACRONAME 937. (PROCNAME_OR_MACRONAME)+;)* 938. 939. (CycleCount integer;) 940. (Fault {})* 941. (Power power_expr 942. <Average | Maximum>;)* 943. })* 944. 945. // NOTE: Syntax for Information on 946. // PatternBursts given with Patterns. 947. // (867 to 891 on page 119) 948. }) 949. } 950. }

At the highest level the PatternExec can be identified to contain pattern data for Production, Characterization or Diagnostics. Test modes that have no

127

test data associated with it but have EstablishMode and TerminateMode patterns need not have a schedule with a PatternExec and a top level PatternBurst. Fault coverage or power dissipation information can be given for all test patterns of the mode. Schedules that use the LockStep construct require different interpretation of Macros or Procedures that are invoked by the Patterns. This special usage of the protocols is identified by the LockStep statement (936) in the PatternInformation block of statements. It allows for modifications to the protocols without having to look at all the pattern data. The LockStep statement describes the set of protocols that are in LockStep. The order of the protocols is the same as that in the Patterns. Information on PatternBursts is the same as that for Patterns. Its syntax and explanations are described in the previous section 867 to 891 on page 119. While the example of this section showed a single schedule that is executed there could have been many patterns and different possible schedules for them. The compatibility of these patterns can be described in a PatternBurst with the help of the PatSet statements. This PatternBurst is not intended for execution on the tester. This PatternBurst is identified in the Patternlnformation block of the mode with a CompatibilityInformation Purpose.

Chapter 8

CTL Syntax and Semantics: Shortcuts

The previous chapters on CTL syntax provide the basis for describing all the information about test of digital designs. The statements in the CTL block provide a single way to represent any piece of test information. The variations in CTL come from the different ways information is partitioned across multiple CTL blocks of statements in test modes. In this chapter syntax to reduce the volume of the information is provided to make CTL easier for a person to write or modify by hand. 8.1 INCLUDE Through the Include statement CTL information can be partitioned in multiple files and brought together as a single entity. The information that is included appears inline where the Include statement is found.
951. Include " FILE_NAME" (IfNeed <BLOCKTYPE>) ;

The Include statement can occur in any location of the CTL file where a legal CTL statement could occur. The IfNeed option allows for skipping the Include if the current processing of CTL does not need the specified BLOCKTYPE. 8.2 NAMEMAPS

Names have a tendency to get very long especially when the names are related to design entities. CTL provides a mechanism to create shorter names and maintain the mapping to the longer names through the NameMaps construct.
952. Environment (ENV_NAME) { 953. (NameMaps (MAP_NAME) { 954. (ScanCells {(CELLNAME map_string ;)+}) 955. (Signals {(SIGNALNAME map_string ;)+}) 956. (CoreType CORE_TYPE_NAME { 957. (CoreInstance { 958. ( CORE_INST_NAME map_string ;) + 959. })

129

960. 961. 962. 963. 964. 965. 966. 967. 968. 969. 970. 971. }

(Signals { (SIGNALNAME map_string ;) + }) (ScanCells { (CELLNAME map_string ;) + }) }>* (CoreInstance { (CORE_INST_NAME map_string ;) + }) })* // incomplete syntax shown

All the design entities described in CTL can be mapped to strings. As a result of mappings a shorter identifier can be used for design entities that have long (possibly hierarchical) names. The following example shows the mapping syntax of some names.

Environment { NameMaps { ScanCells { d[0] long_name_of_a_ff_0 ; d[1] long_name_of_a_ff_1 ; } Signals { a long_name_for_signal_a ; } CoreType typeA { Signals { i [0] long_name_for_coreA_sig_0 ; i [1] long_name_for_coreA_sig_1 ; } } CoreType typeB { Corelnstance { InstA3 long_name_for_instA3 ; } Signals { i [0] long_natne_for_coreB_sig_0 ; i [1] long_name_for_coreB_sig_l ; }

130

} Corelnstance { InstA1 long_name_for_instA1 ; InstA2 long__name_for_instA2 ; InstB1 long_name_for_instB1 ; }

} }

The example mapping takes names of entities out of multiple examples used in Chapter 4 and in particular the cores are those used in Figure 14 on page 40. The example NameMaps maps some scan cells d[0..1] to the flip-flops long_name_of_a_ff_0 and long_name_of_a _ff_1. Similarly, signal a defined in the Signals block in CTL represents long_name_for_signal_a in the design. It is incorrect CTL to have two different entities in CTL point to the same entity in the design. For example one cannot define another signal b in the CTL Signals block to also point to long_name_for_signal_a. A one-toone mapping of entities is required. As a result of the mappings of the names of core instances and of the signals the cores at the top level of the design InstA1, InstA2 and InstB1 represent cores in the design named long_name_for_instA1, long_name_ for_instA2 and long _name_for_instB1 respectively. Furthermore, the signal InstA1:i[0] is in fact long_name_for_instA1:long_name_for_coreA_sig0. The correlation between various names used in the example CTL and the actual names in the design can be reconstructed using the same mechanism.

8.3 INHERIT
CTL syntax allows for the creation of multiple blocks of the same type. For example multiple Environment blocks can be written. Each block is named with the possibility of one unnamed block. Multiple Environment blocks are used to represent different methods of test information that the design supports. If a design can be completely tested by BIST methods a single Environment would be needed to describe it. If the same design could be tested without BIST with scan methods and ATPG then another Environment could describe it completely. A single design may have multiple CTL - Environments of which only one is selected. Since the design being described is the same, a considerable amount of the information is common across the different Environments. Inheritance allows for the

131

common information to be written in one place and made available in another. Let us first go to the basic form of inheritance that is already available without any new statements in the syntax. In section 5.2.3 on page 30 the concept of nameless blocks and named blocks was introduced. The nameless block contains global information and named blocks contain local information. When this concept is applied to the Environment block of statements the common information across named Environments can be put into a nameless Environment block. Environment { // common information across environments. CTL A { } CTL B { } } Environment testMethod1 { CTL C { // for testMethod1 } CTL D { // for testMethod1 } CTL E { // for testMethod1 } } Environment testMethod2 { CTL B { // new B } CTL C { // for testMethod1 } } In the above example, two CTL blocks of statements are written in a nameless Environment block. Hence they are global and visible in the named Environment blocks (testMethod1, testMethod2). Thus testMethod1 Environment has five (A, B, C, D, E) CTL blocks within by inheriting A and B from the global block. The testMethod2 Environment also inherits A and B from the global block. But in this case, the definition that is inherited from the CTL block B is overridden in testMethod2. Thus testMethod2 has three CTL block within it, A inherited from the global block and B and C are defined within testMethod2. The mechanism of the nameless global block is also usable with the definitions of multiple modes in CTL when information is the same across test modes. This concept was introduced in section 6.1 on page 47 and shown in an example below.

132

Signals { w InOut; x InOut; y InOut; z InOut; } Environment testMethod1 { CTL { Internal { w+x { DataType In;} y+z { DataType Out; } } } CTL C { Internal { w+x+y+z { // no DataType statement } } } CTL D { Internal { y { DataType In; } } } CTL E { Internal { x { DataType Out; } } } } In the Environment testMethod1 there exists an unnamed CTL block that provides the default configurations of the bi-directional signals w, x, y and z. Signals w and x are defined to be used in the input direction and y and z are defined to operate as outputs. Test mode C does not define any DataType information for the signals in the example and hence would have the default global blocks configuration. Test mode D overrides the DataType definition for signal y to have three inputs namely, w, x, y and one output namely z. Test mode E overrides the DataType definition for signal x to make the configuration of the design work with one input w and three outputs x, y, z. While the above mechanism works well to reduce the volume of data for common information across all blocks of the same type there are cases where common information exists across couple of CTL test mode blocks. A

133

special Inherit statement allows for this sharing of information. For the two blocks used in the examples in this section two different statements are defined.
972. 973. 974. 975. 976. 977.

Environment (ENV_NAME) { (InheritEnvironment ENV_NAME ;) (CTL (CTL_NAME) { (Inheri tCTL CTL_NAME ;) })* }

Through the explicit Inherit statements information can be written in one place and reused in the next. Through the inherit statement, a chain of blocks that obtain information from each other is formed. In a downward flow of information in the chain the unnamed block is at the top of the chain. The following is an extension of the examples used in this sub-section. Signals { w InOut; x InOut; y InOut; z InOut; } Environment testMethod1 { CTL { Internal { w+x { DataType In;} y+z { DataType Out; } } } CTL D { Internal { y { DataType In; } } } CTL F { InheritCTL D; Internal { x { DataType Out; } } } }

134

A new CTL block named F is defined that explicitly inherits information from the CTL block D. Information in F is created from a chain of information starting from the unnamed CTL block, then D and then F, where the later blocks override information that conies through the earlier blocks in the chain. Thus, from the unnamed block signals w and x operate as inputs and y and z operate as outputs. In block D the DataType on signal y is overridden to define y as an input. Thus CTL block D has three inputs w, x, y and one output z. CTL block F then gets this information and locally overrides the DataType definition on signal x to be an output. This CTL block F has two inputs w and y and two outputs x and z. The same logic works for any type of statement in the CTL block. Information on the same signal or signal group name defined in the current block overrides the inherited information. As explained in section 7.3 on page 63, the signals and group names are treated differently even though a named group may include the signal. The following example shows how information is maintained with signals and signal group names in the presence of inheritance.
Signals { w InOut; x InOut; y InOut; z InOut; } SignalGroup { indicator = z; } Environment testMethod1 { CTL { Internal { w+x { DataType In;} y+z { DataType Out; } indicator { DataType TestFail { ActiveState U;} } } } CTL D { Internal { y { DataType In; } } } CTL F {

135

InheritCTL D; Internal { x { DataType Out; } indicator { DataType TestFail { ActiveState D;} } }

} }

A group name indicator is also assigned a DataType to identify the signals as part of indicator to be TestFail signals in the unnamed CTL block. The indicator signal goes to a logic-1 in CTL D and the indicator goes to a logic0 in CTL F. The information on the signals within the groups should remain consistent with the information on the signals in every CTL block as discussed in section 7.3 on page 63. In the above example the information on indicator would be inherited to both the blocks regardless of the fact that the information on signal z could have been changed in CTL D and F. Inheritance in CTL blocks allows for the availability of information in all sub-blocks of the CTL block except the PatternInformation block. Now let us consider an example where the Environment is inherited and the CTL blocks within the Environments are also using inheritance. Environment { CTL { // info-x } CTL A { // info-x -CTL B { // info-x -} Environment testMethod1 CTL { // info-y } CTL C { // info-y -CTL D { // info-y -CTL E { // info-y -} Environment testMethod2 CTL B { // info-x -CTL C { // info-x -}

info-a } info-b } { info-c1 } info-d1 } info-e1 } { info-b2 } info-c2 }

136

Environment testMethodS { InheritEnvironment testMethod1; CTL E { // info-y -- info-e3 } } The example above gives the associated chain of information to create each block in the comments of the example. With the same logic used for inheritance in the earlier examples Environment testMethod1 consists of 5 named CTL blocks, Environment testMethod2 consists of 3 named CTL blocks and Environment testMethod3 consists of 5 named CTL blocks .

Chapter 9

Examples Describing Test Information in CTL

Consider the design that was used to describe the introductory example about using CTL as an input to ATPG.

This example design is reused in all the examples to follow to show CTL for:
1. The result of ATPG using the input CTL described in section 1.3.2 on page 4 (1 to 31). 2. The example design packaged as a core. 3. One instance of the example design integrated into a SoC as a core. 4. A complex integration of two instances of the example design in a SoC as cores.

Through the examples in this book the reader should be able to see the usage of CTL constructs described in this book. While every syntax item is not covered, most of the concepts are used in one form or another. Some things are described in the examples just so that the usage of certain constructs is shown. While CTL has the ability to describe a large number of concepts through numerous constructs every usage scenario of CTL does not need to use every available construct.

138

9.1

ATPG OUTPUT IN CTL

A typical ATPG tool would first take in a netlist representation of the design as input in a language such as Verilog or VHDL as shown below. module testcase ( a, b, s, e, c, o ); input a, b, s, e, c; output o; wire n1, n3, n4, n5, n6; nand U3 (.A(n5), .B(n3), .Z(n6) ); not U4(.A(b), .Z(n1) ); not U5(.A(o), .Z(n4) ); nand U6(.A(n1), .B(o), .Z(n3) ); nand U7(.A(n4), .B(a), .Z(n5) ); sdff U2(.D(n6),.CP(c),.TI(s),.TE(e),.Q(o) ); endmodule

Using the CTL of section 1.3.2 on page 4, as input, the tool would perform Design Rule Checking on the internal representation of the netlist and extract the scan chains available to apply the test patterns. Then, faults (let us say stuck-at faults) would be injected in the design. In this example, 48 stuck-at faults are created. Then ATPG is run to determine the test patterns. In this example the output of ATPG that is, the test patterns are to be represented in CTL. The following would be a representation of the test patterns. 978. STIL 1.0 { 979. CTL ThisBook; 980. } 981. Header { Title "Test Patterns of Design"; 982. Date "2002"; 983. 984. } 985. 986. Signals { 987. a In; 988. b In; 989. c In; 990. e In; 991. s In; 992. o Out;

139

993. } 994. SignalGroups { 995. inputs [0..4] = 'a+b+s+e+c'; 996. outputs[0] = o; 997. all[0..5] = 'inputs[0..4] + outputs[0]'; 998. } 999. 1000. Timing { 1001. WaveformTable defaultTiming { 1002. Period '100ns'; 1003. Waveforms { 1004. inputs[0..4] { 1005. 01X { 1006. '10ns' D/U/N; 1007. } 1008. } 1009. outputs[o] { 1010. 01X { 1011. '0ns' X; 1012. '90ns' L/H/X; 1013. } 1014. } 1015. c { 1016. P { 1017. '0ns' D; 1018. '50ns' U; 1019. '60ns' D; 1020. } 1021. } 1022. } 1023. } 1024. 1025. 1026. MacroDefs mInternal { 1027. protocol { 1028. W defaultTiming; 1029. C { e = 1; o=X; } 1030. Shift { V { s = s; c = P;}} 1031. V { inputs[0..4] = inputs[0..4]; 1032. outputs[0] = outputs[0];} 1033. V { c = P; outputs[0]=X; }

140

1034. 1035. 1036. 1037. 1038. 1039. 1040. 1041. 1042. 1043. 1044. 1045. 1046. 1047. 1048. 1049. 1050. 1051. 1052. 1053. 1054. 1055. 1056. 1057. 1058. 1059. 1060. 1061. 1062. 1063. 1064. 1065. 1066. 1067. 1068. 1069. 1070. 1071. 1072. 1073. 1074.

C { e = 1;} Shift { V { o = o; c = P; }} V { c=0; 6=0; o=X; } }

initProtocol { W defaultTiming; V { inputs[0..4] = XXX00; outputs[0]=X;} }

}
PatternBurst bTests { PatList { initInternal { MacroDefs mInternal; } stuckAtTestPatterns { MacroDefs mInternal; } } } PatternBurst allBursts { PatList { bTests; } } PatternExec eInternal { PatternBurst allBursts; } Environment eDesign { CTL tmInternal { TestMode InternalTest; DomainReferences { MacroDefs mInternal; } PatternInformation { PatternExec eInternal { Purpose Production; PatternBurst bTests; Fault {

141

1075. Type StuckAt; Boundary Primitive; 1076. FaultCount 48; 1077. 1078. FaultsDetected 48; 1079. } 1080. } 1081. Macro protocol { Purpose DoTest; 1082. 1083. UseByPattern Scan; 1084. } 1085. Macro initProtocol { Purpose ModeControl; 1086. UseByPattern EstablishMode; 1087. 1088. } Pattern initInternal { 1089. Purpose EstablishMode; 1090. 1091. } 1092. } 1093. } 1094. } 1095. 1096. Pattern initInternal { 1097. Macro initProtocol; 1098. } 1099. Pattern stuckAtTestPatterns { 1100. Macro protocol {s=0; inputs[0..4]=10110; outputs[0]=0; o=0; } 1101. 1102. Macro protocol {s=0; inputs[0..4]=00000; outputs[0]=0; o=0; } 1103. Macro protocol {s=0; inputs[0..4]=10000; 1104. outputs[0]=0; o=1; } 1105. Macro protocol (s=l; inputs[0..4]=11100; 1106. outputs [0]=1; o=0; } 1107. Macro protocol {s=l; inputs[0..4]=10100; 1108. outputs[0]=1; o=l; } 1109. 1110. }

The first few statements of the example define the version of CTL used (978 to 980). In this case the example uses CTL syntax as introduced in this book. Furthermore, through the Header block of statements (981 to 984) some

142

comments are provided about the example itself. In this case the CTL describes Test Patterns of Design and was created in 2002. ATPG patterns are written to inputs and outputs of the design. Thus the only design constructs needed in this example are the Signals (986 to 993). In this case, 6 signals of the design are defined of which 5 are inputs of the design and 1 is an output. For the convenience or use and necessity of identifying multiple parameters to a Macro on the same signal SignalGroups are defined for the signals of the design (994 to 998). Three signal groups namely inputs[0..4], outputs[0] and all[0..5] are defined in this example. The remainder of the example represents the patterns and information about the test patterns. One should begin reading the example from the Environment block of statements (1064 to 1094) as it is the block at the top level in the information hierarchy. Test patterns test the internals of the design and are always defined in the InternalTest mode. Thus the example has a single CTL mode defined called tmInternal (1065 to 1093) and it is identified to be of type InternalTest (1066). Most of the blocks needed to create all the information are written as nameless (global) blocks except for the MacroDefs block of information. The Timing block of statements (1000 to 1024), and the SignalGroups block of statements (994 to 998) are nameless. For the purposes of the information in this example, the MacroDefs block could also have been nameless as it applies to all (of the one) test modes defined in the example. Since this example is more like a running example the MacroDefs domain (1026 to 1043) is created from a need in a following example. The named MacroDefs block is brought into the scope of the test mode of the Environment through the DomainReferences statement (1067 to 1069). The test mode defined is to represent test patterns in CTL. All pattern-like information is provided in the PatternInformation block of statements (1070 to 1092). The test patterns rely on a certain mode configuration that is established by an EstablishMode pattern. This initialization pattern is identified in the PatternInformation block of statements (1089 to 1091), defined in statements 1096 to 1098 and invoked (1047) prior to the execution of the test patterns of the test mode. Though the PatternExec statement the location of the test patterns for the test mode is identified (1071 to 1080). In this case the test patterns are identified to be all contained in a single PatternBurst called bTests (1073). The fault coverage of all the tests is identified to be 100%, that is 48 of the 48 stuck-at faults that were inserted on the ATPG primitives were detected (1074 to 1079). The PatternExec itself and the PatternBurst is defined outside the Environment (1045 to 1062). The PatternExec eInternal calls out

143

PatternBurst allBursts which in turn calls out PatternBurst bTests. While the two levels of indirection may seem unnecessary, for the current example it is needed when multiple bursts are brought together from different test modes. Looking into PatternBurst bTests (1045 to 1054), two Patterns (initInternal and stuckAtTestPatterns) are invoked in sequential order. Both patterns use MacroDefs defined in the MacroDefs-domain mInternal. The patterns (1096 to 1110) provide the data that is applied using the sequences in the Macros available to it. This design has one initialization pattern and five test patterns. The Macros used are initProtocol and protocol (1026 to 1043). The sequence used by the initialization pattern uses the defaultTiming (1040) defined in the Timing block of statements (1001 to 1023), and identified in the Environment as the sequence used to establish the test mode (1085 to 1088). The other Macro namely protocol also uses defaultTiming and is used to apply the five ATPG test patterns and is identified in the Environment as such with the DoTest keyword (1081 to 1084). This keyword indicates that the test patterns are not overlapped, that is the scan-in and scan-out operation of consecutive tests is not overlapped in this example. With the signal e set to 1, the scan data is applied to signal s with successive clock pulses on c. Then all the inputs including s are applied a stimulus, and outputs are observed. In the next cycle, the capture clock is pulsed and no outputs are measured. Finally, the test is completed by measuring signal o for values in the shift register.

9.2

DESCRIBING CORES IN CTL

In this section we take the example design for which we had created test patterns in CTL and package the design in CTL as a core. For the purposes of this design it would mean adding more information to the test pattern example to complete the information of the InternalTest mode of the design. This would include how the signals are used in the product or the definition of the design entities that the core provider would like to make available to the system integrator. Other relevant configurations of the design would also have to be described.

1111. 1112. 1113. 1114. 1115. 1116. 1117.

STIL 1.0 { CTL ThisBook; } Header { Title "CTL for the Design as a Core"; Date "2002"; }

144

1118. 1119. 1120. 1121. 1122. 1123. 1124. 1125. 1126. 1127. 1128. 1129. 1130. 1131. 1132. 1133. 1134. 1135. 1136. 1137. 1138. 1139. 1140. 1141. 1142. 1143. 1144. 1145. 1146. 1147. 1148. 1149. 1150. 1151. 1152. 1153. 1154. 1155. 1156. 1157. 1158.

Signals { a In; b In; c In; e In; s In; o Out; } SignalGroups { inputs [0..4] = 'a+b+s+e+c'; outputs [0] = o; all[0..5] = 'inputs[0..4] + outputs [0]'; } ScanStructures ssInternal { ScanChain internalChain_l { ScanLength 1; ScanCells c [0]; ScanIn s; ScanOut o; ScanMasterClock c; ScanEnable e; } } Timing { WaveformTable defaultTiming { Period '100ns'; Waveforms { inputs[0..4] { 01X { '10ns' D/U/N; } } outputs[0] { 01X { 'Ons' X; '90ns' L/H/X; } }

145

1159. c { 1160. P { 1161. '0ns' D; 1162. '50ns' U; 1163. '60ns' D; 1164. } 1165. } 1166. } 1167. } 1168. } 1169. 1170. MacroDefs mNormal { 1171. initProtocol { 1172. W defaultTiming; 1173. V { inputs[0..4]=XXX00; outputs [0]=X;} 1174. } 1175. } 1176. 1177. MacroDefs mInternal { protocol { 1178. 1179. W defaultTiming; 1180. C { e = 1; o=X; } 1181. Shift { V { s = s; c = P;}} 1182. V { inputs[0..4] = inputs[0..4]; 1183. outputs[0] = outputs[0];} 1184. V { c = P; outputs[0]=X; } 1185. C { e = 1; } 1186. Shift { V { o = o; c = P; }} 1187. V { c=0; e=0; o=X; } 1188. } 1189. 1190. initProtocol { 1191. W defaultTiming; 1192. V { inputs[0..4] = XXX00; outputs[0]=X;} 1193. } 1194. } 1195. 1196. PatternBurst bNormalSequence { PatList { 1197. 1198. initNormal { MacroDefs mNormal; } 1199. }

146

1200. } 1201. PatternBurst bTests { PatList { 1202. initInternal { MacroDefs mInternal; } 1203. stuckAtTestPatterns { 1204. MacroDefs mInternal; 1205. 1206. } 1207. } 1208. } 1209. PatternBurst allBursts { PatList { 1210. bTests; 1211. 1212. } 1213. } 1214. PatternExec eInternal { PatternBurst allBursts; 1215. 1216. } 1217. 1218. Environment eDesign { 1219. CTL tmNormal { 1220. 1221. TestMode Normal; DomainReferences { 1222. MacroDefs mNormal; 1223. 1224. } 1225. Internal { 1226. a+b+o { DataType Functional;} c { DataType Functional MasterClock; 1227. } 1228. e { DataType TestMode 1229. { ActiveState D;}} 1230. s { DataType Unused; } 1231. } 1232. PatternInformation { PatternBurst bNormalSequence { 1233. 1234. Purpose EstablishMode; 1235. } 1236. Macro initProtocol { 1237. Purpose ModeControl; 1238. UseByPattern EstablishMode; 1239. }

147

1240. 1241. 1242. 1243. 1244. 1245. 1246. 1247. 1248. 1249. 1250. 1251. 1252. 1253. 1254. 1255. 1256. 1257. 1258. 1259. 1260. 1261. 1262. 1263. 1264. 1265. 1266. 1267. 1268. 1269. 1270. 1271. 1272. 1273. 1274. 1275. 1276. 1277. 1278. 1279. 1280.

} }
CTL tmInternal { TestMode InternalTest; DomainReferences { MacroDefs mInternal; ScanStructures ssInternal; } Focus { PatternTypes Scan; } Internal { c { DataType TestControl MasterClock ScanMasterClock { AssumedInitialState D; } DriveRequirements { TimingSensitive { Period Min 100ns; Period Max 200ns; Pulse High Min 8ns; Pulse High Max 30ns; EarliestTime 50ns; } } } e { DataType TestControl ScanEnable { ActiveState ForceUp; } DriveRequirements { TimingSensitive { LatestTime 45ns; } } } s { CaptureClock c { LeadingEdge;} DataType TestData ScanDataIn { ScanDataType Internal; DataRateForProtocol Maximum 1; }

148

1281. 1282. 1283. 1284. 1285. 1286. 1287. 1288. 1289. 1290. 1291. 1292. 1293. 1294. 1295. 1296. 1297. 1298. 1299. 1300. 1301. 1302. 1303. 1304. 1305. 1306. 1307. 1308. 1309. 1310. 1311. 1312. 1313. 1314. 1315. 1316. 1317. 1318. 1319. 1320. 1321.

ScanStyle MultiplexedData;

} o { LaunchClock c { LeadingEdge; } DataType TestData ScanDataOut { ScanDataType Internal; DataRateForProtocol Maximum 1; } DataType Functional; ScanStyle MultiplexedData; } a+b { DataType Functional TestData; DriveReguirements { TimingSenaitive { Reference c { ReferenceEdge Leading; Setup 5ns; Hold 5ns; } } } }
atternInformation { PatternExec eInternal { Purpose Production; PatternBurst bTests; Fault { Type StuckAt; Boundary Primitive; FaultCount 48; FaultsDetected 48; } } PatternBurst bTests { Purpose Scan; } Macro protocol { Purpose DoTest; UseByPattern Scan; } Macro initProtocol {

149

Purpose ModeControl; 1322. 1323. UseByPattern EstablishMode; 1324. } Pattern initInternal { 1325. 1326. Purpose EstablishMode; 1327. } 1328. } 1329. } 1330. } 1331. 1332. Pattern initNormal { Macro initProtocol; 1333. 1334. } 1335. Pattern initInternal { 1336. Macro initProtocol; 1337. } 1338. Pattern stuckAtTestPatterns { 1339. Macro protocol {s=0; inputs[0..4]=10110; outputs[0]=0; o=0; } 1340. Macro protocol {s=0; inputs[0..4]=00000; 1341. outputs[0]=0; o=0; } 1342. 1343. Macro protocol {s=0; inputs[0..4]=10000; 1344. outputs[0]=0; o=1; } Macro protocol {s=1; inputs[0..4]=11100; 1345. outputs[0]=1; 0=0; } 1346. Macro protocol {s=1; inputs[0..4]=10100; 1347. outputs[0]=1; o=l; } 1348. 1349. } The example design has two modes of operation that are to be described in CTL. In one mode the design operates to perform the intended function and in the other mode test patterns are applied. These test modes are described in the Environment (1218 to 1330) in two different CTL blocks of statements. The normal functioning mode of the design is called tmNormal (1220 to 1241) and the mode in which the internal logic is tested is called tmInternal (1243 to 1329). These test modes are identified (by the TestMode statement) to be the Normal (1221) and InternalTest (1244) test modes respectively. Normal Mode:

150

Not much needs to be described about the normal operation of the design for the purposes of test. For the normal mode the following are described in the example. The sequence to establish the configuration. The signals and their associated function. All patterns associated with the normal operation of the design are included in the bNormalSequence which in this case is only the EstablishMode sequence (1196 to 1200). The top level Burst in this mode is identified in the PatternInformation statements of the associated test mode with the appropriate Purpose (1233 to 1235). The protocols used by the patterns of this mode are contained in the MacroDefs block call mNormal (1170 to 1175) and brought into the scope of the mode with the DomainReferences statement (1222 to 1224). The only protocol of this mode is identified to be the protocol that is used by the EstablishMode patterns (1236 to 1239). It should be noted that the PatternBurst of this mode (1196) was not included in any PatternExec. This is because no relative schedule or ordering of execution of the contents of the patterns of the Normal mode needed to be provided with the InternalTest mode. If an ordering were to be specified relative to the patterns of other modes then bNormalSequence would have to be invoked by allBursts (1209). To maintain the same meaning as the example the PatList in allBursts (1210) would have to be changed to PatSet. Finally the signals and their associated function is identified in the Internal block of statements (1225 to 1231). Signal e is identified to be the test mode signal that is held to a logic-0 after the initialization patterns of the mode are executed for the mode to be valid. Signal c is identified to be a clock and signals a, b and o are available for use for the normal functioning of the design. InternalTest Mode: The internal test mode of the design builds on the example of the previous section. Since initialization of the mode and the pattern description were already covered in the previous section they are repeated in the example for completeness. The following explanation builds on the explanation in the previous section. The design entity needed for the normal mode information and the test pattern information was the Signals (1119 to 1126) of the core. While packaging the design as a core one may want to describe the scan chains that

151

are used in the test mode. Typical informational requirements for cores would only require scan chains that are involved in the external test mode to be described. However, in this example the internal scan chains are described to show the fundamental mechanism of describing scan chains in CTL. The scan chains are a design entity that is described in the ScanStructures block of statements (1133 to 1142). Since these scan structures are only needed for the internal test mode of the design, a domain name (ssInternal) is used for the ScanStructures (1133) and the DomainReferences block of statements (1245 to 1248) is used to bring the scan structures into the scope of the test mode. The Internal block of statements (1252 to 1302) in tmInternal describes some information about the internals of the design on the signals of the core. 1. Lines 1253 to 1266: Signal c is described to be a clock, which is assumed to be at a logic-0 at the beginning of every protocol in the test mode. This clock is used as the scan clock and as the functional clock in the test mode. While the timing used by the sequences in the test mode pulse the clock at 50ns in a 100ns clock period with a pulse width of 10ns, the information in the Internal block describes that the clock period can be varied between 100ns and 200ns. The pulse width could be anywhere from 8ns to 30ns and it could not occur before 50ns into the period. 2. Lines 1267 to 1275: Signal e is used as a scan enable signal in the core with a logic-1 needed on the signal for enabling the scan operation. The scan chain it is associated with is to be determined from the active scan chain definitions in the mode. The timing of signal changes in the waveforms for the scan enable can be changed to occur anywhere in the period from 0-45ns without impacting the test data.

3. Lines 1276 to 1282: Signal s is described to be a test only scan-in signal that is applied an extra value beyond the scan values for the scan chain. This is typically not the case for scan vectors that target stuck-at faults. This characteristic is quite typical when the scan-in is shared with a functional input of the design. In the example, the test patterns defined apply a special value to the scan-in after the scan chain is loaded. The scan-in is connected to memory elements that capture the values on the leading edge of the c signal (the clock of the design). The scan chain is described to be constructed out of memory elements using a multiplexor on the data path to switch between the function of the design and the data from the scan chain. The scan chain is an internal scan chain of the design.

152

4. Lines 1283 to 1290: Signal o is described to be a functional output that is shared with the scan-out. This scan chain is an internal chain of the design and is constructed with memory elements and multiplexors on the data path. The test protocols measure an extra value on the scan data out outside of the values in the memory elements of the scan chain. The values on the scan out are available from memory elements that are sensitive to the leading edge of the c signal. 5. Lines 1291 to 1301: Signals a and b are described to be functional signals that also get test data. Though the test patterns use certain timing to apply the values on these signals the timing can be changed such that the setup and hold times (5ns) of the signal relative to the leading edge of the signal c are maintained.

The core itself does not have any partitions (sub-cores) within it to partition the data intelligently across modes. Though in this case the focus of information in the mode is not interesting, the statement (1249 to 1251) is used to say that test patterns in this mode are only scan test patterns and are not targeted to any particular entity.

9.3 INTEGRATING A CORE IN AN SOC

The example design has been packaged as a core in the previous section with all the test information in CTL. Now a system integrator can attempt to integrate this core into his/her design (SoC) to create a larger design. For test this means that the CTL of the core is consumed (by the system integrator or tools performing the system integration task), to successfully test the SoC. Test patterns that came with the CTL can be reused and applied from the boundary of the SoC. Test patterns can be created for the SoC logic outside the cores in the presence of the cores. The information in the CTL of the previous example is sufficient to perform both the tasks. In this example, the testing of the SoC logic outside the core is ignored. Before focusing primarily on the reuse of the test patterns of the core and the process of applying them from the boundary of the SoC, let us dwell a bit more on the part we are ignoring. The CTL of the core being integrated does not have any description of a boundary scan chain in the core that could be reused to test the SoC logic outside the core. Thus most probably a wrapper would have to be implemented around the core. The wrapper implementation would be determined by information in the CTL of

153

the core that is to be wrapped. Given all the information on data types and how signals are used, wrapper cells could be implemented for signals a and b of the core. Wrapping a core isolates the core from the rest of the logic around the core. In this example we stay focussed on reusing the test patterns of the core in the SoC. This task has been also called test-data-porting. The original CTL of the core provides the test information about the core and the task at hand is to be able to apply those tests from accessible points on the SoC. The example is about doing this task in CTL. That is, a new CTL is being created at the SoC boundary that represents the tests for the core.

Figure 31 shows a possible instantiation of the core in the SoC and the necessary connections needed to provide access to the signals of the core. An already existing scan chain on the SoC is used to provide a values to signals a and b of the core. The scan chain shown could have been a wrapper scan chain for the core. The other signals of the core are given direct access in the mode in which the core is being tested from inputs and outputs of the SoC. To constantly remind us of the boundary of the SoC and the new context, the signals of the SoC are given names with a prefix soc_. The test patterns of the core are to be applied from the signals of the SoC and the scan chains that are accessible from the boundary of the SoC. The original CTL of the core described in the previous section is used as input to create a new CTL at the boundary of the SoC. This new CTL at the SoC boundary only represents the

154

test patterns needed for the testing of the embedded core. The goal of this example is to show how test-data-porting works in the context of CTL. To begin with let us define the design entities being referred to in this example. Since the example is at the boundary of the SoC, the Signals block represents this boundary (1358 to 1361). In this example there are six inputs and two outputs. One core is being integrated into the SoC. This core is of type, eDesign (1370 to 1389). This core comes with an identified boundary (Signals a, b, c, e, s, o) and some scan chains (ScanCells c[0]). This core is given an instance name egDesign (1390 to 1392). All the patterns that come with the core are copied over (or included) from the original CTL and referenced during the instantiation of the core. Finally, the scan chains on the SoC are defined (1394 to 1411). In this example, the SoC has two scan chains. One scan chain (of length 4) is in the logic outside the core and one scan chain (of length 1) is composed of the scan chain of the core being integrated. One should notice how the scan chains of the core are integrated in to the definition of the scan chains of the SoC.

1350. 1351. 1352. 1353. 1354. 1355. 1356. 1357. 1358. 1359. 1360. 1361. 1362. 1363. 1364. 1365. 1366. 1367. 1368. 1369. 1370. 1371.

STIL 1.0 { CTL ThisBook; } Header { Title "CTL for the Core Embedded in SoC"; Date "2002"; } Signals { soc_in[0..5] In; soc_out[0..1] Out; } Variables { SignalVariable SignalVariable SignalVariable SignalVariable }

inputs[0..4]; outputs[0]; s; o;

CoreType eDesign { Signals {

155

1372. 1373. 1374. 1375. 1376. 1377. 1378. 1379. 1380. 1381. 1382. 1383. 1384. 1385. 1386. 1387. 1388. 1389. 1390. 1391. 1392. 1393. 1394. 1395. 1396. 1397. 1398. 1399. 1400. 1401. 1402. 1403. 1404. 1405. 1406. 1407. 1408. 1409. 1410. 1411. 1412.

a b c e s o

In; In; In; In; In; Out;

} ScanStruetures { ScanChaIn internalchain_1 { ScanLength 1; ScanCells c[0]; ScanIn s; ScanOut o; scanMasterClock c; ScanEnable e; } }
} CoreInstance egDesign { egCore1 {PatternBurst bTests;} }
ScanStructures ssInternal { ScanChain chain1 { ScanLength 4; ScanCells wc[0..3]; ScanIn soc_in[1]; ScanOut soc_out[0]; ScanMasterClock soc_in[2]; ScanEnable soc_in[4]; } ScanChain chain2 { ScanLength 1; ScanCells egCore1:c[0]; ScanIn soc_in[3]; ScanOut soc_out[1]; ScanMasterClock soc_in[5]; ScanEnable socin[4]; } }

156

1413. Timing { WaveformTable defaultTiming { 1414. Period '100ns'; 1415. Waveforms { 1416. soc_in[0..5] { 1417. 01X { 1418. '10ns' D/U/N; 1419. 1420. } 1421. } soc_out[0..1] { 1422. 01X { 1423. '0ns' X; 1424. '90ns' L/H/X; 1425. 1426. } 1427. } soc_in[2]+soc_in[5] { 1428. 1429. P { '0ns' D; 1430. '50ns' U; 1431. '60ns' D; 1432. 1433 . } 1434. } 1435. } 1436. } 1437. } 1438. 1439. MacroDefs mInternal { protocol { 1440. W defaultTiming; 1441. C { soc_in[4] = 1; soc_out[1]=X; } 1442. Shift {V {soc_in[3]=s; soc_in[5]=P; 1443. soc_in[1]=\wXX inputs[0..1];}} 1444. V { soc_in[3..5] = inputs[2..4]; 1445. soc_out[1] = outputs[0];} 1446. V { soc_in[5] = P; soc_out[1]=X; } 1447. 1448. C { soc_in[4] = 1;} 1449. Shift { V { soc_out[1] = o; soc_in[5] = P; }} 1450. 1451. V { soc_in[5] =0; soc_in[4]=0; soc_out [1]=X; } 1452. 1453. }

157

1454. 1455. initProtocol { W defaultTiming; 1456. 1457. V { soc_in[0..5]=1X0X00; 1458. soc_out[0..1]=XX;} 1459. } 1460. } 1461. 1462. PatternBurst bTests { PatList { 1463. 1464. initInternal { MacroDefs mInternal; } 1465. stuckAtTestPatterns { 1466. MacroDefs mInternal; 1467. } 1468. } 1469. } 1470. PatternBurst allBursts { PatList { 1471. bTests; 1472. 1473. } 1474. } 1475. PatternExec eInternal { PatternBurst allBursts; 1476. 1477. } 1478. 1479. Environment eSoC { 1480. CTL tmInternal { 1481. 1482. TestMode InternalTest; DomainReferences { 1483. 1484. MacroDefs mInternal; 1485. ScanStructures ssInternal; 1486. } 1487. Focus CoreInstance egCorel { PatternTypes Scan; 1488. PatternBurst bTests; 1489. TestMode InternalTest; 1490. 1491. } Internal { 1492. 1493. soc_in[0] { DataType TestMode 1494. ActiveState U;}}

158

1495. 1496. 1497. 1498. 1499. 1500. 1501. 1502. 1503. 1504. 1505. 1506. 1507. 1508. 1509. 1510. 1511. 1512. 1513. 1514. 1515. 1516. 1517. 1518. 1519. 1520. 1521. 1522. 1523. 1524. 1525. 1526. 1527. 1528. 1529. 1530. 1531. 1532. 1533. 1534. 1535.

soc_in[5]+soc_in[2] { DataType TestControl MasterClock ScanMasterClock { AssumedInitialState D;

} DriveRequirements { TimingSensitive { Period Min 100ns; Period Max 200ns; Pulse High Min 8ns; Pulse High Max 30ns; EarliestTime 50ns; } } } soc_in[4] { DataType TestControl ScanEnable { ActiveState ForceUp; } DriveRequirements { TimingSensitive { LatestTime 45ns; } } } soc_in[3] { CaptureClock soc_in[5] { LeadingEdge;} DataType TestData ScanDataIn { ScanDataType Internal; DataRateForProtocol Maximum 1; } ScanStyle MultiplexedData; } soc_in[l] { CaptureClock soc_in[5] { LeadingEdge;} DataType TestData ScanDataIn { ScanDataType Internal; DataRateForProtocol Maximum 0; }

159

1536. 1537. 1538. 1539. 1540. 1541. 1542. 1543. 1544. 1545. 1546. 1547. 1548. 1549. 1550. 1551. 1552. 1553. 1554. 1555. 1556. 1557. 1558. 1559. 1560. 1561. 1562. 1563. 1564. 1565. 1566. 1567. 1568. 1569. 1570. 1571. 1572. 1573. 1574. 1575. 1576.

ScanStyle MultiplexedData;

} soc_out[1] { LaunchClock soc_in[5] { LeadingEdge; } DataType TestData ScanDataOut ScanDataType Internal; DataRateForProtocol Maximum } DataType Functional; ScanStyle MultiplexedData; } soc_out[0] { LaunchClock soc_in[5] { LeadingEdge; } DataType TestData ScanDataOut ScanDataType Internal; DataRateForProtocol Maximum } ScanStyle MultiplexedData; }
atternInformation { PatternExec eInternal { Purpose Production; PatternBurst bTests; Fault { Type StuckAt; Boundary Primitive; FaultCount 48; FaultsDetected 48; } } Macro protocol { Purpose DoTest; UseByPattern Scan; } Macro initProtocol { Purpose ModeControl; UseByPattern EstablishMode; }

{ 1;

{ 0;

160

1577. 1578. 1579. 1580. 1581. 1582. 1583. 1584. 1585. 1586. 1587. 1588. 1589. 1590. 1591. 1592. 1593. 1594. 1595. 1596. 1597. 1598.

Pattern initInternal { Purpose EstablishMode; }

} } }
Pattern initInternal { Macro initProtocol; } Pattern stuckAtTestPatterns { Macro protocol {s=0; inputs[0..4]=10110; outputs[0]=0; o=0; } Macro protocol {s=0; inputs[0..4]=00000; outputs[0]=0; o=0; } Macro protocol {s=0; inputs[0..4]=10000; outputs[0]=0; o=1; } Macro protocol {s=1; inputs[0..4]=11100; outputs[0]=1; 0=0; } Macro protocol {s=1; inputs[0..4]=10100; outputs[0]=1; 0=1; } }

One should note the similarity in the information that existed on the signals in the Internal block of the CTL of the core (1252 to 1302 on page 147) and the information in this test mode of the SoC's CTL (1492 to 1557). The reason for this is that the type of information at one end of a direct connection is always the same as the information at the other end of the connection. That is if a signal is a clock on the boundary of the core and if the signal is connected to a top level signal of the SoC in the test mode the signal of the SoC would also be a clock. The previous example explained how the information is to be interpreted and it is not repeated here. The reader should notice the subtle differences in the information content to boost ones understanding of CTL. Now let us focus on the patterns that were copied over from the original CTL of the core. If these patterns were in a separate file they need not have been physically copied but could have been included in the existing CTL. The Patterns call Macros passing parameters that are signals on the boundary of the core and were defined in the cores CTL in the Signals block (1584 to 1598). Now these signals are internal points in the SoC and do not exist as

161

far as the test patterns are concerned. CTL is designed to avoid changing the patterns of the core to translate the test pattern boundary. Thus the first task is to define signal variables in place of these signals. The signal variables are defined in the Variables block (1363 to 1368), represent carriers of waveform characters that would eventually be assigned to signals of the SoC. The part of the pattern data that changes is the protocol. A new Macro is written (1439 to 1460) to replace the original Macro that was being called by the patterns of the stand-alone core. This new Macro reflects the new mechanism through which the data of the patterns is applied. If one goes back to the original Macro and compares it with the current one, the changes can be seen. Most importantly, the LHS (left-hand-side) of the assignments in the new Macro represent signals on the SoC and the RHS (right-handside) of the assignments in the new Macro represent the signal variables that are being passed into the Macro. The Macro for applying the test begins with the setup of the scan-enable signal (soc_in[4]), and a Shift operation to deliver the values for the scan cells in the two chains of the SoC. As a result the scan chain of the core get the appropriate data and signals a and b of the core get their stimulus (1443, 1444). This shift operation is performed with the pulsing of the clock (soc_in[5]). After the shift operation, in the next cycle, the values that need to be applied directly are applied or measured. Note that the values for a and b are not included here as they have been applied through the shift operation. The following period the capture clock is pulsed and finally the values one of the scan chains are observed. Thus one can see by modifying the Macro named protocol the patterns which were written to the boundary of the core now operate on the boundary of the SoC. The changes to the initProtocol are trivial. The PatternExec and the PatternBursts that represent the schedule are the same as that of the previous example. Usually this changes, as many more tests would get applied to complete the test of the SoC. It did not change in this example because the example was only about the testing of the core from the boundary of the SoC. The focus statement of this CTL changes to reflect that the patterns of the mode being described were for the core. The core was put into an InternalTest mode and was tested with Scan patterns (1487 to 1491).

9.4

INTEGRATING MULTIPLE CORES IN A SOC

In this section we up the notch on the difficulty of the example to show certain features of CTL that were not used in the earlier examples. This time

162

two instances of the same core are taken to create name clashes. As a result this example shows the name resolution mechanisms in CTL. Since this is the last example of this book, complexity is also added to the SoC integration task by serializing the chains of the two cores being instantiated. The typical usage of CTL may not use the capabilities shown in this example. The same design is maintained so that concepts and explanations of the previous examples remain valid and do not need further clarification. Just like the previous section, the goal of this section is to perform the integration task and provide the CTL at the top level. This time the CTL of the top level only describes the testing of the two cores that are instantiated in the SoC.

The structures and connections in Figure 32 would have been created by looking at the CTL that came with the cores. While the integration of each core is very similar to each other and to the integration in the previous example, there is a difference created by the serialization of the scan chains of the two cores. In this kind of integration the statement DataRateForProtocol (1279 and 1286 on page 147) in the CTL that came with the core plays an important role. This statement describes the requirement of an extra value outside of the scan values on the scan-in and

163

scan-out of the chain. If the scan chains of the two cores are connected to each other directly the ability to observe/control the extra value on the scanoutput/scan-input of the cores that are connected to each other is lost. Thus it can be seen that the integration of the two cores in this example has a scan only flip-flop inserted between the two scan chains. The CTL that represents the tests for the integrated cores is shown below (1599 to 1899).
1599. 1600. 1601. 1602. 1603. 1604. 1605. 1606. 1607. 1608. 1609. 1610. 1611. 1612. 1613. 1614. 1615. 1616. 1617. 1618. 1619. 1620. 1621. 1622. 1623. 1624. 1625. 1626. 1627. 1628. 1629.

STIL 1.0 { CTL ThisBook; } Header { Title "CTL for the Core Embedded in SoC; Date "2002"; } Signals { soc_in[0..5] In; soc_out[0..1] Out; } Variables sgInternal_1 { SignalVariable inputs[0..4]; SignalVariable outputs[0]; SignalVariable s; SignalVariable o; } SignalGroups sgInternal_2 { SignalVariable inputs[0..4]; SignalVariable outputs[0]; SignalVariable s; SignalVariable o; } CoreType eDesign { Signals { a In; b In; c In; e In;

164

1630. 1631. 1632. 1633. 1634. 1635. 1636. 1637. 1638. 1639. 1640. 1641. 1642. 1643. 1644. 1645. 1646. 1647. 1648. 1649. 1650. 1651. 1652. 1653. 1654. 1655. 1656. 1657. 1658. 1659. 1660. 1661. 1662. 1663. 1664. 1665. 1666. 1667. 1668. 1669. 1670.

s In; o Out; } ScanStructures { ScanChain internalChain_1 { ScanLength 1; ScanCells c[0]; ScanIn s; ScanOut o; ScanMasterClock c; ScanEnable e; } } } CoreInstance egDesign { egCore1 {PatternBurst bTests1;} egCore2 {PatternBurst bTests2;} }
ScanStructures { ScanChain chain1 { ScanLength 4; ScanCells wc [0..3]; ScanIn soc_in[1]; ScanOut soc_out[0]; ScanMasterClock soc_in[2]; ScanEnable soc_in[4]; } ScanChain chain2 { ScanLength 3; ScanCells egCore1:c[0] sc egCore2:c[0]; ScanIn soc_in[3]; ScanOut soc_out[1]; ScanMasterClock soc_in[5]; ScanEnable soc_in[4]; } } Timing { WaveformTable defaultTiming { Period '100ns';

165

1671. 1672. 1673. 1674. 1675. 1676. 1677. 1678. 1679. 1680. 1681. 1682. 1683. 1684. 1685. 1686. 1687. 1688. 1689. 1690. 1691. 1692. 1693. 1694. 1695. 1696. 1697. 1698. 1699. 1700. 1701. 1702. 1703. 1704. 1705. 1706. 1707. 1708. 1709. 1710. 1711.

Waveforms { soc_in[0..5] { 01X { '10ns' D/U/N; } } soc_out[0..1] { 01X { '0ns' X; '90ns' L/H/X; } } soc_in[2]+soc_in[5] { P { '0ns' D; '50ns' U; '60ns' D; } } }

} } MacroDefs { initSoC { V { soc_in[0..5]=1X0XX0; soc_out[0..1]=XX; } } }

MacroDefs mInternal_1 { protocol { W defaultTiming; C { soc_in[4] = 1; } Shift {V {soc_in[3]=s; soc_in[5]=P; soc_in[1] =inputs[0..1];}} V { soc_in[3..5] = inputs[2..4];} V { soc_in[5] = P; } C { soc_in[4] = 1;} Shift { V { soc_out[1]=outputs[0] o; soc_in[5] = P; }} V { soc_in[5]=0; soc_in[4]=0;

166

soc_out [1] =X; } 1712. 1713. } initProtocol { 1714. W defaultTiming; 1715. V { soc_in[3..5]=X00;} 1716. 1717. } 1718. } 1719. MacroDefs mInternal_2 { protocol { 1720. W defaultTiming; 1721. C { soc_in[4] = 1; } 1722. Shift {V {soc_in[3]=s inputs[2]; 1723. soc_in[5] = P; 1724. soc_in[1] =inputs [0..1];}} 1725. V { soc_in[4..5]= inputs [3..4]; 1726. soc_out[1]= outputs[0];} 1727. V { soc_in[5] = P; soc_out[1]=X;} 1728. C { soc_in[4] = 1; } 1729. Shift { V { soc_out[1] = o; 1730. soc_in[5] = P; }} 1731. V { soc_in[5]=0; soc_in[4]=0; 1732. soc_out [1]=X; } 1733. 1734. } initProtocol { 1735. W defaultTiming; 1736. V { soc_in[3..5]=X00;} 1737. 1738. } 1739. } 1740. 1741. PatternBurst bTests1 { MacroDefs mInternal_1; 1742. Variables sgInternal_1; 1743. PatList { 1744. initInternal; 1745. stuckAtTestPatterns; 1746. 1747. } 1748. } 1749. PatternBurst bTests2 { MacroDefs mInternal_2; 1750. Variables sgInternal_2; 1751. PatList { 1752.

167

1753. 1754. 1755. 1756. 1757. 1758. 1759. 1760. 1761. 1762. 1763. 1764. 1765. 1766. 1767. 1768. 1769. 1770. 1771. 1772. 1773. 1774. 1775. 1776. 1777. 1778. 1779. 1780. 1781. 1782. 1783. 1784. 1785. 1786. 1787. 1788. 1789. 1790. 1791. 1792. 1793.

initInternal; stuckAtTestPatterns;

} } PatternBurst bTests { PatList { initInternalSoC; } ParallelPatList LockStep { bTests1; bTests2; } } PatternBurst allBursts { PatSet { bTests; } } PatternExec eInternal { PatternBurst allBursts; }
Environment eSoC { CTL tmInternal { TestMode InternalTest; DomainReferences { UsePrefix DomainNames; MacroDefs mInternal_1 mInternal_2; Variables sglnternal_1 sglnternal_2; } Focus CoreInstance egCorel { PatternTypes Scan; PatternBurst bTests1; TestMode InternalTest; } Focus Corelnstance egCore2 { PatternTypes Scan; PatternBurst bTests2; TestMode InternalTest; }

168

1794. 1795. 1796. 1797. 1798. 1799. 1800. 1801. 1802. 1803. 1804. 1805. 1806. 1807. 1808. 1809. 1810. 1811. 1812. 1813. 1814. 1815. 1816. 1817. 1818. 1819. 1820. 1821. 1822. 1823. 1824. 1825. 1826. 1827. 1828. 1829. 1830. 1831. 1832. 1833. 1834.

Internal { soc_in[0] { DataType TestMode ActiveState U;}} soc_in[5]+soc_in[2] { DataType TestControl MasterClock ScanMasterClock { AssumedlnitialState D; } } soc_in[4] { DataType TestControl ScanEnable { ActiveState ForceUp; } } soc_in[3] { CaptureClock soc_in[5] { LeadingEdge;} DataType TestData ScanDataIn { ScanDataType Internal; DataRateForProtocol Maximum 1; } ScanStyle MultiplexedData; } soc_in[1] { CaptureClock soc_in[53 { LeadingEdge;} DataType TestData ScanDataIn { ScanDataType Internal; DataRateForProtocol Maximum 0; } ScanStyle MultiplexedData; } soc_out[1] { LaunchClock soc_in[5] { LeadingEdge; } DataType TestData ScanDataOut { ScanDataType Internal; DataRateForProtocol Maximum 1; } DataType Functional; ScanStyle MultiplexedData;

169

1835. 1836. 1837. 1838. 1839. 1840. 1841. 1842. 1843. 1844. 1845. 1846. 1847. 1848. 1849. 1850. 1851. 1852. 1853. 1854. 1855. 1856. 1857. 1858. 1859. 1860. 1861. 1862. 1863. 1864. 1865. 1866. 1867. 1868. 1869. 1870. 1871. 1872. 1873. 1874. 1875.

} soc_out[0] { LaunchClock soc_in[5] { LeadingEdge; } DataType TestData ScanDataOut { ScanDataType Internal; DataRateForProtocol Maximum 0; } ScanStyle MultiplexedData; }
} PatternInformation { PatternExec eInternal { Purpose Production; PatternBurst bTests; } Macro mInternal_1::protocol { Purpose DoTest; UseByPattern Scan; } Macro mInternal_1::initProtocol { Purpose ModeControl; UseByPattern EstablishMode; } Macro mInternal_2::protocol { Purpose DoTest; UseByPattern Scan; } Macro mInternal_2::initProtocol { Purpose ModeControl; UseByPattern EstablishMode; } LockStep mInternal_1::protocol mInternal_2::protocol; LockStep mInternal_1::initProtocol mInternal_2::initProtocol; Pattern initInternalSoC { Purpose EstablishMode; } Pattern initInternal { Purpose EstablishMode;

170

1876. 1877. 1878. 1879. 1880. 1881. 1882. 1883. 1884. 1885. 1886. 1887. 1888. 1889. 1890. 1891. 1892. 1893. 1894. 1895. 1896. 1897. 1898. 1899.

} } } }
Pattern initInternalSoC { Macro initSoC; } Pattern initInternal { Macro initProtocol; } Pattern stuckAtTestPatterns { Macro protocol {s=0; inputs[0..4]=10110; outputs[0] =0; o=0; } Macro protocol {s=0; inputs[0..4]=00000; outputs[0] =0; o=0; } Macro protocol {s=0; inputs[0..4]=10000; outputs[0]=0; o=1; } Macro protocol {s=1; inputs[0..4]=11100; outputs[0]=1; o=0;} Macro protocol {s=1; inputs[0..4]=10100; outputs[0]=1; 0=1; } }

Let us go over the definitions of the design entities recognized in this example. The SoC boundary is identified by the Signals block (1607 to 1610), the core types in this core are defined in the CoreType block and instantiated as CoreInstances (1624 to 1647). The Patterns associated with the two cores are the same (1885 to 1899). However, the two instances of the core have different connections on the SoC, which are reflected in different protocols (MacroDefs 1700 to 1739) to apply the Patterns. The patternprotocol pair is unique for each instance of the core. The Patterns are uniquified by creating PatternBursts with unique names (1741 to 1756). These PatternBursts are associated with the CoreInstances (1644 to 1647). The scan chains of the SoC are defined in the ScanStructures block (1649 to 1666). One should note how the scan chains are defined and how the chains of the cores are used to construct the chain on the SoC. Integration of the two cores in the embedded environment is reflected in the protocols (Macros) associated with the patterns. Before going any further

171

into the protocols, it should be noted that the Macro protocol in mInternal_1 is run in LockStep with the Macro protocol in mInternal_2 (1867, 1868). That is, the interpretation of the Shift statement of the Macros in isolation of the other would lead to a wrong understanding of the individual Macros operation. The protocol in mInternal_1 is very similar to the protocol in the previous section with the difference occurring in the way the scan-out signal's value before the shift is observed. In the previous example, the output was measured directly (1446 on page 156) while in this example it is shifted out of the scan chain as a value in the flip-flop between the two scan chains of the cores (1709). The protocol in mInternal_2 changes the original protocol of the core to be applied through the SoC boundary. The changes are very similar to those that were done in the other core instance in this example with a difference occurring in the mechanism of applying the scaninput signal's stimulus, which in this case comes from a shift mechanism. The scan-output signals value is observed with a direct measure on the scan out signal of the SoC. The two Macros (protocol) are to be executed together in LockStep (1761 to 1764). Which means that the two protocols are executed as one protocol. If it were written as one Macro it would look like the following sequence. protocol { W defaultTiming; C { soc_in[4] = 1; } Shift {V {soc_in[3]=sgInternal_2::s sgInternal_2::inputs[2] sgInternal_1::s; soc_in[5] =P; soc_in[l] = sgInternal_2::inputs[0..1] sgInternal_1::inputs[0..1];}} V { soc_in[3. .5] = sgInternal_1::inputs[2..4]; soc_out[1]=sgInternal_2::outputs[0];} V { soc_in[5] = P; soc_out[1]=X;} C { soc_in[4] = 1; } Shift { V { soc_out[1] = sgInternal_2::o sgInternal_1::outputs[0] sgInternal_1::o; soc_in[5] = P; }}

172

V {soc_in[5]=0; soc_in[4]=0; soc_out[1]=X;}

}
The reason that the example does not have a single Macro lies in the fact that CTL is designed such that changes to the pattern data are avoided. If all the patterns are re-written, a single Macro could have been used. Without having to look at the patterns the LockSteped protocols are identified in the PatternInformation block of statements (1867 to 1870). The initialization pattern of the cores is also written with a LockStep construct and performs the equivalent function of applying X00 to the signals soc_in[3..5]. In this example an extra initialization pattern (1882 to 1884) is added to the overall execution to reflect the setup of the SoC prior to the testing of the cores. This pattern initializes all the inputs and outputs of the SoC. Most importantly the test mode signal soc_in[0] is initialized to a logic1 and identified in the Internal block of statements (1795, 1796). Information about the signals and their usage is defined in the Internal block of statements (1794 to 1845). The example has some of this information. It should be self explanatory at this point to the reader. If not the reader should go back to the simpler examples for that kind of explanation. The focus of this mode is to test the two cores, namely egCore1 and egCore2. The configuration of every element in the core is specifiable through the Focus statement (1784 to 1793). In this case both cores are in the InternalTest mode and are tested by Scan patterns. While the patterns identified are all the patterns that are associated with the core, this need not have been the case. The special Patterns and the special use of the Macros are identified in the PatternInformation block (1846 to 1878). The Macros in this test mode are defined in three MacroDefs blocks. The unnamed block is already in the scope of this test mode. However, the named blocks need to be brought into the test mode through the DomainReferences statement (1779 to 1783). Since there are name clashes the DomainNames need to be used to uniquely identify the Macros in each MacroDefs block (1780). The Macros are referenced in the PatternInformation and identified to be the Macros that either are used to establish the test mode or be the Macros that represent the test pattern unit sequences (1851 to 1873). The reader should note how the names of the Macros are constructed. Within the Environment the information is static as compared to the temporal nature of information in the patterns. The references to the Macro names in the pattern data did not need

173

the domain references as the domain name was referenced (1742, 1750) before referring to the Macro (1885 to 1899).