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

Actually, I believe 1364 requires function bodies to contain a statement, as it is stated,

"Function inputs shall be declared one of two ways. The first method shall have the name of the function
followed by a semicolon. After the semicolon one or more input declarations optionally mixed with block
item declarations shall follow. After the function item declarations there shall be a behavioral statement and
then the endfunction keyword.

The second method shall have the name of the function, followed by an open parenthesis, and one or more
input declarations, separated by commas. After all the input declarations, there shall be a close parenthesis,
and a semicolon. After the semicolon, there shall be zero or more block item declarations, followed by a
behavioral statement, and then the endfunction keyword."

Shalom

________________________________________
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Warmke, Doug
Sent: Saturday, February 04, 2006 6:51 PM
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.

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.%a0 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