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

From: Daniel Mlynek <danielm@aldec.com.pl>
Date: Tue Apr 22 2014 - 22:30:39 PDT
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:
> interface classes and pre_randomize post_randomize
>
> 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] *On Behalf Of 
> *Daniel Mlynek
> *Sent:* Tuesday, April 22, 2014 4:11 AM
> *To:* 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.
Received on Tue Apr 22 22:31:31 2014

This archive was generated by hypermail 2.1.8 : Tue Apr 22 2014 - 22:31:48 PDT