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

Shalom,

SystemVerilog 3.0 changed the BNF to require zero or more behavioral statements, to remove the extraneous begin/end on the majority of bodies that contain more than one statement. 

In any case, in 1364 you could have

task foo;
begin
end
endtask

begin/end is a behavioral statement, but there is no code generated for it. The point is that looking inside the body of a task or function to see if there statements inside it would be a poor mechanism to state whether it has an implementation or not, and has no precedence in C++, Vera, or Java.

Dave


> -----Original Message-----
> From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
> Sent: Sunday, February 05, 2006 2:38 AM
> To: Warmke, Doug; Ambar Sarkar; Rich, Dave; sv-ec@eda.org
> Cc: Mehdi Mohtashemi
> Subject: 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
>