Re: [sv-ec] Cliff's 1308 email No-vote - See attached example

From: Clifford E. Cummings <cliffc_at_.....>
Date: Thu Mar 30 2006 - 12:42:07 PST
Thanks to both Gord and Dave for responding. Whenever I put an 
example on the reflector, I expect to be beat up - don't worry, I can 
take it and I would much rather remedy my misconceptions that sit and 
train in ignorance.

More below.

At 01:54 PM 3/28/2006, Gordon Vreugdenhil wrote:

>Cliff,
>
>I don't think we want to make this as long and tedious a
>description as all the ISO/ANSI C++ rules - you might
>want to look at that if you really want to get confused. :-)
>
>We are following "normal" OO rules here -- virtual methods
>with static property binding in the methods.  I think that
>some of your questions are based on not having a completely
>correct understanding of normal OO binding rules.

True, but I'm not sure how many SV LRM readers have a completely 
correct understanding of normal OO binding rules.

My brother-in-law is a programmer for Boeing. I asked him how much he 
uses virtual methods in his C++ and Java programming. He said, "not much."

So far what I gather from OO programmers is that they are very 
familiar with classes and extensions, but not generally as familiar 
with virtuals so I want to make sure we have sufficient detail in the 
spec for HDL coders to understand the important details. I don't want 
to go ISO/ANSI overboard but some clarification is in order.

If I understand OO correctly, most OO programmers do not want default 
visibility of class properties from outside the class, but 
SystemVerilog takes the opposite view and the VMM relies heavily on 
this visibility for verification strategies. I am still waiting to 
hear how SystemVerilog coders intend to use "local" and "private" 
given these circumstances. When I first started using SystemVerilog 
classes, I found it strange that I could do $display and even 
manipulate the object.properties from an external initial block in 
true Verilog hierarchical fashion.

>See below for [Gord -- ...] for corrections to your
>expected output.
>
>
>
>Clifford E. Cummings wrote:
>
>>Cliff votes NO on the 1308 proposal as is. Friendly(?) amendments 
>>pending (to be proposed by Cliff)
>>Reason - not yet clear enough. I will propose additional 
>>clarifications to Dave's greatly-improved-wording after I 
>>understand the following example. In the following example, there 
>>are two levels of extension and an interesting mixture of virtual 
>>and non-virtual methods. Please examine the (untested) example 
>>(shown below and attached) and let me know if my reasoning is 
>>correct or not. The output lines with ??? are where I am most unsure.
>>Regards - Cliff
>>module virtualmenthods;
>>   //-------------------------------------------------------------
>>   class BasePacket;
>>     int A = 1;
>>     int B = 2;
>>     int C = 3;
>>     function void printA;
>>       $display("BasePacket::A is %d",A);
>>     endfunction : printA
>>     virtual function void printB;
>>       $display("BasePacket::B is %d",B);
>>     endfunction : printB
>>     virtual function void printC;
>>       $display("BasePacket::C is %d",C);
>>     endfunction : printC
>>   endclass : BasePacket
>>   //-------------------------------------------------------------
>>   class MyPacket1 extends BasePacket;
>>     int A = 4;
>>     int B = 5;
>>     int C = 6;
>>     function void printA;
>>       $display("MyPacket1::A  is %d",A);
>>     endfunction : printA
>>     function void printB;
>>       $display("MyPacket1::B  is %d",B);
>>     endfunction : printB
>>     virtual function void printC;
>>       $display("MyPacket1::C  is %d",C);
>>     endfunction : printC
>>   endclass : MyPacket1
>>   //-------------------------------------------------------------
>>   class ExtPacket extends MyPacket1;
>>     int A = 7;
>>     int B = 8;
>>     int C = 9;
>
>
>[Gord -- "C" here is useless; it will not be used by any method;
>          bind is NOT dynamic.  A method declaration (virtual or not)
>          binds to the member visible at the level of hierarchy
>          of the declaration.  Only methods are virtual -- I think
>          you are viewing the property as virtual as well.
>]

Thanks. I was wondering if calling the MyPacket1 method from 
ExtPacket would pick up a ref-like local definition of C. I guess 
that is dynamic (something I did not understand).

>>     function void printA;
>>       $display("ExtPacket::A  is %d",A);
>>     endfunction : printA
>>     virtual function void printB;
>>       $display("ExtPacket::B  is %d",B);
>>     endfunction : printB
>>     // No printC function in ExtPacket
>>     // Inherit printC from MyPacket1
>>   endclass : ExtPacket
>>   //-------------------------------------------------------------
>>   BasePacket P1 = new;
>>   MyPacket1  P2 = new;
>>   ExtPacket  P3 = new;
>>   initial begin
>>     P1.printA; // displays 'BasePacket::A is 1'
>>     P1.printB; // displays 'BasePacket::B is 2'
>>     P1.printC; // displays 'BasePacket::C is 3'
>>     //-----------------------------------------------------------
>>     P1 = P2; // P1 has a handle to a MyPacket1 object
>>     P1.printA; // displays 'BasePacket::A is 1'
>>     P1.printB; // displays 'MyPacket1::B  is 5' - latest derived method
>>     P1.printC; // displays 'MyPacket1::C  is 6' - latest derived method
>>     P2.printA; // displays 'MyPacket1::A  is 4'
>>     P2.printB; // displays 'MyPacket1::B  is 5'
>>     P2.printC; // displays 'MyPacket1::C  is 6'
>>     //-----------------------------------------------------------
>>     P1 = P3; // P1 has a handle to an ExtPacket object
>>     P2 = P3; // P2 has a handle to an ExtPacket object
>>     P1.printA; // displays 'BasePacket::A is 1'
>>     P1.printB; // displays 'ExtPacket::B  is 8' - ???
>
>[Gord - yes.]
>
>>     P1.printC; // displays 'MyPacket1::C  is 9' - ???
>
>[Gord - no.  printC in object P3 (referenced by P1) is
>         a virtual method defined in class MyPacket1 which
>         is the "latest" override.  The "C" that is
>         visible to that method is the one in MyPacket1
>         with the value 6.
>]

Acknowledged.

>>     P2.printA; // displays 'MyPacket1::A  is 4'
>>     P2.printB; // displays 'ExtPacket::B  is 8' - ??? (virtual again???)
>
>[Gord - I don't know what you mean by "again".  printB is *always*
>         virtual since the root of the hierarchy declared it as
>         virtual.  So, yes, the output you give is correct but
>         possibly from faulty reasoning
>]

Yes - I had faulty reasoning here. Thanks. After I read the 
explanation, I realized that I had forgotten about once-virtual, 
always-virtual. Seems like a good coding guideline would be to 
override virtual methods with another mothod declared as virtual, 
even though it is not required.

>>     P2.printC; // displays 'MyPacket1::C  is 9' - ??? (9???)
>
>[Gord - no.  You get the value 6 for the same reason as above. ]
>
>>     P3.printA; // displays 'ExtPacket::A  is 7'
>>     P3.printB; // displays 'ExtPacket::B  is 8'
>>     P3.printC; // displays 'MyPacket1::C  is 9' - ??? (9???)
>
>[Gord - no.  Same reason again]
>
>
>
>Gord

Thanks. I sometimes through these examples out to see if all the EDA 
vendors are in agreement with the responses. I hope that someone from 
Synopsys and Cadence also read the responses and agrees with the 
explanation (it seems to make sense to me now).

Regards - Cliff



>>     //-----------------------------------------------------------
>>   end
>>endmodule
>
>--
>--------------------------------------------------------------------
>Gordon Vreugdenhil                                503-685-0808
>Model Technology (Mentor Graphics)                gordonv@model.com

----------------------------------------------------
Cliff Cummings - Sunburst Design, Inc.
14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
Phone: 503-641-8446 / FAX: 503-641-8486
cliffc@sunburst-design.com / www.sunburst-design.com
Expert Verilog, SystemVerilog, Synthesis and Verification Training
Received on Thu Mar 30 12:42:11 2006

This archive was generated by hypermail 2.1.8 : Thu Mar 30 2006 - 12:42:16 PST