Re: [sv-ec] mantis item 2848

I agree that some variant of this is likely the best approach.
Due to compatibility issues, I suspect it would be best to adopt
the more permissive approach of saying the virtual interfaces
are permitted to be used with interfaces containing class,
structs, etc but that the virtual interface does not have
visibility to such items.

Gord.

Rich, Dave wrote:
> There is already this paragraph in 25.9 for the same reason:
> 
> Although an interface may contain hierarchical references to objects
> outside its body or ports that reference other interfaces, it shall be
> illegal to use an interface containing those references in the
> declaration of a virtual interface.
> 
> Just add class declarations to the list. We could optimize the rule in
> general so that only references to these things on the list through a
> virt interface are illegal.
> 
> 
> 
>> -----Original Message-----
>> From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]
> On
>> Behalf Of Francoise Martinolle
>> Sent: Thursday, August 13, 2009 6:21 PM
>> To: Francoise Martinolle; Vreugdenhil, Gordon
>> Cc: sv-ec@server.eda.org
>> Subject: RE: [sv-ec] mantis item 2848
>>
>>
>>
>>
>> Actually should we make it an error only if someone tries to create a
>> virtual interface access through the
>> class? or should it just be an error to connect an virtual interface
> to
>> such an interface.
>> i.e:
>>
>> vi.ch expression should be an error or vi = ifc1 is an error?
>>
>> The problem really arises when you write an expression which is of the
>> class datatype and
>> that expression prefix is the virtual interface.
>>
>> Francoise
>>     '
>> -----Original Message-----
>> From: Francoise Martinolle
>> Sent: Thursday, August 13, 2009 9:13 PM
>> To: 'Gordon Vreugdenhil'
>> Cc: sv-ec@server.eda.org
>> Subject: RE: [sv-ec] mantis item 2848
>>
>>
>> Good. If the vendors agree that it should be an error, I think we will
>> be ok.
>> It is not very useful anyways to declare a class inside an interface.
>>
>> Francoise
>>     '
>>
>> -----Original Message-----
>> From: Gordon Vreugdenhil [mailto:gordonv@model.com]
>> Sent: Thursday, August 13, 2009 6:31 PM
>> To: Francoise Martinolle
>> Cc: sv-ec@server.eda.org
>> Subject: Re: [sv-ec] mantis item 2848
>>
>> Francoise,
>>
>> This is where the "type" nature of interfaces really breaks down.  I
>> agree with the issue -- there is no definite type for "vi.ch" since
> the
>> referenced type is dependent on the instance of the target.  Most such
>> issues were resolved by the introduction of parameterized virtual
>> interface typing, but strong types (classes, unions, enums, structs)
> are
>> not addressed by the current LRM.  The "best" argument that I can make
>> is that since the types are not statically determinable, it should
>> probably be an error.  It is certainly going to be ill-defined across
>> vendors at this point.
>>
>> Gord.
>>
>>
>> Francoise Martinolle wrote:
>>> I filed a mantis item today regarding virtual interfaces which can
> get
>>> assigned interfaces containing class declarations.
>>> I think it should be illegal to traverse through such virtual
>>> interface to a class handle declared in the interface if its class
>>> datatype is also in the interface declaration.
>>> The datatype of the virtual interface select expression cannot be
>>> statically determined by the elaborator.
>>> ex:
>>> interface ifc;
>>>    class C;
>>>    int i;
>>>    endclass
>>>      C ch;
>>>
>>> endinterface // ifc
>>>
>>> module top;
>>>
>>>    ifc ifc1();
>>>
>>>    ifc ifc2();
>>>
>>>    virtual interface ifc vi = ifc1;
>>>
>>>    initial begin
>>>       vi.ch = new(); // is this legal
>>>       $display(vi.ch.i); // is this legal?
>>>       vi = ifc2;
>>>       $display (vi.ch.i);
>>>    end
>>>
>>> endmodule // top
>>>
>>> Comments?
>>>
>>> Francoise
>>>        '
>>>
>>> --
>>> This message has been scanned for viruses and dangerous content by
>>> *MailScanner* <http://www.mailscanner.info/>, and is believed to be
>>> clean.
>> --
>> --------------------------------------------------------------------
>> 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.
>>
> 
> 

-- 
--------------------------------------------------------------------
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.