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

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
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> >
> >
>
Received on Wed Sep 1 17:09:14 2004