P1800 Ballot Comments  
Entity: Cadence Design Systems, Inc.  
Primary/Alternate Name: (Jim Vellenga's comments)  
Email:  
                 
Entity Sub-Group No. Clause/ Subclause Paragraph/Figure  /Table Type of Comment (Technical/   Editorial) COMMENTS (Justification) Proposed change Priority Disposition Severity Mantis Item # MUST FIX Committee
        Paragraph Technical  VPI changes to support Encryption - Encryption without this may be meaningless Define the access that should be allowed. High   major 345 YES Encryption
    27.33 Paragraph Technical  PTF 312: Need two new time related callbacks   High   Major 372 YES PTF
  1 Annex H Paragraph Technical  Annex H descriptions need revision for clarity  See Mantis item High   Text 576 YES Encryption
  2 28 Paragraph Technical  Clause 28: replace "should" with more appropriate text  See Mantis item High   Text 577 YES Encryption
  3 26 Paragraph Editorial handle by Index properties need to have parens after the routine names   High   Trivial 413   PTF
  4 26.6.42 Paragraph Technical  The reference to 'taskfunc' should be 'task func'   High   Trivial 414   Stu
  5 26.6.3 Paragraph Technical  Improperly drawn LHS of diagram - regression   High   Major 415   PTF
  6 26.6.22 Paragraph Technical  PTF 311 Problem with loads in VPI   High   Major 417   PTF
  7 Annex G Paragraph Technical  PTF 562 Need to have a vpiTimeConst in the vpi_user.h file   High   Trivial 418   PTF
  8   Paragraph Technical  `compatibility - backward compatibility compiler directives   High   Major BTF 287   BTF
  9   Paragraph Technical  Depricate configs in Verilog source files   High   Major BTF 350   BTF
  10 Annex B Paragraph Technical  Annex B: include, incdir, library listed as reserved   High   Trivial ETF 99   ETF
  11 15.2.4, 15.2.5 Paragraph Technical  The spec is confusing since it implies that for both $removal and $recovery, data_event (the second parameter in both sytnax 15-6 and 15-7) is the time check event.  Along this line, the example of $recrem given in page 256 won’t make much sense. To correct the issue, Table 15-4 on page 253 should be changed as follows: The description for reference event should be 'Timecheck event' and the description for data_event should be ' Timestamp event'. High   minor     ETF
  12 15.3.2 Paragraph Technical  As specified in the syntax box 15-10 (p258), users can specify two flags (event_based_flag and remain_active_flag) to change the behavior of $timeskew. It should be explicitly stated that remain_active_flag can be set only when the event_based_flag is set. This constraint is somewhat vaguely implied in the text of this section, but it is pretty confusing to users. To make it more confusing, the example on page 259 lists four cases of the two flag values combination. However, Case 4 and Case 3 are the same and one should be removed. A similar example is given in 15.3.3 where the spec correctly illustrates the sensible combinations of the two flags.   High   minor     ETF
  13 Annex G Paragraph Technical  PTF 562  Need to have a vpiTimeConst in the vpi_user.h file   Low   trivial 418   PTF
  14 26.1 Paragraph Editorial 26.1 use of 'user'   Low   trivial 539   PTF
  15 26.1 Paragraph Editorial 26.1 inconsistency   Low   trivial 540   PTF
  16 26.2.1 Paragraph Editorial 26.2.1 Several uses of the term 'user'   Low   trivial 541   PTF
  17 26.2.4 Paragraph Editorial 26.2.4 inconsistency   Low   trivial 542   PTF
  18 12.8.2 Paragraph Editorial 12.8.2 example could use some minor cosmetic corrections.  "module mid2();" should be "module mid2;"  Change "mid1" and "mid2" to "m1" and "m2" respectively (in a total of 4 places).   Low   Trivial     ETF
  19 15.3.3 Paragraph Editorial On page 261, in the third paragraph, $timeskew should be $fullskew.   Low   Trivial     ETF
  20 16.2.1 Paragraph Technical  In Table 16.1 there are 3 "RETAIN  ignored without warning" comments.  Are these really necessary?   Low   minor     ETF
  21 16.2.2 Paragraph Editorial The note (b) following Table 16-2 states ($nochange) "not ususally implemented in Verilog simulators".   Low   Trivial     Clarification Needed.  There is no request here.
  22 18.1.5 Figure Editorial Typo in table caption change "Syntax fro" to "Syntax for" Low   Trivial     Stu
  23 27 Paragraph Editorial 27 - Need to not use the ambiguous term 'user'       minor 416   PTF
  1 19.6 Paragraph Technical  As discussed in http://www.boyd.com/1364_btf/report/full_pr/469.html it shouldn't be legal to `resetall within a module declaration. In 19.6, APPEND the following sentence --

   It shall be illegal for the `resetall directive to be
   specified within a module declaration.
 High         ETF
STU1 1) Throughout the LRM, there are references to errors and warnings that
implementations can or shall issue.  There is no definition as to the
meaning of "error" and "warning".  Does an "error" terminate compilation,
elaboration or run-time execution?  Should an error message include the term
"error" and a warning message the term "warning"?  It appears that "error"
and "warning" are often used either inconsistently, or interchangeably.  The
standard needs to define the meaning of these terms, and ensure that all
references to the terms are used clearly and consistently.  I suggest that
there be three definitions:


Fatal error: Shall result in the generation of an error message informing
the user that a specific syntactic or semantic condition has been detected.
The message reporting the fatal error shall contain the word "Error",
"error" or "ERROR".  A fatal error shall result in the termination of the
current process of compilation, elaboration or run-time execution.  An
implementation may report other fatal errors, non-fatal errors or warnings
before terminating.


Non-fatal error: Shall result in the generation of an error message
informing the user that a specific syntactic or semantic condition has been
detected.  The message reporting the non-fatal error shall contain the word
"Error", "error" or "ERROR".  A non-fatal error shall not terminate the
current process of compilation, elaboration or run-time execution.


Warning: Shall result in the generation of an warning message informing the
user that a specific condition has been detected and a specific Verilog
semantic rule applied.  The message reporting the warning shall contain the
word "Warning", "warning" or "WARNING".


Clauses that are ambiguous as to whether "error" is fatal, non-fatal or
really just a warning include:
1.2, 3.6 (table 3-1), 3.7, 4.6.5, 5.2.1, 5.6, 7.1.6, 10.4.5, 12.3.3, 12.4,
12.4.1, 12.8.2, 13.2.1.1, 13.3.1.4, 13.3.2, 14.6.2, 14.6.4.1, 14.6.4.2,
15.3.4, 15.3.5, 15.5, 17.1.1.1 (table 17-1), 17.2.3, 17.2.9, 17.6.1, 17.6.2,
17.6.3, 17.6.4, 17.6.5, 18.3.1, 19.3.1, 19.8, 27.1, 27.5, 27.6, 27.22,
27.24, 27.25, 27.26, 27.28, 27.29, 27.31, 27.32, 27.33.2, 28.4.27.2,
28.4.28.2, 28.4.29.1, C.8


Clauses that should be reviewed as to whether the terms "warn" or "warning"
are correctly used include:
3.8, 4.6.5, 12.3.8, 12.3.9.3, 12.3.10.2, 13.2.1.1, 15.5.1 (multiple
occurrences), 16.1 (multiple occurrences), 16.2.1 (table 16-1, multiple
occurrences), 16.2.4, 17.2.3, 17.2.9 (multiple occurrences), 18.3.1, 19.3.2,
27.8
   1364
STU2 2) In many places throughout the LRM, the usage of "Note" and "Notes" is not
correct.  In IEEE standards, notes are informative, and not a required part
of the standard.  It is clear that in many places in the LRM, there are
notes that are both intended to be normative, and are required for proper
implementation of the standard.  I believe that IEEE standards also require
that notes be in a separate paragraph, and use a smaller font.  In many
places in the LRM, there are sentences (often in the middle of a paragraph)
that begin with "Note..." but are not in a smaller font.  It is unclear as
to whether these notes are meant to be an informative notes, or an important
normative fact that users and/or implementers need to observe.  All usages
of the word "Note" "note", "NOTE", "Notes" "notes" and "NOTES" should be
reviewed and brought into IEEE standards compliance.


Clauses that should be reviewed as to whether the terms "note" or "notes"
are correctly used as only informative text include:
3.5,1 (multiple occurrences), 3.6.2, 3.7, 4.2.2, 4.5, 4.6.1, 4.6.2, 4.9,
5.1.3, 5.2.1, 5.4.1, 5.5.1, 6.1.1, 6.2.1, 8.1, 8.1.2, 9.2, 9.2.2, 9.5,
9.5.2, 11.2, 11.4.2, 12.1.1, 12.2.1, 12.3.8, 12.4.1, 12.4.2 (multiple
occurrences), 12.4.3, 12.8.1, 13.2.1, 13.2.1.1, 13.3.1.6, 13.4.1, 13.7.1,
14.2.4.3, 15.5, 17.1.1.2 (multiple occurrences), 17.1.1.5, 17.2.1, 17.2.3,
17.2.4.1 (multiple occurrences), 17.2.4.4, 17.2.5, 17.2.9, 17.5, 17.5.3,
17.7.1, 18.2.1, 18.4.1, 19.3.1, 19.4, 19.5, 20.1 (multiple occurrences),
26.6.1 through 26.6.44, 27.6, 27.10, 27.14, 27.25, 27.33.3, 27.34.2
(multiple occurrences), 28.2.1 (multiple occurrences), 28.4.14.2, 28.4.20.2,
28.4.27.2, 28.4.28.2 (multiple occurrences), 28.4.29.1 (multiple
occurrences), A.9.4
   All
STU3 3) Table 17-5 continues onto a second page, but the table title on the
second page does not say "continued".

   STU
STU4 4) Section 20.1 is marked as an informative clause.  New IEEE documentation
rules do not allow informative clauses.  This entire clause needs to be a
note, or it needs to be made normative.
 
   1364