RE: [sv-ec] Jeda SV-Errata: #14 class method overwrite

Hi Mike,

From the language perspective, yes. However, from verification
application and user perspective,
It brings significance. I can share notes with you down the road listing
company culture A, B, C, D
And why this 'overwrite' feature help save verification pains.

Please educate me on how SV LRM addresss separate compiling ?

Your question is purely an implementation issue, the solution exists for
separate compiling under
This context.

Cheers,
-Eugene

-----Original Message-----
From: Michael Burns [mailto:Michael.Burns@freescale.com]
Sent: Wednesday, September 01, 2004 10:36 AM
To: eugene zhang
Cc: 'Michael Burns'; sv-ec@eda.org
Subject: Re: [sv-ec] Jeda SV-Errata: #14 class method overwrite

Thanks for the clarification; so, it sounds like the only thing this
does is to allow one to make a method virtual without adding the
"virtual" keyword to the parent class - is that right?

Wouldn't this cause a problem with separate compilation? If the parent
class was compiled in one compilation unit, the method call to foo() in
bar() would be bound at compile time - there would be no way for the
compiler to know that another compilation unit wanted to overwrite the
body of foo().

Mike

eugene zhang wrote:
> Hi Mike,
>
>
>>Do instances of the parent class also see the overwritten method?
>
> No
>
> Thanks for the feedback, the description is not clear and could be
> mis-leading. The overwrite takes effect only from an instance of a
> Child !!
>
> We will re-write the English and code example to make it clear.
>
> Why not simply use virtual method in parent here? Well, 'overwrite' is

> needed to reflect the real verification environment. Typically,
> parent class was done earlier, and child class is done later
> to leverage earlier work and by a different user. Using 'virtual',
one
> has to directly change the parent
> code ( adding 'virtual' to a method) which is typically owned by
> others.
>
> However, using 'overwrite' get around this problem, avoiding to change

> anything in legacy code ( parent). If the parent class is owned by a
> third party, the 'overwrite' advantage is even more compelling.
>
> Cheers,
> -Eugene
>
> -----Original Message-----
> From: Michael Burns [mailto:Michael.Burns@freescale.com]
> Sent: Tuesday, August 31, 2004 5:21 PM
> To: eugene zhang
> Cc: sv-ec@eda.org
> Subject: Re: [sv-ec] Jeda SV-Errata: #14 class method overwrite
>
>
>
> Hi Eugene,
>
> I have some questions about this proposal. Do instances of the parent
> class also see the overwritten method? How about instances of other
> child classes of parent (that do not themselves overwrite or override
> it)? What if two child classes try to overwrite the same parent
method?
> It seems to me that, if all that is desired is for instances of the
> overwriting class to see the new definition, that a virtual method
would
>
> work fine, even if the call chain goes through a method whose
> definition
>
> is in the parent. Exposing the overwritten definition to instances of
> other classes in the hierarchy (such as the parent or siblings) seems
> fraught with peril - a sibling class's code might start behaving
> differently, and finding out why would be a difficult task. Besides,
> the overwritten definition could refer to data members that only exist

> in the overwriting child class, thus making the overwritten definition

> meaningless for other class instances.
>
> Mike Burns
>
> eugene zhang wrote:
>
>
>>
>>
>>------------------------------------------------------------
>>function overwrite
>>------------------------------------------------------------
>>
>>problem statement:
>>The class construct in Section 11 of the SV 3.1a specification does
>>not provide a mechanism for a child class to redefine a function/task
>>defined in the parent class.
>>
>>
>>summary: A class function/task attribute, 'overwrite' provides a level
>
>
>>of flexibility of propagating changes to a redefined function/task
>>from the child class to the parent class
>>
>>description:
>>The "overwrite" function provide a level of flexibility beyond what's
>>been provided in the current SV specficiation. In developing
>>Verification code its literally impossible to develop classes that
>>anticipate all the future use of that particular class.
>>
>>Using inheritance one can extend the base class and redefine the
>>task/funciton in the child class but the parent class does not see the
>
>
>>change. The question then is, how is it possible to have the changes
>>made in the child class be reflected to the parent class is an easy
>>way? Using existing class constructs, this is not possible until we
>>define the new capability with the 'overwrite' construct.
>>
>>The following example will illustrate the challenge faced as described
>>above:
>>
>>class parent ;
>> function new();
>>
>> task foo ;
>> begin
>> $display( "parent foo called foo" ) ;
>> end
>> endtask
>>
>> task bar ;
>> begin
>> foo ;
>> end
>> endtask
>>
>> task bar1 ;
>> begin
>> foo ;
>> end
>> endtask
>>
>>endclass // end of class parent
>>
>>class child extends parent ;
>> task foo ;
>> begin
>> $display( "child foo called in child\n" ) ;
>> end
>> endtask
>>
>> task method_1 ;
>> begin
>> foo();
>> bar();
>> end
>> endtask
>>endclass
>>
>>When an instance of the child class calls bar(), the function will
>>refer to the definition of the task foo() from the parent class and
>>not the redefined foo() inside the child class. If a function is
>>redeclared with 'overwrite' attribute in the child class then the
>>change will also be visible to the parent class as follows:
>>
>>class child_a extends parent ;
>> overwrite task foo ;
>> begin
>> $display( "child foo called" ) ;
>> end
>> endtask
>>endclass
>>
>>This way, the functions bar() and bar1() in the parent class will use
>>the redefined task foo() from the child class.
>>
>>In using the 'overwrite' attribute on a function, the function
>>prototype both in the child and parent class have to be identical
>>otherwise a runtime error is reported.
>>
>>Additional information:
>>
>> BNF changes:
>>
>> method_qualifier::=
>> virtual
>> | class_item_qualifier
>>
>> is modified as
>> method_qualifier::=
>> virtual | overwrite
>> | class_item_qualifier
>>
>>Attached files:
>>None
>>
>>
>>
>>
>>
>
>
>
Received on Wed, 1 Sep 2004 12:06:35 -0700