3.12 Class
§ “An object can be declared as an argument of type input, output, inout, or, ref.“
§ input, outputs etc. are not types!
§
The comma after “or” is not needed.
4.2
Packed and unpacked array + 4.6 Dynamic array + 4.9 Associative arrays
§
Can an unpacked
array be declared with a basic type “dynamic array” etc.?
typedef int int_a
[8];
int_a k[];
int_a l[int];
typedef int
int_da [];
int_da m[8];
int_da n[];
int_da o[int];
typedef int int_aa
[int];
int_aa p[8];
int_aa q[];
int_aa r[int];
§
“SystemVerilog accepts
a single number (not a range) to specify the size of an unpacked array, like
C.”
§
Is this possible for unpacked arrays, only? Why
not for packed arrays?
5.3
Constants
· If a constant instance of a class references another object, can this object be changed?
10.5.2
·
If an instance
of a class (used as “const ref” parameter) references inside another object,
can this object be changed in the subroutine?
11.3
Overview + 17.10 The property definition
·
The term
“property” is introduced twice into SystemVerilog for two different things!!
11.7
Constructors
·
Semantic of the
following example should be defined.
class
A ;
integer j = 5;
function new();
j = 3;
endfunction
endclass
11.8
Class properties
·
It should be
mentioned that class properties can be used without any instance as in the
example from the LRM.
Packet p;
c = $fgetc(p.fileID );
11.9
Static methods
·
Different
semantic of “static task” and “task static” is very confusing.
11.18
Abstract classes
·
I suggest to
change the grammar that there is no “endfunction” in
the example:
virtual class BasePacket;
virtual protected function integer send(bit[31:0] data);
endfunction
endclass
11.18
Abstract classes
·
According to the
LRM, non-abstract classes can have virtual methods (which must have a body).
What is the difference to a “normal,” non-virtual methods? If there is none,
they are not needed. As I know now:
Virtual methods are a basic polymorphic construct. A virtual
method overrides a method in all the base classes, whereas a normal method only
overrides a method in that class and its descendants. One way to view this is
that there is only one implementation of a virtual method per class hierarchy,
and it is always the one in the latest derived class.
This
is a very important info and should be inserted in the LRM in any case!
11.20
Polymorphism
·
The method call
“send” in the example can not be used if it is assumed a method from the
example in 11.18 is called because they are protected. If there is no
connection between the examples of the subsections, then the classes must be
defined.
·
Otherwise, the
names of the classes are identical with the classes in the previous subsection.
In addition they all have the method “send”, so every reader would assume that
the used classes “BasePacket”, “EtherPacket”
are the classes defined in the subsection before. But here “send” is defined as
“protected”. So the only change, which is needed, is the removing of the
keyword “protected” in the declaration of “send” in 11.19.
11.22
Out-of-block declaration (please note the orthography)
·
The location,
where the out-of-block declarations have to be, must be declared.
12.5.2
Random Constraints
·
Only here the term
“overload” is used (twice). Does this means the same as “override”? Definition
is needed!!
13.2.1
new() (Semaphores)
·
One sensible
enhancement would be to define a maximal number of keys in the semaphores to avoid
programming mistakes, which can happen very easily (e.g., a process puts two
keys back instead of one so that two processes can get a key).
13.2.3 get() (Semaphores)
· “f the specified number of key are not available, the process blocks until the keys become available.”
·
It should be
defined, when exactly get() will continue after
blocking. In the same time step ….
14.2 Event simulation
·
Maybe, the
special handling of always_comb etc. should be
mentioned here.
14.3.1
The SystemVerilog simulation reference algorithm
·
Initialization
of consts are missing
·
What is the
initialization order in case of dependent initialization?
19.5.3
An example of exporting tasks and functions
·
The tasks Read
and Write are used (declared, defined, called) four times each. Sometimes they
have one parameter, sometimes none. I assume that the slave defines the tasks
and made them available via “export”. It seems, the
master want to use exactly these tasks because the tasks with parameters are
not defined in the interface, and in the master module (cpuMod),
the comment describes explicitly the use of the slave method--but the call is
made with a parameter!!