Phone Conference P1450.1 Working Doc Subgroup
Thurs July 3, 10:00 am PDT
http://grouper.ieee.org/groups/1450/dot1/minutes-2003-06-19.html (minutes of last meeting)
http://grouper.ieee.org/groups/1450/dot1/for-review-on-7.3.03.pdf (stuff for discussion)
http://grouper.ieee.org/groups/1450/private/p1450.1-D16.pdf (latest working draft)
1. Pattern data - see above link
2. Changes to PatternBurst to remove details of LockStep - see above link
3. Fail data feedback - status report
4. Review open issues in review-resolution doc
The updated clause 18 was briefly discussed and approved by the working
It was proposed at the prior working group meeting to remove the
detailed semantic discussion (2 sub clauses) and instead include only
the high level requirements for patterns running in lockstep. The
re-wording of the explanation in clause 13.1 reflects this decision.
There was considerable discussion as to whether the standard could be
effective without completely defining the details. Paul, in particular,
felt that this was very important to interoperability of various vendor's
tools for embedded cores. The conclusion by all present was that the
wording, as modified, is sufficient. It is up to the pattern creator to
insure that the test patterns are suitable for running in lock-step.
Paul plans to discuss the issue further with the P1450.6 (CTL) working
group to see if the details of lockstep for cores should be defined in
Paul also raised the issue that the technique as currently being
developed in P1450.6 relies on capabilities that may not be possible in
1450.1 - i.e., the ability to write a single macro or procedure that can
reference the parameters from multiple patterns. Tony agreed to work
with Paul to identify and resolve any issues.
The re-worded and shortened explanation was accepted by the working
Fail data feedback
This issue was raised by Jason Doege more than 1 year ago. We still
don't have a concrete proposal for review. Tony agreed to attempt (one more
time) to contact Jason. Tony also stated that he thinks he understands
enough about what is requested to: a) believe that a more concise syntax
for fail reporting is needed, and b) prepare a proposal. It was also
discussed that even if new more abbreviated syntax is created, that the
existing X-statement probably should be maintained as a way of labeling
vectors in a pattern and for full reporting of failures.
Meeting adjourned at 11:00 PDT.
Next phone meeting July 17.
[AI-1] Greg - generate examples requested at 6/27 meeting
[AI-2] Tony - Work with Paul Reuter to see if any additional syntax or
interpretations are required to support the lock-step implementation as
currently being envisioned by the P1450.6 working group.
[AI-3] Tony - Contact Jason with regard to fail data feedback and somehow
bring a proposal to this working group for discussion