STIL.4 members;

(Gordon, I appologize for refering to you in the 3rd person below.)

I found Gordon's found thoughts very interesting and enlightening. I agree with most of them. Here are some of my own general thoughts on flow issues.

Execution Mechanisms
Although there are probably endless variations, I can think of only a few fundementally different approaches we could use to specify test sequencing:

Procedural - Pick an existing language - such as C/C++ or Pascal or Tcl or JavaScript or ...
A directed graph - this subsumes Flowcharts and (I think) Ernie's FSM; a directed graph (perhaps with cycles) can represent a flow chart or a FSM. A vertex represents some operation - such as testing or termination. Each vertex may have some number of outgoing edges (selection of which is based on different conditions such as pass/fail) leading to the next vertex.
Rule based (AI people called this chaining). For example:
    Bin1: Contact, Idd, Functional666MHzHiVdd, Functional666MHzLoVdd
    Bin2: Contact, Idd, Functional500MHzHiVdd, Functional500MHzLoVdd
    Bin10: !Contact
    Bin11: !Idd
    Bin12: default.

I realize that there is no clear line between #1 and #2 since a C compiler makes a parse tree of executable statements - the parse tree is essentially a directed graph as in #2. But I think there is a big difference in how we would approach this (reference an existing language versus specifying our own limited syntax).

Gordon listed alternatives such as Sequence, Tree, Graph, State Machine or a Turing Machine.

As I recall (and it has been many years) a Turing Machine is basically a state machine defined in a simple abstract manner suitable for formal analysis of algorithms. Thus, I didn't consider a Turing Machine separately from my #2 above. As I said I believe a Graph can represent a State Machine, and a Graph is a more general form of a Tree - it allows reconvergence. And a Sequence is a simple graph - where each node has no more than 1 outgoing vertex. So, I believe Gordon's alternatives can be reduced to adding restrictions to a graph - such as a) branching, b) reconvergence and c) cycles (loops).

Syntactically, there are lots of ways of representing a graph. What's in the STIL.4 document (3/8/99) and my Inovys example from last meeting are two examples.

I think it is interesting to note that its possible to use one approach (such as #2) to control the flow of execution, and another approach (such as #3) to determine the binning result.

Pass & Fail tests

I believe a test operation can return any type of output - not limited to a single pass/fail. So I disagree with Gordon on this: "Personally I'm a strong believer in tests producing pass/fail decisions. That seems to be the main concept in so many test execution systems that I see it as fundamental." (Gordon, I hope I'm not misinterpretting you here; elsewhere you say "Multiple shades of pass/fail give different next tests as the destination." which implies a perspective much closer to my own.) Being on the implementation side of things, I've been requested to support N-output ports on flow nodes. Some people want to have a test that identifies different speed bins (i.e. one test with 2 passing output ports and at least 1 fail port). And I've seen requests to support multiple fail types as well. One example (probably obsolete considering modern tester capabilities) is a ganged leakage test. It could have 3 output ports: Pass (measurement < limit), Fail (measurement > #pins * limit) and Indeterminate (somewhere in between - typically this would lead to a pin-by-pin leakage test). Also, I've seen "tests" used to branch the flow for temperatures (Hot, Room, Cold), or based on Probe versus Package (versus QA).

Finally, it is common for a test program to make some measurements. Although some measurements are immediately compared to a limit, and thus produce pass/fail result, not all do.

I don't know of any implementation concerns that encourage us to mandate that each test operation returns a pass/fail result.

So, my conclusion is that such a restriction is unnecessary and sometimes unnatural.

Test Numbers

One question I think we'll need to answer at some point is whether each "test" (whatever that is) must be associated with a unique identifier (such as a test number) - such as for use in datalogging. Doing so can become somewhat complicated in cases of "sub-flows" and in cases of looping.

-DVO-