NON-MERGED CORES REQUIREMENTS SURVEY
Your Name _______________________________________________
Contact Information _______________________________________________
_______________________________________________
_______________________________________________
E-Mail Address _______________________________________________
OBJECTIVE
This is a Survey Document of the IEEE Study Group on Embedded Core Test.
The information will be used to help define and validate cores and system-on-silicon
related test standards. Please provide information on the key core-related
test methodologies used in your company. Each methodology requires completing
a separate survey. Information should be provide only on non-merged cores,
i.e., those cores that remain distinguishable from other IC regions for
test purposes.
ACCESS
Access to response information on this survey will be limited to three Study
Group members. Access to summary and statistical information will be made
public, i.e., available to all Study Group members and any other requesters.
A WEB page is also proposed.
HOW TO OBTAIN AND RESPOND TO THIS SURVEY
This survey will be distributed by FAX, postscript and PDF. It should
be completed and returned by FAX. Please fill in the information as
completely as possible. Survey requests and responses should be
directed to Yervant Zorian:
by E-mail to <zorian@lvision.com>,
or USA FAX: 609-497-1754,
or Address: LogicVision, 31B Chicopee Dr., Princeton, NJ, 08540.
CONFIDENTIALITY
Do not provide company proprietary or confidential information without permission
from your appropriate management. Omit this information if necessary. Since
our focus is on test specific information, please be as complete and precise
as possible in these areas. Thank you.
1. GENERAL CORE-RELATED INFORMATION
INTELLECTUAL PROPERTY (IP/Core) PROVIDER
My company name & division is __________________________________________________
Does your company manufacture the core? Y___ N ___
The primary core process technology is/will be (e.g., 0.25u CMOS GA-5ML-3W)
________________________________________________________
Groups in my company are responsible for the following operations in development
of the core:
Specification ____ Design & Validation ____
DFT ____ Floorplanning ____ ATPG ____ Place & Route ____ Manufacture
____ Test ____ Failure Analysis ___
COMPONENT DEVELOPMENT
The principle core function(s) is (e.g., PCI, ATM, microprocessor, MPEGII)
________________________________________________________
Is reuse an objective for development of this core? Y___ N ___
Is core manufacture limited to your process technology? (HDL) NA ___ Y___
N ___
Is the core derived from a standalone IC? Y___ N ___
PORTABILITY OBJECTIVES
Do you plan internal (in-house) reuse for the core? Y___ N ___
Do you plan sale of this core to an external customer? Y___ N ___
Are existing ATPG Patterns to be reused with this core? Y___ N ___
Are Gate/Layout level descriptions to be provided to users? Y___ N ___
Are full timing simulation model(s) to be provided to users?
RTL level Y___ N ___
Gate-level Y___ N ___
Are interface/protocol simulation model(s) to be provided to users? Y___
N ___
Are timing shell(s) to be provided to users? Y___ N ___
For simulation Y___ N ___
For synthesis Y___ N ___
INTERNAL CORE LOGIC TYPES
Does the core contain:
Synchronous fully-static digital logic? Y___ N ___
Synchronous dynamic digital logic (e.g., domino)? Y___ N ___
Asynchronous (no clock) digital logic? Y___ N ___
Analog (e.g., PLL) circuits? Y___ N ___
Embedded static memory? Y___ N ___
Embedded dynamic memory? Y___ N ___
Internal Clock generation? Y___ N ___
Can ATE clock(s) override core internal clocks? Y___ N ___
CORE INTERNAL DFT
Are modifications made to enhance testability? Y___ N ___
Scan Method: Partial Scan ____ Full-scan ____
Scan Style: MUXed FF ____ Clocked Scan ____ LSSD ____ Other ____
Is RAM/ROMBIST used? Y___ N ___
Serial ____ Parallel ____
Is other Regular Structure BIST used? Y___ N ___
Is function-dependent BIST used? Y___ N ___
Is Logic/ScanBIST used? Y___ N ___
Is an IDDQ Testable State available? Y___ N ___
Any Other (Please Specify) ______________________________________________
CORE BOUNDARY
Specify the number of signal IO on the core boundary
Input #____ Outputs #____ Bi-directional #____
How is the direction of bi-directional core IO controlled? NA ____
____________________________________________________________
(e.g., Core Pins, JTAG controller, Other internal
registers)
Can the core be in Hi-Z state, all outputs tri-stated?
Y___ N ___
If yes, this state can be established by
Can the core can be in safe state, where it cannot
be harmed by changes on its input pins? Y___ N___
If yes, this state can be established by
CORE BOUNDARY DFT
Is core boundary Scan or register bounding used? Y___ N ___
If yes, are boundary registers in
Series? ____ Parallel? ____ Both? ____
Is the core an 1149.1 "compatible" system by itself? Y___ N ___
Is a core bypass or transparency mode available? Y___ N ___
Are there other electrical concerns (internal SSO, noise, power, ...) for
core testing?
____________________________________________________________
CORE TEST PATTERN CONTEXT
In what context(s) were test patterns generated?
These context(s) or TEST MODES will need to be re-established with the
embedded core to allow for reuse of the same patterns.
What kind of patterns are to be reused? ___________________________________________
What is their Test Vector Format? _________________________________________________
What is the simulation Vector Format (for signoff of test vectors)? ________________________
Are Static Timing analysis checks run for the Test modes? Y___ N ___
2. OVERALL IC TEST REQUIREMENTS
IC BOUNDARY
How many and what type of signal IO are on the IC boundary?
How is the direction of bi-directional chip IO
controlled? (0 bidis) NA ____
____________________________________________________________
(e.g., Core Pins, JTAG controller, Other internal
registers)
Can the IC be in Hi-Z state, all outputs tri-stated?
Y___ N ___
If yes, this state can be established by
Is the IC 1149.1 compatible? Y___ N ___
How many pins can be dedicated to IC test (in addition to 1149.1)? # ____
Is diagnosis to the failing core required? Y___ N ___
Is diagnosis internal to each core required? Y___ N ___
Is parallel (concurrent) testing of cores required? Y___ N ___
Please provide a high Level description of testing of logic external to
the core(s)
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
AC OR AT-SPEED TEST AND CHARACTERIZATION
Do you plan to test or characterize your core at-speed? (if no skip rest
of this) Y___ N ___
How many clock domains does the core contain? # _____
If more than 1, are the domains synchronized with one another? Y___ N ___
What frequencies are used?
<50MHz _____ 50-100 MHz ______ 100-200 MHz ______ >200 MHz ______
Does your core have pins besides clock pins with special timing requirements?
(e.g. signals which have timing requirements which do not correspond to
a clock edge)
If so, do these requirements relate to (check all that apply)
chip pins_____
other cores_____
other logic in the chip_____
How many core I/O's are registered?
All ________ Most ________ Some ________ None ________
Do you plan to use functional test vectors
for test ________
for characterization ________
for both ________
Do you plan to use at-speed scan-based test vectors
for test ________
for characterization ________
for both ________
3. TEST ARCHITECTURE
The Figure shows three main elements:
1. Test Socket and Core Test Model
A Test Socket is a universally recognizable structural entity that encodes
test-related information associated with a core. Test Sockets are delivered
by the core provider together as part of a structural test model of the
core. The structural test model may be functionally incomplete, for example
only include a boundary-scan shell. The Test Socket encapsulates important
information like how the (possibly very complex and hidden) internal functions
can be tested (e.g., which Socket pins must be directly accessed at the
chip-level or be connected to specific BIST controller pins to apply tests
to the core internals), or how the core can be protected while other cores
and user-defined functions are tested (e.g., a core input condition that
forces the core internals into a safe, low-power, stand-by state, and enables
the boundary-scan functions to support external testing). In a addition
to the Test Socket and the structural model, the core test model may contain
test data (e.g., functional test patterns, or BIST control patterns) and
attributes that guide the construction of on-chip support features (e.g.,
a memory BIST controller to test memories inside the core).
2. Test Adapter
The chip integrator will generally have to add on-chip features that establish
the conditions specified in the Test Sockets included in the chip. These
additional test support features are what is called Test Adapter. The Test
Adapter has to support the various modes of operation required for a comprehensive
chip-level test. This includes, for example, the ability to select one or
more Test Socket and sensitize on-chip access paths such that test patterns
can be applied to the selected cores (e.g., by adding a multiplexing matrix
that allows for connecting core pins to chip pins). At the same time the
Test Adapter may have to assert the necessary core input conditions that
force other cores into a protected state.
3. Embedded or Built-In Test Utilities
The chip test methodology may make use of Built-In Self-Test (BIST) and
other test, special test support functions (e.g., an IEEE 1149.1 TAP controller).
Rather than multiplexing core pins out to chip pins, the target test environment
may require to connect certain core pins to specific pins on these other
test utilities (e.g., a core-level scan string is added to an IEEE 1149.1
port as an internal shift register), or to connect matching core-test bus
pins in a known bus topology.
The basic idea of a Test Socket is to have a universally recognizable place
and format for specifying core-related test requirements and test data.
4. NON-MERGED CORE TEST REQUIREMENTS
Testing of an embedded core with pre-existing
test vectors requires a Test Architecture that supports:
a) its isolation (the establishment of persistent safe conditions internal
to the IC through conditioning signals applied at the IC boundary), and;
b) access to its boundary (to apply the stimulus and measure the response
as represented by the test set). Use of each set of existing test patterns
requires a mapping established by a TEST MODE that persists through the
test set application (the persistence of a stable mapping may require conditioning
on IC I/O as
well). Mapping of the test data associated with the test set to reflect
the access conditions (such as inversions, register stages in the path,
etc.) may be complex but a necessary condition is that access to core boundary
pins provides at least as much "capability" as was assumed when
the original test set for the TEST MODE was generated.
Note that a mapping may be indirect. Referring to the Figure, mapping may
be from the Test Socket (e.g., core pins) through Adapter Logic to Chip
IO. Alternatively, mapping might be from the Test Socket through Adapter
Logic to properly configured Test Utilities.
Expected Core TEST MODES include:
1. External Test Mode
2. Safe Mode
3. Internal Test Mode (one or more)
Repeat this full page for each Core Test Mode
CORE A: TEST MODE # 1 of ___
What is the function of this test mode? ___________________________________________________
Pin Type Descriptions
The Pin Type descriptions (see Appendix) and Fixed Connection Table for
the core will be used to establish structural connectivity between the Core
in its Test Socket and the Adapter Logic and Test Utilities.
Stable Value Output pins Y ___ N ___ # ___
Dont Care pins Y ___ N ___ # ___
Input pins must be held static Y ___ N ___
Direct untimed access pins Y___ N ___ # ___
Direct timed access pins Y___ N ___ # ___
Scan pins Y___ N ___ # ___
Test pins Y___ N ___ # ___
Clock pins Y___ N ___ # ___
Other (Describe) _________________________________________________
_________________________________________________
Fixed Connection Table
If fixed connections are required a Fixed Connection Table can be specified.
This information is used to determine Test Adapter Logic when combined with
the Pin Type description information.
Is a partial mapping from the Test Socket to the Test Utilities and the
IC pins required to be specified? Y___ N ___
Configuration Information
The Configuration Information determines the programming (hard or soft)
of Test Utilities. It may need to be specified for macro blocks internal
to the core which might be tested with special techniques (e.g., RAM block
parameters for RAMBIST)
Does configuration information need to be specified? Y___ N ___
Test Pattern Information
What is the target ATE model? _____________________________________________
What is the length of each target tester cycle (nsec)? #___________
How many scan-based tests (including scanBIST)? #___________
How many scan-based tester cycles? #___________
How many non-scan tester cycles (functional patterns) #___________
What are the type of patterns generated to be reused?
Deterministic stuck-fault (independent tester cycles) Y___ N ___
Deterministic stuck-fault (w/memory) Y___ N ___
Deterministic AC Y___ N ___
(Weighted) Random self-test Y___ N ___
Functional Y___ N ___
Regular Structure (eg RAM/ROMBIST) Self-Test Y___ N ___
APPENDIX: CORE BOUNDARY PIN TYPE
DEFINITIONS
1. Stable Value Outputs
Outputs that hold static at (0,1,H) or inputs that must be held static at
(0,1)
2. Dont Care
Unmonitored outputs or inputs that must be held static (0 or 1) or can switch
3. Direct untimed access
Inputs requiring stimulus or outputs requiring observation each test mode
cycle
4. Direct timed access
Inputs requiring timed stimulus or outputs requiring timed observation each
test mode cycle
5. Scan
Scan data inputs or scan data outputs
6. Test
Test mode input pins (e.g. enables) that are used
establish the Test Mode and phases within it (e.g., scan phase)
7. Clock
Input pins where levels or edges control synchronous operation or handshaking
in the core
Version 0.4
IEEE Study Group on Standards for Embedded Core Test
<coretest@computer.org>