Conference call meetings for 11/19/2002

Dave Dowding

Jim O'Reilly

Tom Micek

Jose Santiago

Don Organ

Jim Mosley

Ernie Wahl

Agenda for Our P1450.4 Weekly Conference Call (19November 9:30AM Pacific)
-------------------------------------------------------------------------
1. Minutes from last meeting (review/approve)
2. Review the directed graphs of Test Flows (refer to Jim O'Reilly's earlier email.)
3. Revisit the Use Cases list / submissions
a. Further ideas/suggestions for use case form, additions, and submissions
b. Use Case #1: Simple production program (see attached)

1) Regarding last week's meeting minutes... No issues

2) Reviewing the directed graphs (http://65.119.15.228/stil.4/flow_diagrams_100702.pdf). Jim O'Reilly: Start with page 2 where the emphasis is on the interrelation between FlowNodes. Each FlowNode points to a Test (which may be a Test or a TestBlock - a TestBlock is inherited from a Test). Note that FlowNode's A and D both point to the same Test. Dave - the STIL.4 can not take into account the ramifications of the implementation - so we can't say what someone using a (GUI) tool would see if someone were editing the tests associated with FlowNode A and FlowNode D simultaneously). Jim: This example shows all flow executions eventually leading to the same Exit block. Now - to page 1, bottom diagram. The Pre-Action (a logic expression) allows the body of the FlowNode to be skipped - assumed to be controlled by some logic determined by the programmer. Haven't completely defined the logic of how to support multiple exit ports based on a logic expression. Exit ports could be identified either by name (as Ernie prefers) or at least by an number/index.

Regarding the top diagram - a Test itself returns only a pass or a fail, so the arbiter is simpler. Ernie - the Test is an entity that may contain certain status/state information about the test operation that can be later accessed from later in the flow. Jim: so, the Test looks similar to, but somewhat simpler than a FlowNode (since the arbiter is simpler). Tom: where do you identify what to do if you want to ignore a fail? Jim: the test itself might record the status. Ernie - there are a couple of choices in how to support this - just because a test fails and data is assigned in someway, doesn't mean that the execution needs to act on that. Could have an "Override On" mode that would cause a binning action to not stop execution, i.e., just continue with the appropriate actions, be they Pass, Fail or something else. If a "test" produced no discernible result, then it didn't fail and the flow would carry on with pass actions. Jim Mosley: May want the bypass logic to lead to the Arbiter instead of to the port so people can control the port logic. Jim O'Reilly - I agree with this. Ernie - well, I think it is correct as it is. There are times when the test should be skipped completely - so the bypass as written is correct. However, there are times when I'm on an offline emulator when I want to control the test flow. Ernie - we haven't talked about Actions yet: Pre-action is bypass (conditionally). Post-action is binning (conditionally), also either could perform assignment of variables (conditionally). What about custom user-actions (such as setting a relay on a loadboard). One approach is that that must be handled from within a TestMethod, another is that that could be put anywhere an Action can be.

Dave: the directed graphs are representation of what the user wants.Once we get these to the point where most people are comfortable with this model - we should go off and start implementing the specification.

Tom: what if a test did a binary search and wanted to return something other than a binary response. Ernie: the search measurement would be some data associated with your test - and that data is available to be referenced elsewhere. The test itself either passes or fails. The arbiter can decide whether to accept the pass/fail of the test, or invert it, or even examine some other data and make the decision based on that data.

Dave - I think we can conclude that although some tweaks may be necessary, we have some synergy. I'd propose that we start addressing the underlying issues via email.

Next time, review any follow-on discussions and move into the first use case.