From: E.J.Wahl [ejwahl@agere.com]
Sent: Monday, March 11, 2002 6:32 AM
To: don.organ@inovys.com; dave_dowding@agilent.com; bill_chown@ims.com;
daniel@san-jose.tt.slb.com; wahl@aloft.agere.com;
Gordon_Robinson@3mts.com; gwilder@dal.asp.ti.com; gmaston@qwest.net;
h.ehrenberg@att.net; jason_doege@inovys.com; mosley@san-jose.tt.slb.com;
jim_oreilly@agilent.com; jim.showman@inovys.com;
jose.santiago@philips.com; larry.moran@teradyne.com;
stuart.h.nelson@teradyne.com; Tom.Micek@motorola.com; tonyt@synopsys.com
Subject: STIL Testflow

Glossary item:

    Finite state machine:

        An event-driven automaton that appears as though it can occupy
        one of a finite number of states.  In a deterministic finite
        state machine, the combination of current state and input event
        determine the output and new state.

Finite state machine example:

    Attached you should find a state transition diagram which is a
    pictorial representation of the C++ and quasi-stil example below.

    Here's a C++ example where the nodes (states) are labels, the
    transition arrows are goto statements, and the tests are objects
    functional and next_power_range presumed to have a member
    function exec:

        node_start:
            if (initialize())
                goto node_functional;       // Pass
            else
                goto node_end;              // Fail

        node_functional:
            if (functional.exec())
                goto node_end;              // Pass
            else
                goto node_next_power_range; // Fail

        node_next_power_range:
            if (next_power_range.exec())    // Pass
                goto node_functional;
            else
                goto node_end;              // Fail

        node_end:
            cleanup();                      // Choose exit port, etc.


    Don Organ's proposal exhibits finite state machine behavior. It
    seems agreeable for the most part but i'd like to add PRE Action and

    some maintainability constructs, e.g., Goto NEXT, and bring up the
    sticky subject of logic and variables. Borrowing from Tony Taylor's
    draft and Don Organ's presentations and filling in the fewest of
    details, syntax might look like this:

        TestFn fn1 {
            timing        = a;    // Assuming a was previously defined
            dc_levels     = b;    // Assuming b was previously defined
            selector      = c;    // Assuming c was previously defined
            pattern_burst = d;    // Assuming d was previously defined
        }

        // Set variable or selector to to next power range if it exists,

        // otherwise FAIL.
        TestCalc next_power_range {
            Action PRE ExecIf(... next power range exists ...; FAIL)
            logic = ... set variable to next range ...
        }

        TestBlock functional {
            same internal structure as "TestFlow main", would refer to
fn1 ...
        }

        TestFlow main {
            Action PRE Assign(CkPowerRange = True)

            Node functional {
                Action PRE ExecIf(CkPowerRange == True)
                TestBlock functional;
                Action PASS Goto END;
                Action FAIL Goto NEXT;
            }

            Node next_power_range {
                Test next_power_range;
                Action PASS Goto functional;
                Action FAIL Goto END;
            }

            Action PASS Bin x;
            Action FAIL Bin y;
        }

    NOTE: Actions PRE, PASS, FAIL, etc. require the ability to evaluate
    logic for the purpose of conditionally setting variables and/or
    soft bins.

    NOTE: every Test, TestBlock, and TestFlow intrinsically has Actions
    PRE, PASS, and FAIL. They may be no-ops.

Observations/comments regarding OddEven.stil example:

    * i prefer the hierarchical approach, i.e. A over B:

        A: transfer of control from one node (Segment) to another is
        limited to the TestFlow or TestBlock (ProgSeq or BLOCK, flow or
        sub-flow).

        B: transfer of control from one node to another is unlimited.

    * consider Bin as one of a number of node (Segment) Actions as
    opposed to an object that occupies the same space as a Segment
    (StylusSubmission.jpg shows them as derived from the same base-class

    for the purpose of occupying the same slot as a Segment, if i
    understood Don's explanation correctly).  The reason is GUI clutter
    and maintainability, i.e., fewer and more homogeneous GUI objects, a

    test or node and its associated binning can be added or removed in
    a single action.

    * consider define before use: this is not the best choice of words
    but refers to, e.g., the reference to TestContinuity before it is
    known whether any parameters exist for it.

    * a test and its parameters ought to be married so that they can be
    referred to by different nodes in the flow, i.e., is TestParams
    "LeakHigh" really only a listing of that test's parameters or a
    definition of that test ?

An aside to Dave Dowding: now that i'm making up my new mailing list,
i'm noticing my old one and finding a number of people not on the new
list.  Presumably you're aware but i thought i'd list them, just in
case one might have slipped through the cracks:

    f-hernandez@ti.com
    m.purtell@ADVANTEST.COM
    tommu@risc.sps.mot.com
    James_Dexter@notes.teradyne.com
    Chris_J_Nelson@mail.intel.com
    felty@icd.teradyne.com
    danialy@san-jose.ate.slb.com
    nathan.biggs@Microchip.COM

--

-----------------------------------------------------------------------
Ernie Wahl           Agere Systems              Tel:   610.712.6720
Computer-Aided Test  22Y-210EO, 555 Union Blvd  Fax:   610.712.4235
Department 10036677  Allentown, PA, 18109-3286  Email: ejwahl@agere.com
-----------------------------------------------------------------------