RE: [sv-ec] 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.