Overview of the IEEE PI500 Standard

',
Francisco DaSilva Yervant Zorian 2, Lee Whetsel 3, Karim Arabi 4, Rohit Kapur
1
Synopsys, Inc. Mountain View, CA. USA Francisco.DaSilva@,synopsys.com
Virage Logic. Fremont, CA. USA zorian@Jviranelop;ic.com
Texas Instruments. Dallas, TX. USA [email protected]
4
PMC Sierra. Burnaby, BC. Canada Karim ArabiOpmc-sierra.com
5
Synopsys, Inc. Mountain View, CA USA Rohit.Kapur@,synopsys.com

various types of difficulties including automation and test

Abstract Plug-and-Play just to name a few. Many companies have
Design reuse has been a key enabler to efficient ,System- recognized these issues for years and have developed
On-Chip creation, by allowing pre-designed functions to home-grown solutions to cope with them. While these
be leveraged, thereby reducing development cycles and solutions are appropriate in scenarios where the core
time to market, The test of these pre-designed blocks, provider and the core user are the same entity, these
often referred to as cores, is a primordial factor to solutions don't scale very well to cases where third-party
successful design reuse methodologies, and must be core providers or core users are involved. This creates a
considered by anticipation with various degrees of need for a standard approach to the resolution of these
challenges depending on the mergeable or non-mergeable challenges. To meet this requirement, the IEEE P1500
nature of the core. This paper presents the state and working group was formed and has developed a core-
accomplishments of the IEEE 1500 proposal for the test level solution to facilitate test integration and test reuse.
of non-mergeable cores. This solution is based on the combination of a hardware
architecture and an information model that provides a
standard and automated approach to the test reuse
I Introduction challenge. After presenting the IEEE P1500 hardware and
According to the ITRS (2001), the number of SoC logic information model, the following sections will discuss
transistors per designer-year, for a 10-person design team, compliance to PI500 and current limitations of the
will increase by 116% in the four year span ranging from standard.
2001 to 2004. This increase is predicted to be around
392% by the year 2007. Another key statement from the
same report is an accompanying exponential increase in 2 IEEE PI500 hardware
design cost. These predictions make overall design cost architecture
productivity optimization methodologies, a vital
economic requirement. One such methodology has been The IEEE P1500 architecture is characterized by
design reuse, where reuse methodologies allow pre- flexibility and scalability. Careful consideration was given
existing design functions (cores) to be efficiently to the Plug-and-Play aspects of heterogeneous cores
integrated into new chips, thereby cutting design integrated into the same chip. The PI500 hardware
development cycle time and reducing time to market. This architecture comprises an Instruction Register (the
however assumes that certain guideline-steps are taken Wrapper Instruction Register), and two data registers, the
during the design of these cores, making them efficiently Wrapper Bypass Register (WBY) and the Wrapper
reusable. Design-for-Reuse therefore becomes an Boundary Register (WBR). The use of Core Data
indispensable condition to the above-mentioned design Registers (CDRs) is also anticipated by the standard.
productivity optimization. The same is valid for efficient Access to these registers is provided via a set of wrapper
test of non-mergeable cores, because this would require interface ports. Figure 1 displays the mandatory
test reuse, which in turn assumes that certain test-specific components of the IEEE P 1500 architecture.
guideline-steps are taken during the design of these cores.
The test of these cores can become a challenge, with
Paper 38.1 ITC INTERNATIONAL TEST CONFERENCE
988 0-7803-8106-8/03 $17.00 Copyright 2003 IEEE
 0 A Wrapper Serial Output (WSO) terminal.
A Wrapper clock (WRCK) terminal
A Wrapper Reset (WRSTN) terminal
Functional Functional
Inputs outputs 0 An Instruction Register selection (SelectWIR)
Functional Functional terminal
Outputs Inputs
A Wrapper Capture (CaptureWR) terminal
A Wrapper Shift (ShiftWR) terminal
WSI wso Optionally, the WSPs can contain functional clocks
referred to as Auxiliary Clocks.
h
wsc The Wrapper Instruction Register exclusively relies on the
state of WSP terminals for the configuration of the P1500
wrapper.
Figure 1: Mandatory components of the IEEE P1500
wrapper
2.1.2 Wrapper Parallel Ports (WPP)
WPP terminals are optional signals provided for the
anticipated use of high bandwidth test requiring more data
2.1 The'wrapperhterface ports terminals than the mandatory serial path connecting the
WSI and WSO terminals. These parallel access terminals
IEEE std. P1500 defines a collection of wrapper interface
are user-defined.
ports that fall into two categories:
0 Wrapper Serial Ports. (for serial access to the
wrapper) 2.2 The Wrapper Boundary
Wrapper Parallel Ports (for parallel access to the Register (WBR)
wrapper) The WBR provides access to core terminals from the
wrapper interface ports. It is a collection of P1500
Figure 2 represents the P1500 wrapper interface
wrapper cells configurable in response to an instruction
terminals.
shifted into the WIR. While The IEEE P1500 architecture
---------_ mandates use of storage elements for the creation of
User Defined Port I Wrapper I Optional Wrapper P1500 wrapper cells, this architecture also recognizes the
for Test Flexibility-/ Pa t r o ~I f i p a r a l l e I port (WPP)
----------- I---------_- I
need for exempting test-only core terminals from that
I
requirement. The P1500 hardware anticipate the use of
harnessing logic to provide control over these test-only
-------- terminals that are otherwise exempted from the need of a
wrapper cell. This type of harnessing provides parallel
access to the P1500 wrapper from a Test Access
I- - - - - - - -1 Mechanism (TAM). Whether accessed through the
mandatory serial wrapper interface of the optional parallel
wrapper interface, the WBR's behavior is categorized in
I-----------
Senal Input Senal Output i
terms of events.
Required W r a p p e r d I
Serial Port (WSP) I- -Senalcontrol
---_---- 1 for Plug & Play
2.2.1 WBR events
P1500 defines a set of events that control the operation of
Figure 2: Wrapper interface terminals the WBR. These events are Shift, Capture, Update and
Transfer. The WBR events are defined below.
2.1 . I Wrapper Serial Ports (WSP)
WSP terminals are mandatory signals made of:
A Wrapper Serial Input (WSI) terminal
Paper 38.1
989
 2.2.1.1 The Shift event at-speed testing. The PI500 wrapper has a flexible WBR
structure that supports any type of wrapper cells.
Shift is an event whereby the data stored in the WBR shift
path is advanced one storage position closer to the WBR's
Test Output (TO). The data present at the WBR's Test 2.2.2.1 P1500 wrapper cell naming
Input (TI) is loaded into the shift path storage element
closest to the WBR's TI. convention
In order to represent the scalable nature of P1500 wrapper
cells, the following regular expression is used to name
2.2.1.2 The Capture event P 1500 wrapper cells:
Capture is an event whereby the data present on WBR cell /WC-S[DF]\d+cC( [IOB][IOU])l N)?CU[DF])?CO)?CG)?/
functional inputs (CFI), or on WBR cell functional
outputs (CFO), at a characteristic instant is stored in a The above regex provides a descriptive, parse-able
sequential element within a WBR cell. P1500 requires method for identifying P1500 wrapper cells. Each cell
that data captured in a cell is stored in the shift path type name begins with "WC", meaning WBR Cell,
storage element of the cell closest to the cell's test input followed by a sequence of characters that describes the
(CTI), or in the shift path storage element of the cell capabilities and structure of the cell. The information will
closest to the cell's test output (CTO), or in the optional indicate whether a particular storage element is shared or
off-shift-path update storage element of the WBR cell. dedicated to wrapper operation, how many shift-path
storage elements exist, the existence and type of the
optional update cell and the existence of a safe data. To
2.2.1.3 The Update event support this, from one to five fields will exist in the name
in a specified order. Each field begins with an underscore.
Update is an optional event whereby data stored in a
WBR cell's shift path storage element closest to CTO is The first field is mandatory, and describes the nature and
loaded into an off-shift-path storage element. The update number of shift path storage elements. The first letter of
event is only applicable to wrapper cells provided with an this field is "-St', to represent the word "Shift". The
update storage element. The provision of an update second letter is either D or F indicating "Dedicated" or
storage element is an optional step. (shared) Functional, followed by an integer indicating the
number of shift path storage elements. This first field has
the following regular expression (regex) format:
2.2.1.4 The Transfer event /-S [DF]\d+/.
Transfer is an optional event that moves data to or within The second field indicates the site where data is captured.
the shift-path of a WBR cell dependent on both or either: The first letter of this field is " C " ,to represent the word
"Capture". The second letter of this field specifies the
the case where data stored by the capture event is origin of captured data: I (CFI Input), 0 (CFO Output) or
stored in any storage element other than the shift B (selectable). The last letter of this field indicates the
path storage element closest to CTI. In this case, capture site: the first element of the shift path (I), the last
the transfer event will cause the data present in element of the shift path (0)or the update storage element
the storage element used for the purpose of (U). In the case where data is captured from CFI and the
provisioning the capture event, to be stored into capture site is the first element of the shift path (i.e.
the shift path storage element closest to CTI; CII"), the entire second field may be omitted. In case
the case where more than one storage element the wrapper cell being described does not perform the
exists in the shift path; in this case, the transfer capture function, both second and third letters in this field
event will cause data stored in the shift path to should be replaced by "N" (None), to indicate that there
move one element closer to CTO. are no origins for captured data, and that the capture site
does not exist. The regex matching this second field is
2.2.2 P I 500 wrapper cells /CC([IOB][IOU]) I N)?/.
A PI500 wrapper cell is expected to contain at least one The third field describes the nature of the update element.
register and respond to the shift and capture events. The It is composed of two letters, the first of which is "-Uf'
PI500 hardware architecture ensures that all the test data representing the word "Update". The second letter is
related to a particular core terminal is contained in the either a D or an F indicating dedicated or (shared)
wrapper cell associated with that terminal. This provides a Functional. Its regex format is /CU[DF])?/. The absence
scalable architecture containing one or more registers that of this field indicates the absence of an Update storage
can be adapted to multiple-stimulus type of testing such as element.

Paper 38.1
990
The fourth field indicates by its presence or absence, the
presence or absence of an observe-only characteristic. It is
composed of an under-bar followed by an 0. Its regex
format is /-O/.
The final field indicates by its presence or absence, the
presence or absence of safe data support in non-hazardous
mode. It is composed of an under-score followed by a G
(Guarded data). Its regex format is / -G/.
storage
elements

Figure 3 , Figure 4 and Figure 5 show P 1500 wrapper cells STC

named with the above regular expression.

2.2.2.2 P1500 wrapper cell examples

T
CTI

The following two examples are provided to demonstrate Figure 4: A WCSDn-CII-UD wrapper cell
the flexibility built into PI500 wrapper cells. Figye 3
depicts the simplest P 1500 wrapper cell structure
containing a single storage element (represented with the Figure 5 shows other flexibility characteristic of a PI500
circle). The letters inside the circle describe WBR events wrapper cell. The cell in this figure selectively captures
that affect the storage element. The storage element data from CFI, or CFO (to provide testability on the CFO
shown in the below figure responds to the shift (S) and terminal). In addition, this cell has provision for safe data
capture (C) events. In addition, the register is shared with output to prevent corruption of external logic data.
functional logic (F). The wrapper cell pin names are:
CTI: Cell Test Input
--
0

-
CTO: Cell Test Output
CFI: Cell Functional Input
CFI
-
- b

Safe CFO
CFO: Cell Functional Output Valu?

CTO

CFI CFO
Figure 5: A WC-SD1-CBI-UD-G wrapper cell

2.2.3 Configuration of the WBR

P1500 provides support for serial and parallel types of
test. Each type (serial or parallel) of test corresponds to a
Figure 3: A WC-SF1-CII wrapper cell serial or parallel configuration of the WBR

The example in Figure 4 is a more complex case featuring 2.2.3.1 Serial configuration of the
the optional Transfer and Update events along with
multiple shift-path storage elements.
WBR
The serial configuration of the WBR is mandated by the
P1500 standard. Through this configuration, the WBR is

Paper 38.1
991
 accessed via a unique set of Test Input (TI) and Test CDRs, as depicted in Figure 6 . In addition, the state of the
Output (TO) signals. WSP set of terminals is used to determine selection of the
currently active data register.
I I

TI TO
WSI ‘

Figure 6: Data Register control from the WIR

2.2.3.2 Parallel configuration of the
WBR
The parallel configuration of the WBR is optional. In this 2.3.1 IEEE PI500 instructions
configuration the Wrapper Boundary Register becomes a
IEEE std. P1500 wrapper instructions determine the state
set of chain segments, with each segment serially
the wrapper. Two types (mandatory and non-mandatory)
individually accessible via its own Test Input (TI) and
of instructions are defined by the proposed standard, with
Test Output signals.
provision for optional user-defined instructions. The
WO1 WIl predefined P1500 instructions cover needs for inward-
facing test, outward-facing test and also the serial, parallel
or hybrid nature of the test. Serial instructions are
required to use WSP terminals while parallel instructions
use WPP terminals. Hybrid instructions are specific to
tests that require the use of a combination of WSP and
WF-2 WPP terminals. A generic naming convention was
defined for P 1500 instructions as follows:
W<ParalleYSeriaVHybrid>
-<Mode>-<Configuration>
v=-3
Where:

CLK .
W - stands for wrapper and is a prefix to all standard
1500 instructions
ParalleYSeriaYHybrid - an “S” denotes a serial mode
instruction. A “I”’ represents a parallel mode instruction.
An “H’ stands for a hybrid instruction. Note that a
standard parallel instruction (e.g. WP-EXTEST) must
2.3 The Wrapper Instruction have the WBY between WSI and WSO - although this is
not a hybrid instruction. An instruction by which any
Register register other than WBY is configured between WSI and
The wrapper instruction register configures the P1500 WSO and which also uses the parallel port, is classified as
wrapper into a certain mode of operation determined by a hybrid instruction.
an instruction shifted into the WIR via the WSP set of Mode - “Mode” is a shortened description of the
terminals. The WIR circuitry decodes loaded instructions instruction mode, such as Bypass, Preload, Clamp, Safe,
and provides individual controls to the WBR, WBY or Intest, Extest or User (for user-defined instructions).
Paper 38.1
992
Configuration - “Configuration” describes the wrapper
configuration of a particular instruction. Possible
configurations are SCAN to denote that internal core scan
chain(s) participate in the test, RING to denote that only
the WBR participate in the test (at the exclusion of any
internal core chains), User for a user defined
configuration not covered in the above configurations.
For instance, during the serial instructions
WS-INTEST-SCAN and WS-lNTEST-RING, SCAN
denotes that internal scan chains are included in the single
scan chain between WSI and WSO. RING indicates that
only the wrapper chain is between the WSI and WSO.
The IEEE P 1500 standard requires the following
instructions:
0 WS-Bypass
WS-Extest Figure 8: Wrapper configuration during the
WS-Intest-Scan instruction
0 One Serial, Parallel or Hybrid Intest instruction
The following figures depict the wrapper configuration
during mandatory P1500 instructions. Figure 9 shows the P1500 wrapper configured following
the load and update of the WS-Extest instruction. In this
Figure 7 depicts the P1500 wrapper configuration configuration, data flows from WSI to WSO through the
following the load and update of the WS-Bypass WBR (which interacts with the external logic being
instruction into the WIR. In this, configuration the data tested).
path flows from WSI to WSO through the bypass register.

Miss

Miss Mission Mode

\
WS-Extest
4 \
WSP Data Path
Is highlighted
Figure 9: Wrapper configuration during the
WS-Extest instruction
Figure 7: Wrapper configuration during the
WSBypass instruction
In Figure 8 the P1500 wrapper is configured as a result of
the WS-Intest-Scan instruction being active in the WIR. 2.4 The Wrapper Bypass Register
In this configuration, data flows from WSI to WSO via WBV3
the WBR and the core (internal scan and functional I/Os).
The WBY is a mandatory register selected by the WIR in
response the WS-BYPASS instruction. This data register
is then connected between the WSI and WSO terminals of
the WSP and can be shifted using protocol applied to the
signals of the WSC terminals. This register is the default

Paper 38.1
993
 wrapper data Register and is selected when no other
wrapper data register is selected. While the WBY
preferably contains a single register to facilitate
abbreviation of the scan path length through a wrapper, it
may contain additional registers. The WBY does not
have an update stage.

2.5 Timing and Plug-and-Play

The operation of a P1500 wrapper relies on well-defined
protocols applied via the WSP terminals. These protocols
insure plug-and-play interoperability between serially
connected wrappers in an SOC.

2.5.1 Wrapper enabled and disabled

states
The "wrapper enabled" state allows regular P1500
operation of the wrapper logic. Conversely the "wrapper
' ul-! w
disabled" state puts the wrapper logic into a transparent
state that forces functional operation of the core. The Figure 10: WSP timing diagram
"wrapper disabled" state is activated by loading the
WS-Bypass instruction into the WIR or by asserting the
The above-described PI 500 architecture defines design-
WRSTN WSP terminal to its active (low) value. The
"wrapper disabled" state can be achieved by gating the for-test-reuse considerations to be taken, specific to the
WIR outputs (with WRSTN = 0). In this case a reuse of non-mergeable cores. This however only
addresses half of the problems related to test reuse. SoC-
synchronous reset operation is still needed to load the
WS-BYPASS instruction into the WIR before the specific issues such-as TAM design and pattern mapping
from core-level to SoC level must also be considered.
Wrapper is enabled by de-asserting the WRSTN signal.
For this reason it is allowed to require an active WRCK PI 500 does not address TAM-related challenges, but
clock during Wrapper Disabled state, prior to using the provides a solution for ease of pattern mapping. This is
Wrapper in the Enabled state. achieved via the use the IEEE P1450.6 Core Test
Language to create core-level P1500 information model.

2.5.2 Wrapper operation timing

3 P I 500 Information Model
One of the challenges specific to the core-provider I core-
Figure 10 displays the timing relationship between WSP user business model is providing test-relevant information
terminals, for a proper operation of the P1500 wrapper. from the core-provider to the core-user in a consistent
At the exception of WRSTN, all WSP terminals are active manner that is not company-specific. This is one of the
high. Also noteworthy are the facts that update operations areas where the P1500 standard innovates by tying the
are effective on the falling edge of WRCK, and the WSO P1500 hardware architecture to a P1500 specific
terminal is clocked on the falling edge of WRCK. language. This language is the P1450.6 Core Test
Language (CTL).

3.1 Introduction to CTL

The Core Test Language was developed to allow the
description of design-specific data required for test
purposes. CTL is an extension to the Standard Test
Information Language (STIL), and as such carries
protocol and data (patterns) required to integrate core-
level test data into an SoC environment. CTL has a
Paper 38.1
994
modular approach that separates test protocol from test (PINID). The wrapper cell is described via the cell-enum
data, thereby simplifying the test data integration variable. The cell-enum variable represents the regular
challenge at the SoC level. With the use of CTL, patterns expression used to name P1500 wrapper cells in section
provided with a core remain unchanged, while the 2.2.2.1 (P1500 wrapper cell naming convention). This is
protocol information is adapted to the SoC environment also shown on lines 14 to 17. The above CTL example
hosting the integrated core. This is achieved without therefore shows a mechanism for describing the
requiring the netlist of the core, but by considering the association of a P1500 wrapper cell to a core terminal.
core as a black-box. The black-box approach is The absence of a wrapper cell on a particular core
particularly usefid for test data integration since certain terminal is also describable in CTL.
cores (hard cores) are not (by definition) provided with a
full netlist. This approach also serves Intellectual Property
protection purposes. 3.1.1.2 P1500 protocol specification in
CTL
3.1.I P I 500 and CTL There are two types of protocols involved with the
integration of P1500 compliant cores in an SOC.The first
One of the main P1500 achievements is the ability to
type of protocol relates to the operation of P1500-specific
automate the overall test reuse process from the core
functions, while the second type of protocol relates to the
creation stage to the core integration stage. This was
mapping of core-level patterns into the SoC environment.
achieved by defining the P1500 hardware with a very
Only the former type is addressed here, since the latter
structured approach wherever appropriate in order allow
chip-specific.
ease of software automation. The following two sub-
sections show how PI 500-specific information is The proper operation of P1500 core depends on the
described in CTL for automation purposes. definition of predefined sequences of event referred to
here as protocols. Therefore, protocols are associated with
Pl500 instructions, and are expected to be defined by the
3.1.1.1 Core pin wrapping description core provider for the core-user's benefit. The below
in CTL section of CTL code is an example describing the protocol
associated with the loading of an Intest instruction into the
One example of this is the parse-able structure of the WIR.
P1500 wrapper cell naming convention.

1 MacroDefs {
1 Environment (Env-name) { 2 setup-intest {
2 CTL (CTL-name){ 3 W defaultWFT;
3 External { 4 V { WRSTN=O; }
4 (sigref-expr { 5 V { WSP[ 0. .5] = 110100; 1
5 (connectTo { 6 Shift { V {
6 Wrapper /IEEE1500/ 7 i-wir=' instruction[ 0. .3] ;
7 (CellID cell-enum I PinID 8 WRCK=P;} }
8 user-def ined); 9 V { si-wir=X; WRCK=O; ShiftWR=O;
9 1 )* 10 UpdateWR=l;}
10 I)+ 11 V { WRCK=P;}
11 1 12 V { WRCK = 0; SelectWIR=O;
12 1 UpdateWR =O;}
13 1 13 1
14 cell-enum = 1 4 Environment {
15 / (WC-S[ DE7 \ d+ C-C ([ IOBI IOU] ) I 15 CTL {
16 N)? (-v[ DFI ) ? (-GI?) I 16 PatternInformation {
I7 (User USER-DEFINED) / 17 Macro setup-intest {
18 Purpose Instruction
19 1
The above CTL description shows P1500-specific CTL 20 }
keywords used to identify P 1500 hardware components. 21 1
The fEst one on line 6 notes the existence of a P1500 22 1
wrapper. The following line (7) identifies the P1500
wrapper cell associated with a particular core pin

Paper 38.1
995
 The above CTL code contains two sections, a macro 4.2 Wrapped Compliance
definition section (lines 1 to 13) and an environment
section (lines 14 to 22). The purpose of the above setup The P 1500-wrapped compliance level requirements must
macro is to load the Intest instruction into the WIR. This be met in order to achieve test reuse. The information
is done by first putting the P1500 logic into wrapper- model for a wrapped-compliant core provides all data
enabled mode (line 4), and then constraining Wrapper required by core integrators to successfully integrate the
Serial Port terminals (line 5) to allow shifting into the core and map test patterns to the top-level of the device.
WIR. The actual shifting of the WIR occurs in lines 6 Wrapped compliance is achievable by the core provider or
through 8, followed by the update of the instruction with the core user. Core users can achieve wrapped compliance
lines 9 through 11 (with UpdateWR active). The from unwrapped-compliant cores or directly from non-
environment section of the CTL code puts the above setup compliant cores.
macro in to the context of the overall test. In this
particular example, the “Purpose” (line 18) indicates that
the above macro is to be applied to the “Instruction” 5 Limitations
register. The P1500 standard does not provide support for bi-
directional wrapper cells, since the use of bi-directional
The above examples are meant for describing how P1500
terminals is discouraged under design reuse guidelines.
specific information is provided in CTL to allow test
reuse automation at the SoC level. The Pl500 standard
requires that CTL is provided with P1500 cores as a
condition for claiming P1500 compliance. 6 Discussion
While P1500 does not provide direct support for bi-
directional terminal wrapping, users of the standard can
4 IEEE 1500 Compliance provide wrapper cells on the individual signals
composing the bi-directional terminal. In the case where
Cores can be provided and used by third-party companies
the bi-directional terminal exists at the core level,
and because of this it may not always be possible for the
wrapper cells for the input, enable and output signals of
core-provider to optimally select certain P1500
the bi-directional can be provided inside the core being
components such as the type of wrapper cell to be used to
wrapped.
wrap the core, since, this selection could be TAM
dependent and therefore chip-dependent. For this reason,
the P1500 standard allows cores to exist in both
unwrapped and wrapped forms and has defined
7 Conclusions
unwrapped PI 500 compliance requirements as well as The presented IEEE P 1500 standard overview provides a
wrapped P1500 compliance requirements. Both solution to test reuse challenges by defining core-level
compliance levels require provision of the core design-for-test-reuse requirements. These requirements
information in CTL, by using CTL specific keywords are a combination of hardware rules and information
identified by the P1500 standard in order to achieve CTL model requirements that allow for automated Plug-and-
interoperability. The type of P1500 compliance achieved Play test integration at the SoC level.
by a particular core is expected to be provided in the
accompanying CTL code.

4. I Unwrapped Compliance
The P1500-unwrapped compliance level is an
intermediate level defined to ensure that appropriate test
information is provided to the core user. A P1500-
unwrapped compliant core information model enables
automatic P 1500 wrapper generation. For unwrapped-
compliant cores, the core user is expected to complete
compliance by meeting wrapped compliance
requirements, without having to modify the original
(unwrapped) core.

Paper 38.1
996
 [8] Rohit Kapur, Maurice, Lousberg, Tony Taylor, Brion
Keller, Paul Reuter, Douglas Kay, “CTL the Language for
Acknowledgements Describing Core-Based Test,” in Proceedings of the
International Test Conference, 2001, pages 131-139.
At the time this document was written the following
people were P1500 task force contributors: [9] Michael Keating, Pierre Bricaud, Reuse
Methodology Manual for System-on-a-Chip Designs,
Alan Hales, Brion Keller, Bulent Dervisoglu, Douglas
Kluwer Academic Publishers, Nonvell, Massachusetts.
Kay, Erik Jan Marinissen, Fidel Muradali, Francisco da
Silva, Grady Giles, Jason Doege, Jim Monzel, Jon Udell, [ 101 Erik Jan Marinissen and Maurice Lousberg, Macro
Karim Arabi, Lee Whetsel, Luis Basto, Mike Collins, Test: A Liberal Test Approach for Embedded Reusable
Mike Mateja, Mike Ricchetti, Paul Soong, Rohit Kapur, Cores, in Digest of Papers of IEEE International
Saman Adham, Teresa McLaurin, Tom Waayers, Vivek Workshop on Testing Embedded Core Based Systems
Chickermane, Wu-Tung Cheng, Yervant Zorian (TECS), 1997, pages 1.2-1.9.
[ l l ] V. Iyengar, K. Chakrabarty, and E.J. Marinissen,
References “CO-Optimization of Test Wrapper and Test Access
[ 11 Semiconductor Industry Association (SIA), Architecture for Embedded Cores,” Journal of Electronic
International Roadmap for Semiconductors (ITRS), 200 1 Testing: Theory and Applications, vol. 18, no. 2, pp. 213-
230, April 2002.
[2] IEEE P1500 Web Site,
http://grouper.ieee.orrz/aroups/l5OO/ [12] E.J. Marinissen and Y. Zorian, “Challenges in
Testing Core-Based System ICs,” IEEE Communications
[3] Erik Jan Marinissen, Yervant Zorian, Rohit Kapur,
Magazine, vol. 37, no. 6, pp. 104-109, June 1999.
Tony Taylor, and Lee Whetsel, Towards a Standard for
Embedded Core Test: An Example, in Proceedings IEEE [I31 M. Sugihara, H. Date, and H. Yasuura, “A Novel
International Test Conference (ITC), 1999, pages 616- Test Methodology for Core-Based System LSIs and a
627. Testing Time Minimization Problem,” in Proceedings
IEEE International Test Conference (ITC), Washington,
[4] Erik Jan Marinissen, Rohit Kapur and Yervant Zorian,
On Using IEEE PI500 SECT for Test Plug-n-Play, in DC, Oct. 1998, pp. 465472.
Proceedings of the International Test Conference (ITC), [14] L. Whetsel and M. Ricchetti, “Tapping into IEEE
2000, pages 770-777. PI500 Domains,” in Digest of Papers of IEEE
International Workshop on Testing Embedded Core-
[SI Yervant Zorian and Erik Jan Marinissen, System Chip
Test: How will it impact your design, Embedded Tutorial Based Systems (TECS), Marina del Rey, CA, May 2001,
8.1 at ACMJIEEE Design Automation Conference (DAC) pp. 3.2-1-7.
2000 [15] L. Whetsel, “An IEEE 1149.1 Based Test Access
[6] CTL Web Site, http://grouper.ieee.org/groups/ctl/ Architecture For ICs With Embedded Cores”, IEEE
International Test Conference 1997, pp. 69-78.
[7] IEEE Computer Society, IEEE Standard Test Interface
[ 161 L. Whetsel, “Addressable Test Ports - An Approach
Language (STIL) for Digital Test Vector Data Language
to Testing Embedded Cores”, IEEE International Test
Manual IEEE Std. 1450.0-1999. IEEE New York,
Conference 1999, pp. 1055-1064
September 1999.

Paper 38.1
997