[3B2-8] mdt2009010036.

3d 6/1/09 11:10 Page 36

IEEE Std 1500 and Its Usage

CTL and Its Usage

in the EDA Industry
Rohit Kapur Sandeep Bhatia and Brion Keller
Synopsys Cadence Design Systems

Paul Reuter
Mentor Graphics
superset of STIL with restrictions in the
Editor’s note: way patterns can be represented in
The Core Test Language, originally developed within the IEEE 1500 develop- STIL for test pattern reuse (see http://
ment working group but later spun out as an independent standard, grouper.ieee.org/groups/ctl).6 As a re-
specifies the standardized language in which core test information for both sult, every CTL pattern is a STIL
wrapped and still-to-be-wrapped cores is described. pattern, but not every STIL pattern is a
Erik Jan Marinissen, IMEC CTL pattern. Two extensions of the
CTL standard are currently under devel-
THE CORE TEST Language (CTL) began as a sub- opment, and these are discussed in the ‘‘Open
activity of IEEE Std 1500, the standard for core Compression Interface’’ and ‘‘Memory CTL’’ sidebars.
testing.1,2 It was initially proposed as one of the solu- In this article, we present a brief tutorial on CTL
tions for core testing competing with the hardware and describe its usage in the EDA industry. We also
proposal. Over time, CTL evolved into a general lan- describe the uses of CTL in various parts of a DFT
guage for core testing, and the hardware became flow. Released tools already include some of these
the wrapper technology. As a result, separate stan- uses; others will be included in tools still in
dards were needed for CTL and the hardware: development.

 CTL became IEEE Std 1450.6-2005.3 The language

 The wrapper, along with requirements concerning
the information to be defined in CTL, became
IEEE Std 1500-2005.4
CTL describes a core that is to be wrapped with a
1500 wrapper. It also describes the wrapper’s opera-
tion and connections when the wrapped core is
delivered. CTL is an important part of IEEE 1500
and the reuse solution, providing a necessary infor-
mation mechanism for test automation of SoCs.5
Because a core can be tested in many different
ways, CTL is extensive in its capability to represent
all test constructs. CTL is a generic test language
with the power to represent test information in multi-
ple modes, test patterns, and DFT constructs and
behavior relevant to test. Hence, the language is
used in more scenarios than originally intended.
The language itself leverages the Standard Test Inter-
face Language syntax and can be considered a
A core comes with many modes or configurations
relevant to test. At the highest level, the language
breaks down its information across these modes.
Figure 1 shows an Environment block of state-
ments representing the top level of information in
CTL. In this block, each configuration is defined as
CTLMode blocks of statements. The figure shows two
modes defined for the core. In terms of the 1500
wrapper, each instruction represents a configuration
(CTLMode) that can be described. In many cases, con-
figurations handle information in a common way. The
language supports information reuse across modes
by inheriting information from one mode to another.
Modes have a purpose, which is defined within the
mode through a TestMode statement. This purpose
allows for the definition of wrapper configurations
such as InternalTest, ExternalTest, and ByPass.
Modes can have defined alternates. In this case,
the two configurations defined as alternates perform

36 
0740-7475/09/$25.00 c 2009 IEEE Copublished by the IEEE CS and the IEEE CASS IEEE Design & Test of Computers
 [3B2-8] mdt2009010036.3d 6/1/09 11:10 Page 37

Open Compression Interface

Bruce Cory, nVidia CompressionStructures my_compression {
The Open Compression Interface (P1450.6.1) extension Decompressor my_decompressor {
is aimed at creating a language that enables information si1 ‘in0 ? in2 : in1’;
si2 ‘in0 ? in1 : in2’;
transfer between different steps in the DFT-ATPG-diagnos- si3 ‘in0 ? in3 : in1’;
tics flow. Although CTL thus far has not been used for }
Compressor my_compressor {
information transfer between these steps in creating a test out0 ‘so1 ^ so2’;
solution, it would be possible to use CTL for scan, though out1 ‘so2 ^ so3’;
}
not for scan compression. As a result, OCI extends CTL }
to describe enough information about the compression
logic for a user to implement DFT from company A, perform Figure A. Example syntax added to CTL (Core Test
ATPG with company B’s tools, and diagnose the design with Language) to describe scan compression.
company C’s tools.
OCI has created syntax to describe scan compression and exclusive-OR gates in the compressor. In the figure,
using a certain set of equations. Figure A gives an example si1 and so1, si2 and so2 , and si3 and so3 represent
of this syntax. the internal chains in the design, and in0 , in1 , in2 ,
As with scan structures in CTL, the example syntax out0 , and out1 represent the scan terminals at the
in Figure A defines another block to represent compres- boundary of the design under test. Many compression
sion structures. The compression logic between the structures can be defined and tied to other information
scan inputs and the internal chains is called the decom- in the modes defined in CTL.
pressor, and the compression logic between the internal
scan chains and the scan outputs is called the compres- Bruce Cory is a DFT staff engineer at nVidia. Contact him at
sor. Figure A shows multiplexers in the decompressor bcory@nvidia.com.

the same function, and a typical integrated test solution ScanCells (Figure 2). Therefore, these entities must
would need only one of the two. be defined in CTL such that information can be pro-
Within the mode, test information describes usage vided for them. Figure 1 shows the blocks of syntax
or characteristics of Signal, CoreInstances, and that define these entities in CTL relative to the Envi-
ronment block of statements that contains the mode
information. Within each mode, information is
defined for these entities or using these entities.
Signals ScanStr CoreInst
{} {} {}

Signals Core instances

Environment {
CTLMode config1 {
Internal { }
External { }
ScanInternal {}
CoreInternal {}
}

CTLMode config2 {
Internal { }
External { }
}
}

Scan cells

Figure 1. Information structure in the Core Test

Language (CTL). Figure 2. Design entities recognized by CTL.

January/February 2009 37
 [3B2-8] mdt2009010036.3d 6/1/09 11:10 Page 38

IEEE Std 1500 and Its Usage

Saman Adham, LogicVision
Memory CTL (P1450.6.2) was created to
address some limitations of IEEE Std
1450.6-2005 regarding embedded memo-
ries. Although CTL can represent a memory
that has undergone BIST, the standard has
limitations in supporting a flow in which infor-
mation must be represented for a memory
such that BIST logic can be created to test
and repair that memory. As a result,
P1450.6.2 is creating syntax and semantics
to support this flow. New CTL blocks define
different aspects of the memory, enabling ef-
ficient and accurate memory test: memory
redundancy and repair is defined in one spe-
cific CTL block, the memory’s physical
topology is defined in another block, and
so on.
Figure B shows an example of a memory
described in this new syntax. A new block
represents the physical information about
memories. This example focuses on the
scramble map. A three-port memory is
defined with the same address- and data-
scrambling for all ports. The relationship be-
tween the topological address and data is
defined in terms of the pins to the memory
being described.
Saman Adham is senior director of engi-
Figure B. Example of a memory described in the new syntax
neering at LogicVision. Contact him at
defined by Memory CTL (P1450.6.2).
saman@logicvision.com.
Memory CTL
MemoryPhysicalTopology {
// Physical info in this block
BitDistribution 1;
ColumnMultiplexing 8;
BitLineMirroring 1;
// Address and Data Scrambling
ScrambleDefinition AddMap {
// Address topology
TopologicalColumnAddress[0] = Add[0];
TopologicalColumnAddress[1] = Add[1];
TopologicalColumnAddress[2] = Add[2];
TopologicalRowAddress[3] = Add[3];
TopologicalRowAddress[4] = Add[0]^Add[4];
TopologicalRowAddress[5] = Add[5];
TopologicalRowAddress[6] = Add0]^Add[6];
TopologicalRowAddress[7] = Add[7];
TopologicalRowAddress[8] = Add[0]^Add[8];
TopologicalRowAdd[9] = Add[9];
TopologicalRowAddress[10]= Add[0]^Add[10];
}
ScrambleDefinition DataMap {
// Data topology
TopologicalData[0] = Data[0] ^ Add[3];
TopologicalData[1] = ~Data[1] ^ Add[3];
TopologicalData[2] = Data[2] ^ Add[3];
TopologicalData[3] = ~Data[3] ^ Add[3];
.
.
TopologicalData[23] = ~Data[23] ^ Add[3];
}
Relation{
// All memory ports use same Scramble Map
ScrambleMap AddMap + DataMap {Port 0}
ScrambleMap AddMap + Datamap {Port 1}
ScrambleMap AddMap + DataMap {Port 2}
}
}

This information is partitioned into subblocks of
modes, as also shown in Figure 1. Figure 3 illustrates
the information described in a design and the blocks
of syntax used in a CTLMode.
Relation{} describes relationships between sig-
nals of the design. Examples of such relationships
include one-hot or differential. Internal{} describes
information in the mode, which is indicated by the
shaded area from the signals inward. PatternInfor-
mation{} describes sequence information in a mode.
The language achieves its generality by using sequen-
ces to describe the establishment of a mode or its
termination.
One characteristic of the language that deserves
special mention is test pattern reusability. Test patterns
that come with a core can be described in CTL
syntax. Of course, this information resides in the Pat-
ternInformation{} portion of the syntax. The test
patterns are restricted to be written with the data and
protocol portions separated. The data consists of the
1s and 0s, and the protocol is the procedure that
applies the data to the signals such that the stimulus
and observations occur in a special sequence that
could entail shift operations. This separation lets test
engineers write pattern-porting applications, which ma-
nipulate the test patterns in an embedded core’s CTL
such that they work from the SoC’s boundary. The in-
complete code segment in Figure 4 shows how
patterns are described in CTL with the data and proto-
col separated.

38 IEEE Design & Test of Computers

 [3B2-8] mdt2009010036.3d 6/1/09 11:10 Page 39

In this figure, Procedures represent the protocol.

Design Scan chains Cores (black boxes)
A single procedure called load_unload_grp1 is
defined such that it accepts parameters for data (rep-
resented by #). The parameters are applied to signals
_chain1_a1_ and _chain1_so_. The first parameter
represents stimulus values, and the second represents Relation Relation
{} {}
measure values for the scan chain that has not been
explicitly defined. The patterns supplying the data
call the procedures, as Figure 4 shows. Labels
chain_pattern 0 and chain_pattern 1 identify the
two tests that use the load_unload procedure.
If the example patterns represented patterns of a Internal {} CoreInternal {} ScanInternal {}
core embedded in an SoC, those patterns, which
External {} Outside the design
are written to the core boundary, would need to be PatternInformation {} Pattern or sequence-related
changed to apply them from the SoC boundary. In information of the design
this example, the procedures could be modified with-
out having to touch the patterns.
Figure 3. Organization of information in a CTLMode.
Using IEEE Std 1500 and CTL in EDA
Figure 5 shows an example of what the tool flow Cadence provides 1500 wrapper support but has not
might look like when working with CTL from before yet migrated to CTL from its preexisting language for
ATPG all the way through reusing the design as a migrating core tests (CTL is used within Cadence
core in a larger design. Implicit in the flow (in the DFT tools to communicate test structure information).
part before creation of a core) is the use of netlists Synopsys had provided a simple wrapper-based CTL
at each step. In a test reuse flow, once a core is cre- solution that created cores in CTL and integrated
ated, CTL is assumed to provide the information cores at the next level of hierarchy using CTL. Mentor
about that core that is needed for the next step. Graphics had provided a core test reuse flow that did
DFT tools output CTL to provide the instructions to not use the CTL standard, since the flow had been
the ATPG tool regarding the existence and use of
the DFT constructs. ATPG then uses this information
to create test patterns that keep the data and protocol // Sequence portion of the patterns
// Procedures are called by Patterns that
separated. At this point, there are two possibilities: If // supply the data
the design is for the complete chip, the CTL test pat- Procedures {
load_unload_grp1 {
terns would go to the tester. If the design is embedded W tset_gen_tp1;
in an SoC as a core, further modifications would C { _po_ = X ;}
C { "_chain1_a1_" = X; "_chain1_so_" = X;}
occur. Wrapping of the core with a 1500 wrapper V { se = 1; clk = 0;}
would also output CTL for the wrapped core. CTL in- Shift { V {
formation should describe the DFT constructs and "_chain1_a1_" = #;"_chain1_so_" = #;clk=1;
}}
the patterns such that they are reusable in an }
embedded environment. CTL would thus describe }// end Procedures
all the modes (instructions) available and the con- // Data portion of the patterns follow
structs associated with each configuration (see Pattern chain_test_pat {
“chain_pattern 0”: load_unload_grp1
http://grouper.ieee.org/groups/1500). Wrapped cores {“_chain1_a1_” = 01;
from multiple sources being integrated together “_chain1_so_” = XX;}
would also require extensive use of CTL in describing “chain_pattern 1”: load_unload_grp1
{“_chain1_a1_” = 01;
the test access mechanism (TAM) and the SoC’s test “_chain1_so_” = HL;}
schedule regarding the testing of its many cores. }
The three EDA companies that have contributed to
this article have had some form of core-testing solution Figure 4. Code segment illustrating how patterns are described
(either currently available or discontinued). Today, in CTL with the data and protocol separated.

January/February 2009 39
[3B2-8] mdt2009010036.3d 6/1/09 11:10 Page 40

IEEE Std 1500 and Its Usage

the information in the ATPG tool’s data structures. As

Test synthesis test automation and designs have become more com-
plex, clocking sequences have become more specific,
requiring ATPG to use specific sequences. Today, pro-
CTL test
tocols or sequences tell the ATPG tool how to operate
protocols
the scan chains and other test structures, how to
put the device into a test mode, and how to operate
ATPG on-chip clock generators. Furthermore, to format
final test patterns, the ATPG tool requires timing infor-
mation for use within each test cycle.
CTL test Loading this information into an ATPG tool typi-
patterns cally either employs a proprietary language or
employs STIL syntax but still uses proprietary seman-
tic interpretations of the data presented by that STIL
ATE syntax. The problem with both of these approaches
is that it is difficult to create protocol information
for ATPG tools without explicit knowledge of how
Wrap core the tools operate. The purpose of the protocols, as
CTL well as specific information about the required sig-
schedule nals, is inferred from the unstandardized protocol
names and secondary effects of the languages. There-
fore, Mentor Graphics leverages CTL as an input to
CTL core CTL ATPG through an application that inputs CTL and out-
patterns TAM puts the proprietary commands for ATPG. Although
this is currently a two-step process, the power of rep-
resenting multiple configurations in CTL is not
Integrate
directly available to the ATPG tool. As the number
core patterns of configurations running ATPG increases (because
of the different power domains in the design), CTL in-
formation to ATPG will need to be brought directly
into the ATPG environment.
ATE In CTL, metadata about Signals, MacroDefs, and
Procedures can be expressed in the CTLMode block.
Thus, the semantic rules do not depend on parsing
Figure 5. Test flow using CTL at all stages. (TAM: the names of those objects; instead, they can use the
test access mechanism.) predefined Purpose and DataType keywords in the
CTLMode to convey the intended use of these Signals
developed prior to the CTL and 1500 standards. This and Macros. Also, if the DFT structures in a design can
has been discontinued in favor of developing a new be configured into multiple test configurations, then it
flow based on the current standards. would be possible to express this using one CTL file
with multiple CTLMode blocks rather than using multi-
Using CTL for protocol input to ATPG tools ple STIL or proprietary files.
Running full- or partial-scan ATPG on a given device
requires communicating to the ATPG tool how to oper- Using CTL as ATPG output
ate various aspects of the device under test. At a STIL is already fairly widely used as an ATPG output
minimum, ATPG must recognize the scan chain infor- format, and multiple tools process the STIL for tester
mation. Since the early days of test automation, scan- consumption. CTL overlays some further restrictions
enable signals and clock signals have been identified to the way patterns are described for test pattern
at the chip’s boundary, and a design-rule-checking reuse. These restrictions primarily concern the way
step within ATPG extracts the scan chain and saves the data and protocol portions of the tests are

40 IEEE Design & Test of Computers

 [3B2-8] mdt2009010036.3d 6/1/09 11:10 Page 41

separated. Both Synopsys and Mentor Graphics see

this as a cleaner and more powerful method for repre- Block-level
senting patterns and have adopted it in their tools. DFT setup Block netlist Library
A CTL file organizes all patterns into specific pat-
tern types. A pattern-level protocol can represent
each ATPG pattern. In the Pattern blocks, a pattern DFT synthesis
consists of the P (protocol) statement followed by at block level
the pattern data. The PatternBurst block specifies Top-level
which protocol to use. DFT setup
Each of these top-level protocols is represented
by a Procedure or a Macro. This Procedure or Block-level CTL-based
output netlist DFT model Top-level netlist
Macro specifies the test sequences needed for a spe-
cific type of ATPG pattern and calls the previously
defined test protocol Procedures and Macros. Sepa-
rating the test data from the top-level test protocol DFT synthesis
at top level
and grouping the patterns into blocks by pattern
type makes it easier to later merge pattern sets
from multiple cores into a single top-level pattern
Top-level
set when cores are tested concurrently. output netlist
CTL can expand on all of STIL’s strengths for trans-
ferring test data from ATPG to ATE or simulation
Netlist assembly CTL-based
environments. Using CTL enables extra metadata at top level DFT model
about signals, better documentation of scan and test
structures, and full documentation of all test protocols.
Top-level
Using CTL in test synthesis full netlist
A core is a hierarchy internal to the design. The
needs in a hierarchical DFT flow are similar to
Figure 6. Bottom-up hierarchical DFT synthesis flow using
those in a test reuse flow except that the core’s
a CTL-based DFT model.
test patterns are not needed. Thus, CTL lets you de-
sign a chip’s DFT logic in a bottom-up, hierarchical
flow (Figure 6). Lower-level blocks can be designed The model also allows for the definition of the test
in parallel complete with any DFT logic and scan mode setup at the block’s boundary, and this setup
chain segments. An abstract DFT model can then can then be verified at the top level to ensure that
be generated for these blocks, and this model can scan chains throughout the block are operational at
be used to integrate the block-level DFT logic at that level. At the top level, the scan segment informa-
the top level. Using CTL to model the DFT logic fos- tion from the CTL model is used to configure the
ters a standard, more flexible flow for DFT block-level scan segments into top-level scan chains,
insertion, in which different DFT synthesis tools balancing the chains and automatic insertion of lock-
can be mixed and matched, leading to higher pro- up latches to avoid any issues related to clock skew
ductivity and tool interoperability. for scan chain operation.
The Synopsys and Cadence DFT solutions let The CTL-based model greatly improves the effi-
designers write a complete CTL model for the DFT ciency of DFT insertion at the top level because it
logic of a block or design. The model captures infor- doesn’t need the full netlist only a far smaller DFT
mation such as number of scan chains or segments in model for each block.
the block, the start and end scan data pins (scan-in
and scan-out pins) for each scan segment, the length CTL HAS BEEN ADOPTED for use in test automation
of each scan segment, the launch and capture clock tools in many different ways. Although it has been
pins, and the active edge for each scan segment, as used to develop tools for test reuse, it has also been
well as scan control signals such as shift enable. employed as an input to ATPG, an output to ATPG,

January/February 2009 41
[3B2-8] mdt2009010036.3d 6/1/09 11:10 Page 42
IEEE Std 1500 and Its Usage
and an integral part of a DFT synthesis environment
where abstraction is needed for capacity reasons. 
 References
1. E.J. Marinissen et al., ‘‘Towards a Standard for
Embedded Core Test: An Example,’’ Proc. Int’l Test
Conf. (ITC 99), IEEE CS Press, 1999, pp. 616-627.
2. E.J. Marinissen, R. Kapur, and Y. Zorian,‘‘On Using IEEE
P1500 SECT for Test Plug-n-Play,’’ Proc. Int’l Test Conf.
(ITC 00), IEEE CS Press, 2000, pp. 770-777.
3. IEEE Std 1450.6-2005, IEEE Standard Test Interface
Language (STIL) for Digital Test Vector Data-Core Test
Language (CTL), IEEE, 2006.
4. IEEE Std 1500-2005, IEEE Standard Testability Method for
Embedded Core-Based Integrated Circuits, IEEE, 2006.
5. M. Keating and P. Bricaud Reuse Methodology Manual:
For System-on-a-Chip Designs, 3rd ed., Springer, 2002.
6. IEEE Std 1450-1999, IEEE Standard Test Interface Lan-
guage (STIL) for Digital Test Vector Data, IEEE Com-
puter Society, 1999.
Rohit Kapur is a scientist at Synopsys working in the
area of IC test. His research interests include IC test
methods and their use in design flows. He has a BS
in electronics engineering from Birla Institute of Tech-
nology, Mesra, India, and an MS and a PhD in
42
computer engineering from the University of Texas at
Austin. He is a Fellow of the IEEE.
Paul Reuter is an engineer in the DFT organization at
Mentor Graphics. His research interests include ATPG,
core test reuse, memory BIST, and defect-based test-
ing. He has a BS in electrical engineering from the
University of Cincinnati. He is a member of the IEEE
Computer Society.
Sandeep Bhatia is a senior architect at Cadence De-
sign Systems. His research interests include DFT, test
compression, ATPG, low power, and logic synthesis.
He has a BTech in electrical engineering from the Indian
Institute of Technology, Delhi, India, an MS in computer
engineering from the University of Rochester, and a PhD
in computer engineering from Princeton University.
Brion Keller is a senior architect at Cadence Design
Systems. His research interests include ATPG, logic
and fault modeling, fault simulation, logic BIST, and
test compression. He has a BS in computer science
from Penn State University. He is a member of the IEEE.
Direct questions and comments about this article to
Rohit Kapur, Synopsys, 700 East Middlefield Road,
Mountain View, CA 94043; rkapur@synopsys.com.
IEEE Design & Test of Computers
[3B2-8] mdt2009010036.3d 6/1/09 11:10 Page 43