6c: ballot list

Tony and Greg will assemble a list of current reviewers, WG members, and

interested parties (including the p1450 reflector members) to be ready

at the ITC meeting next week.

clause 6:

Tony identified that this was a re-write of the current clause 6 to

address several review concerns about clarity. The group was requested

to do a thorough review of this and we would discuss it at the ITC

meeting.

clause 10:

Tony has a concern that there is not currently a strategy to cause an

integer variable value to persist between blocks, as it is reset to

the InitialValue value each time the variable comes into

scope. Therefore there is a proposal to define a 'HoldValue' attribute

on the variable. This discussion was tabled to the ITC meeting.

clause 13:

Question: why is there an If construct in the patternburst, but no

Else? This is inconsistent with other occurrences of the If.

Greg responded that the If statement in the patternbust is not a

flow-control construct as much as an 'attribute' on the selected

pattern or burst reference. The syntax in this block is constructed to

perform selective execution of bursts, but at the individual burst

level and not in a generalized 'control flow' structure. This was

defined this way because selective execution of bursts was seen as a

requirement for this standard, but generalized control-flow is a

separate dot standard, and attempting to do robust control-flow here

will interfere with other efforts (and is in excess of the requirements

here). No change to the current syntax. Tony agreed to improve

the explanation of the If statement needs clarify this point.

clause 19:

Question about the presence of the (label:) constructs on all

statements here. Perhaps it is not necessary to put that label

statement here.

Greg identified that someplace in this standard needs to identify that

the label statement is present on all statements, and placing it here

makes that issue unambiguous. Tony will add the (label:) as an option

to the X statement as well [AI1] as Jason stated it was perhaps

not just uniform, but necessary.

clause 22:

The Working Group agreed that the fail offset count starts at

zero. Zero specifically indicates a failure AT the label, which is a

'label+0' position.

Other issues will be held to the Monday ITC meeting.

Greg agreed to generate some examples on x-ref statements before and

inside loops to identify the *expected* behavior when x-refs are

placed at these locations [AI2].

clause 3.2

Doug identified extra acronyms in this section to be removed now that

BistStructures was no longer part of this draft ([AI3] to Tony).

LockStep discussion with P1450.6 working group

Tony reported that he has had discussions with Rohit with regard to the

use of LockStep in CTL. The concept being adopted in CTL is to have

a common macro that is called by multiple patterns in "lockstep". The

macro then explicitly references the data from each of the calling

patterns and applies it appropriately, thus allowing complete reuse

of the pattern data with no modification.

At this time, no additional syntax is required in 1450.1 to support this.

The definitions in 1450.6 will  be something like the following (exact

details will come from the 1450.6 wg):

- a top level block like LockStepMacros {}to contain these special macros.

- variable domains used to identify each pattern's signal variables

- dereference the pattern variable in the lockstep macro by:

    V { signals = \Wdom1::varname \Wdom2::varname; }

new

old