minutes-2002-06-21

Phone Conference P1450.3 Working Group

Thursday, Aug 4, 2005 - 10:00-10:30 Pacific Time

Docs:

http://grouper.ieee.org/groups/1450/private/1450.3-D10.pdf

http://grouper.ieee.org/groups/1450/dot3/1450.3-D10-review-resolution.pdf

Agenda:

IEEE meeting clearances

Nothing under discussion or presentation for this meeting was identified as being proprietary or restricted.

Started discussing the SignalCharacteristics, with the first question: should MaxVectorMemory be removed from this block and put only in PatternCharacteristics? If so, should other *memory statements be removed from here as well? Greg says yes, these statements are out of context with where the counting occurs (unless counting statements are added here as well).

Identified addition to syntax to reference multiple PatternCharacteristic blocks in one SignalCharacters block.

Added MaxVectorsCount statement to the PatternCharacteristics block, form slightly different than original doc. Greg was fine with syntax here.

Brief discussion about the issue of context contributing to these counts. Sometimes the amount of memory required for a construct depends on what came before. Greg identified that this is the "sub-behaviors" issue, identified in Annex B, "limitations to this approach". Sub-behaviors can become arbitrarily complex, depending not just on the prior statement, but the constructs present within some
statements as well (for instance, single-vector loops vs. multi-vector loops).

Tony proposed an additional statement to support counting when Vectors consume less than an integral count, some sort of statement to indicate when 2 or 3 or more Vectors add 1 to the count.

Tony proposed changing MaxVectors to MaxVectorMemory, to reduce the implication that this was simply a count of STIL Vectors.

Much discussion ensued over the issue of shared resource memory effects. How do we count when, for instance, 2 instruments are applied across a different set of (overlapping) signals, and both access a common sea of memory?

Daniel identified a desire to use the TRC to assist in resource allocation / configuration identification. When multiple configurations are possible, how does the TRC identify which is desirable?

Some discussion about the mechanism to identify signals into SignalCharacteristics blocks - the attributes Scan, Data, etc being defined in Table 2. Tony to move Table 2 into the syntax definition.

Concern that Table 2 is too restrictive and inappropriately defined (particularly for multi-bit contexts) to provide sufficient "bucketing" of signal types for checking signal-type-specific rules.