Flow Control Issue (from 5/14/2002)	Resolution (from various meeting minutes).
1	Are we agreed on the general concept of a FSM/FlowChart/declarative approach?	Yes. We'll defer specifics for the future.
2	Are we agreed on supporting hierarchy? (SubFlows)	Yes. Ernie prefers to call them TestFlows. Jose - is the nesting limited? No - but from a partical point, implementations may have limits. Jim - subflows can be used for grouping, and also for parallel flows at the same level in the hierarchy. Jose/Jim/Ernie - subflows could be used for different cores.
3	What are the basic boxes in the Flow? Something for a TestMethod call, the SubFlow, some decision/branch/loop point, a bin. Are these extensible (such as to include the Plot in the 3/8/99 document)?	FlowNode=Vertex (in graph theory). Also, consider adding a non-branch action (such as closing the relay on a loadboard). We had some discussion as to what this point means (is the FlowNode a test? or a pointer to a test? we tried to defer this issue). Ernie thinks the binning might be an attribute of a test (or of a flow) - would like to ensure that removing a test that is associated with a bin to also remove that bin. Ernie thinks of the test and the test method as one thing (with pre-action, body, and post-action) - so he sees binning as an exit action. Ernie's emphasis is to encourage a maintainable program structure. We didn't close on this issue. We seem to have good agreement on all aspects other than the binning, and we might be close on the binning as well. We'll pick up here next time. --- Regarding #3 - binning will need further discussion. Other issues were agreed to (in general terms).
4	What are the return types from a Test Method (pass/fail, or pass/fail/error, or user-defined)?	We are all agreed that we need to have the TestMethod be able to return parametric results. We are all agreed that we need to be able to return pass/fail. We are not all agreed that the error return needs to be explicit. (we avoided dealing with what "user-defined" means).
5	In whatever box the TestMethod is called from, is it possible to call more than one TestMethod?	This raised some questions about at what level of abstraction we want to consider. For example we haven't defined what a "TestMethod" is. Can a TestMethod be hierarchical? Several people agree that it is. Also, generally, pe ople agree that the container for a TestMethod contain just a single TestMethod. Daniel suggests that we use the term "execution function" instead of the term TestMethod. ---- The specific question is: "In whatever box the TestMethod is called from, is it possible to call more than one TestMethod?" There is no compelling requirement here. Ernie feels it is inappropriate because this is unnecessary and somewhat contrary to his pre and post action concepts.
6	Is there a restriction on the number of output arcs from a FlowNode?	There should not be any restriction on the number of output arcs from a FlowNode.
7	How do Ernie's concepts of pre-action and post-action and arbiter fit in?	There is only one pre-action. There can be multiple post-actions - depending on whether the actions are associated with a FlowNode or with a Test - generally there is one pre-action per port. Arbiters are associated with a Test (only) and is responsible for determining if the test passed or failed. It is still an open issue as whether we will generalize this abstraction of having the arbiter be responsible for interpretting the test result and determining control flow.
8	What are the highest level entry points into the flow? (Load, StartOfTest, Unload)	(We didn't have a clear summary in the 9/6/2000 minutes). A couple of different approaches are possible. First, with a single entry-point, it is not hard to emulate multiple entry-points by having conditional branch points at/near the beginning. However, there are numerous entry-points that might make sense: StartOfTest (Connect), EndOfTest (Disconnect), Initialization(ProgramLoad), LotSummary, Reset and maybe user-defined actions such as for external instrumentation.
9	Assuming SubFlows, how many input ports are allowed? How are the return ports specified?	The input ports could be used for different entry points - such as for initialization, calibration, test, unload, etc. Ernie points out that with a single entry point, you can emulate multiple entry points via conditional statements (such as "if"). Dave, refer to page 7 of Tony's http://65.119.15.228/stil.4/1450_4.pdf for one example used in speed binning. Jim: We have testers that use the separate entry-point philosophy. An entry point is something you execute when you have an activity that you want to do that is separate from other activities (such as loading patterns, power-down, etc.) Conclusions for the first question - from an applications perspective, there are merits in having a multiple input port system. There may be some implementations perspective, there might be difficulty in realizing a multiple input port system in some existing test languages. There are some different ideas regarding what is meant by "input point" and "entry port" (9b: Ernie is suggesting using a boolean logic equation (arbiter) to determine the result of a subflow. Don's approach is to have an explicit return flownode in the subflow. (Lots of discussions regarding the abstractions of tests and flows.) Ernie feels that it is important to be able to create a "test" by connecting a bunch of other tests. We didn't really close on this specifics of the question (we spent much time on broader issues regarding different approaches of different languages) but we did say we'd like to be able to handle various approaches used by different tester languages.
10	Where is the Pattern Exec called from? (Calling it from low in the hierarchy - such as from within a TestMethod, allows more control and flexibility. However, calling it from high in the hierarchy would allow an entire sub-flow be grouped under a single Pattern Exec - which could be desireable when creating speed-binning flow - where 2 subflows differ only in the Category/Selector. Or do we consider breaking it apart?)	We will consider breaking open STIL's PatternExec - and maybe using its components (such as Categories) separately at different levels of the Flow Model.

Various proposed definitions so far

Testmethod	parameters and a defined or implied sequence of events yielding a pass/fail judgment and potentially parametric data.	Ernie 4/3/2002
Test	an object with a pre and two post actions (pass and fail) and a body (the test method instantiation).	Ernie 4/3/2002
Testblock	A Test whose associated test method consists of executing the flow of Tests/Testblocks inside the block.	Ernie 4/3/2002
Testflow	The top-level Testblock. The only Testblock not pointed to by a Testflow-node.	Ernie 4/3/2002
Testflow-node	an object with a pre and multiple post actions and associated ports (port of entry, pass, fail, etc ports) and a pointer to a Test or Testblock.	Ernie 4/3/2002
BinMap	minimally stores software to hardware bin mappings, i.e., might additionally store alphanumeric alias to bin number mappings.	Ernie 4/3/2002
Variables		Ernie 4/3/2002
Mathematical Expressions		Ernie 4/3/2002
Logical Expressions	These form the basis for the following other definitions: Assign, Bin, Execute	Ernie 4/3/2002
Assign: conditional/unconditional, pre/post test execution	assign a value, potentially a mathematical expression, to a variable potentially based on the evaluation of a logical expression.	Ernie 4/3/2002
Bin: conditional/unconditional, pre/post test execution	set a soft bin potentially based on the evaluation of a logical expression.	Ernie 4/3/2002
Execute conditional, pre test execution	execute the test if the associated logical expression evaluates as true (unconditional test execution is the default).	Ernie 4/3/2002
Test Method	a specification of zero or more parameters paired with a defined or implied sequence of events yielding a pass/fail judgment and potentially parametric data. The specification must be sufficient to permit implementation on a target tester and should therefore describe the input (each parameter), the output (under what conditions to expect Pass, under what conditions to expect Fail, and what if any parametric data is produced) and potential side-effects. On the target tester, a TestMethod may be represented by, for example, an object containing the parameters, or a subroutine or macro where the parameters are passed in as arguments. Can we stretch the parameter/method description a bit further to say for example, that a true leakage test must test adjacent buffers that are in opposite logical states ?  In other words, do we only supply useful methods or do we also attempt to provide a standard that increases the probability of getting consistent test results ?  If we want to do the latter, we may want to draw a distinction between test types and test methods, i.e., to perform a test of a particular type, you would employ a particular method (capable of performing tests of other types).	Ernie 6/17/2002 (and follow-up on 8/22/2002)
Test Method	a definition of a software interface (API) that encapsulates a particular testing-related operation the operation is generally defined abstractly (e.g. "to measure Idd", rather than precisely defining the ATE-steps necessary to achieve the desired result) the operation is generally defined in device-oriented terms (rather than tester-oriented)  the API includes identification of input and output parameters. Each parameter is named and has a precise semantic purpose the API may include identification of side-effects (such as datalogging, or changes to the state of the DUT - such as programming a flash memory)  the API includes a definition of potential error situations. I think it may be helpful to distinguish between an abstract TestMethod description (such as may be in a future STIL specification) and a particular TestMethod implementation. An analogy for C programmers: the abstract TestMethod definition is like a function declaration you see in a header file or in the documentation, while the TestMethod implementation is like the function definition that you see in the .c file. I think it may also be helpful to consider that the abstract TestMethod may be extended in a particular TestMethod implementation. For example, an ATE vendor may wish to enhance an Idd TestMethod with some additional optional arguments that are utilized in debug or characterization.	8/21/2002
Test Method	At some level of the test system, every test in the flow obeys a common API, which is the API that the part that obeys the flow uses to invoke a particular test step. As new test methods get added to a system, the test step sequencing shouldn't have to change. The big difference between different test methods to me is the data that they need. This can be simple, or extremely complicated. For instance a "simple digital" method in a STIL world may need only get the name of a PatternExec. That's a simple schema, one text field. More complex methods will have much more complex data in the schema.	Gordon Robinson 8/22/2002