minutes-2002-06-21

Phone Conference P1450.3 Working Group

Thursday, Mar 16, 2005 - 10:00-11:30 Pacific Time

Tony Taylor (chair)
Greg Maston (scribe)
Daniel Fan
Jose Santiago
Gary Murray

Docs:

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

Agenda:

1) Can a TRC be defined as all "global blocks", with no references?
TRC {
   SignalAttributes { }
   PatternAttributes { }
   PeriodAttributes { }
   WaveformAttributes { }

}

WG: Yes. Assume that there was a Module { }. This empty module block would include all the other global blocks and hence be a complete TRC specification.

2) Does the following do anything? i.e., Do named blocks have to be referenced in order to be applied?
TRC {
   SignalAttributes SA1 { }
   PatternAttributes PA1 { }
   PeriodAttributes PE1 { }
   WaveformAttributes WA1 { }
}

WGL No. These blocks only have effect when referenced.

3) Does the following allow for 100 or 200 signals? i.e., Does global Signal stil apply?
TRC {
   SignalAttributes { MaxSignals 100; }
   SignalAttributes SA1 { MaxSignals 100; }
   PatternAttributes { }
   PeriodAttributes { }
   WaveformAttributes { }
   Module {
      MaxNumberModules 1;
      SignalAttributes SA1;
   }
}

WG: 100. The sig-attrs in the Module block overrides the global one. In this case the global sig-attrs has no effect.

4) Does following allow for 100 or 200 signals? i.e., Are the two modules referencing the same 100 signals? Or, is this allowing for the same 100 signals to be used in different contexts?
TRC {
   SignalAttributes SA1 { MaxSignals 100; }
   PatternAttributes { }
   PeriodAttributes { }
   WaveformAttributes { }
   Module {
      MaxNumberModules 1;
      SignalAttributes SA1;
   }
   Module {
      MaxNumberModules 1;
      SignalAttributes SA1;

}

WG: 200. Each module is an independent specification of attributes. So, the system has two modules of 100 signals each and the signals all have the same attributes.

5) Which pat-attr applies? a) the one in Module?, b) the one in sig-attrs?, c) both?
TRC {
   PatternAttributes PA1 { }
   PatternAttributes PA2 { }
   SignalAttributes SA1 {
      MaxSignals 100;
      PatternAttributes PA2;
   }
   Module {
      MaxNumberModules 1;
      SignalAttributes SA1;
      PatternAttributes PA1;
   }
}

WG: Both. Since they are both named references, they must both be used. The rules from the two referenced pat-attrs must not conflict since both sets must be met. The attrs of both are merged into one set of attrs.

6) Which patt-attrs apply? a) PA1 and PA2 , b) PA1, PA2, and global? Note: multiple pat-attrs are allowed.

TRC {
PatternAttributes { }
PatternAttributes PA1 { }

   PatternAttributes PA2 { }
   Module {
      MaxNumberModules 1;
      PatternAttributes PA1;

PatternAttributes PA2;
}
}

WG: Either. Since both are specified at the same level, either set of pat-attrs may be selected. All rules for the one selected must be met.

7) Should we allow both wave-attrs and wave-descrs? Or, should we restrict it to one or the other?

TRC {
WaveformAttributes WA1 { }

WaveformDescriptions WD1 { }
Module {

WaveformAttributes WA2;

WaveformDescriptions WD1;
}
}

WG: No. The EBNF should be changed to disallow both being specified.

8) NameMaps - I think that all reference to NameMaps can be removed from dot3? It is fully defined in dot1. The statement belongs at the Environment level, not the TRC. We need to review the definition in dot3 vs. dot1 as they are quite different ... I think because the dot1 syntax evolved and the dot3 did not.

WG: No. The env->NameMaps has a different function from the trc-NameChecks. Both are legitimate. Should be able to do a name-map and follow with a name check.

9) Lot's of changes in the PatternAttributes. See red-x in the doc.

WG: Changes reviewed and agreed to.

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

- Removal of the systemattributes block and moved all statements into the TRC block. Accepted by all present.

- discussion about namechecks vs. namemaps vs. names. This needs more review, and possibly desciption of the process under which names are resolved (via namemaps) and then the mapped names are checked. Greg indicated that, he believes, that the NameMaps in dot1 serves a different purpose that NameChecks in dot3. A question was raised as to whether it is possible to map the names (per dot1) and then check the newly modified names (per dot3).

- signalattributes:
Confusion between attributes found in two different locations. Recommendation from Tony to remove some attributes from this block. The discussion centered around a set of interpretations that define how the different forms of syntax should be done - global vs. referenced in Module vs. referenced in sig-attrs. Tony is going to figure out a way to organize the definitions (in a table, perhaps) so that the various syntax options are clear and well defined. See more info in the points below.

- PatternAttr - remove a set of yes/no statements in favor of InstructionAttr statements. Presence of the InstrAttr statement for a particular construct defines the "yes" option as it indicates this name is supported; absence of the InstrAttr for a construct defines that this construct is not allowed. This will generate some overhead to present these statements for all supported constructs; Tony will add a semicolon-terminated statement as an option here, Which allows minimal overhead for statements that are fully supported without additional constraints or restrictions.

- global and named blocks resolution. Rules are not straightforward, as they differ for global-unnamed blocks from multiple instances of named blocks. The proposed behavior is: any attribute defined in a global-unnamed block will be applied in any context that may contain a (named) reference to that block. These may be considered default, common, or "base" attributes. The context may also reference a named block, in which case all attributes of that named block will be applied, overriding (replacing) any attributes also defined from the global-unnamed block. If two named blocks of a type occur at the same context, then the attributes of EACH are maintained as distinct from one another, and checking/validating (as appropriate) will occur against the attributes of each. A rulescheck failure occurs only if ALL blocks fail. If blocks are referenced from different contexts where there is a hierarchy of references to this type of block, then the note-taker suspects we will have more discussions about whether information from one block propogates down (although the note-taker hopes not).

- waveformattr and waveformdescs - don't allow both references at the same level. This is a change from the current definition in D11, but the group felt that the original intent was to only allow waveforms to be defined one way or the other.

Meeting adjourned 11:00 Pacific time