CTL the Language for Describing Core-Based Test

Rohit Kapur Maurice Lousberg Tony Taylor

Synopsys Inc. Philips Synopsys Inc.

Brion Keller Paul Reuter Douglas Kay

IBM Mentor Graphics Cisco

Abstract
As part of an industry wide effort IEEE is in the
process of standardizing the elements of test
technology such that plug & play can be achieved
when testing SoC designs. This standard under
development is a language namely, Core Test
Language (CTL), which is introduced in this paper.
CTL describes all necessary information for test
pattern reuse and the needs of test during system
integration. CTL syntax and its link to STIL are
explained with examples.

1 Introduction
Design Reuse Methodologies [11 have allowed for the
partitioning of effort needed to create a complete
design at the expense of communication between the
teams creating the design. Tasks when partitioned
across teams that are in close proximity to each other,
the teams can get together with frequent formal
meetings, Share C ~ - U K J ~dOctumWation Or discuss Figure 1: Usage of the CTL representation of the
problems informally in coffee breaks. This is a core in the creation of a generic test access
normal business process for any company that has a architecture.
reasonably sized project under way. This breaks
down when the design teams are separated in time
and space. To avoid Figure 1 shows a usage of CTL where the information
problems the process needs to be formalized and the about the core is represented in CTL. Using the CTL
interface between the partition (or core) providers and Of the ‘Ore a wrapper can be constmcted7 and the
the integrators needs to be standardized.This is where appropriate Test Access Mechanism (TAM) can be
indus&y-wide standards step in. A Core Test determined based upon the test constraints in the CTL
L~~~~~~~(CTL) is being developed to address the of the core [61[71[81. Once all the structures are in
interoperability needs of SoC test [2]. IEEE P1500 place the test patterns that are a part Of CTL can
[3][4] is proposing a standard wrapper with a CTL be re-targeted to the boundary Of the In this
interface to isolate the cores from the embedded example the core described by the CTL did not have a
environment. As a precursor to this, the VSI Alliance wrapper inside the ‘Ore.
[5] is defining a similar hardware architecture to be
replaced by the p15OO hardware when it becomes an CTL is the language to support the information
IEEE Standard. that the core provider needs to give the system
integrator such that the integrator can successfully
This paper is focusses on the Core Test Language test the WdXdded core and any user-defined logic
(CTL). Through this mechanism all test aspects of around the core. This language is broad enough to
cores can be described such that a system integrator describe p15009
and even IEEE 1149.1 L91
can integrate a core as a black box into a SoC and hardware as described in BSDL [101* The language
perform all the usual test tasks as though the core was constructs being defined in CTL with
a white box with test patterns to be reused. As shown Of digital their different test
in ~i~~~~1, CTL describes d l the information about methodologies and the different ways in which they
the core needed by the system integrator. The are integrated in the
language is designed to be manually written and
created and/or consumed by test automation tools. Since CTL is the formal means by which a core
provider supplies test information to the system
ITC INTERNATIONAL TEST CONFERENCE Paper 5.3
69-0/01$1 0.00 0 2001 IEEE
0-7803-71 131
integrator, it is important for this mechanism to not
restrict the way cores are designed. CTL is designed
to work with cores that come with any type of DfT
methodology. Furthermore, CTL also works with any
type of test methodology (structural tests that use the
stuck-at or delay fault model, Iddq tests and
functional tests).

In this paper we show how aspects of the information

that describes the test details of a core are presented
in CTL. Since CTL builds on STIL [ll], a brief Figure 2: Example core without a wrapper and the
introduction is given in Section 2 on some of the associated signals definition.
concepts in STIL needed to understand the examples
of this paper. In Section 3 the overall structure of the
information in CTL is described. CTL information
2.2 Patterns
includes Patterns define the stimuli to and responses from the
Design Configuration Information. core occurring in a sequence. That is, patterns are
Structural Information. sequences of vectors that contain logic values to be
Test Pattern Information. applied to Signals.
These concepts are described in Sections 4, 5, and 6
respectively. The details are explained using a Figure 3 is an example pattern (allgats) that applies a
running example of a wrapped core right through the scan operation in a flattened format where values are
paper. At times information is replicated across CTL applied to the input SI repeatedly with the right
code to highlight concepts. The example is the unified values for the conditioning signal SE and clock CLK.
CTL across the different sections describing the After scan, input A is applied some stimulus, and a
wrapped core. The unification of the different pieces response measured on signal B. After a single clock
of CTL will result in some redundancies which are to pulse, a scan operation is performed by repeated
be removed in the unification of the code. measures of the SO signal and application of the CLK
with signal SE conditioned to allow for the scan
The full details of CTL syntax are avoided in order to operation. The example introduces syntax for the
highlight the main features of the language. Bold vectors, namely V. Each V statement defines one test
words highlight the keywords that have a special vector that defines the state to be applied to each
meaning that is defined by the standards which in this signal. It should be noted that this example ignores
case are CTL and IEEE 1450. No attempt is made in details of the overlapped operation of scan in and
this paper to provide all the associated parameters of scan out across consecutive test patterns and
the keywords that are presented. waveform information required for patterns.

2 Some Basics of STIL

STIL constructs are the building blocks of CTL. STIL
being a test pattern language, it is very good for
defining all of the sequence information that needs to
be described in CTL. In this section some basics of
STIL are discussed such that the CTL examples in
this paper can be easily understood.

2.1 Signals
The U 0 signals of a core define the boundary to
which test patterns are written. STIL defines a block Figure 3: Example pattern of an ATPG generated
of statements named Signals, within which the single test where the scan-in and scan-out operation
interface of the design is specified. are not overlapped.

As shown in Figure 2, along with the signal name, a

direction can be assigned to the signal to describe its
2.3 Macros
use as Input (In), Output (Out) or bi-directional The test pattern of Figure 3, can be also be written as
(ZnOut,not shown in Figure 2). The U 0 signal names shown in Figure 4 using a Macro definition.
must match the names of the pins of the core block as
defined by its netlist.

Paper 5.3
132
 CLK 1
I
Figure 4: Example of a single ATPG test pattern
A0
where the protocol information is separated from the
data portion of the test.
AI

The pattern of Figure 4 is written to use a protocol or

Figure 5: Waveform Tables defining the waveform
template called a Macro (named seq) that applies the
characters used in the patterns and macros.
data defined by the pattern in a certain sequence. The
C statement is a Condition statement that defines the
assumed value on signals that are not specified. The Now that the waveform table concept has been
first Shij? statement is used to apply the two values introduced, the test patterns of Figure 3 and Figure 4
applied to SI as defined by the pattern. Similarly, the should be augmented with a statement that references
second Shij? statement is used for SO the scan out. the constructs in Figure 5 (W timel;).
Since this example is the same as that in Figure 3, it
also ignores details of the overlapped operation of 3 CTL
scan in and scan out across consecutive test patterns Information in CTL is organized around a mode
and waveform information required for patterns. (configuration) of the core being represented. Figure
6, is a pictorial representation of the CTL structure.
2.4 Timing
The above explanations used 0 and 1 as logic values. The signals of the core being described are global
However, these values are applied with certain timing across all modes. In each mode the signals are used in
relative to a clock period and are not simple logic different ways and are attributed to describe the
values. In the parlance of STIL, these are waveform different needs of the configuration. Every mode of
characters that are defined in a waveform table on a the core has a mechanism to initialize the mode. The
per signal basis. initialization sequences are described in CTL on a per
mode basis. Some modes of the core contain test
Figure 5, shows an example definition of the patterns with their associated timing information,
waveforms for the running example in this section. constraints, and statistics. Some modes contain
The waveform characters “0” and “1” are assigned structural information such that the structure can be
values with timing information. In the example, 0 and used to create patterns at another level of integration
1 for all logic signals is a logical 0 and 1, where the of the design. CTL is designed to describe all these
value is applied at the beginning of the period and is needs of different modes of the core. For any given
held to that value. However the same waveform test mode of a core, typically only a subset of the full
characters were used differently for clock signals. A CTL syntax will be required to adequately describe
waveform character 1 was used for the CLK signal as the attributes of the mode.
a pulse that happens somewhere within the clock
period (a better name would have been P). An Using the basic constructs identified in Figure 6, CTL
example definition of the 1 for the clock is shown in has the ability to describe the following.
Figure 5 as a pulse of width 5ns that happens after 0 Controls to configure the core for testing the core
60ns in a clock period of 100ns. Figure 5 uses D and and the surrounding SoC logic.
U to represent drive events for “down” and “up”. Requirements and constraints on the
Similarly, L and H are used for expect events for implementation of SoC-level interfaces to the
“low” and “high” values. The waveform characters 0 core.
and 1 are also defined for the other signals for Inclusion of test data specific for the core, but
completeness (though the waveforms are only drawn defined independently from any particular use of
for the CLK 1, and signal A being a logic 0 and logic the core.
1).

Paper 5.3
133
These allow for complete representation of the There are numerous other blocks of statements in
information needed to test the core within an SOC. CTL that are not covered, since the complete syntax
of CTL is not the focus of this paper.
The Language: The primary task of CTL is to
describe information that allows for the reuse of test While every syntax description of STIL is part of
patterns. This brings a natural affinity for Test CTL, there is a distinct difference in the way the
Patterns to CTL. IEEE has standardized a format pieces of the CTL information are represented
called STIL to represent test patterns. The standard is relative to the origin of the syntax itself. Figure 6,
known as IEEE 1450 [ll]. It became the natural depicts the relationship between the STIL portion of
choice for the syntax for CTL information. CTL the CTL syntax and the syntax that is not part of
builds on STIL by leveraging off pattern information STIL.
available in STIL whenever appropriate without
replicating or creating any new syntax for the same.
Since CTL describes a number of concepts that a test 4 CTL for Design Configurations
pattern language is not intended to describe, new A typical SoC’s design for testability (DFT) would
syntax is created for CTL in a STIL-friendly way. follow a methodology where individual cores are
isolated from other logic during test of the SOC. This
CTL can be viewed as a superset of STIL in terms of isolation can be accomplished by using a boundary-
the syntax. Furthermore, some constructs in CTL can
scan like wrapper added to the periphery of the core.
also be viewed as a meta-language of STIL when it
comes to describing the patterns since it defines how Once bounded, the new wrapped core would support
the test data described in STIL should be interpreted. multiple modes (configurations) to allow for internal
testing of the original core embedded in its wrapper
STIL and the test of the logic external to the wrapped core.
STIL (Note: Although a wrapper is used in the example,
Independent Dependent CTL is not limited to describing wrapped cores.)
information information

Info Da
Test BSE Y z
-i--l-----
.................I.......i......................................
1 Bist Structures]
A B

SI so

Protocols ~~
. ~.
BCK CLK SE

Figure 7 : An example of a core with a wrapper. The

Figure 6: CTL structure depicting multiple test core has multiple modes of operation.
modes of a single core.
Figure 7 shows a wrapped core supporting multiple
CTL Syntax: For the scope of the examples in this modes of operation. In this example the shaded box
paper, CTL information for a mode is partitioned into represents the original (unwrapped) core as an
two blocks namely, Internal and PatternInformation embedded core of the wrapped core. The picture
(shown in Figure 6). represents the core with an internal wrapper built
using flip-flops, multiplexers and some gating logic.
1. The Internal block of statements provides The context of this example is the complete core,
information describing the core boundary relative which includes the wrapper.
to the U 0 signals of the core. For example, a
signal used as a clock by the core would be Figure 8, is a pictorial view of different modes of the
described in an Internal block. core. The different modes of the wrapped core are to
2. The PatternInformation block of statements be described in CTL. Figure 9 shows partial CTL
describes the test patterns and related constructs code for the associated modes of Figure 8.
needed for the test mode.
Paper 5.3
134
A) N o m 1 Mode.

SE Y=O Z=O n;
2; 1 SO Out { ScanOut 2; }
n 2; } BSO Out { ScanOut 2; }

A B

SI

I I

BCK CLK SE

B) External Test Mode.

ment wrapped-core {

BSE Y=O Z=1

-i--l----- ‘Y+Z { DataType TestMode;
BSI 1 ..................I.......i......................................
Activestate ForceDo

A
pose EstablishMode
s1
I
I
! i

C ) Internal Test Mode.

InternalTest;

BSE Y=l Z=O

----A-----
BSI ........................i ......................................
Patternlnformation {
A
Purpose EstablishMode;}})

SI

BCK CLK SE

Figure 8: Modes of operation of the wrapped core to

show three configurations A ) Normal Mode B )
External Test Mode and C) Internal Test Mode Figure 9: Partial CTL code to describe the
initialization of the three modes of the core.

Paper 5.3
135
The three modes are defined in the Environment (1) for a scan operation. This scan chain is described in
block of statements to be myN (2), myE (6) and myl the CTL of Figure 11.
(11). Using a TestMode statement, these modes are
identified to be the configurations for the following. BSE Y z

Normal, functional operation of the core (3). BSI h ,................. ci.--i-.--.r dI

0 ExternalTest, the configuration that allows for
controllability and observability of the logic
outside of the core in the integrated SoC (7).
0 InternalTest, the mode that allows for testing of
the logic inside the wrapper (12).

Each of the modes defined for the wrapped core have

different initialization sequences. Three different
BCK CLK SE
patterns P1 (16), P2 (17) and P3 (18) are defined to
create three different initialization sequences as
required for the three modes. In this example the Figure 10: An example of a scan chain of a core that
initialization sequences are the simple application of is to be described in CTL.
values to the signals Y and Z of the core. A common
protocol is defined via the Macro M1 to enable each The ScanStructures block (36) is used to describe the
of the three modes. The macro takes in two scan chain and its components. The cells are
parameters (Y, Z), that are provided by the represented by a symbol (implementation
initialization patterns P1, P2, P3 of the three modes independent) that represents the state in the scan cell
(16, 17, 18). (41). In this case two scan cells exist on the scan chain
and are named c[O] and c[l]. The values in the scan
The initialization patterns are linked to the modes in chain are accessible through the scan input (1, 20, 38)
the PatternInformation block of statements. The and scan output (1,25,39) by using the Macro M2 (33)
Normal mode uses pattern P1 (5), the ExternalTest defined in CTL. M2 is labelled as a ControlObserve
mode uses pattern P2 (IO) and the InternalTest mode (31, 32) macro in the PatternInformation block (30).
uses pattern P3 (15) to establish their configuration.
These patterns are identified to be the initialization The Internal block (3) is used to provide details
patterns through the Purpose statement. In this case, about every signal (4, 9, 14, 17, 20, 25) as related to the
the three patterns are identified to be EstablishMode scan and boundary structure. Signal A is connected to
patterns. scan cell c[O] of chain bcl and the leading edge of the
BCK signal affects the capture of the value (4, 5, 6,7).
After the initialization patterns are executed the core Once the value is captured in the scan cell it is
is in the desired mode. However, some signals may observable using Macro M2 as specified by the
need to be maintained at a fixed value to ensure that TestAccess statement (8). Similarly, the connections
the core stays in the mode. The DataType TestMode of Signal B is defined (9, 10, 11, 12, 13). Since B is an
(4,8,9, 13, 14) on the signals in the Internal Block is output, the LaunchClock statement is used to define
used to highlight the constant signal after the clock off which the signal is launched (12) and the
initialization is complete. The Activestate defines the TestAccess statement (13) is used to define the
driving value on the associated signal for the mode. mechanism to control values in the scan cell. In this
example, test signals are assigned various data types
5 CTL for Structural Information with associated active values as demanded by the
example. BSE is identified as a scan enable signal
A core could contain some design elements that are with a logic-0 needed to allow for the scan operation
reused on the SOC.These design elements need to be (14, 15, 16). BCK is identified as a scan clock with an
described in CTL for reuse without giving away associated state (17, 18, 19). The scan chain input and
actual implementation details that might be construed output signals are identified to be the scan data
as Intellectual Property (IP). signals of a boundary scan chain of the design (20,23,
24, 25, 28, 29).
Consider the scan chain in the wrapper of the core
used in the examples of this paper. Figure 10,
highlights the scan elements (cells) built out of flip-
6 CTL for Test Pattern Information
flops, and multiplexers. There are two scan cells in A core provided as a black box would need to come
this chain with a scan input BSI and a scan output with test patterns that can be reused to complete the
BSO. The chain is clocked by the BCK signal and the SoC test. CTL provides the test patterns in a restricted
BSE signal determines if the scan chain is configured STIL syntax, to enable reuse.

Paper 5.3
136
 Figure 12: Partial CTL code to describe test patterns
Figure 11: Partial CTL code to describe information that come with a core, for internal testing of the core.
for the wrapper scan chain of the example.

Paper 5.3
137
STIL is the preferred format for the patterns that for a very controlled environment that is mostly
come with a core. However, test patterns in STIL available in a single company. CTL [2] is a new
come in many flavors and CTL requires that the data language that is created to allow for a general SoC
and protocol portion of the patterns be separated [12]. strategy that goes beyond controlled environments.
Figure 12 shows example patterns for the (wrapped)
core that has been used in the previous sections. The In this paper, the basic capabilities of the Core Test
patterns are defined in a PatternExec topPat. The Language are described. Examples are used to
PatternInformation block (4) identifies this top level describe
pattern to be used for Production test (5, 6). The 0 Design ConfigurationInformation.
actual patterns of the PatternExec exist in 0 Structural Information.
PatternBursts and are referenced in the 0 Test Pattern Information.
PatternInformation block of statements (7, 8). The This paper should not be interpreted to be an
PatternBurst in this example contains patterns that exhaustive description of CTL. There are numerous
are applied through Scan (8, 9). The fault coverage of syntax items of CTL that were not introduced. The
the patterns is described by CTL to be 96% of the CTL used reflects the latest syntax of the
StuckAt fault model (10, 11, 12, 13). standardization effort upon the time of writing this
paper and is subject to changes before it is finalized.
As mentioned earlier, the sequence information is
separated from the Patterns in CTL. As a result of this 9 Acknowlegements
separation the Macro which represents the sequence
is the entity that gets modified to reflect the The authors would like to thank Erik Jan Marinissen,
embedded environment. The macro that needs to Greg Maston and Ben Bennetts for their constructive
change is identified in this example as a DoTest criticism of this paper.
macro, implying that the sequence represented by the
macro is the application of a single test (14). In this References
case, the sequence is called non-overlapping, as the Michael Keating, Pierre Bricaud, Reuse
scan-in and scan-out operation of consecutive tests do Methodology Manual for System-on-a-Chip
not overlap. Designs, Kluwer Academic Publishers, Norwell,
Massachusetts.
7 Beyond the Example CTL Web Site, http://grouper.ieee.org/groups/ctll
The example used describes the basic constructs for
CTL needed to describe information that comes with IEEE P1500 Web Site,
a core. The keywords used here are a limited subset http://grouper.ieee.ordgroups/l5OO/
of the keywords available in the language. Erik Jan Marinissen, Yervant Zorian, Rohit
Kapur, Tony Taylor, and Lee Whetsel, “Towards
CTL relies on protocols (Macros) to describe the a Standard for Embedded Core Test: An
needs for every configuration of the core. The Example,” in Proceedings ZEEE Znternational
protocols differ from design to design and can be of Test Conference (ZTC), 1999, pages 616-627.
any length. This is the fundamental mechanism
behind CTL’s design independence. VSI Alliance Web Site, httv://www.vsi.org/
Erik Jan Marinissen and Maurice Lousberg,
There are numerous other aspects to SoC designs that “Macro Test: A Liberal Test Approach for
have not been covered in this document. Most of Embedded Reusable Cores,” in Digest of Papers
these aspects deal with different design and test of ZEEE International Workshop on Testing
methodologies, such as Logic BIST, or diagnostic Embedded Core Based Systems (TECS), 1997,
issues. Of all the possible subjects one deserves pages 1.2-1.9.
special mention here. CTL is designed to allow for
system integration activities to be performed within Erik Jan Marinissen, Rohit Kapur and Yervant
the realm of CTL itself. The conversion of test Zorian, “On Using IEEE P1500 SECT for Test
patterns that come with a core to the SoC level can be Plug-n-Play,” in Proceedings of the Zntemational
done by changing the Macros associated with the Test Conference (ZTC),2000, pages 770-777.
patterns. This discussion is beyond the scope of this Erik Jan Marinissen, Robert Arendsen, Gerard
paper and the reader can contact the authors for more Bos, Hans Dingemanse, Maurice Lousberg, and
details on this subject. Clemens Wouters, “A Structured And Scalable
Mechanism for Test Access to Embedded
8 Conclusions Reusable Cores,” in Proceedings IEEE
SoC test itself has been performed in numerous ways Znternational Test Conference (ZTC), 1998, pages
in the past. The problems encountered are well known 284-293.
and solutions have existed in the industry that work

Paper 5.3
138
[9] IEEE Computer Society, IEEE Standard Test
Access Port and Boundary-Scan Architecture -
IEEE Standard 1149.1-1990, IEEE New York,
1990.
[101IEEE Computer Society, Supplement to IEEE Std
1149.1-1990, IEEE Standard Test Access Port
and Boundary-Scan Architecture, IEEE Std
1149.1b-1994,IEEE New York, March 1995.
IEEE Computer Society, IEEE Standard Test
Interface Language (STIL) for Digital Test
Vector Data - Language Manual - IEEE Std.
1450.0-1999. IEEE New York, September 1999.
[ 121Erik Jan Marinissen and Maurice Lousberg, ‘The
Role of Test Protocols in Testing Embedded-
Core-Based System IC’s,” in Proceedings of the
IEEE European Test Workshop (ETW), May
1999, pages 70-75.

Paper 5.3
139