Phone Conference P1450.1 Working Doc Subgroup
Thurs June 19, 10:00 am PDT
Attendees:
Bruce Kaufmann
Greg Maston (chair and scribe)
Peter Wohl
Documents
http://grouper.ieee.org/groups/1450/dot1/minutes-2003-05-08.html (minutes of last meeting)
http://grouper.ieee.org/groups/1450/dot1/for-review-on-6.19.03.pdf (stuff for discussion)
http://grouper.ieee.org/groups/1450/private/p1450.1-D16.pdf (latest working draft)
Agenda
1. Pattern data - see above link to for-review-on-6.19.03.pdf
2. Lockstep - see above link to for-review-on-6.19.03.pdf
3. Fail data feedback - status report
4. Review open issues in review-resolution doc - see above link
Meeting discussion
Proposal for a Working Group Extension
Greg briefly presented his justification for an extension - to allow
the WG time to resolve the remaining issues without generating the
perception that this effort is being pushed through too fast. Also, to
allow ballot resolution without falling into a nebulous area of "PAR
expired, ballot is iterating". This was generally excepted but Peter's
objections, which were voiced later, are mentioned below.
Pattern Extensions (clause 18 changes in stuff for discussion)
Bruce raised two specific questions:
(1) concern about returning a 'blank' for the error condition. Greg
identified that the intent here was to cause some sort of
WFC-miscounting/misalignment as a final error condition in this
situation. The application was more than able to generate ADDITIONAL
errors, but that this situation is also a reliable error condition and
vector processing should not continue in this situation.
Bruce then requested an example be added, demonstrating the ability to
check for a ' ' value in the situation where perhaps this condition
was expected. Greg generated the following example to add to the
examples. NOTE: this example needs to be reviewed, because Greg
doesn't know how to compare against the undefined WFC either.
(2) Bruce questioned what the last-WFC should be if a '#' was assigned
to a Signal. Greg identified that the last substituted value of that
signal ought to be the value returned, not '#' because technically
'#' is not a WFC.
Bruce requested this be clarified and an example demonstrating this
behavior added as well. Greg defined the following example and text
for review, Tony to add for next review [AI1 and AI2].
example addition -
Procedures {
"var_ex" {
C { SIG1 = #; }
If '\W SIG1 == ' { V { SIG1=B; SIG2=C; } }
Else { V { SIG2=\W SIG1; }}
}
}
note in this example, that the value returned from '\W SIG1' in the If
expression will be the WFC assigned to this signal from the '#'
operation -- not the value '#'. The If test identifies that if there was no
assignment to SIG1 in the call, then set the value of SIG1 to B. If there was
an assignment then set SIG2 to the same value.
Pattern PAT {
....
Call "var_ex"; // no value passed to SIG1
Call "var_ex"{SIG1=A;} // both SIG1 and SIG2 are assigned WFC A.
....
LockStep
Greg briefly reviewed the concept identified in the review document,
to remove the semantic elaborations in sections 13.3 and 13.4, and
present the LockStep attribute definition only. These elaborations are
implementation details that are outside the scope of this document and
identify strategies for supporting LockStep but are not intended to be
constraints on the definition. Hence the proposal to remove these
elaborations. Tony to implement requested changes. [AI3].
How To Push Forward
Peter identified the desire to bring this effort to closure, and
voiced concern over the proposal to get an extension. The members
discussed:
- implementing the lockstep changes and closing this issue.
- push for fail feedback resolution and failing that, close this
issue.
- hold a face-to-face meeting to resolve any remaining issues, most
likely in CA since most members are available with notice to attend
a meeting there, [AI4] for Tony.
Meeting adjourned at 10:45 PST.
Post meeting discussions
After the WG meeting, Greg and Tony had further discussion on the issues.
These points are presented here and will be brought up at the next meeting.
returning a 'blank' for error - We decided and will propose at the
next wg meeting that the (currently unused) character '~' be returned for an
error condition. This makes the reporting and testing for an error state explicit.
fail feedback issue - This has been an AI (for Jason) for over 1 year
now. It is still felt by many of the wg to be an important need of STIL.
At this time, however, now that the STIL extensions have become
better defined, it seems like this feature would better fit into the STIL.3
standard - tester targeting. This needs further discussion and would
require an adjustment to the scope. STIL.1 scope currently contains the
following sentence -
"Define structures in STIL to relate fail information from device testing
environments back to original stimulus and design data elements."
Next meeting
Next phone meeting July 3.
AIs
[AI-1] Bruce - contact Jason on fail feedback.
[AI-2] Greg - generate examples requested above.
[AI-3] Tony - add examples to document.
[AI-4] Tony - implement LockStep description reduction.
[AI-5] Tony - consider scheduling face-to-face to close these issues.