RE: [sv-ec] Abstract classes and virtual methods

Doug,

 

Thanks for the pointer.

 

The problem I mention arises specifically because we are dealing with
inheritance which Verilog 1364 does not have. This convention might have
been fine for Verilog, but it is a new issue because of its new scope of
usage. A Verilog task/function is somewhat different in its nature compared
to that of a method defined for a class construct.

 

Also, having a function with empty body is different than no body being
defined. I would be fine with returning x's in the former case, but still
would expect some error in the latter. So I am not sure if your analogy
quite applies. 

 

Regards,

-Ambar

 

  _____  

From: Warmke, Doug [mailto:doug_warmke@mentor.com] 
Sent: Saturday, February 04, 2006 11:51 AM
To: Ambar Sarkar; Rich, Dave; sv-ec@eda.org
Cc: Mehdi Mohtashemi
Subject: RE: [sv-ec] Abstract classes and virtual methods

 

Ambar,

 

While your concerns certainly hit home, this behavior of functions with
empty bodies is

already present in 1364 Verilog. It's nothing new related to SystemVerilog
functions,

or class member functions.

 

Regards,

Doug

 

  _____  

From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Ambar
Sarkar
Sent: Saturday, February 04, 2006 4:51 AM
To: Rich, Dave; sv-ec@eda.org
Cc: 'Mehdi Mohtashemi'
Subject: RE: [sv-ec] Abstract classes and virtual methods

Dave,

 

I looked at related emails on this thread, and couldn't find one that
addresses the concern I have about the following note in your proposal: 

Note - A method without a statement body is still a legal, callable method.
For example, if the function send was declared as show below, it would have
an implementation:

virtual function integer send(bit[31:0] data); // Will return 'x

endfunction

 

I believe this is potentially quite confusing to the end user. Consider a
function that is supposed to return a sampled value. If someone forgot to
implement the body, or the runtime resolved to an unintended derived class,
the end user may not be able to determine whether the x's coming in are
because something wasn't implemented or because the testbench was really
sampling x's. This can be really frustrating if that person was using an
external, and possibly encrypted VIP and not be able to determine if an
implementation body actually exists.

 

I believe this should be a runtime error. Or more likely, I am missing some
subtle point.

 

I apologize if I am opening a can of worms and will appreciate if someone
can point out the justification behind this decision.

 

Resectfully, 

-Ambar

 

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Rich,
Dave
Sent: Saturday, February 04, 2006 3:49 AM
To: sv-ec@eda.org
Subject: RE: [sv-ec] Abstract classes and virtual methods

 

I have updated the proposal to incorporate the feedback from the email

reflector. http://www.eda.org/svdb/bug_view_page.php?bug_id=0001308.  I

have attached a version with markups from 1800 to this for your

convenience. 

 

There seems to be two remaining issues that need consensus.

 

1. What level of matching defaults is needed for virtual methods? The

current proposal only requires the presence of a default to match for

each argument, not their expressions. I think a matching expression is

unnecessary and not very useful.

 

2. The syntax for declaring a method without an implementation. The

current proposal reuses the syntax for out-of-class body, which is what

Vera does. Some have suggested that this might be visually ambiguous,

but I think since you have to mark the class as 'virtual', it is

unlikely that you will be providing out-of-class bodies at the same

time.

 

I may not be able to make most of Monday's meeting, but I think #2 is

very critical because a lot of class libraries are being written as this

very moment. Let's try to reach consensus on this issue via e-mail ASAP.

 

Thanks,

 

Dave

 

David Rich

Verification Technologist

Design Verification & Test Division

Mentor Graphics Corporation

dave_rich@mentor.com

Office:   408 487-7206

Cell:     510 589-2625