From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Wed Oct 04 2000 - 18:29:18 PDT
Before enumerating by page, I have a few general comments.
JohnW-General #1: The PLI and maybe VF really are not part of the Verilog
Hardware
Description language; they don't describe hardware very much. So, perhaps they
should be moved to a different standard, one for access to a Verilog
simulator or
synthesizer database?
<p><p>JohnW-General #2: This document is too "flat" for a standard so big. I
suggest a
reorganization of the material into a smaller set of related categories. I am
supplying the following as an example:
I. Introduction and Overview, with minimal hierarchical Verilog design
example, including some timing checks.
II. Functional-modelling language elements (modules, nets, etc).
III. Library model language elements (UDPs, etc).
IV. Design hierarchy representation.
V. Timing checks & formats.
VI. Simulator and compiler elements (system tasks; compiler directives;
etc).
VII. Backannotation.
VIII. VPI.
IX. Backus-Naur, Annexes, etc.
<p><p>JohnW-General #3: Often, terms are used before being defined, and no
indication is given
as to where to find them. For example, "nonblocking" and "static".
Instances are
indicated specifically below.
The circumstances under which one would use the PLI often seem not obviously
defined. Does the "PLI" run on the Verilog source code? On the compiled but
not
yet simulated Verilog simulator db? On the simulation runtime code in memory?
What is the file format of the db that one must create to use the PLI? The
TF? The
VPI?
<p><p>JohnW-General #4: In the PLI areas, I often find the end-user of this
document being
called a "consumer". This creates a strange image of a design engineer. A Std
document might get dog-eared, but it never will be "used up" or "consumed",
so why
call the user a "consumer"? I suggest simply "user", or maybe "Verilog
designer",
"design engineer", or "code interface writer", depending on context.
<p><p>JohnW-General #5: For this ballot, I read most of the language
specification closely; I
merely skimmed the PLI; and, I just looked at the VPI and Annex material. So,
ones reassurance as to thoroughness of my criticism should be weighted
accordingly.
Nevertheless, I used up a whole pad of sticky notes . . ..
Pagewise Comments:
<p><p>JohnW-Comment #6: p. iii, Introduction, 2nd paragraph, last sentence:
Delete "It is
because of these rich features that". Reads like a tacky self-advertisement to
conceal a deficiency somewhere.
<p><p>JohnW-Comment #7: p. iii, Introduction, 3rd paragraph, after 3rd sentence:
After ". . .
nets and variables", add "The nets represent electrical or logical wires;
the variables
represent values of electrical or logical expressions."
<p><p>JohnW-Comment #8: p. xxxiii, after List of Tables, add a list of examples,
by design object
(adder, gate-level flip-flop, fifo, etc). These are scattered throughout
the text of this
big document, and designers will have to page around a lot to find one they
recalled
having seen.
<p><p>JohnW-Comment #9: p. 7, Section 2.3, Comments, add to the end, ", and
neither shall a
block comment token in a one-line comment." Thus, comments can't be
interleaved,
as well as can't be nested.
<p><p>JohnW-Comment #10: p. 7, Section 2.5, Numbers, add after the end,
"Real" here refers to floating-point format or other noninteger
numbers; it does not refer to the "real" vs imaginary part of a
complex number.
<p><p>JohnW-Comment #11: p. 7, Section 2.5, Numbers, Syntax 2-1. This really
should be a
general comment, I guess, but in this and almost every other Syntax box,
there seem
to be bitmapped font characters. I think the bitmapping is supposed to be
BOLD,
but the word processor or hard-copy printer used for this draft document
can't seem
to get them right. For example, the third lhs says, exp ::= e | E, but the
rhs is
bitmapped and grainey. Almost every line after lhs decimal_base is full of
grainey
characters. This is OK in a draft, but it should be fixed before final
typesetting.
<p><p>JohnW-Comment #12: p. 9, Section 2.5.1, Integer Constants, 4th paragraph
from top,
change the first sentence to read, "The second token, a base_format, shall
consist of
a case-insensitive letter . . .".
<p><p>JohnW-Comment #13: p. 11, Section 2.5.2, Real Constants, below the last
examples of
invalid formats, I suggest adding, "Decimal points are illegal for numbers
in binary,
hex, or octal format." Better: The standard should be changed to ALLOW real
numbers at least in decimal-like binary format (e. g., 'b0101.1110, where the
fractional part would mean 14/16 == 7/8).
<p><p>JohnW-Comment #14: p. 11, Section 2.6, Strings, first line of paragraph:
Here as well as
occasionally elsewhere, "smart quotes" are being used (this is what
Microsoft Word
calls them). These "smart quotes" are not ASCII standard characters and
generally
can not be found on a standard keyboard. They should not appear in this
document. So, change ". . . enclosed by double quotes ("") and . . ." to ".
. . enclosed
by double quotes ("") and . . .". Some programmers like the smart quotes for
sentimental historical reasons or because they are symmetrical, like open &
close
parens. But they are not standard. Maybe a Note should explain this here?
<p><p>JohnW-Comment #15: p. 12, Section 2.6.1 and 2.6.2: Smart quotes should be
changed (see
Comment #14).
<p><p>JohnW-Comment #16: p. 14, Section 2.7.4, System tasks and functions, after
the first
sentence, add, "System constructs are not design semantics but refer to
simulator
functionality."
<p><p>JohnW-Comment #17: p. 15, Section 2.8, Attributes, before the last sentence
on this page, I
suggest stating that attributes are boolean objects which, if present, only
may be
evaluated as true or false in a boolean expression. As elsewhere in Verilog
or C,
wherever meaningful, true means 1 and false means 0.
<p><p>JohnW-Comment #18: p. 16, Section 2.8.1, Examples, in all three parts of
Example 1,
parallel_case is mispelled "parallee_case".
<p><p>JohnW-Comment #19: p. 23, Section 3.2.1, Net declarations, the last
sentence in the first
paragraph ("It is illegal . . .") is not necessary here. This is a general
feature of any
modern programming language: The scope and conflict of names. If this has
to be
somewhere, it should be moved maybe to 2.7.
<p><p>JohnW-Comment #20: p. 26, Section 3.3.1, Specifying vectors, the two Notes
at the end
actually specify part of the standard; they should be plain text, not Notes.
<p><p>JohnW-Comment #21: p. 27, Section 3.4.1, Charge strength, I suggest adding
an example
declaration here.
<p><p>JohnW-Comment #22: p. 28, Section 3.6, Net types, really should not be just
a random list.
I suggest reorganizing Table 3-1 in five columns with labels: Connection
elements
= wire & tri; Logical connection elements = wor, wand, trior, & triand;
Logic storage
elements = trireg; Pull elements = tri0 & tri1; Supply elements = supply0 &
supply1.
<p><p>JohnW-Comment #23: p. 35, Section 3.9, Integers, reals, times, and
realtimes, ends with a
Note which specifies part of the standard. It should be text, not a Note.
<p><p>JohnW-Comment #24: p. 35, Section 3.9.2, Conversion, first paragraph ends
with the
statement, "The ties shall be rounded away from zero". I am not sure what this
means, so perhaps it should be deleted: What is tied here?
<p><p>JohnW-Comment #25: p. 36, Section 3.10, Arrays, I think the first two example
declarations should read,
reg x[11:0] scalar reg with 12, 1-bit elements
wire [0:7] y[5:0] eight-bit-wide vector wire indexed from 0 to 7
<p><p>JohnW-Comment #26: p. 37, Section 3.10.3.1.1, Array Declarations, I think
"reg rega;"
should be declared here to be used in the next section.
<p><p>JohnW-Comment #26a: p. 37, Section 3.10.3.1.1, Array Declarations, after
the declaration
examples, I suggest adding a Note: "Note: The reasoning here is the same as
for
numerical constants, in that the width comes first. For example, 16'h0531
has a
width of 16, just as reg [15:0] x does.
<p><p>JohnW-Comment #27: p. 37, Section 3.10.3.1.2, Assignment to array elements,
ends with a
Note which actually specifies part of the standard and should be moved as
text to
Section 3.10. Contrariwise, the immediately following Section 3.10.3.1.3
should be
deleted and its text moved as a Note to Section 3.10.3.1.1.
<p><p>JohnW-Comment #28: p. 38, Section 3.11, Parameters, should address the
question of
rounding when assignment is from a wider to a narrower range.
<p><p>JohnW-Comment #29: p. 38, Section 3.11.1, Module parameters, the caption
for Syntax 3-4
should read, "Syntax for module parameter declaration", even though
Backus-Naur
for local parameters is included. Or, it should be moved to Section 3.11.
<p><p>JohnW-Comment #30: p. 41, Section 3.12, Name spaces, the third paragraph
should end
with, ". . . shall not be defined again in that space, whether of the same
or a
different type."
<p><p>JohnW-Comment #31: p. 43, Section 4, Expressions, I suggest adding a Note:
"Expressions
differ from statements. An expression merely shows how a value is to be
computed;
a statement uses one or more values to change the state of something--for
example,
the state of the simulation. It is not hard to see that '==' or '===' may
be part of an
expression; however, '=' always is part of an assignment statement."
<p><p>JohnW-Comment #32: p. 47, Section 4.1.5, Arithmetic operators, in the
paragraph about
power operators, I suggest adding a specification that implied division by
zero shall
be handled by conversion to 'x' or an x vector.
<p><p>JohnW-Comment #33: p. 51, Section 4.1.9, Logical operators, the entire
"recommendation"
should be a Note: It doesn't make sense to make a recommendation part of the
specification of a standard. How could it be decided whether some Verilog
conformed with such a standard?
<p><p>JohnW-Comment #34: p. 60, Section 4.2.3.3, Null string handling, the
examples all are in
"smart quotes", which are illegal in ASCII.
<p><p>JohnW-Comment #35: p. 62, Section 4.3, Minimum, typical, and maximum delay
expressions, the Example 2 text at the top of the page should say, ". . .
shows a
typical expression . . .".
<p><p>JohnW-Comment #36: p. 64, Section 4.4.3, Example of self-determined
expressions should
end with the example, c=21 // example size is 16 bits (size of c).
<p><p>JohnW-Comment #37: p. 68, Section 5.3, The stratified event queue, around
the middle of
the page, should include a Note explaining blocking briefly & referring to its
explanation (5.6.3 & 9.22).
<p><p>JohnW-Comment #38: p. 77, Section 6.2.1, Variable declaration assignment,
says in the
first paragraph that "Variable declaration assignments to an array are not
allowed".
Why not? This exception seems merely to make things harder for the designer
and
should be deleted from the standard.
<p><p>JohnW-Comment #39: p. 82, Section 7.1.5, The range specification, says in
the third
paragraph that one instance identifier shall be associated with only one
range, and
the example, nand #2 t_nand[0:3] (. . .), t_nand[4:7] (. . .); is
shown illegal. Why? So long as there is no implied name conflict (t_nand[j]
declared more than once), array-name holes should be allowed.
<p><p>JohnW-Comment #40: p. 86, Section 7.3, buf and not gates, The paragraph
second from
the bottom of the page is not only pedantically repetitive, but it is
confusing because
it is repetitive. A designer would have to spend time comparing this and
the very
similar statement in Section 7.2, to be sure there was no difference in the
details.
This paragraph should be shortened to read in its entirety, "The delay
specification
shall be zero, one, or two delays, with meanings identical to those of 7.2."
<p><p>JohnW-Comment #41: p. 87, Section 7.4, bufif1, bufif0, notif0, and notif1
gates, I suggest
rewriting the first line as, "The instance declaration of these three-state
logic gates .
. .". The term, tristate, has been trademarked by National Semiconductor
and is not
necessary for this document.
<p><p>JohnW-Comment #42: p. 89, Section 7.5, MOS switches, the first three entire
paragraphs
on this page, as in Comment #40, simply repeat a previous description. They
should be deleted and replaced by something such as, "The delay
specification shall
be zero, one, two, or three delays, with meaning and terminal arrangement
as in
7.4."
<p><p>JohnW-Comment #43: p. 111, Section 8, User-defined primitives (UDPs), ends
with a
second-from the last sentence saying that the output shall be in one of
three states,
0, 1, or x. Why is not z allowed? This exception probably should be
eliminated.
Also, as in Comment #41, I suggest saying "three-state" instead of "tristate".
Finally, I also suggest a Note around here, explaining why UDPs might be
useful:
After all, a case variant in a module would allow one to define a lookup
table, too.
<p><p>JohnW-Comment #44: p. 113, Section 8.1.1, UDP header, the third sentence of
the first
paragraph probably should read, "This in turn is followed by a
comma-separated list
of port names enclosed . . .." Also, the second sentence in the second
paragraph
should say, ". . . comma-separated list of port declarations . . .".
<p><p>JohnW-Comment #45: p. 113, Section 8.1.1, UDP header, the third paragraph says
bidirectionals and vector port declarations are not allowed on a UDP. Why not?
Why this apparent irregularity in Verilog?
<p><p>JohnW-Comment #46: p. 155, Section 10.2, Tasks and task enabling, I suggest
that a new
paragraph be inserted before the first one here, or maybe at the start of
Section 10,
defining what "enable" means. A reader unfamiliar with Verilog will not
understand the similarity of an enabled task to an executing VHDL procedure
or a
called function in C. Is an "enabled" task somehow like a latch or gated
clock, or a
three-state? How does "enable" differ from "activate"?
<p><p>JohnW-Comment #47: p. 155, Section 10.2, Tasks and task enabling, final
sentence on this
page: Closely related to the previous Comment, it is unclear whether a task
enabled by another task necessarily has been declared or instantiated
within the
latter (in a nested or hierarchical sense). For example, suppose a task
changed the
value of a reg during simulation, and the change in turn propagated through
some
logic, maybe even to another module, and caused a second task to be
enabled. Does
this Section mean to say that the first task "enabled" the second?
In any event, I suggest the last sentence be replaced by, "Regardless of
how many
other tasks have been enabled by a certain task, control shall not be
returned by
that task until all tasks it enabled have returned control to it."
<p><p>JohnW-Comment #48: p. 159, Section 10.2.3, Task memory usage and concurrent
activation, should be preceded by a definition of what "static" means.
<p><p>JohnW-Comment #49: p. 162, Section 10.3.4, Function rules, Rule a possibly
should deal
with the case in which the '#' character introduces a parameter?
<p><p>JohnW-Comment #50: p. 162, Section 10.3.4, Function rules, Rule e should
allow for an
alternative usage, in which the function may be returned by executing a
return(value) statement, as in C.
<p><p>JohnW-Comment #51: p. 186, Section 12.2.2, Module instance parameter value
assignment, possibly includes a typo on the second line of the first
paragraph: I
think it should be, "They are: Assignment by ordered . . .".
<p><p>JohnW-Comment #52: p. 188, Section 12.2.3, Parameter dependence, seems
fairly obvious
and should be deleted or possibly rewritten as a Note or example.
<p><p>JohnW-Comment #53: p. 188, Section 12.3.4, may have a typo and probably
should be
called Port name declarations. Also, the second sentence of the first
paragraph is
ambiguous: Does it refer to all modules in a given design or compiler run?
Or (as I
think), just all port names in a given module? I suggest the second
sentence begin
with, "Each module . . .", or, maybe, "Any one module . . .".
<p><p>JohnW-Comment #54: p. 201, Section 12.6, Scope rules, end of second
paragraph from the
bottom might be improved a little by rewriting as, ". . . instance the same
name as
that of the net connected . . .".
<p><p>JohnW-Comment #55: p. 202, Section 12.6, Scope rules, I do not understand what
"precedence" means in the second paragraph. Does this mean there will not be a
name conflict if there is a module name and an instance name the same? If
there
will be a name conflict, then what difference would "search order" make?
Also, the
final sentence refers to a "downward path", which should be defined here.
<p><p>JohnW-Comment #56: p. 203, Section 12.6, Scope rules, I suggest the caption
be changed
to, "Figure 12-3 -- Scope of upward name referencing for nonhierarchical
names."
<p><p>JohnW-Comment #57: p. 209, Section 13.3.1.6, The use clause, I suggest the
last sentence
be changed to a Note.
<p><p>JohnW-Comment #58: p. 210, Section 13.4, Using libraries and configs, the
entire Section
13.4 should be removed from the binding text of the standard and changed to
a Note
or Annex, or maybe added to a nonbinding Introduction somewhere.
<p><p>JohnW-Comment #59: p. 213, Section 13.7, Reserved words, should be deleted
or changed
to a Note: These words already are in Annex B; respecifying that they are
reserved
here merely establishes dual points of control and creates unnecessary
opportunity
for error in the standard document.
<p><p>JohnW-Comment #60: p. 275, Section 16.2, Mapping of SDF constructs to
Verilog, possibly
should be reworded to say, ". . . replacing the timing values in the
Verilog file with
those from the SDF file." When synthesis of netlists is involved, there may be
several different design representations present, including RTL Verilog, and
Verilog, VHDL, or proprietary netlists.
Question: Should it be required that all SDF backannotation be reversible?
So that
it always shall be possible to recover the original timing values, before
backannotation, by a single backannotation run? This would be equivalent to
requiring that backannotation never could replace a timing format of n
values with
a different format of m values.
<p><p>JohnW-Comment #61: p. 285, Section 17.1.1.1 through Section 17.1.1.4, each
final
example should be made neater. Perhaps a little box with dotted lines and
rounded
corners should be used to represent the screen display during simulation?
<p><p>JohnW-Comment #62: p. 286, Section 17.1.1.2, Format specifications, third
paragraph
from the bottom. There is a problem in allowing the data to be written in the
native machine integer format, which varies with CPU hardware and compiler,
and
may be anywhere from 16 to 128 bits. I suggest standardizing and explicitly
requiring a definite width, say signed 32 bits, for data. Let the user
figure out
whatever native format specifier should be coded; if the user has unusual
hardware
or compiler, he or she will know it. This will improve portability and
reusability of
the data.
<p><p>JohnW-Comment #63: p. 304, Section 17.3.1, $printtimescale, the text just
before the
example probably should say, "The timescale information shall appear in the
following format:". Likewise, just after the example, it probably should
say, "The
information about c_det shall be displayed in . . .".
<p><p>JohnW-Comment #64: p. 318 - p. 327, Section 17.9.3, Algorithm for
probabilistic
distribution functions, I suggest that the code be moved to an Annex.
Perhaps it should be explicitly stated whether it is allowed to use an
improved
algorithm (maybe a numerical recipe in assembly language) which achieves the
same result? Also, technically, a "distribution function" of a random
variable is a
cumulative distribution function, an integral of the probability density
function from
the low end of the domain.
<p><p>JohnW-Comment #65: p. 334, Section 18.1.5, Limiting the size of the dump file
($dumplimit), really should include an option to allow the file to become a
FIFO on
limit: In a long simulation, often it is the latest data that are of
interest to the
designer.
<p><p>JohnW-Comment #66: p. 340, Section 18.2.3.2, $date, should default to the
yyyy MM dd
hh:mm:ss format, which makes sorting things by date much easier.
<p><p>JohnW-Comment #67: p. 342, Section 18.2.3.8, $var, seems to have a typo in
the final
example: Shouldn't the format be, "integer 32 addr[31:0]"? The unmatched
parenthesis here and elsewhere makes me uneasy.
<p><p>JohnW-Comment #68: p. 360, Section 19.3.1, ' define, I suggest some text or
a Note
explaining whether recursion is allowed in macroes, and whether macro
references
are allowed in macro definitions. For example, is this legal:
'define nand reg nand['high_bit:'low_bit]
<p><p>JohnW-Comment #69: p. 360, Section 19.3.2, ' undef, the final text should
be expanded to
read, "A 'undef'ed text macro has no value and no name; any subsequent
appearance of the 'name shall be replaced by the compiler by one
whitespace" (or,
maybe, be removed?)
<p><p>JohnW-Comment #70: p. 364, Section 19.6, ' resetall, the first line of text
should read, ". . .
all compiler directives except 'line are set to the default . . .". Also,
where are the
default values listed? They should be in a table or Annex referenced here.
<p><p>JohnW-Comment #71: p. 373, Section 21, probably should be named, PLI TF and
ACC
interface, and, the fourth bullet after the first paragraph should say, ".
. . should be
treated as functions (which return only a value) or tasks (analogous to
procedures or
subroutines in other programming languages)
<p><p>JohnW-Comment #72: p. 373, Section 21.1, User-supplied PLI applications,
before the
final paragraph, it would be nice to explain what "TF" means (task-function?).
<p><p>JohnW-Comment #73: p. 373, Section 21.1.1, The sizetf class of PLI
applications, the
second sentence probably should read not shall but, ". . . how many bits
wide that
return-value will be."
<p><p>JohnW-Comment #74: p. 377, Section 22.1, ACC routine definition, after the
first sentence,
I suggest adding, "ACC stands for PLI access".
<p><p>JohnW-Comment #75: p. 378, Section 22.2, The handle data type, it is
unclear whether all
handles are the same exact type, or whether there might be several different
predefined (sub)types of handle (there certainly are in Windows
programming). I
suggest rewriting the first sentence as, "Handles are pointers to objects
in the
design hierarchy. All handles are of the same predefined data type."
<p><p>JohnW-Comment #76: p. 379, Section 22.4.1, Fetch routines, the table and
other tables use
the word "Get". While this is OK for C++ methods, which get stuff but
generally
keep within the class, it is not really descriptive of what happens in the
PLI: The
routines return the gotten data to the caller. Therefore, I suggest
relabelling all
tabulated routines, using the word, "Returns the . . ." instead of "Gets
the . . .".
<p><p>JohnW-Comment #77: p. 405, Section 22.9, String handling, I don't see any
value to
including this Section in the standard: It (Sections 22.9.1 through 22.9.4)
should be
removed entirely. Unless I am missing something, this section merely
describes a
user-unfriendly peculiarity of some specific Verilog implementation. That
implementation should be redone, with dynamic memory allocation for
strings, thus
conforming with this Standard.
<p><p>JohnW-Comment #78: p. 407, Section 22.10, Using VCL ACC routines, and
subsequent
Sections. Suddenly, we find the Standard referring to the designer,
programmer, or
other user as a "consumer". This word should not be used (looks as though
an EE
student switched to an MBA, forgot what he was doing, and ended up in SA by
mistake). Please see my General Comment #4.
<p><p>JohnW-Comment #79: p. 592, Section 24.3.7, Writing the correct C data
types, the second
sentence ("There is no inherent data type checking in the C language.")
should be
deleted as false: Ever since ANSI C, C has had data typing as strong as
garlic;
however, it has been optional. When desiring strong type checking, one need
merely
declare tagged structs; or, better, upgrade to C++.
<p><p>JohnW-Comment #80: p. 671, Section 26.1, VPI system tasks and functions, I
suggest
adding a Note mentioning how VPI differs from PLI ACC and TF.
[end of Comments]
//*****************************************************************//
// Cliff Cummings Phone: 503-641-8446 //
// Sunburst Design, Inc. FAX: 503-641-8486 //
// 14355 SW Allen Blvd. E-mail: cliffc@sunburst-design.com //
// Suite 200 Web: www.sunburst-design.com //
// Beaverton, OR 97005 //
// //
// Expert Verilog, Synthesis and Verification Training //
//*****************************************************************//
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:14 PDT
and
sponsored by Boyd Technology, Inc.