Subject: Re: [sv-ec] Questions/Issues on classes
From: Arturo Salz (Arturo.Salz@synopsys.com)
Date: Wed Mar 12 2003 - 12:04:05 PST
Message> The "parameter" declaration issue came from the new Verilog 2001 parameter list mechanism as opposed to the older method.
Yes, but in the case of parameterized classes, the in-line syntax makes a lot more sense since classes are not likely to contain as many parameters as modules, and this syntax is much closer to the one used by C++ templates :
template <class parameter> class name ...
or Java generics:
class name <parameter> ...
Thus, it is evident from the class header declaration that the class is parameterized.
Arturo
----- Original Message -----
From: Jay Lawrence
To: Arturo Salz ; sv-ec
Sent: Wednesday, March 12, 2003 11:37 AM
Subject: RE: [sv-ec] Questions/Issues on classes
See, I knew that wouldn't take long. Thanks for the response.
The "parameter" declaration issue came from the new Verilog 2001 parameter list mechanism as opposed to the older method.
Jay
===================================
Jay Lawrence
Architect - Functional Verification
Cadence Design Systems, Inc.
(978) 262-6294
lawrence@cadence.com
===================================
-----Original Message-----
From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]
Sent: Wednesday, March 12, 2003 2:20 PM
To: Jay Lawrence; sv-ec
Subject: Re: [sv-ec] Questions/Issues on classes
Jay,
My comments are interspersed below in blue.
Arturo
----- Original Message -----
From: "Jay Lawrence" <lawrence@cadence.com>
To: "sv-ec" <sv-ec@eda.org>
Sent: Wednesday, March 12, 2003 4:57 AM
Subject: [sv-ec] Questions/Issues on classes
In the process of trying to write some examples of classes I found the
following other nitty-picking problems with the current class
definition that should be fixed and should be a quick vote or
explanation.
-------------------------------
Declaration of class parameters
-------------------------------
The current syntax for class parameters in the examples is
class Foo_c #(parameter type p_t);
...
endclass
This should be changed to be like module, interface, and program
parameters:
class Foo_c;
parameter type p_t;
...
endclass
The current syntax for class parameters IS the same as for modules and interfaces.
The examples use the same synatx as shown in section 18.6 (parametrized interfaces)
and section 19 (Parameters).
---------------------------
Declaration of 'new' method
---------------------------
None of the examples show a type on the declaration of the "new" method
class Foo_c;
function new;
enclass
Is this OK or should we require/allow a type?
class Foo_c;
function Foo_c new;
endclass
The current syntax is intentional. The new method is the object constructor, not
the object allocator. We could have chosen "function void" which would be more
semantically appropriate (the constructor doesn't return a value, it only initializes
the object). However, new is called as a function (it invokes the allocator which
calls the constructor) so the declaration as a function is less confusing. C++ also
uses special grammar for the declaration of constructors (it mandates no function
return type, not even void) so SV's usage of new is consistent with that approach.
-----------------------------
Setting return value from new
-----------------------------
Is the "new" method allowed/required to set the return value?
None of the examples show it.
class Foo_c;
function new;
begin
...
new = this;
endfunction
endclass
See the comments above.
In particular the statement "new = this;" is unnecessary (and illegal).
----------------------------
Sensitivity of class objects
----------------------------
Will a change on the value of 'x' or 'x.i' wake up the following event
control?
class C;
int i;
endclass
C x;
...
@(x)
...
The donation explicitly disallows waiting on an object handle (this is
documented in section 12.9:
"The variables variable1,..., variableN can be any one of the integral data types
(see section 3.3.1) or string. Each variable may be either a simple variable, or a var
parameter (variable passed by reference) or a member of an array, associative-array,
or object (class) of the aforementioned types. Objects (handles) are not allowed."
The reason why this is not allowed is to avoid the ambiguity raised by
the statement above. There is no construct to wait for all of the elements of
a class, but it can be written explicitly as @(x.a , x.b, x.c, ... ).
Currently, the statement @(x) is illegal. If that were to be allowed, I would
suggest that the consistent interpretation must be to wait for the handle to
change and not the object's contents. Currently @ cannot be used to wait for
agregates (unpacked structs and unpacked arrays), so not being able to wait
on the object's contents is consistent with that usage. There are obvious
performance reasons why that is not cirrently allowed.
[ As an aside, section 12.9 needs to be reconciled with 8.9. $wait_var should
be removed, and it's functionality folded into the event control ]
===================================
Jay Lawrence
Architect - Functional Verification
Cadence Design Systems, Inc.
(978) 262-6294
lawrence@cadence.com
===================================
This archive was generated by hypermail 2b28 : Wed Mar 12 2003 - 12:03:06 PST