RE: [sv-ec] mantis item 2848

From: Francoise Martinolle <fm_at_.....>
Date: Wed Aug 19 2009 - 14:23:24 PDT
 

Same issue exists for anonymous structs/enums etc variables
declared in an interface and accessed through a virtual interface not
just when there is a typedef for the
datatype.
Also I want to note that this is not only for unpacked structs/unions
but also packed, since the
type matching of packed structs makes two typedefs of a packed structs
with exact same members NON matching.
see rule (d) in section 6.22.1 type matching.


Perhaps the LRM could say something like:
a virtual interface expression is illegal if the datatype of the
expression cannot be statically
determined. Or the virtual interface expression is illegal if the
datatype of the expression can potentially
resolve to more than one non matching datatype.

Francoise
    '
-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Francoise Martinolle
Sent: Wednesday, August 19, 2009 1:40 PM
To: Mark Hartoog; Gordon Vreugdenhil; Rich, Dave
Cc: Vreugdenhil, Gordon; sv-ec@eda.org
Subject: RE: [sv-ec] mantis item 2848

 
If you have an interface which contains oomrs and we have several
instances of that interface at the same scope level, the oomrs will
resolve the same way. So it would be safe to assign such interfaces to
this virtual interface of a matching type.
However if the interface instances are at different scope level, oomrs
may resolve a different way. So in that sense, it changes the "interface
typing" (but we never defined the interface typing using oomrs, we just
decided to forbid such interfaces). So I think it is not safe to assign
such interface to a virtual interface because our matching type rule is
incomplete.
The same problem arises with strong types like
structs/unions/enums/classes. The interface type does not take those
into account. Additionally there are parameters inside interfaces which
are not represented in the virtual interface datatype and therefore not
used for matching. I believe that this is a problem too. A defparam
could change one of these parameter values and make one instance of an
interface different from another interface instance even though the
virtual interface type is said to match. I filed a mantis item for this.
My proposal is to make those interfaces illegal to be assigned to vifcs.
I am not sure how to solve the strong types inside interfaces. Perhaps
you are not allowed to use a vifc expression that is of a
struct/union/enum/class datatype or a vifc expression which prefix is a
struct/union/class/enum datatype and the datatype is declared in the
interface.

Francoise
    '




-----Original Message-----
From: Mark Hartoog [mailto:Mark.Hartoog@synopsys.com]
Sent: Friday, August 14, 2009 2:43 PM
To: Gordon Vreugdenhil; Rich, Dave
Cc: Francoise Martinolle; Vreugdenhil, Gordon; sv-ec@eda.org
Subject: RE: [sv-ec] mantis item 2848

I think we need to formulate some realistic restrictions.

From discussions with customers it appears that vendors are not
enforcing the rule quoted below by Dave Rich that forbids interfaces
that contain hierarchical references to be used as virtual interfaces. I
do not understand why that restriction was put into the LRM in the first
place. There are corner cases where some restriction is needed, for
example a hierarchical references used in clocking block expressions
could cause variables in clocking blocks to infer a different types in
different instances. Perhaps this is the problem that this restriction
was trying to address, but as far as I can tell vendors have largely
ignored the restriction.

If we completely forbid interfaces that define user defined types from
being used as virtual interfaces, I suspect many vendors will ignore
that restriction also.

It would be better if we took the time to come up with restriction that
are realistic and encourage vendor convergence rather than unrealistic
restrictions.


-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Gordon Vreugdenhil
Sent: Friday, August 14, 2009 7:07 AM
To: Rich, Dave
Cc: Francoise Martinolle; Vreugdenhil, Gordon; sv-ec@eda.org
Subject: 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.


--
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.
Received on Wed, 19 Aug 2009 17:23:24 -0400

This archive was generated by hypermail 2.1.8 : Wed Aug 19 2009 - 14:27:55 PDT