Subject: Re: SystemVerilog draft4 - PRELIMINARY
From: Adam Krolnik (krolnik@lsil.com)
Date: Tue Mar 05 2002 - 14:47:40 PST
Hi Stuart;
I have not had a chance to review the previous documents before. So my
comments may cover what others have said. Some of the comments are
also about the necessity of an element. The text does not really go into
detail about some elements, which this makes me wonder why this element
is included and necessary.
Section 3.7 The last typedef
There is a comment 'anonymous union'. You really are meaning that this
is an
anonymous type.
The paragraph beginning with "A structure can be assigned..." The last
sentence
brings up an array of variable size . Could there be a reference to how
one
creates an array of variable size?
Section 5.3 "Constants"
Would the document talk about when one would use a constant type vs. a
localparameter?
Or maybe a contrast of the two would be informative (like other sections
do.)
Section 6.1 "Attributes"
The sentence starts with "The default type of an attribute with no value
is bit..."
Why are you creating a type to a typeless element? Are you creating
methods to
access this information that would necessitate a type? Could you provide
a description of the new elements that will have attributes - or is this
list going to be from
the BNF box?
Section 7.1 "Introduction"
It would be good to explain the example so that people learning this
will understand.
7.3 "Assignment, incrementor and decrementor operations"
The example here in the text:
if ((a=b)) b = (a+=1);
Is a good exmaple against assignments within expressions. I will
definitely ask
lint tools to check for and warn against this practice. There are just
too many
times where people mistype and get an assignment instead. The idea of
requiring
parenthesis around this would be okay, except for the groups of people
that
'parenthesize when in doubt'. This is the group that will use
parenthesis
because they are worried that the operator precedence rules are not
correct
for what they expect in their code.
Another example is later in the event section:
@(a = b + c)
Section 7.4 "Operations on logic and bit types"
The first example looks odd:
a( ) || b ( );
a( ) && b( );
At first glance it does not look like A and B are functions. Maybe
stating this
would help, maybe removing some of the spaces would help also.
a() || b();
a() && b();
Section 7.9 "Concatenation"
The sentence "The following examples may give warnings of size
mismatch:"
I would be nice to explain how one would suppress these warnings. When
warnings
are not dealt with (fixed or suppressed) and they are common, then they
become
informational messages.
In the second example set, one should point out that these are unpacked
(maybe
reference the packed/unpacked section.)
Also, a size mismatch warning may/should be given in the line:
int unpackedints [1:0] = {1'b1, 1'b1};
Because one is only asking for a single bit value to be assigned to a
multiple
bit element. I do not necessarily require this kind of warning because
this
is a very common and harmless coding style.
Section 8.3 "Selection statements"
The sentence "If either keyword is used, it is a run-time warning for no
condition to match unless there is an explicit else."
I recommend that a run-time error be issued instead of a warning. If you
are
truly pointing out a functional problem, issuing a warning is not the
correct
course of action. Simulations do not stop for warnings and people (and
tools)
ignore warnings. What one would need for this to be effective is the
following:
1. Report an error.
2. Provide a method for detecting this error so that one can determine
if they
want to terminate the simulation, continue on, etc.
Of course, some people will want to be able to suppress the error. This
is where
#2 comes in, or having the ability to switch the error to a warning
within the tool.
The same recommendation should be applied to unique and priority case
structures.
Warnings will (almost) always be ignored.
8.5 "Loop statements"
Did one consider using 'repeat' instead of the 'do' keyword. When we
were developing
the IEEE1364-2001 standard, there was the repeated direction to
introduce as few
new keywords as possible. This keyword 'do' would only be used in this
construct.
Section 8.8 "Processes"
It appears that introducing the dynamic process creation in this section
does not
fit since all that is done is to name this language element and then
refer to
another section for its description and everything else. Maybe this
section
should be named 'Static processes' instead and a reference to dynamic
processes
be inserted.
Section 8.10 "Delay and event control"
The description of the differences between @(myvar) and @(changed myvar)
would
best be shown in a list form rather than embedded in a paragraph.
@(changed myvar) vs. @(myvar)
o changed defines a change on the result of the expression.
o @(expression) may change on changes to operands of the expression.
Section 9 FSM's
skipped for now...
Section 10 "Processes"
The second sentence of the second paragraph:
"However it is missing a case statement for multiplexors and there is no
name
for the driving value if the wire has multiple drivers."
There is no supporting text for this statement within this section. Is
there a
something missing?
Regarding the editors note - does one have a need for an autonomous
block construct
that is atomic?
Section 10.2 "Static process labels"
The examples shown here introduce the static process label, but give no
support for code that will use the label. I would like to see how one
would need
to use this label. Without this example, I don't quite understand how
these
are different/better than named blocks (with the exception that they
require
a little less typing.)
Section 10.3 "Level sensitive logic"
The second bullet of the always_comb comparison to @* says:
always_comb is sensitive to changes within the contents of a function
whereas
@* is only sensitive to the changes to the arguments of the function.
I would argue that this is bad form. An example is this:
function [3:0] bad_code;
input [3:0] offset;
bad_code = offset + base;
endfunction
...
wire [3:0] the_offset = ...
wire [3:0] mynewval = bad_code(the_offset);
I would not recommend that people write code in this form because it
obscures the
actual state used in the function. We actually had this kind of error
occur in
our designs. It was found because the correct value was not obtained
when the
signal not part of the function interface was changed.
Could you provide an example where one would want to do this?
Section 10.7 "Dynamic processes"
Why is there no mechanism to disable a dynamic process? What would
happen if
I did this?
task monitorBus (input int data);
process the_monitor: forever @strobe $display("data %h", data);
endtask
...
begin
monitorBus(asig); //
...
disable the_monitor;
...
Aside from the "the syntax does not allow for a process label" answer,
isn't it
a little incomplete to provide dynamic processes (like unix/OS's do) and
not
provide the facility to kill -9 <id> them?
Could you explain the example (task monitorBus), what it does and why?
It may be advantageous to provide a simple example that is a little more
obvious as the usefulness of a dynamic process.
Section 11.3 "Function"
Why allow a function to not have any direction specification for it's
inputs.
I wouldn't be put out for having to insert the word 'input' in the
provided
example.
Why does SystemVerilog allow void functions? Why not call them tasks
since that
is what they are? Why should we move to the C model where tasks and
functions are
one in the same?
Section 12.2 "The $root top level"
The second paragraph says, "SystemVerilog requires an elaboration
phase...
and the order of elaboration must be defined."
It would appear that this paragraph is beginning the discussion of the
definition
of the order of elaboration. Is this going to be discussed here? Is
there
a difference from the verilog 2001 elaboration algorithm that needs to
be
discussed somewhere?
Not only does there need to be an example on the use of $root, but also
a discussion
about the elements in the $root, abilities within $root, etc. There is
very little
discussion about $root in the entire document.
The section discussing the differences between $root and modules
includes this
bullet in the module section:
Section 12.5 "Port declarations"
The second example module (mh) uses an uncommon construct of verilog
that is rarely
seen:
module mh (input .in(w[0]), output .out(w[1]));
Does this example provide any benefit to systemVerilog? A project I was
on tried
unsuccessfully to utilize this construct but was unable to get this kind
of code
through the set of verilog tools that they had. This is a construct that
I would
put on the deprecation list.
Section 12.9 "Port connection rules"
The second bullet list, first bullet:
"An unput can be connected to any expression... If unconnected it has
the
value 'z"
Really? I thought inputs had the value 'x when not connected.
Section 12.11 "Hierarchical names"
Second sentence, "The consist of instance names separated by dots..."
Hierarchical names may use the module name in addition to an instance
name.
An example of this is where one references their module name and then
a particular instance within the module.
Section 13.2 "Interface Syntax"
The interface declaration syntax shown ends with [: <name>]
Should this really be 'indentifier'? It is shown in the example that is
said, "The simplest for of a SystemVerilog interface", yet it is
optional.
You may want to explain what it is (though I do know, reading farther
that
it provides better error detection.
There needs to be more discussion about interfaces and their ability.
Reading
the text, I am hit with one after another example of what you can do
without
a roadmap of where these examples are going. I am left trying to compare
example
after example to see what this one introduced that the other did not
have.
Section 13.2.3 "Interface example using a generic bundle"
Second memMod definition, the previous sentence says:
"An implicit port cannot be used to connect to a generic interface. A
named
port must be used to connect..."
Why? Implicit ports simply connect like-named things to each other. Why
does
a particular type get exceptioned?
continued next mailing...
Adam Krolnik
Verification Mgr.
LSI Logic Corp.
Plano TX. 75074
This archive was generated by hypermail 2b28 : Tue Mar 05 2002 - 14:48:57 PST