Re: [sv-ec] interface classes and pre_randomize post_randomize

http://www.verilog.org/mantis/view.php?id=4914
W dniu 4/23/2014 5:17 PM, Tipp, Brandon P pisze:
> interface classes and pre_randomize post_randomize
>
> I agree that the behavior here is not at all intuitive.  The fact that 
> the built-in pre_randomize() and post_randomize() in (non-interface) 
> classes are not virtual, but appear to be virtual is a feature that 
> has been in the language for some time.  I’ll admit that this 
> particular point of interface classes was not scrutinized quite as 
> closely as many of the other features.
>
> I’m not sure that I see any reason to NOT mention that pre_randomize() 
> and post_randomize() from an interface class can be overridden.  I 
> think that it is worth opening a Mantis item to clarify the virtual 
> behavior of these methods in interface classes and clean up the 
> language with respect to interface classes.  I don’t think that we can 
> do much about the existing definition of pre_randomize() and 
> post_randomize() being non-virtual in a class, however the LRM may 
> have some wiggle room in it to clarify what it means for an interface 
> class.
>
> -Brandon
>
> *From:*Daniel Mlynek [mailto:danielm@aldec.com.pl]
> *Sent:* Tuesday, April 22, 2014 10:31 PM
> *To:* Tipp, Brandon P
> *Cc:* sv-ec@eda.org; Piotr Rozkoszek
> *Subject:* Re: [sv-ec] interface classes and pre_randomize post_randomize
>
> 1.
> The behaviour you are describing is in my opinion not intuitive but ok.
> This way virtuality of the pre/post_randomize depends of the fact if 
> class implements interface class. This may be a suprise for users. 
> Chapter about pre/post_randomize do not mention about such exception.
> Calling pre/post_randomize directly is not typical usage.
>
> 2. So what LRM means when saying "/These methods can be overridden"
> /I thought that it refers to overriding method in same class as in my 
> example./
> /if it refers to virtual method override in child class - then all 
> classes can be overriden in child class so why even mention about it?/
> /
>
> DANiel
>
> W dniu 4/22/2014 5:45 PM, Tipp, Brandon P pisze:
>
>     1. I believe that you are referring to this in the LRM:
>
>     The pre_randomize() and post_randomize() methods are not virtual.
>     However, because they are
>
>     automatically called by the randomize() method, which is virtual,
>     they appear to behave as virtual
>
>     methods.
>
>     Since randomize() is virtual, if you call randomize() on a parent
>     class you will invoke randomize() of the child class which in turn
>     will call pre_randomize() and post_randomize() of the child class,
>     which means that pre_randomize() and post_randomize() act like
>     they are virtual anyway. You could try to build an example where
>     the virtual/non-virtual definition of pre_randomize() and
>     post_randomize() would matter; but in order to do that you would
>     have to call pre_randomize() and/or post_randomize() directly.
>
>     It was convenient to define the built-in pre_randomize() and
>     post_randomize() methods of interface classes as being virtual. 
>     This makes it possible to call pre_randomize() or post_randomize()
>     directly on an interface class handle, which would not be possible
>     if it were not defined to be built-into interface classes.  Also,
>     calls to pre_randomize() or post_randomize on an interface class
>     handle would explicitly do nothing if it were not defined to be
>     virtual.  The implication of this is that if a class implements
>     any interface class, then pre_randomize() and post_randomize()
>     would be virtual methods in that class and all children of that
>     class, where otherwise they merely act like virtual methods when
>     you call randomize().
>
>     2) The code that you wrote below is illegal.  An interface class
>     may only contain type declarations,  pure virtual method
>     prototypes, paramters and local parameters.  The code in your
>     example code contains method definitions.
>
>     -Brandon
>
>     *From:*owner-sv-ec@eda.org <mailto:owner-sv-ec@eda.org>
>     [mailto:owner-sv-ec@eda.org] *On Behalf Of *Daniel Mlynek
>     *Sent:* Tuesday, April 22, 2014 4:11 AM
>     *To:* sv-ec@eda.org <mailto:sv-ec@eda.org>
>     *Cc:* Piotr Rozkoszek
>     *Subject:* [sv-ec] interface classes and pre_randomize post_randomize
>
>     LRM says:
>
>     /"Interface classes contain two built-in empty virtual methods
>     pre_randomize()and post_randomize() that are automatically called
>     before and after randomization. These methods can be overridden.
>     As a special case, pre_randomize()and post_randomize()shall not
>     cause method name conflicts."/
>
>
>     1. Later on LRM says that pre/post randomize are not virtual so
>     using virtual in above sentense seem to be an error (LRM: "The
>     pre_randomize()and post_randomize()methods are not virtual.")
>
>     2. I assume that above quotation allows to define A and B like this:
>
>     interface class A;
>         parameter p=0;
>         function void pre_randomize();
>             $display("A");
>         endfunction
>     endclass
>
>     interface class B;
>         parameter p=0;
>         function void pre_randomize();
>             $display("B");
>         endfunction
>     endclass
>
>
>     But what should happened when class C implements both A and B  and
>     randomize on C object is called via A,B or C handle?
>
>     class C implements A, implements B;
>     endclass
>     C c=new;
>     A a=c;
>     B b=c;
>     a.randomize; //A::pre_randomze is called?
>     b.randomize;//B::pre_randomze is called?
>     c.randomize;//A::pre_randomze and B::pre_randomze is called?
>
>
>     I cannot see where LRM defines this behaviour.
>
>
>
>     DANiel
>
>
>     -- 
>     This message has been scanned for viruses and
>     dangerous content by *MailScanner* <http://www.mailscanner.info/>,
>     and is
>     believed to be clean.
>


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.