Subject:
            STIL group-4 Flow Control Minutes
       Date:
            Wed, 15 Apr 1998 11:06:30 -0700
       From:
            Don Organ <don_organ@ltx.com>
 Organization:
            LTX/Trillium
         To:
            stil-a@tessi.com
 
 
 

The minutes for the 4/15/98 STIL Flow Control teleconference minutes.

Attendees:
-------
Francisco Hernadez - TI
Gregg Wilder - TI
Ernie Wahl - Lucent
Greg Maston - TSSI
Warren Davis - IMS
Don Organ - LTX
Tony Taylor- TSSI

Agenda:
------
a) Continuation of Requirements discussion.
    Starting with Tony's  "common parameters for the flow"
    Then:
        test sites (where special processing may be required)
        flow statistical reports
        Multiple threads
        easy to maintain
b) Any missing requirements?
c) Wrap-up, action items.
 
 
 

Continuation of Requirements
-------------------

Test Sites:
    For testing special test-dice on a wafer. For example,  consider that a higher level program
    controls the test program. This higher level program recognizes when the X-Y coordinates indicate
    a different die and passes information into the Flow - where it is treated as a different
    test program.
    Another example is for environmental testing of every Nth device.
    Another example is an characterization flow - for every Nth device.
    (Also consider separate power-up and power-down flows for different devices.)
    (Also consider separate flows from Loading and Unloading a program. Ernie - each
    level of the hierarchy has an entry action, do-something, exit action.)

Flow statistical reports:
    We have no responsibilities beyond our binning requirement.
    Gregg - should we be able to program something in the Flow that
    allows the generation of a summary report after every Nth wafer?
    How much of this is design/device information the STIL program should
    contraint versus how much is
    added in from a factory process perspective?

Multiple Threads
    a) multi-site
    b) parts of tests that can be done in parallel (for mixed signal, or for cores).
    Tony: perhaps we can talk about the tests in a way that some parallelism can
    be achieved without forks and joins.
    Numerical processing may be a good candidate for compilers to institute
    multi-threading. Processing that involves the stimulus or response of
    the DUT are not good candidates.

Easy to Maintain
    Avoid redundent information/definitions.
    Use good software practices.

Don - I'll try to write this up as a more formal list of requirements to be reviewed.
Tony - Let's try a data model next.
Warren - Using use-cases would be helpful, and these can be tested against a data model.
We'll try to collect some use cases over the next weeks via e-mail.
Ernie will work with the data-model.
Next meeting we will discuss how to prepare for the STIL-A group.
 

-DVO-
 

--
==============================================
Don Organ   (408) 383-2518   don_organ@ltx.com
LTX Corp. 3930 N. First St. San Jose, CA 95134
==============================================