RE: [sv-ec] "this" and member resolution in inline constraints

Ray,

I don't believe there's any doubt as to how virtual functions should
work. Regardless of the object handle used to call the virtual function,
the result is always to call the object's (not the class) function
(D::vfnc in your example). If you consider a virtual-table
implementation for virtual functions then the function called is a
function of the object (created by new) and not the handle used in the
call.

I do agree that any such clarification should be a separate mantis.

	Arturo

-----Original Message-----
From: Ryan, Ray [mailto:Ray_Ryan@mentor.com] 
Sent: Wednesday, December 19, 2007 12:25 PM
To: Vreugdenhil, Gordon; Arturo Salz
Cc: Mark Hartoog; SV_EC List
Subject: RE: [sv-ec] "this" and member resolution in inline constraints

What is the semantics of a reference to a virtual function within a
randomize with clause: For example:

    class C;
        rand int x;
        virtual function bit vfnc ();
            return 0;
        endfunction
    endclass

    class D extends C;
        rand bit[1:0] x;
        virtual function bit vfnc ();
            return 1;
        endfunction
    endclass

    D d = new;
    C c = d;

    initial begin
        c = d;
        assert ( c.randomize with { x[0] == vfnc();} );
    end

I'd suggest that virtual functions not be allowed in constraints (like
functions with side-effects aren't allowed).

Probably this is a separate mantis item, but needs to be considered.

- Ray

> -----Original Message-----
> From: owner-sv-ec@server.eda.org 
> [mailto:owner-sv-ec@server.eda.org] On Behalf Of Vreugdenhil, Gordon
> Sent: Wednesday, December 19, 2007 11:09 AM
> To: Arturo Salz
> Cc: Mark Hartoog; SV_EC List
> Subject: Re: [sv-ec] "this" and member resolution in inline 
> constraints
> 
> 
> 
> Arturo Salz wrote:
> [...]
> 
> > Since at this point, we seem to agree on what the rules are (please 
> > correctly if that is not the case), shouldn't we concentrate on the 
> > verbiage that removes any potential ambiguity. I propose 
> the following:
> > 
> >  
> > 
> >   The scope for resolution of variable names referenced in the in a 
> >   constraint block begins with the randomize()...with 
> object class, i.e., 
> >   the class of the object used in the call to randomize. If 
> a name fails 
> >   to resolve within the randomize()...with object class, 
> the name is 
> >   resolved normally starting in the scope containing the 
> inline constraint.
> 
> I still don't like the phrase "class of the object used in 
> the call" because the type is NOT the class of the *object* 
> it is the class of the reference.
> 
> How about:
>     The scope for resolution of variable names referenced in a
>     constraint block begins with the class type of the reference
>     to the "randomize()...with" object. If a name fails
>     to resolve within the class of the reference, the name is resolved
>     normally starting in the scope containing the inline constraint.
> 
> 
> > If this is acceptable, I'll incorporate it into the proposal. 
> > Otherwise, would you please suggest a better alternative.
> 
> I don't think "this" is covered yet since "this" is not a 
> member of the *class* it is an implicit of a non-static method.
> 
> So, in addition to the above, how about adding:
>     A reference to "this" in the "with" clause shall be treated as
>     having the type of the reference to the "randomize()...with"
>     object.  A reference to "super" in the "with" clause shall
>     be treated in the same manner as a reference to "this.super".
> 
> 
> Something along that line should cover things.
> 
> I am hesitant to talk about (effectively) replacing "this" by 
> the object reference which is what Ray was hinting at since 
> that becomes incorrect in the face of side effect index 
> expressions in the prefix.  I'm also a bit hesitant to adopt 
> Steven's approach of talking about a non-static method 
> equivalence since that only applies to the names that do 
> resolve into the target object.
> 
> Gord
> 
> --
> --------------------------------------------------------------------
> Gordon Vreugdenhil                                503-685-0808
> Model Technology (Mentor Graphics)                gordonv@model.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.