Subject: [sv-ec] testbench review comments and issues until chapter 7 (included)
From: Francoise Martinolle (fm@cadence.com)
Date: Fri Dec 06 2002 - 18:15:56 PST
I reviewed the testbench donation until chapter 7.
I expect to have more review comments and issues for the remaining chapters.
section 2.2 page 2 are comments compatible with SV Verilog?
I have not found a definition of comments in SV 3.0 except in the BNF.
can someone check?
section 26 page 7: header 2.6 for strings section is absent.
missing clarification that the default value of a uninitialized
string is null
Conflict: The SV 3.0 lrm (see annex A.8.8) says that the new line in a string
is not allowed. Vera says it is allowed if preceded by a backslash
section 2.8: the keyword program should be in bold
section 3.5: event can be passed to tasks; this is a change from SV 3.0. bnf in SV 3.0
needs to be updated
section 4.1: fixed size array
vera wants to allow short hand notation int a[8][10];as for int a[8:0][10:0];
inconsistent with Verilog language but nice short hand; this should be
reviewed by the bc committee and get their vote.
section 4.3: dynamic array
The CC committee is assuming to have multi-dimensional unconstrained
arrays. This section along with the operators (new, size etc...)
needs to be enhanced to support that requirement.
section 4.3.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 consistensy in the way verilog uses system
functions.
on 4.3.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...
page 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.4 page 18:
dynamic allocation can also occur by initializing the dynamic array with string literals.
ex: string p [*};
p = {d[1:3], "hello", d[4:5]}
Is this beyond what SV 3.0 allows?
section 4.6.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.7.2: delete
why is this a task and not a function returning the sucess/failure of the deletion?
all other methods on the associative array are functions.
section 4.7.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. Contrary to the semanctics of these functions since the index
content is expected to be modified by the function?
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 5 (enumerations)
enum Colors = {reb, blue, green)
Colors c;
initial
c = green;
c = 1; // illegal in testbench donation
if (c == 1) // legal in testbench donation
c++; => this goes out of range , not sure if it is legal in the testbench donation
endif
I am wondering if the assignment and comparison with the c variable are legal in system Verilog.
I cannot find anything in the SV lrm to indicate legal operations on enumeration typed objects
except for the sentence in section 3.6 which says" the type is checked in assignments,
arguments and relational operators (which check the value)."
page 24, 4th paragraph : typo enumerate type (should spell as enumerated type)
page 24: enumerated names defined by ranges
enumerated named defined by ranges such as sub[5] are not in SV 3.0
secondly, name[N:M] can either create a sequence of names incrementing or decrementing,
until reaching nameM.
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.
Question: what is the default value of a enumeration typed object? unspecified at present
in both SV and testbench
Example Colors c;
what is the value of c ?
section 5.1: enumeration values in assignments
Colors c;
integer a, b;
section 5.2 Dynamic casting.
In the SV 3.0 LRM, it looks like you can cast any variable of some type to another type,
you may loose part of the data when doing the assignment as part of the casting operation. (see section 3.8)
Usage is type_name ' (expression).
The testbench donation added $ task and function to determine a coercion of values by assigning to
variables of differing types.
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.
I think that the destination variable should retain its previous value rather than triggering
back to its un-initialized value.
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.
section 5.3
the only operators that are listed are ++enum, --enum, enum+= and enum-=
what about enum++ and enum--? They are in SV 3.0.
Chapter 6:
General comments:
1. we need to homogenize the way the new verilog language will deal with properties
of data types. For example System Verilog uses system tasks or functions to get the length
of an array, on the other hand testbench donation defines methods associated with data types
to get the properties of these data types. A great example of this is the string type and the
methods defined on that type:
len (length of the string) usage in testbench is str.len
System verilog define $length(array, 1); size of the first dimension of the array.
systemverilog also define $bits.
2. Changing the well known standard C string manipulation functions (such as
compare, toupper, atoi, putc, getc) to look like OO methods which do not take the same arguments
as the C functions looks strange to me. Verilog then looks more like C++.
example str. toupper();
str.putc(1, 'c') changes the first character of the string str with the character c.
Furthermore the string type is not defined as a class in the test bench donation
I think this is a major architectural changes which should be decided by the architectural committee
that Vassilios was talking of putting together. We want a conscious decision for moving Verilog in that
direction and we want this uniform ally across all the donations and across all the data types!
3. The string type does not map to C string which the cc committee needs the additional definition of
in SV
In C a string is terminated by \0 and its un initialized value is not "", its space needs to be allocated
explicitly unless defined statically by the assignment to a string literal.
I am assuming from the spec in the testbench donation that the new operator is used to
dynamically allocate a string. Am I correct?
The spec needs to explicitly state when and how deallocation of the space occupied by the
string happens. It is not clear.
The definition of the string type needs to be reconciled between EC and CC,
they need to be interoperable.
4. why having a string data type which is not defined as a predefinedd standard class with predefined methods?
Chapter 7: Classes
General comment:
I think the classes construct in testbench, interfaces construct in SV3.0, and structures should be reconciled
in 1 single construct. This would simplify the language.
The first 2 have the similar concepts of local, public variables. Interfaces can be hierarchically defined.
tasks and functions can be declared in interfaces. Interfaces also can optionally add directions for the ports.
Classes, interfaces and structs have structural data decomposition.
i am not sure if we need all the concepts of polymorphism, virtual functions etc in systemVerilog
We need to create some data types which have associated functions and tasks, and local
variables. I would prefer to provide some OO functionality but not all its sophistication.
however it would have to be sufficient for people to be able to write testbenches. This subset
needs to be defined.
This is another candidate for the architectural committee...
section 7.5
typo in the example: we define fileid as a static integer in the class Packet, however following uses
semid (instead of fileid).
section 7.7
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);
section 7.12:
typo "super keywors" instead of super keyword
section 7.13 Data hiding and encapsulation
local is the keyword used to mean private data
Why not stay with C++ and use private?
section 7.16 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 an an extern in the class definition.
section 7.17 typedef
I think this was decided to be removed by the BC committee. I send out the question to
the bc reflector.
section 7.18 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...
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).
If we added dynamic allocation to structures and pointers
we have a lot. I don't think we need all of C++.
This should be discussed in the architectural committee that Vassilios was talking about.
This is a fundamental concept which will be a determining factor for the adoption of the system
verilog by the users community.
Structs, pointers, classes and interfaces need to be reviewed all together.
That is all for now.
I will send out my comments on the remaining chapters as soon as I can.
Francoise
'
This archive was generated by hypermail 2b28 : Fri Dec 06 2002 - 18:16:30 PST