Phone Conference P1450.3 Working Group
Thursday, Nov 9, 2005 - 10:00-11:30 Pacific Time
http://grouper.ieee.org/groups/1450/private/1450.3-D15.pdf (Nov 11, 2006)
http://grouper.ieee.org/groups/1450/dot3/comments.xls (Nov 11, 2006)
Nothing under discussion or presentation for this meeting was identified as being proprietary or restricted.
item 62: discussed and agreed to
item 64: discussed and agreed to
item 65: discussed and agreed to
item 112: discussed and agreed to the wording of the response. Decided to add additional, optional fields to the Variables -> ConfigConstant statement with ALT_CONFIG_NAME(s) defined as follows: "This statement allows for zero or more ALT_CONFIG_NAME identifiers to be specified. These names shall be defined in the same Variables block. The ALT_CONFIG_NAME specifies another resource that is available and capable of satisfying the same requirements and is to be used when the CONFIG_NAME resource is exhausted."
item 140: discussed and agreed to
item oku-3: same as issue 65. Change comment to so indicate.
item oku-4: same as issue 64. Change comment to so indicate.
item oku-8: multi-clocking using SubWaveforms - WG agrees with the
solution of adding a boolean time expression. A further change was
proposed and accepted to define separate statements for
SubWaveformIterations and SubWaveformTiming.
item oku-9: same as issue 49-GR, 77-JC, 118-GM, 119-GM, 137-GM,
138-GM. Change comment to so indicate.
item oku-10: discussed and agreed to
item oku-12: discussed and agreed to
VMeas, IMeas, TMeas question? Several options were discussed -
1) A MeasureAttributes block that would define new resources like VMeas, Imeas. There was much concern that the resources that we define at this time may not satisfy the needs of dot4/dot5 when the details are worked through.
2) A UserResourceAttributes block that defines a structure, but not the actual resource names. The idea was concerning, too. How do we know what the form of the resource will take? Will it be a per-pin resource? The structure itself may not suffice when dot4/dot5 is defined.
3) Expect dot4/dot5 to specify enhancements to TRC as part of those extensions. This is acceptable in an IEEE standard. The precedent already exists in that dot1 extends dot0, and dot6 extends dot0/dot1. The working group decided on this option.
Clause 5 - This information in this clause has been moved to the annex (per request from IEEE editors). Removing the clause will cause re-numbering of all subsequent clauses. We decided that even though it may cause some confusion, the clause numbering should be done in order to present the document in its final form.
The working group is anxious to get D15 submitted to re-ballot quickly. We are rapidly approaching the holiday season when it is typically difficult to get people to spend time on such activities. Also, we would like to get through the ballot process without requiring additional time extensions.
Here's our plan:
- make the agreed changes to D15
- send pdf to wg and Gregg Wilder for immediate review
- send email to the ballot group indicating that re-ballot is about to start
- submit D15 to IEEE on Monday 11/13 with a 2 week review period
Meeting adjourned 11:12 Pacific time
Phone meeting - Dec 7, 10:00 to 11:30 pacific time
Note: meeting on Nov 23 cancelled (due to Thanksgiving Holiday, plus we expect to be in ballot review)
- Tony - complete D15 and submit to IEEE for re-ballot