Pattern Data

The updated clause 18 was briefly discussed and approved by the working

group.

Lockstep

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

that standard.

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

group.

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.