From: owner-stds-1450-4@majordomo.ieee.org on behalf of dave_dowding@agilent.com
Sent: Wednesday, November 05, 2003 9:36 AM
To: stds-1450-4@majordomo.ieee.org
Subject: RE: stds-1450.4: suggested pre/post/exit actions

1. FlowNode                   is a keyword in the P1450.4 Extension that describes a construct where a test activity shall be organized/instantiated. A FlowNode is a named (DomainName) entity with three segments or components, namely: Pre-"test activity" block, Body or "test activity", and a Post-"test activity". The Pre- segment is a block of information that can establish setup parameters for the "test activity" and shall establish the required TestMethod interface protocol where the activity enables a TestMethod. The FlowNode Body follows the Pre- block and contains the "test activity", which can be a call or pointer to a function, TestMethod or other container of sequenced events related to the ATE/DUT environment. TestMethods reference in the Body should be viewed as an instance of a TestMethod. The interface to the TestMethod is a set of parameters for communicating in and out of the TestMethod. The TestMethod will take in parameters to qualify its activity and will pass back predefined result(s) to the FlowNode Post-"test activities" blocks. The Post- segement is comprised of three sub-blocks of constructs that are ordinal in their association and nature. The first Post sub-block is the PostActions block described below. This is followed by the Arbitor sub-block of the Post- FlowNode segment. Execution flows from the Body segment to the PostActions block to the Arbitor block and information within the Arbitor determines which Exit Action block is accessed/executed.
2. EntryPath                    is simply a Graphical entity or "arc" that shows access to a FlowNode PreActions block. Associated with this EntryPath however may be FlowNode initialization data that is not yet defined. In the "language" construct view of the EntryPath as the FlowNode DomainName entity.
3. PreActions Block       is
4. Module Block             is
5. PostActions Block     is
6. Arbitor Block              is
7. ExitActions Block      is
8. ExitPath                        is simply a Graphical entity or "arc" that shows execution of test sequence flowing out of the current FlowNode to the destination determined in the ExitAction block information.
9. SkipPath                       is
   
   
   
   
   
   
   
   -----Original Message-----
   From: jim_oreilly@agilent.com [mailto:jim_oreilly@agilent.com]
   Sent: Tuesday, November 04, 2003 5:46 PM
   To: stds-1450-4@majordomo.ieee.org
   Subject: stds-1450.4: suggested pre/post/exit actions
   
   
   
   Hi, all,
   
   Following Ernie's lead (and his format), here's what I see for the pre/post/exit
   actions.
   
   Assumptions:
   1.  Integer and boolean symbols.  To this, I would also add reals (floats).
       I think these symbols will represent test program variables (globals?)
       and/or other STIL block variables - i.e., timing/levels/spec values).
       If the integer/boolean/(real?) symbols are test program variables, do
       we also want to include arrays?  What about structs?
   
   2.  Logical expressions/operators: ! && || == != > >= < <= ()
   
       To Ernie's list, I would also add additional logical bitwise operators
       & | ^ << >> ~ and arithmetic operators  + - * / % ++ --
   
       It might also be useful to include the assignment operators
         += -= *= /* %= &= |= <<= >>=
       Do we also want to include the ternary operators (expr1)?(expr2):(expr3) ?
   
   3.  Expressions can be combinations of logical and arithmetic operations.
   
   Actions: (actions can be a list of one or more actions)
   1.  Assignment (pre/post/exit)
   2.  Binning (pre/post/exit)
   3.  Conditional execution (pre).  If bypassing, need a way to specify which
       exit path will be taken.
   4.  Conditional assignment (pre/post/exit)
   5.  Conditional binning (pre/post/exit)
   6.  Conditional actions (pre/post/exit) - a way to conditionally execute an
       action in a list of actions.
   
   I haven't included inversions (conditional or unconditional) because I'm
   including the inversion operator ~ as one of my assumptions.
   
   I also haven't included in the actions a way to call other tests - in general,
   if you want to do that, subflows (which should be freely substitutable for a
   test in the module or body of a flow-node) can be used - or the test(s) you
   want to call can be placed in the flow-graph following the flow-node in which
   you wanted to place an action to call such a test.
   
   Hopefully, this will get us started tomorrow.
   
   Jim
   
   -----------------------------------------------------------------------
   Jim O'Reilly                            Tel:   408-553-2453
   Agilent Technologies, M/S 53L-NE        Fax:   503-603-1865
   5301 Stevens Creek Blvd
   Santa Clara, CA  95051                  Email: jim_oreilly@agilent.com
   -----------------------------------------------------------------------