From: Jim Mosley [mosley@san-jose.tt.slb.com]
Sent: Monday, February 25, 2002 6:56 PM
Subject: Requirements for STIL-Flow Extensions (P1450.4)

1. Ability to reuse Tests and Sub-Flows

 Background:

   The UML diagram on page 2 of the P1450.4 document suggest that a Test can
   be executed from only one Node, and that a Sub-Flow can be executed from
   only one Node. This is much to restrictive for our purposes.

 Proposed Requirements:

 a) The user should have the ability to execute the same test from different
    points in the test program. It is undesirable to implement this behavior
    using duplicate tests, since modifications to one of the duplicates will
    not cause the other duplicates to be updated with the same modification.
    Thus, we need the ability for the exact same test to be referenced from
    multiple Nodes in the flow.

 b) The user should have the ability to execute the same Sub-Flow form
    different points in the test program. The important concept here is that
    one Sub-Flow is referenced from several nodes in the the higher level
    flows. Thus, modifying the flow of the sub-flow affects all flows that
    call the sub-flow.


2) More Flexibility in Binning Parts.

 Background:

  In the UML diagram on page 2 and the Flow Example on page 7 of the P1450.4
  document, the Bin object is being used to represent the end of the flow, and
  the binning of the part to a particular hard bin. Thus, there is a one-to-one 
  correlation between where the test program ends its flow and where the part is
  binned. This scheme is too restrictive for the following reasons:

  1) Binning is totally dependent on where you end your flow, rather than on what
     occurred during the flow.

     Example (using an algorithm):

     Flow MAIN_FLOW {
        Node TestA {
          Goto {TestB, resA = 1},   // exit port 1
          Goto {TestB, resA = 2},   // exit port 2
          Goto (TestB, resA = 3}    // exit port 3
        }
        Node TestB {
          Goto {End1, resB = 1},   // exit port 1
          Goto {End1, resB = 2},   // exit port 2
          Goto {End1, resB = 3}    // exit port 3
        }
        Node End1 {
          BIN = userBinAlgorithm()
        }
      }

      In the user binning algorithm, it assigns the bin as flows

               BIN=1, if flow is TestA.port1 -> TestB.port1 -> End
               BIN=2, if flow is TestA.port1 -> TestB.port2 -> End
               BIN=3, if flow is TestA.port2 -> TestB.port1 -> End
               BIN=4, if flow is TestA.port2 -> TestB.port2 -> End   
               BIN=5, if flow went thru TestA.port3
               BIN=6, otherwise.
                         
      
  2) It does not work well when you consider soft bins. A hard bin maps directly
     to a physical bin on the handler/prober, while a soft bin is a logical
     concept to sub-dived the hard bins into smaller categories for analysis.
     Thus, if I define 100 soft bins, I would have to have 100 Bin nodes
     terminating the test.
  
  You can see in Flow Example #2 an attempt to work around the restrictions by
  putting in a SWITCH Node. Thus, based on a calculation or algorithm in the
  switch node, the  flow proceeds to the correct End node to be process. This
  would not be necessary if the End of Flow Nodes allowed you to have a
  calculation or user algorithm to determine the Soft and Hard Bins. In the
  degenerative form, the calculation to could be as simple as the hard-coded
  setting of the soft bin and hard bin.
 

 Proposed Requirement:

  The user should have the flexibility to bin the part to multiple soft and hard bins
  from an end-of-flow node. These calculations or algorithms should be able to make
  use of variables previously set in the program flow (From user code for a user
  algorithm or from program variables (e.g., 'HVRes=1') for a calculation.