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

From: Warmke, Doug <doug_warmke_at_.....>
Date: Sat Feb 04 2006 - 08:51:05 PST
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.

 

Respectfully, 

-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

 

 
Received on Sat Feb 4 08:51:24 2006

This archive was generated by hypermail 2.1.8 : Sat Feb 04 2006 - 08:53:40 PST