Subject: SV 3.0 errata and clarification requests
From: Stuart Sutherland (stuart@sutherland-hdl.com)
Date: Fri Dec 06 2002 - 16:39:42 PST
Karen,
Here is the list I mentioned on errata that I've found in the SV 3.0
LRM. Many of these, such incorrect fonts, are the fault of the editor (me)
but should probably be documented in order to make changes to an approved
document. I suspect you are already aware of most of these, along with may
more that I haven't noticed yet.
I've also included a number items in the LRM where further clarification is
needed. Where possible, I also made suggestions for the clarifications.
Stu
========================================================
SV 3.0 section 3.3:
Are bit selects of int, byte, char, etc. allowed? Clarification is needed
on what data types bit selects are allowed on, and which bit number to use
for the LSB. SystemSim 2.1.4 does not allow bit selects of an int, for
example, but Peter Flake tells me it should be allowed.
----------------------------------
SV 3.0 section 3.7, paragraph 7:
Change "masked" to "4-state" and "unmasked" to "2-state".
----------------------------------
SV 3.0 section 3.7:
A paragraph needs to be added defining how to assign values to packed and
unpacked unions. Is it legal to assign a value to the name of an unpacked
union? If so, which member of the union is used? For example:
union {
real r;
int i;
} data;
...
data = 5;
SystemSim allows the preceding example, but Peter Flake says it should only
be legal to assign to the name of packed unions. Clarification and rules
are needed.
----------------------------------
SV 3.0 section 4.2, next to last paragraph, last sentence:
Change "may" to "can".
----------------------------------
SV 3.0 section 5.6, second paragraph, last sentence:
States "A reg variable cannot be written through a port". This conflicts
with section 12.1 and 12.5, which says any data type can be passed through
a port. Which section is correct?
----------------------------------
SV 3.0 section 5.6, third paragraph, first sentence:
Change "A logic variable can be written by one continuous assignment..." to
"A logic variable can be written by one explicit continuous assignment
using an assign statement...".
----------------------------------
SV 3.0 section 5.6, third paragraph, last sentence:
Change "The assign statement..." to "A procedural continuous assign
statement (also called a quasi-continuous assign statement)...".
----------------------------------
SV 3.0 section 5.6, fourth paragraph:
Change "Note the difference between a net declaration with assignment and a
variable initialization:" to "Note that the logic type cannot have an
implicit continuous assignment as part of the declaration, the way a net
data type can. An assignment as part of the logic declaration is a variable
initialization, not a continuous assignment. For example:". This
clarification came by way of a comment from a training class, where every
single student was confused by the meaning of the original wording.
----------------------------------
SV 3.0 section 5.6:
This section does not explain where the bit type can be used. I believe
the intent is for bit to be allowed anywhere logic can be used, and
therefore should be included in this section. Peter Flake responded to my
question on this with: "A bit should not be driven by a 4state logic, reg
or wire. This is not currently trapped in Systemsim, but it leads to
strange behavior and customer complaint. Any other use is OK."
----------------------------------
SV 3.0 section 5.6:
This section, or a new section, should describe where it is legal to use
the other new data types, such as int, byte, char, etc. I assume the rule
is that they can only be used in the same places a Verilog reg, integer,
etc. can be used.
----------------------------------
SV 3.0 section 7.8, precedence table.
The operators && and || are listed as unary operators, which is different
than 1364 (Note that one of the changes the SV-EC made for the 3.1 draft 1
LRM changes placement of these two operators). The concatenation operator
is listed as lowest priority, but I believe that in 1364 it is highest
priority. The replicate operator is not listed at all. There may be other
difference between SystemVerilog and 1364--I did not do a line-by-line
comparison.
----------------------------------
SV 3.0 section 8.9, third paragraph:
Change signal name "clk" to "a".
----------------------------------
SV 3.0 section 8.9, last two example lines:
The comments for both examples are the same--either the examples do not
illustrate the difference "changed" makes, or the comments are incorrect.
----------------------------------
SV 3.0 section 9.1, first paragraph:
Change "always_ff" to bold keyword font
----------------------------------
SV 3.0 section 9.2, first paragraph (and second paragraph) and 9.3 second
paragraph:
Do always_comb (and always_latch) allow references to hierarchical
references? I hope that this is illegal.
----------------------------------
SV 3.0 section 9.3 second paragraph:
Add a bullet that always_latch is sensitive to changes within the contents
of a function, the same as always_comb. OR, change the first bullet to
state that always_latch infers the same sensitivity list as always_comb.
----------------------------------
SV 3.0 section 9.3, last paragraph:
"always_latch" should be in the bold keyword font.
----------------------------------
SV 3.0 section 11.9, first bullet:
Delete the first occurrence of the word "only".
----------------------------------
SV 3.0 section 12.2, fourth paragraph:
What is the instance name for implicitly instantiated modules? Without
knowing the instance name, it is not possible to refer to anything
hierarchically. Tools that write or read hierarchical path names will need
to infer the same name for portability. I suggest that the inferred
instance name be the same as the module name, and if that name is used in
the same name space, an error occurs. Note that some tools will already
infer instance names for primitives even though there is no standard
inferred name, but this is different because there is nothing within a
primitive that can be referred to hierarchically.
----------------------------------
SV 3.0 section 12.2, last bullet under "The $root top level":
Change "shall" to "can". It is not mandatory that $root have procedural
statements.
----------------------------------
SV 3.0 section 12.6 (or section 3.4.1):
Add a clarification that a global timeunit/timeprecision must be defined
prior to the module definition in order to be in effect for that module.
----------------------------------
SV 3.0 section 12.6 (or section 3.4.1):
Add a clarification that it is illegal to have multiple timeunit or
timeprecision definitions in the same hierarchy space (e.g. it is illegal
to have two or more global timeunit definitions). Note that Peter Flake
has suggested that it would be a possible enhancement to allow multiple
definitions in the same space, provided they are the same.
----------------------------------
SV 3.0 section 12.7.4, throughout:
The rules for what .* will infer a connection only for "variables". This
eliminates any net data type from being used with .*. Since SystemVerilog
also allows structures and unions and arrays as ports, will .* also infer
connections to objects that match those names as well?.
----------------------------------
SV 3.0 section 12.7.4:
This section does mention if a global identifier will also infer a
connection to a matching port name. E.g. will a global clock or reset be
automatically connected?
----------------------------------
SV 3.0 section 12.7.5, first paragraph:
Change "simulator is not required to report..." to "standard does not
require..." (I assume this rule applies to more than just simulators).
----------------------------------
SV 3.0 section 12.7.5, second paragraph:
Change "SystemVerilog will run this simulation..." to "SystemVerilog
shall..." (again, assuming this rule applies to more than just simulators).
----------------------------------
SV 3.0 section 12.7.5, third paragraph:
Change "Verilog run this simulation without warning..." to "shall now
generate a warning..." (again, assuming this rule applies to more than just
simulators).
----------------------------------
SV 3.0 section 12.7.5, fourth paragraph:
Change "Verilog simulators shall issue a warning..." to "shall result in a
warning..." (again, assuming this rule applies to more than just simulators).
----------------------------------
SV 3.0 section 13.1, fifth paragraph:
Change "modelling" to "modeling".
----------------------------------
SV 3.0 section 13.5.3, interface block:
The comments mention that import requires a full task prototype, and infer
that export does not require a prototype. These rules need to be specified
in normative text (examples are typically informative).
----------------------------------
SV 3.0 section A.2.1.2:
The word "identifier" should not be in bold text.
----------------------------------
SV 3.0 section A.2.2.1:
Superlog allows the signing to be specified either before or after the data
type keyword.
unsigned int foo; //C language style
int unsigned bar; //Verilog-2001 style
I think the C-style syntax was inadvertently dropped from the BNF when the
Superlog BNF donation was converted to the 1364-2001 style BNF. Having the
C language style declaration helps make SystemVerilog more intuitive to
C/C++ system designers. The Verilog style is more intuitive to Verilog
users, and backward compatible. Allowing both styles is a nice feature of
Superlog.
----------------------------------
SV 3.0 section A.6.1:
The continuous assign syntax does not allow logic or bit types. Section
5.6 says a logic type can also be used. I believe the bit type is allowed,
as well.
----------------------------------
SV 3.0 section A.6.2:
The initial, always, always_comb, always_latch and always_ff keywords
should be in bold.
----------------------------------
SV 3.0 section A.6.4:
The keyword "process" should be in bold.
----------------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland Sutherland HDL Inc.
stuart@sutherland-hdl.com 22805 SW 92nd Place
phone: 503-692-0898 Tualatin, OR 97062
www.sutherland-hdl.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2b28 : Fri Dec 06 2002 - 16:40:51 PST