Phone Conference P1450

Meeting discussion

First, the Working Group wants to thank Tony for the EXCELLENT email

meeting reminder/meeting call notice. All information and numbers and

references to working docs were in one location. Thank you, Tony!

Second, the members of the Working Group are aware of no patents or

proprietary infringments on constructs being defined in the working

document at this time.

clause 6.7

The Working Group accepts this section as currently written.

clause 10.1

The Working Group accepts to eliminate the Length attribute as

proposed here. This was after much subsequent discussion presented

later.

The changes to lines 51-57 to reflect elimination of the Length

attribute were also accepted.

clause 10.3

The Working Group accepts this section as currently written, with the

following additions:

1. There was subsequent discussion about 'persistence' and 'accessing

variables out-of-explicit scope', and Greg provides the following

additional paragraphs to be placed under the first paragraph of this

section, for review at the next meeting:

Variables declared in an unnamed Variables block are global in scope

and may be accessed from any Pattern context unless that variable is

hidden by a declaration of the same name from a named Variables

block referenced from a PatternBurst context. Global variables are

assigned an InitialValue (if defined) at the start of a PatternExec

and maintain the last-assigned value throughout the execution of the

PatternExec.

Variables declared in named Variable blocks are local to the

PatternBurst context where that named Variable block is

referenced. Local variables are assigned their InitialValue (if

defined) when the first Pattern that contains that Variables block

reference starts to execute, and the value of that variable only

persists while the PatternBurst context that contains that Variables

reference is executing. Each reference of a Variables block in a

PatternBurst context defines separate and unique instances of local

variables for that context.

2. Questions were raised about the access of variables for procedure

blocks. In particular, lines 70 and 71 start a procedure definition

but are incomplete. Procedure examples need to be fleshed out as well.

This raised a discussion about facilitating reuse. It is desireable to

reuse as much definition as possible, in particular to reuse the same

Procedure definitions across multiple Patterns. There was some

discussion about how to FACILITATE this desired behavior. Jason

identified that the quantity of constructs causing separate

instantiation of procedures is difficult to process, and Bruce

identified that variables issues adds to this complexity.

Jason identified that the ability to identify Variables blocks under

the Procedures block (rather than inferred from the context of the

PatternBurst) would probably facilitate addressing reuse. Greg

identified that this would be contrary to the current resolution

techniques for SignalGroups.

A separate meeting or discussion opportunity was postulated to

consider how to address this, for instance, the definition of usage

models which would facilitate reuse and simplify identification when

reuse was not appropriate.

Greg proposes the following additions to fill-in around lines 70,71

and present variable access in procedure contexts as well. THIS IS A

STRAWMAN PROPOSAL FOR REVIEW.

70: Procedures {

// This procedure can only be used in PAT2 or PAT3 because it

// contains a reference to LOCAL_VAR that is defined only for

// those pattern contexts.

71: PROC1 {

If 'GLOBAL_VAR==1' {} // true

If 'SHARED_VAR==0' {} // only true before PAT2, PAT3 execute

If 'LOCAL_VAR==3' {} // only true in PAT2

}

clause 21 Pragma

The Working Group accepts this section as currently written.

There was discussion here about the potential separation of Pragma

"definitions" from Pragma "applications". Conceptually "definitions"

would be found in Pragmas at a top-level block location, and

"application" of those definitions would be found inside other

blocks. Greg identified that the current constructs do not prohibit

this interpretation, and that the interpretation of Pragma usage is

entirely in the context of the application anyways. Bruce is going to

think more about this.

clause 100 - 'length'

The general sentiment of the group is that the 'Length' attribute is

troublesome and should be eliminated. The consensus of the Working

Group is that a strong definition centered around the use of arrayed

constructs for SignalVariables would provide sufficient capability

without burdensome overhead.

Greg identified that the Length attribute was (in his consideration)

more of a 'depth' value rather than a 'width' value, allowing multiple

WFCs to be assigned to a single index. Jason identified that this

could be supported (if necessary) by a second bracketed construct and

2-D array, which could be a direct extension to the current constructs

if truly needed.

Greg identified that for the bracketed construct to be functional, the

ability to *implicitly* apply values to all indexes of a SignalVariable

needs to occur as shown on line 115. This is different than current

dot-zero behavior but isn't a problem to be supported for

SignalVariables.

The Working Group requests that clause 100 be regenerated with the

agreed changes to eliminate the examples here that use Length, and

present a cohesive example of assigning values to an arrayed

SignalVariable only.

Greg recommends that the following paragraph be added someplace in the

SignalVariables definitions as well:

SignalVariables may be declared as either a single entity, or

consist of a bracketed declaration. It is an error to access a

bracketed index that is outside the declared range of a bracketed

SignalVariable. A SignalVariable consumes one WFC for each index

when assigned a wfc-list. When declared as a bracketed

SignalVariable, a reference to that SignalVariable without brackets

is equivalent to a reference of that SignalVariable across the

declared bracketed range of that SignalVariable.

clause 101

There was not disagreement here, but the request was made to complete

the context of this example and identify exactly when there was a

conflict with variable and group names, and when there wasn't.

Greg recommends adding the following for discussion next time:

117: Signals { FOO In; }

SignalGroups { FEE = 'A+C'; } // unnamed SignalGroup block

118: SignalGroups G { FOO = 'A+B+C'; }

119: Variables V { SignalVariable FOO[1..3]; SignalVariable FEE; }

PatternBurst A {

SignalGroups G; // FOO is a SignalGroup; Signal FOO is hidden

// FEE is a SignalGroup

}

PatternBurst B {

Variables V; // FOO is a SignalVariable; Signal FOO is hidden

// FEE is a SignalVariable; SignalGroup FEE is hidden

}

PatternBurst C {

SignalGroups G;

Variables V; // ERROR: FOO is in conflict between these named blocks

}

Jason opened the discussion here about the ability to reference across

namespaces, for example to reference a variable in a named Variables

block using a construct like "V:FOO". This is when the discussion of

persistence of value started. Greg identified that local variables (in

named Variable blocks) do not exist except under a PatternBurst

context. It was identified that given this behavior, the only context

where it might be useful to access a 'hidden' variable is where that

variable is global and has been hidden locally (perhaps even by a

SignalGroup reference in that local context). It may be useful to

define a construct to support accessing the global reference, for

instance, GLOBALSIGNAL:FOO, or GLOBALSIGNALVARIABLE:FOO, when that

reference has been masked by a local declaration. However, it was

identified that this issue can be addressed by careful naming

considerations as well and may not need a constructural

solution. Yet.

clause 102

The Working Group accepted this behavior, with the additional

elaboration that comparisons of Signals, SignalGroups, and

SignalVariables are performed against WaveformCharacters only and are

purely textual comparisons. This means (a) that these comparisons are

not performed against 'state' values even if the reference has a

current state value that matches, and (b) these comparisons pass only

when the last-assigned WFC is the same text as the WFC being compared

- a comparison doesn't pass even if the waveforms defined by two

different WFCs are identical.

After presentation of the second example here (the Substitute

comparison), the Working Group requested that in ADDITION TO passing

the 'interpreted WFC' condition, this test should also pass if the

comparison is made to the current WFC assigned (in this case, the 'S'

wfc). The following additional line was requested:

139: If 'SIG==H' {} // test for the substitute value returned

140: If 'SIG==S' {} // test for the current WFC value too

Both of these tests are considered valid -- one tests against the

mapped value returned and the other tests against the current WFC

assigned.

Meeting adjourned at 11:35 PST.