From: Gordon Robinson [Gordon_Robinson@3mts.com]
Sent:
Thursday, August 22, 2002 9:46 AM
To: 'don.organ@inovys.com'; STIL.
4
Subject: RE: stds-1450.4: TestMethod definition
I have
a very different view of what a test method is, although it
may
turn
out to be the same!
I
don't think of it as an API, but as mainly a schema.
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.
Now we
will never succeed in standardizing all test methods. And many test systems
will
have
system-specific extensions on any test methods that we do standardize. But we
can standardize
some
common elements of many well-known test methods, and we can standardize the
methods
of
specifying schema for additional test methods so that our languages can adapt to
the
schema
definitions. (That way we don't have to go through the standards ballot process
for
every
test method!!!)
To
answer one specific question: I see the flow as activating a single test method,
not several.
Gordon
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
> -----------------------------------------------------------------------