IEEE P1500 First SURVEY Results:

The attached survey questionnaire was sent to the members of the IEEE P1500 Working Group and an on-line version of it was posted on the Working Group web site and linked to the VSI Alliances site from April to June 1996. The core types covered by the attached results include: MPEG, PCI, SRAM, DRAM, microprocessor, video DAC, DSP, and router:


1. GENERAL CORE-RELATED INFORMATION

INTELLECTUAL PROPERTY (IP/Core) PROVIDER

My company name & division is:

Does your company manufacture the core?     Yes:9     No:1     N/A:
The primary core process technology is/will be (e.g., 0.25u CMOS GA-5ML-3W)

    1 X 0.5,  7 X 0.35, 1 X 0.25

Groups in my company are responsible for the following operations in
development of the core:

    Specification:                    Design & Validation:
    DFT: 9                            Floorplanning:
    ATPG: 8                           Place & Route: 9
    Manufacture: 8                    Test: 10
    Failure Analysis: 8

COMPONENT DEVELOPMENT

The principle core function(s) is (e.g., PCI, ATM, microprocessor, MPEGII)

    MPEG, PCI, SRAM, DRAM, microprocessor, video DAC, DSP, Router

Is reuse an objective for development of this core?      Yes: 10  No:         N/A:
Is core manufacture limited to your process technology?  Yes:  7  No: 3 (HDL) N/A:
Is the core derived from a standalone IC?                Yes:  5  No: 5       N/A:

PORTABILITY OBJECTIVES

Do you plan internal (in-house) reuse for the core?          Yes: 10  No:     N/A:
Do you plan sale of this core to an external customer?       Yes:  7  No: 3   N/A:
Are existing ATPG Patterns to be reused with this core?      Yes:  4  No: 5
Are Gate/Layout level descriptions to be provided to users?  Yes:  3  No: 7
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: 8    No: 2    N/A:
Are timing shell(s) to be provided to users?
        For simulation     Yes: 8    No: 0    N/A:
        For synthesis      Yes: 7    No: 1    N/A:

INTERNAL CORE LOGIC TYPES

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

CORE INTERNAL DFT

Are modifications made to enhance testability?     Yes: 9    No: 1    N/A:
    Scan Method:     Partial Scan: 3    Full-scan: 4      N/A:
    Scan Style:      MUXed FF: 4        Clocked Scan:     LSSD: 3      Other:
Is RAM/ROMBIST used?     Yes:     No:     N/A:
    Serial: 1    Parallel: 4    N/A:
Is other Regular Structure BIST used?     Yes: 2    No: 8    N/A:
Is function-dependent BIST used?          Yes: 2    No: 8    N/A:
Is Logic/ScanBIST used?                   Yes: 1    No:      N/A:
Is an IDDQ Testable State available?      Yes: 6    No: 4    N/A:
Any Other (Please Specify)

CORE BOUNDARY

Specify the number of signal IO on the core boundary
    Input #39-345      Outputs #8-402      Bi-directional #48
How is the direction of bi-directional core IO controlled? (e.g., Core Pins,
JTAG controller, Other internal registers)
     external / internal
Can the core be in Hi-Z state, all outputs tri-stated?    Yes: 3   No: 4   N/A:
    If yes, this state can be established by:
         internal
Can the core can be in safe state, where it cannot be harmed by changes on its
input pins?
    Yes: 7    No: 0    N/A:

CORE BOUNDARY DFT

Is core boundary Scan or register bounding used?        Yes: 7    No: 2    N/A:
    If yes, are boundary registers in    Series: 3   Parallel: 2   Both: 1   N/A:
Is the core an 1149.1 "compatible" system by itself?    Yes: 4    No: 6    N/A:
Is a core bypass or transparency mode available?        Yes: 3    No: 7    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?    BIST, functional, scan,
What is their Test Vector Format?          proprietary
What is the simulation Vector Format (for signoff of test vectors)?  proprietary
Are Static Timing analysis checks run for the Test modes?    Yes: 2   No: 6   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)
     internal register, core pin, IC pin
Can the IC be in Hi-Z state, all outputs tri-stated?     Yes: 8    No: 0    N/A:
Is the IC 1149.1 compatible?                             Yes: 3    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: 6    No: 2    N/A:
Is diagnosis internal to each core required?             Yes: 5    No: 3    N/A:
Is parallel (concurrent) testing of cores required?      Yes: 3    No: 2    N/A:
Please provide a high Level description of testing of logic external to the
core(s)
     scan, BIST, Functional, Emulation

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: 9    No: 1     N/A:
How many clock domains does the core contain? 3 X 1, 4 X 2, 1 X 3, 1 X <25
If more than 1, are the domains synchronized with one another?  Yes: 3  No: 3  N/A:
What frequencies are used?
    <50MHz:      3
    50-100 MHz:  3
    100-200 MHz: 1
    >200 MHz:    1

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: 1    Most: 7    Some: 1     None:     N/A:

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

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


4. NON-MERGED CORE TEST REQUIREMENTS

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: 5    No: 1    N/A:     #
    Dont Care pins                    Yes: 5    No: 2    N/A:     #
    Input pins must be held static    Yes: 4    No:      N/A:
    Direct untimed access pins        Yes: 4    No:      N/A:     #
    Direct timed access pins          Yes:      No: 4    N/A:     #
    Scan pins                         Yes: 3    No: 3    N/A:     #
    Test pins                         Yes: 6    No: 1    N/A:     #
    Clock pins                        Yes: 7    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: 5    No: 2    N/A:

TEST PATTERN INFORMATION

What is the target ATE model?
What is the length of each target tester cycle (nsec)?     10ns-100ns
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: