> -----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