Phone Conference P1450.1 Working Doc Subgroup
Thurs, Mar 11, 2004, 10:00 am PST
Attendees:
Tony Taylor (chair)
Greg Maston (scribe)
Jim Teisher
John Cosley
Bruce Kaufman
Doug Sprague
Peter Wohl
Dan Fan
Documents
http://grouper.ieee.org/groups/1450/private/P1450.1-D18.pdf
(ballot draft)
http://grouper.ieee.org/groups/1450/private/P1450.1-D19.pdf
(latest draft - with changes)
http://grouper.ieee.org/groups/1450/private/P1450.1-D19-ballot-resolution.pdf
(issues & resolutions)
http://grouper.ieee.org/groups/1450/private/P1450.1-votes.pdf (ballot results)
Agenda
1. Decide which topics are
ready to discuss. Note: You may save some time in the meeting by emailing
your topics for discussion prior to the meeting.
2. My list of topics for discussion:
DB-1, DM-22C - Annex O - use of STIL.1 for specific applications (new
writeup attached)
DM-9,10,11,10 - Clause 13 - parallel patterns (new writeup attached)
DM-14 - making scan length optional
RK-6 - Annex F and AllowInterleave statement
DM-1,13, JC-9, TT-1 - scan-cell-groups (need Rohit to discuss this
one)
3. New AI's and plans for next week
Meeting discussion
IEEE meeting clearances
Nothing under discussion or presentation for this meeting was identified
as
being proprietary or restricted.
1: Annex O
----------
This annex identifies features of the .1 extensions that have
specific pertinence to context of applications, in response to issues
raised by DM and DB.
Doug recommended adding mergedscan references in here.
Recommendation to add another section O.3 for simulation contexts.
There was some discussion to consider folding the fail feedback annex
into here as well. This will be taken under consideration; fail
feedback is definitely a specific context with specific constructs to
be applied, but there's a lot of usage explanation in the current fail
feedback annex as well that may not fold into here directly.
2: clause 13
------------
New clause 13.3 explains tiling behaviors.
Fixed explanation on pg 35. Reviewers found the first sentence
confusing, 3rd sentence too, and asked for clarifications.
Explanation bullet 8 needs to have Fixed and Wait references removed.
Explanation bullet 10 2cd paragraph needs to refer to 13.3.
13.3 c) Add 'There are two forms of the breakpoint stmt' in here; the
two forms that follow are confusing without knowing that two forms
will be discussed.
Question about interaction between breakpoint and extend - how do they
interrelate? What happens when both are present?
Question was raised by Dan about the usage model - Are patterns
assembled (combined, through the use of parallelpatlists) with
breakpoints already present, or not? When patterns are being created,
does the need to define a breakpoint in the pattern get identified ---
or does the NEED for breakpoints not get identified until patterns are
being assembled, and how are breakpoints defined at this point (after
the pattern creation, when the stand-alone behavior of that pattern
may not be easily ascertained)?
It was determined in the group that Extend must override application
of Breakpoint cycles since the need to extend is not identified until
patternburst is defined with integrated set of patterns. So Extend
needs to takes precedence when present.
If two non-integral (periods are not small common multiples of each
other) patterns in a parallelpatlist both have breakpoints and extend
statements, what is the process that applies a full set of breakpoint
vectors vs. uses a steady-state signal extend, to terminate these
patterns?
This raised another question about fig 1 (related to an issue raised
by DM). Obviously the extend goes to end of pattern block, but does it go
beyond block boundaries? Do we need an initial concept for the start
of a new block? Do the go to the default?
Some members of the WG had an implicit assumption that there is a hard
boundary between 'blocks' (a 'block' being a single patlist, patset,
or parallelpatlist), and that the state from the previous block would
not carry into the next block. This implies that signals need some
sort of initial state. This specific issue was raised by inverting the
two blocks in fig 1, allowing the second block to go first: what state
is present on the 'unused' signals at the start of that block in this
context?
3: scanlength...
----------------
Peter is concerned about confusion raised by making the scanlength
statement of the scanstructures optional, when it's required in
dot-zero at this time. Greg identified he already has an AI to discuss
with denis and understand if there's strong motivation here.
4: Annex F removal issue
------------------------
There is a recommendation to remove Annex F, but because this
documents a current construct (AllowInterleave), it does not seem to
be the right thing to do at this moment. Topic tabled until the
submitter of this comment attends a WG meeting to discuss this more
completely.
5: logistics
------------
Tony will send clause 6 to Greg for manipulation by the Expression
subgroup.
A concern was raised that the submitter's issues may be getting
re-synched in the ballot review doc, to the current draft. It was
recommended to keep the submitter's issues synched with draft 18 since
that is the version they reviewed (comments and responses, however,
should be synched to the current revision).
Meeting adjourned at 11:00 pm PST.
Next meeting
Thursday, March 25, 2004, 10:00 to 11:30AM, PST
AIs