Subject: RE: [sv-ec] Questions/Issues on classes
From: Jay Lawrence (lawrence@cadence.com)
Date: Wed Mar 12 2003 - 11:37:26 PST
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" < <mailto:lawrence@cadence.com>
lawrence@cadence.com>
To: "sv-ec" < <mailto:sv-ec@eda.org> 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
<mailto:lawrence@cadence.com> lawrence@cadence.com
===================================
This archive was generated by hypermail 2b28 : Wed Mar 12 2003 - 11:38:59 PST