RE: [sv-ec] virtual methods issues - disable on virtual, virtual method with static life time

From: Rich, Dave <Dave_Rich_at_.....>
Date: Wed May 28 2008 - 05:57:45 PDT
> -----Original Message-----
> From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]
On
> Behalf Of Daniel Mlynek
> Sent: Wednesday, May 28, 2008 4:39 AM
> To: 'Steven Sharp'; sv-ec@server.eda.org
> Subject: RE: [sv-ec] virtual methods issues - disable on virtual,
virtual
> method with static life time
> 
> This answer rises lots of other similar issue
> 1. most important: Where does LRM states that:
> "Hierarchical references cannot be started with class handles. "
[DR] "22.6 Hierarchical Names" defines what components are used to
create valid hierarchical path references. Class handles are not, and
should not be, part of that definition.

>
> 2. What about implicit handles (this)
> class A;
> 	task t1;
> 	endtask
> 
> 	task t;
> 		disable t1;	// this is same as : disable this.t1 -
is it
> legal???
> 	endtask
> endclass
[DR] The current BNF definition of disable defines its argument in terms
of a static hierarchical path, so I would say that it disables all
active invocations of A::t. This form of disable is almost useless in a
class based environment. But now we have "return" to accomplish what
users usually want.
> 
> 3.What about <BASE_CLASS? References:
> Class B; task t; endtask endclass
> Class C extends B; task t; disable B::t; endtask
[DR] Again, this disables all invocations of B::t.
> 
> DANiel
> -----Original Message-----
> From: Steven Sharp [mailto:sharp@cadence.com]
> Sent: Tuesday, May 27, 2008 10:06 PM
> To: sv-ec@eda.org; daniel.mlynek@aldec.com
> Subject: Re: [sv-ec] virtual methods issues - disable on virtual,
virtual
> method with static life time
> 
> 
> >From: "Daniel Mlynek" <daniel.mlynek@aldec.com>
> 
> >Below code presents two issues of virtual methods - LRM does not
define
> >how it they should work . Description in comments
> >
> >class B;
> >     virtual task static   t(input i, output o);
> >        int y;
> >        o = i;
> >    endtask
> >endclass
> >
> >class A extends B;
> >     virtual  task static  t(input i, output o);
> >        int y;
> >        o = 2*i;
> >    endtask
> >endclass
> >
> >module top;
> >        B b;A a=new;
> >        initial  begin
> >            b=a;
> >            disable b.t; //which method would be disabled, does
disable
> >take polimorphism into account?
> >            b.t.i=10; //which method port would be assigned - does
such
> >assignment take polimorphism into account? ()
> >            b.t.y=10; //which method port would be assigned - does
such
> >assignment take polimorphism into account? ()
> >        end
> >endmodule
> 
> 
> I think the answer is that none of these 3 lines of code is legal, so
the
> question does not arise.
> 
> The later two are attempts to do hierarchical references to variables
in a
> scope.  Hierarchical references cannot be started with class handles.
> They
> must start with static hierarchy: an instance, block name or class
scope.
> You cannot refer to b.t.i; you must refer to B::t.i or A::t.i.  Since
you
> cannot use a class handle, the issue of polymorphism does not arise.
You
> must use a static class scope, which specifies exactly which task you
are
> referring to.
> 
> The disable statement also takes a hierarchical reference, to a scope.
> So again, it cannot start with a class handle.  It must start with
static
> hierarchy.  You would have to use B::t or A::t instead.
> 
> Steven Sharp
> sharp@cadence.com
> 
> 
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Wed May 28 05:58:20 2008

This archive was generated by hypermail 2.1.8 : Wed May 28 2008 - 05:59:00 PDT