From: owner-stds-1450-4@majordomo.ieee.org on behalf of Don Organ
[don.organ@inovys.com]
Sent: Wednesday, August 21, 2002 6:32
PM
To: STIL. 4
Subject: stds-1450.4: TestMethod
definition
Gentlemen;
During our last
teleconference, we agreed that we will continue with the May 14th "Flow Control
Issues" on our next call - continuing with issue #5: In
whatever box the TestMethod is called from, is it possible to call more than one
TestMethod?. The previous time we discussed that issue (June 14th), we
said that we should try to define what a TestMethod is via email. Ernie provided
his definition on 6/17.
Here's my thoughts.
A
TestMethod is:
- 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.
I hope I'm doing
doing Ernie a disservice by attempting to identify a couple of differences
between his definition and my thoughts:
- I don't think a
TestMethod necessarily results in a pass/fail judgment. For example,
I think I should be able to have a TestMethod that makes process
monitoring measurements that are intended only for datalogging and have no
bearing on the final binning of the Dut.
- I'm not sure I
agree with "a defined or implied sequence of events" in Ernie's definition.
Should a leakage TestMethod implementation be free to choose between FVMI and
FIMV? Should it be free to skip executing a pre-conditioning pattern if it
discovers that the output pins are already tri-stated? Should it be free to do
a ganged leakage testing and do pin-by-pin PMU test only if the ganged test
fails? Should it be very to use the functional pattern system (with load
currents) to perform the test? I'm not sure I disagree with that phrase
either, but it seems unnecessary. I do agree that most TestMethod descriptions
will identify a sequence of operations.
-DVO-
-----------------------------------------------------------------
Don
Organ
Inovys Corporation
(925) 924-9110
x122
-----------------------------------------------------------------
> From: owner-stds-1450-4@majordomo.ieee.org on behalf of Ernst_Wahl
> [wahl@cool.agere.com]
> Sent: Monday, June 17, 2002 4:23 AM
> To: STIL. 4
> Subject: stds-1450.4: TestMethod definition
>
>
> Referring to previous email
> http://65.119.15.228/stil.4/stds-1450.4TermsConceptsClassificationsDefinitionsfromErnieWahl.txt
> I decided to take a stab at an expanded definition suitable for STIL:
>
> TestMethod: 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.
>
> -----------------------------------------------------------------------
> Ernie Wahl Agere Systems Tel: 610.712.6720
> Computer-Aided Test 55B-148D, 6755 Snowdrift Rd Fax: 610.712.4235
> Allentown, PA, 18106 Email: ejwahl@agere.com
> -----------------------------------------------------------------------