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

Hi Eugene,

It appears to me that virtual methods give sufficient functionality for
achieving the goals that you have outlined. The only additional item that is
missing is a set of coding guidelines stating that all class methods should be
virtual unless there is a very good reason to not declare them to be virtual.
That creates the opportunity for others to define new behavior without having
to go back and touch the base classes. One obvious use of having the ability to
change behavior like this is the process of creating error conditions. As
already stated by others, it is difficult to foresee all possible uses of a
base class, so the liberal use of virtual methods is recommended.

Neil

eugene zhang wrote:
> Ray,
>
> Both of them achieve the similar goal, just that 'virtual' requires
> anticipation, which is far-fetching
> In writing verification code ( parent ) to anticipate someday, by
> someone, it could be used in extended
> Way. While 'overwrite' can be a complete afterthought. Mike's email
> mentioned some other benefits also.
>
> The bottom line, verification projects are not quite close to a big
> software project in term of OOP. We
> Think 'overwrite' better reflects that reality.
>
> -Eugene
>
> -----Original Message-----
> From: Ryan, Ray [mailto:Ray_Ryan@mentorg.com]
> Sent: Wednesday, September 01, 2004 4:24 PM
> To: Michael Burns; eugene zhang; sv-ec@eda.org
> Subject: RE: [sv-ec] Jeda SV-Errata: #14 class method overwrite
>
>
> Eugene, Michael,
>
> As I understand virtual methods, if 'foo' is declared to be virtual I
> believe you should get what you want. That is:
>
> class parent;
> virtual task foo;
> $display( "parent foo called foo" ) ;
> endtask
>
> task bar;
> foo;
> endtask
> endclass // end of class parent
>
> class child extends parent;
> task foo ;
> $display( "child foo called in child\n" ) ;
> endtask
>
> task method_1 ;
> foo();
> bar();
> endtask
> endclass
>
> child c1 = new;
>
> c1.foo; // this should display "child foo called in child"
> c1.bar; // this should also display "child foo called in child"
> c1.method_1; // "child foo called in child" repeated twice
>
> -------
> If 'foo' is not declared as 'virtual' in the base class, then a child
> class should NOT be allowed to override the method in the base class.
>
> - Ray Ryan
>
>
>
>>-----Original Message-----
>>From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On
>>Behalf Of Michael Burns
>>Sent: Wednesday, September 01, 2004 1:02 PM
>>To: eugene zhang
>>Cc: 'Michael Burns'; sv-ec@eda.org
>>Subject: Re: [sv-ec] Jeda SV-Errata: #14 class method overwrite
>>
>>
>>Hi Eugene,
>>
>>I agree that this feature would help in any context where the
>>user can't change the base class code, and that such contexts
>>exist in the real world. This does in fact solve the problem.
>> I just don't know if it's implementable, or if it's the best
>>solution to the problem.
>>
>>Does anyone with more detailed knowledge of separate
>>compilation have any comments on the implementability of this
>>proposal?
>>
>>Since the overwriting definition only applies to the
>>overwriting class (and presumably its sub-children), I'm not
>>concerned about the perilousness of the proposal; however,
>>I'm concerned that we'd be adding
>> complexity (and another keyword) to the language to address
>>an obscure problem. I'd expect, when using 3rd party VIP,
>>that users would need to make bug fix/enhancement requests to
>>the VIP providers as a normal part of business; if one user
>>wants a method changed to virtual, chances are other
>>customers would like that changed to virtual as well. In this
>>case, why not just request that the VIP provider (who could
>>be either an outside vendor or another in-house group) change
>>the base class? There will likely be a wide variety of base
>>class changes a users will want, and this proposal only
>>addresses one very specific change.
>>
>>Freescale currently uses this model internally; my group
>>provides a base-class library (implemented in another
>>language) for use by all Freescale testbench developers, and
>>this is the kind of thing that users submit help tickets for.
>>We would not want clients of the base class library to make
>>such changes thenselves; if there's a problem requiring such
>>a change, we'd definitely want to know about it!
>>
>>Of course, there are cases where, due to code freezes, time
>>constraints, unresponsive VIP providers, or whatever, a user
>>would want to be able to do the fix himself, and do it right
>>away. For these tactical short-term cases, there's always
>>copy-and-hack :)
>>
>>Mike
>>
>>
>>eugene zhang wrote:
>>
>>
>>>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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>
>

-- 
---------------------------------------------------------------------
Neil Korpusik                                     Tel: 408-720-4852
Member of Technical Staff                         Fax: 408-720-4850
Frontend Technologies - ASICs & Processors (FTAP)
Sun Microsystems
email: neil.korpusik@sun.com
---------------------------------------------------------------------