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 TrainingReceived 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