Face-to-face meeting of P1450.1 Working Doc Subgroup (at VTS)

Thurs, Apr 28, 2004, 10:30 am PDT

 

Attendees:

Tony Taylor - chairman
Bruce Kaufmann
John Cosley
Greg Maston - scribe
Rohit Kapur - for specific issues
Jose Santiago
 

Documents

Agenda

 

- opening dot-zero (5-year cycle)
- dot-1 ballot issues review


Meeting discussion

 

0. IEEE meeting clearances

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

1. opening dot-zero for 5-year review

Greg wants to open a PAR to incorporate clarifications into dot-zero.

This presents an opportunity to do more, for instance to move
constructs currently in dot-1 into dot-0, for example:
- expression constructs (to make a more baseline functionality)
- F, E, WFCMap, \j
- ScanStructure additions
- reserved-word handling

While this is possible, Greg identified a preference to do this effort
solely to integrate clarifications previously identified (and on the
website) into the dot-0 standard, as we identified we would do, and to
NOT make any technical changes to this standard. It was acknowledged
that opening this standard always opens the potential for additional
changes.

John raised issue with defining both input and output states on
Procedures as part of the initial/startup state requirements. This is
currently not in the clarifications but needs to be considered.

2. Expressions

Current group consensus is to support what's in the standard. Reviewed
the motivation for these constructs - previous issues were raised with
the requirement to enclose all integer expressions in single-quotes,
therefore expression assignments were changed to := but there are are
still places where single-quote expressions are needed for
unambiguous statement interpretation. The example in Pattern constructs
is the repeat operator followed by an expressions, for example: \r 5 +
x A, which is meant to be \r'5+x' A. This is not truly unambiguous at
a parse level (it is parse-able) but requires parse-ahead to the next
token to determine if the expression has been completed or not, and is
difficult to interpret by a human. Single-quotes around the
expression clarify the behavior.

During this discussion the perspective was taken that these problems
occur in situations where a "single token" is expected but "multiple
tokens" (in an expression) are found. By enclosing the expression in
single-quotes, the expression is parsed once again as a single token
and is interpreted unambiguously. The recommendation of the Working
Group is to leverage this concept in the wording of the document - to
maintain a "single token" context where single tokens are a single
value or a single-quoted expression. if expression is ambiguous or
contains more than one token, use single quotes.

The Working Group identified the need to categorically identify all
contexts where "single tokens" are the expected construct. The
statement "single-quotes are optional but there are cases where they
are necessary.", page 13 d18. is one place where a reference is made
but the context of where the quotes are required is not identified
here (and needs to be) - add reference to \r and whatever other
constructs that have this requirement. Also in 6.5 pg 18, bare
integers optionally quoted.

Tony turned the discussion back to the other expression issue with
':=' for integer assignment. Several reviewers disapprove of := and
there's a conflict with using '=' in Spec variables (in dot-0) for
real expressions which may only contain integers.

Motivation for this construct was again discussed, the construct is
used to distinguish early parse syntax errors without full context of
the operators present.

The statement: V { W = FF; } was used to talk to this point, where 'W'
may be either a signal reference or a variable, and FF may be a
waveform-character-list, variable, or hex value. The purpose of := here
is to make clear that this statement is NOT a signal assignment, which
even if it doesn't affect error generation (although you can generate
much more focused error messages knowing the intent of the statement),
it does facilitate human interpretation of the intent as well, and
therefore eliminates confusion of the human reader.

3. ScanCellGroups

Expressions were tabled with the arrival of Rohit, to talk over one of
his issues. The issue is with the ScanCellGroups block, which is
currently proposed in this standard but has no defined use. One
reviewer attempted to do more with CellGroups than currently
defined, while another questioned the presence of this construct with
no application.

Rohit identified the application of this construct in dot-6,
identified the purpose of placing this in dot-1 was to keep cell
related information in a single place, and a concern about moving
things between standards during ballot.

Rohit identified the purpose as: we want to have collections of cells
with defined attributes as part of the CTL Environment. The attributes
are distinctly CTL, but the cells are part of the cell namespace found
under ScanStructures (today).

Tony proposed putting an attribute on the scanchain block or scancell
block, for instance, "logical", "unordered", "unconnected", to support
grouping but to identify this group as a non-scan-chain group. A
concern about this solution is that the grouping behavior is limited
in functionality, in particular there's no "-" capability in scancells
to allow removal of a cell from another collection.

The 'cellnames' used in this block may be cells identified as part of
scanstructures BUT ARE NOT LIMITED to cells in scanchains. The intent
of these organizations are to facilitate attributing these
collections, which may not have any association with scan chains at
all.

After much additional discussion, the Working Group made the following
decisions:
1. Change name from ScanCellGroups to CellGroups. This is critical to
remove all association of this block with scan.
2. Remove ability to reference cellgroups in scanstructures, and to
make a statement in ScanStructures that these groups shall not be used
in scanchains.

4. Expressions (continued)

The previous discussion on expression resumed, with a new construct to
talk to:
 ( 5 == Y ) --- where both sides of the "==" are ambiguous.  5 could be
WFC or integer Y could be var, sigvar, WFC...

Need \W, \w to explicitly identify variables, integers, from
WFC-lists in this context. Some discussion was raised to consider a
similar operator such as \i to disambiguate integers from WFC-lists.

The following syntax expectations were defined:
1. without a modifier, 'thing' is a WFC-list.
2. Modifiers are required to identify signals/variables.
( w == x ) is wrong; ( \W w == x ) is required to identify the variable.

Greg took an AI from the group to write-up the issues above and to
draft a response for the negative balloters on the :-operator issue
(and likewise cover issues with single-quote handling).

It was identified that the assignment operator '=' is used for REALS
and WFCs. ':=' is used for integer expressions and  integer variables only.

5. Unresolved issues

At this point, the WG effort focused on the set of unresolved
issues. All issues in the current ballot resolution document were
reviewed, only technical issues discussed, and only the discussions
that identified new concerns are listed below.

DB-2: block data collection, annex i, data collection is wrong L and H
should be 0 and 1 or WFCMap needs to be re-declared. Also the first WFT
reference in this annex is confusing, just show the necessary parts of
the example to make the example complete.

DB-3: section 18.3, example with incomplete WFT, making interpretation
of the V statements confusing. Add A and B WFC declarations to
clarify.

DM-18: This is an example of unpleasant application, but it is not
"wrong" in the view of the Working Group. Both matches are correct
(otherwise the fundamental WFCMap is wrong), therefore it doesn't
matter which of the matching WFCMap definitions is selected.

GR-5: Concern in the WG discussion about correlating user-keywords
across disparate blocks if not defined in each block; for instance a
UserKeyword might be defined for two Pattern blocks when they are
together, but if one of the Patterns is moved into a
different/additional test but the UserKeyword definition is not moved
(because it's not defined in that Pattern block) then the Pattern will
be incorrect in this new context. By maintaining the UserKeywords in
each block where they are used (even though they are redundantly
declared), this problem doesn't happen and the "requirements" to use
this Pattern are not affected.

AllowInterleave scope --- During the discussion, the construct was
moved up to the PatternBurst, but consideration of sequential
procedures where different sets of signals may be interleaved caused
the statement to be returned to the currently defined locations. Final
resolution is to leave as-is but document the persistence is only to
the scope of the context it was called under - if defined inside a
proc or macro it persists ONLY for that context. on exit from a proc,
states are restored; on exit from a macro, the last specified state is
returned to both contexts (it is sticky from the single definition).


Meeting adjourned at 5:00 PM, PDT.
 


Next meeting

Thursday, May 6, 2004, 10:00 to 11:30AM, PDT

 

AIs

  1. Greg - Statement of Intent on expression syntax and get NO-voters buy in

  2. Tony - update doc per discussion