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
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
>
Received on Wed Sep 1 13:01:24 2004