1. WFCConstant proposal (changes-5.8.03.pdf)

2. Fail data (Jason status update)

3. Lockstep (see link above for proposal by Paul Reuter)

Note to 1450.1: This is a proposal that has come from the 1450.6 (CTL)

working group.

1. WFCConstant proposal

Reviewed the proposed changes created by Tony, to replace enums by

IntegerConstants.

The one previous behavior that does not have a close parallel is the

"values" attribute. For enumerated variables the values provide the

definition of the permissable values of this variable. The "values"

functionality can be provided, but validation of these values needs to

be performed at run-time, and this group sees little benefit and large

overhead to supporting this construct. The Working Group agreed to

removing the "values" construct in this environment.

Tony identified an ambiguity in the language, differentiating

constants (or in general, any variable, signal, or group name) from

complicated WFC-lists. Tony presented the additional

backslash-operator \V, which shall be present before any

'variable-namespace-reference' is made, to eliminate this

ambiguity. The Working Group accepted this construct. There was some

discussion that the \W operator may provide the same functionality, to

be reviewed.

There was a short discussion about the context of WFC interpretation

with SignalVariables. Because SignalVariables support Base attributes

and are applied interchangeably with Signals and Groups, the

mechanisms of WFC-assignment and WFC-interpretation as defined in

dot-zero apply to SignalVariables. The dot-one spec needs to make this

clear.

There was some quick review of previous meeting decisions on variable

issues, to identify if there was missing additional constructs or

functionality to define. The one issue identified was the question

about where variables become initialized (or set to their initial

values). In a prior meeting, the need for supporting a mechanism to

maintain a variable's value across multiple PatternBursts was

identified, and a "holdstate" construct was contemplated. After some

additional review, the existing mechanism of scope-based

initialization was considered sufficient without attempting an

exception-style attribute to control this behavior; if a variable

needs to be maintained across multiple PatternBursts, then those

Bursts can (and should) be organized hierarchically, with the top

level of the Burst hierarchy containing the Variables-block reference,

controlling instantiation (and initialization) of these variables for

this entire hierarchical scope.

2. Fail data

Jason was not present, however Bruce identified an interest in this

issue as well and will contact Jason with the hope that some progress

can be made on this issue.

3. LockStep

No progress by Tony or Greg on this; continuing AI.