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:


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 ____

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


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 ____

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

Block Diagram

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>