Subject: [sv-ec] testbench review comments from chapter 3 through chapter 11 (included)
From: Francoise Martinolle (fm@cadence.com)
Date: Mon Dec 16 2002 - 09:38:18 PST
I will be sending another email of comments for the remaining chapter (12 through 23) later today.
Chapter 3:
section 3.10.2:enumeration type range.
I don't particular like this. I think this type of name substitution is foreign to Verilog, we should not add
such a feature which usefulness is really limited. Then the next thing we will want is other
substitution capabilities. Moreover this syntax overlaps with part selects
and array definitions.
I don't see this very useful except for reducing typing.
I would like to remove this to leave the language clean.
section 3.10.3: typo: first paragraph "enumerate type"
section 3.10.5:
The only operators that are listed are ++enum, --enum, enum+= and enum-=
what about enum++ and enum--? They are in SV 3.0.
add to the note that enumvar += 5 is different from enumvar = enumvar + 5
only in the case where the integer values of the enumeration type are not contiguous
enumvar += <number> will always get a value which lays in the enumeration type range
while enumvar + 5 may not lay in the enumeration type range and may generate
a type check error.
section 3.14:
when using the $cast task, an illegal assignment causes a fatal runtime error.
When using the function $cast, an illegal assignment does not cause an error and the destination
variable is set to its uninitialized value.
Why setting it back to its un-initialized value, just specify that the value is of the variable is unchanged.
Why defining both a task and a function?
Let's just say that only a $cast function is defined and if used as a statement (the int return type is
ignored) and it operates as a task (runtime fatal error if illegal assignment) and if used in an
expression it operates as a function (no error generated). This would be consistent with
system Verilog definition which states that a function can be used as
a statement and the return type is ignored.
It does not seem necessary to declare both a function and a task for $cast.
Just pass a additional parameter to indicate whether or not a runtime error should
occur and to change the function behaviour.
----------------------------------------------------------------------------------------------------------------------------------
Chapter 4:
section 4.2:
change "object handles" to class object handles
short hand notation: nice but can be confused with bit selects
is only for one way direction. [8] means [7:0] and not [0:7]
If done it should be done globally for declaration of any ranges.
section 4.6: dynamic arrays
The CC committee is assuming to have multi-dimensional unconstrained
arrays. Check with the CC committee . This section along with the operators (new, size etc...) will need to be enhanced to support that requirement.
section 4.6.1: new operator. The syntax is inconsistent with the rest of the Verilog language.
new[100] looks like a bit select of an array.
Should use () instead of brackets because it is like
a built-in function. Or may be better should be $new()
would rather like a syntax such as $new(<alloc_number> {, <src_array>})
a = $new(100); allocates 10 array elements
a = $new(200, a); reallocates a with 200 elements
This syntax change preserves consistency in the way verilog uses system
functions.
on 4.6.1 the proposed syntax of the use of the "new" operator is inconsistent
with the rest of the Verilog language.
new [size] (src_address).
is it legal to write: a = new; Does it defaults to 1 element allocation?
what does it mean that if the size of src_array is greater than size, the additional elements
are ignored. Is the memory reclaimed?
similarly I would prefer if the size function is a system task $size
section 4.3.2: the size method is equivalent to $length(add, 1)
Again this adds more inconsistency to the syntax of SV.
Let's either define system tasks and functions or methods which can be
obtained on classes of objects.
For example on array type objects, the size and length methods would
be available. Usage would be addr.length(1) or addr.size
This is a general issue to be dealt with by the architectural committee that Vassilios
was thinking of...
section 4.7 and 4.8 : please define what are "compatible types" in a formal way. The definition is too loose.
for example are these compatible types?
logic b [8:1]
bit bb [8:1]
bit [8:1] bbb;
char bbb[1:1]
section 4.7 (end of section) :
dynamic allocation can also occur by initializing the dynamic array with string literals.
ex: string p [*};
p = {d[1:3], "hello", d[4:5]} ;
Isn't d[1:3] beyond what Verilog language allows for initialization of arrays? This will populate
the array p with the first 3 strins in array named d.
section 4.9.3 Class index:
"any other type is illegal and results in a compiler error"
Is it always possible to detect at compile time that the index is not compatible with the
declared class index? Or can this also be a runtime error?
int array_name [packet];
class packet
...
endclass
packet p;
p = new;
i = array_name [p]; // in that case it is determinable and it is legal
Consider the case where we have a sub-class subpacket
is this legal:
subpacket k;
k = new;
i = array_name[k]; // is this legal?
section 4.10.2: delete
why is this a task and not a function returning the success/failure of the deletion?
all other methods on the associative array are functions.
section 4.10.4: first, last, next, prev functions
These functions take an argument "index" declared as a var.
The index is passed by reference. Shouldn't it also be declared as an inout to be compliant with
SV 3.0 syntax? In SV, default mode type is input, this would mean that the
index passed as a var cannot be modified unless var is synonymous to var inout?
Who allocates the storage for the index value?
The var keyword is very often used by designs, why not use an operator such as & to indicate
passed by reference?
--------------------------------------------------------------------------------------------------------------------------------------------------------------
Chapter 7: Operators and expressions
section 7.3:
I believe that the bc committee decided to leave it unspecified at the 11/15 meeting.
I do agree with them. it is unspecified in ansi c, should be the same in verilog. Do not encourage
bad programming practices by allowing this.
-------------------------------------------------------------------------------------------------------------------------------------------------------------
Chapter 9: Processes
section 9.8: remove dynamic process since it is deprecated.
section 9.9.3: suspend_thread
does not specify how long is the thread suspended neither how to reactivate the thread.
explanation of the example is not clear.
---------------------------------------------------------------------------------------------------------------------------------------------------------------
Chapter 10: Tasks and functions
section 10.2 and 10.3: BNF needs update with respect to the " var " passing by reference mechanism and to
default values
section 10.3.2: assigning the function call to the void type??
I don't understand this:
void = some_function();
section 10.4:
needs syntax for the automatic attribute. is this a standard predefined attribute?
section 10.5.2: passed by reference
Why not using the C notation & to indicate passing by reference?
typo: "Not that in the example"
Needs to specify which classes of objects can be passed by reference and when the simulation semantics
will occur (i.e. propagation fanout).
section 10.5.3
is thislegal:
my_function ( int i,j,k =1 ); Are the default values of i, j also 1?
Chapter 11: Classes
section 11.8
typo in the example: we define fileid as a static integer in the class Packet, however following uses
semid (instead of fileid).
section 11.10
inconsistency or error in the use of new:
p2 = new p1
why not
p2 = new(p1);
The notation above will match the dynamic allocation of dynamic arrays: arr = new(src_array);
"new" is a function and should always require the ().
section 11.16 Data hiding and encapsulation
local is the keyword used to mean private data
Why not stay with C++ and use private?
section 11.19 out of block declaration
The syntax class_name:: function_name to describe a function outside of its class is
not very verilog-like. Why not keeping the out of module syntax with the . like it is currently
used in Verilog to refer to an out of scope reference. class_name.function_name
The function name being defined as an extern in the class definition.
section 11.21 typedef
I think this was decided to be removed by the BC committee. I send out the question to
the bc reflector.
section 11.22 class, structs and unions comparison
This section attempts to explain why we need classes and structs as 2 different data types.
It provides the following arguments:
a) structs are static while classes are dynamically allocated
b) classes are strongly typed while structs are not.
c) classes provide pointer like functionality, SV structs do not have the pointer capability
d) classes provide inheritance, polymorphism and dynamic casting
My answer to this is that structs are incomplete and not so useful in systemVerilog
if pointers are not defined; Therefore users will have to use classes in their design to model
lists, trees, etc... We need to be able to dynamically allocate structs.
I think we have 2 kinds of structs, the unpacked structs which are strongly typed
and the packed structs which are not so strongly typed (because they are just vectors of bits).
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
This archive was generated by hypermail 2b28 : Mon Dec 16 2002 - 09:39:14 PST