Subject: Re: SystemVerilog draft4 - PRELIMINARY
From: Peter Flake (flake@co-design.com)
Date: Sun Mar 10 2002 - 19:48:43 PST
Hi Adam,
At 04:47 PM 3/5/02 -0600, Adam Krolnik wrote:
>Section 3.7 The last typedef
>
>There is a comment 'anonymous union'. You really are meaning that this
>is an anonymous type.
I agree.
>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?
This is should have been removed. SUPERLOG allows variable size arrays for
testbenches, but SystemVerilog is aimed at synthesis and does not.
>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.)
The distinction is that a localparameter must be set during elaboration,
whereas a constant can be set during simulation, e.g. in an automatic task.
>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?
The thinking was that attributes in general have data types, so what should
the default be? It could be bit or void. The Verilog 2001 spec says that
if no value is specified then its default value is 1, which fits 'bit'.
>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.
This should be a tool feature.
>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.
The problem with using repeat is that it is ambiguous if a statement can
begin with an expression in parentheses.
This is not important in SystemVerilog but it is in SUPERLOG.
>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 something missing?
I think this is a leftover sentence that should have been removed.
>Regarding the editors note - does one have a need for an autonomous
>block construct that is atomic?
We can probably limit the requirement to ensuring that execution of a
single statement (not a block) containing no user task or function call is
uninterrupted. This allows atomic test-and-set using assignment operators
in an if statement.
>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.)
The label can be used by a disable. In fact this is just an example of the
syntax rule that any statement can be labeled.
This can also be used for assertions.
>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?
This was actually a user request. The need is to partition very large
combinational blocks containing repeated code.
To make sure the result is always correct, mynewval should be sensitive to
changes in base.
>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?
The syntax allows any statement to have a label - in this case the forever
loop.
The "disable monitorBus.the_monitor" statement should kill all instances of
the process.
This is more of a testbench action, and not likely to be synthesizable.
>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.
Yes, the example will print the same value each time, so a better one
should be provided e.g.
task monitorMem(input int address);
process forever @strobe $display("address %h data %h",
mem[address] );
endtask
This can be launched to display a selected location at every strobe.
>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.
It would break existing Verilog.
>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?
Void functions are not tasks because they cannot take time.
C has no timing controls and so does not have this distinction.
>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 BNF at the end shows what can be put in $root, but more explanation
would be good.
>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.
If the project tried to use it, does that not mean that the users liked it?
>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.
This may be an area of differences between tools.
>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.
Agreed.
>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.
Yes, it should be identifier.
>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.
The aim of interfaces is to encapsulate communication. At the lower level,
this means bundling variables and wires in interfaces, and bundling ports
with directions in modports. The modules can be made generic so that the
interfaces can be changed. The first examples show these features.
At the higher level, communication is by tasks and functions. Interfaces
can include task and function definitions, or just task and function
prototypes with the definition in one module (server/ slave) and the call
in another (client/ master).
>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?
Good point.
Peter.
This archive was generated by hypermail 2b28 : Mon Mar 18 2002 - 08:05:13 PST