COMPONENT DEVELOPMENT

The principle core function(s) is (e.g., PCI, ATM, microprocessor, MPEGII)
   
Is reuse an objective for development of this core?     Yes:     No:     N/A:
Is core manufacture limited to your process technology?     Yes:     No:     (HDL) N/A:
Is the core derived from a standalone IC?     Yes:     No:     N/A:

PORTABILITY OBJECTIVES

Do you plan internal (in-house) reuse for the core?     Yes:     No:     N/A:
Do you plan sale of this core to an external customer?     Yes:     No:     N/A:
Are existing ATPG Patterns to be reused with this core?     Yes:     No:     N/A:
Are Gate/Layout level descriptions to be provided to users?     Yes:     No:     N/A:
Are full timing simulation model(s) to be provided to users?
        RTL level     Yes:     No:     N/A:
        Gate-level     Yes:     No:     N/A:
Are interface/protocol simulation model(s) to be provided to users?     Yes:     No:     N/A:
Are timing shell(s) to be provided to users?     Yes:     No:     N/A:
        For simulation     Yes:     No:     N/A:
        For synthesis     Yes:     No:     N/A:

INTERNAL CORE LOGIC TYPES

Does the core contain:
    Synchronous fully-static digital logic?     Yes:     No:     N/A:
    Synchronous dynamic digital logic (e.g., domino)?     Yes:     No:     N/A:
    Asynchronous (no clock) digital logic?     Yes:     No:     N/A:
    Analog (e.g., PLL) circuits?     Yes:     No:     N/A:
    Embedded static memory?     Yes:     No:     N/A:
    Embedded dynamic memory?     Yes:     No:     N/A:
    Internal Clock generation?     Yes:     No:     N/A:
    Can ATE clock(s) override core internal clocks?     Yes:     No:     N/A:

CORE INTERNAL DFT

Are modifications made to enhance testability?     Yes:     No:     N/A:
    Scan Method:     Partial Scan:     Full-scan:     N/A:
    Scan Style:     MUXed FF:     Clocked Scan:     LSSD:     Other:
Is RAM/ROMBIST used?     Yes:     No:     N/A:
    Serial:     Parallel:     N/A:
Is other Regular Structure BIST used?     Yes:     No:     N/A:
Is function-dependent BIST used?     Yes:     No:     N/A:
Is Logic/ScanBIST used?     Yes:     No:     N/A:
Is an IDDQ Testable State available?     Yes:     No:     N/A:
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? (e.g., Core Pins, JTAG controller, Other internal registers)
   
Can the core be in Hi-Z state, all outputs tri-stated?     Yes:     No:     N/A:
    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?
    Yes:     No:     N/A:
    If yes, this state can be established by
       


CORE BOUNDARY DFT

Is core boundary Scan or register bounding used?     Yes:     No:     N/A:
    If yes, are boundary registers in     Series:     Parallel:     Both:     N/A:
Is the core an 1149.1 "compatible" system by itself?     Yes:     No:     N/A:
Is a core bypass or transparency mode available?     Yes:     No:     N/A:
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?     Yes:     No:     N/A:

2. OVERALL IC TEST REQUIREMENTS

IC BOUNDARY

How many and what type of signal IO are on the IC boundary?
    Input #     Outputs #     Bi-directional #
How is the direction of bi-directional chip IO controlled (if any)? (e.g., Core Pins, JTAG controller, Other internal registers)
   
Can the IC be in Hi-Z state, all outputs tri-stated?     Yes:     No:     N/A:
    If yes, this state can be established by
       
Is the IC 1149.1 compatible?     Yes:     No:     N/A:
How many pins can be dedicated to IC test (in addition to 1149.1)? #    
Is diagnosis to the failing core required?     Yes:     No:     N/A:
Is diagnosis internal to each core required?     Yes:     No:     N/A:
Is parallel (concurrent) testing of cores required?     Yes:     No:     N/A:
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)
    Yes:     No:     N/A:
How many clock domains does the core contain?    
   If more than 1, are the domains synchronized with one another?     Yes:     No:     N/A:
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:     N/A:

Do you plan to use functional test vectors
    For test:     For characterization:     For both:     N/A:

Do you plan to use at-speed scan-based test vectors
    For test:     For characterization:     For both:     N/A:

---

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)


Please repeat this section for each Core Test Mode

The simplest way is to submit the form for the first test mode, then go back to the form. Your data should still be there, so only this section needs to be changed before resubmitting the form.

CORE A: TEST MODE # 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     Yes:     No:     N/A:     #
    Dont Care pins     Yes:     No:     N/A:     #
    Input pins must be held static     Yes:     No:     N/A:
    Direct untimed access pins     Yes:     No:     N/A:     #
    Direct timed access pins     Yes:     No:     N/A:     #
    Scan pins     Yes:     No:     N/A:     #
    Test pins     Yes:     No:     N/A:     #
    Clock pins     Yes:     No:     N/A:     #
    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?     Yes:     No:     N/A:

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?     Yes:     No:     N/A:

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)     Yes:     No:     N/A:
    Deterministic stuck-fault (w/memory)     Yes:     No:     N/A:
    Deterministic AC     Yes:     No:     N/A:
    (Weighted) Random self-test     Yes:     No:     N/A:
    Functional     Yes:     No:     N/A:
    Regular Structure (eg RAM/ROMBIST)     Yes:     No:     N/A:

---

---

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>

(Last modified: March 26, 1997 - piero@synopsys.com)

---