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.