Re: [sv-bc] search rules for type vs interface

On 8/22/2011 8:57 AM, Gordon Vreugdenhil wrote:
> Good question, particularly since one must also then account for
> the implicit instantiation rule:
> Nested modules with no ports that are not explicitly instantiated
> shall
> be implicitly instantiated...
>
> When does the implicit instance name "exist"? Can one even declare
> a virtual interface of such a module?
>
> To be consistent (?), I might expect that an inner "module" would
> be skipped in favor of an outer type, but that gets very weird.
No, I agree that's too messy.
The implicit instance should be created on-demand as soon as there is a first reference
to the local interface (on a port list or at the top of a hierarchical reference).
>
> The rules are a mess and I really don't think that they are anywhere
> close to "complete" enough to make an argument about what is
> correct in such situations. The status of "interface as type", any
> precedence of name spaces during search, etc. would all have to
> become much more clear. And we've been unable to reach any
> consensus on even the "interface as type" question.
>
> Gord.
>
> On 8/22/2011 5:26 AM, Bresticker, Shalom wrote:
>> Hi,
>>
>> This discussion goes back three years, but I think it is no less relevant now than then.
>>
>> Question:
>>
>> How do the search rules change when the interface is declared inside a module, not in the global scope?
>>
>> Thanks,
>> Shalom
>>
>>> -----Original Message-----
>>> From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On
>>> Behalf Of Gordon Vreugdenhil
>>> Sent: Wednesday, July 23, 2008 9:30 PM
>>> To: Greg Jaxon
>>> Cc: Brad Pierce; Daniel Mlynek; sv-bc@server.eda-stds.org
>>> Subject: Re: [sv-bc] search rules for type vs interface
>>>
>>>
>>> Greg, the LRM is not at all consistent in how an "interface"
>>> is treated in terms of its nature as a "type" versus its
>>> nature as a design element. Certainly in the context of
>>> virtual interfaces and the like, there are aspects of both.
>>> (i.e. How about a type parameter that resolves to a
>>> virtual interface type? )
>>>
>>> I've taken the position in other contexts (class/package
>>> resolution for example) that the definitions space should
>>> only be inspected after all other legal visibilities have
>>> been exhausted. I think that applies here as well.
>>>
>>> Whether the interface even *exists* is another entire story --
>>> I think Brad's answer has an existence assumption that
>>> isn't even true in practice. It certainly isn't the case
>>> that the LRM requires an interface to exist during compilation
>>> though for elaboration is (likely) does. If also isn't at
>>> all clear whether it is legal to elaborate code with
>>> virtual interface types for which there is no corresponding
>>> interface at all. For example, is the following legal as
>>> a complete design?
>>> module top;
>>> virtual intf i;
>>> endmodule
>>>
>>> Gord.
>>>
>>>
>>> Greg Jaxon wrote:
>>>> I misread the BNF.
>>>> As you say, the port_direction is optional.
>>>> So the context _is_ ambiguous, and only
>>>> a search order rule can resolve it.
>>>>
>>>> My impression is that definitions from the compilation unit scope
>>>> take precedence over the definitions name space, but I cannot
>>>> locate a sentence that confirms that view.
>>>>
>>>> Brad's point is worth extending, if there really is a preference
>>>> for $unit scope over definitions: in that case, it would also
>>>> not matter if the interface declaration came _after_ the typedef.
>>>>
>>>> Do typenames in $unit completely shadow interfaces of the same name
>>>> in all subsequent references within that compilation unit? Or only
>>>> in ambiguous contexts?
>>>>
>>>> typedef integer T;
>>>> interface T;
>>>> T j;
>>>> endinterface
>>>> module top;
>>>> T j; // a local variable declaration
>>>> T i(j); // an interface instantiation
>>>> initial $display("%b %b", j, i.j);
>>>> endmodule
>>>>
>>>> My personal feeling is that the cost of supporting this kind
>>>> of confusing flexibility exceeds the practical benefits, if any
>>>> can be described. Since the grammar has two ambiguities between
>>>> interface identifiers and typenames, they should either be in
>>>> the same name space, or the name space searches should be ordered.
>>>>
>>>> Greg
>>>>
>>>>
>>>>
>>>> Brad Pierce wrote:
>>>>> Daniel,
>>>>>
>>>>> The answer to your question
>>>>>
>>>>> module top (T i); //T is a type or T is an interface??????
>>>>>
>>>>> should be independent of where the interface is declared, such as
>>>>>
>>>>> 1) In the same file as "top", before "top" in the text
>>>>> 2) In the same file as "top", after "top" in the text
>>>>> 3) In a different file than "top", already read
>>>>> 4) In a different file than "top", not yet read
>>>>>
>>>>> Suppose that the answer were "interface" -- you would have to wait until
>>>>> you've seen every file before being able to parse "top", because of the
>>>>> possibility that there might be an interface "T" declared somewhere.
>>>>>
>>>>> Hence, the answer is "type".
>>>>>
>>>>> -- Brad
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
>>>>> Daniel Mlynek
>>>>> Sent: Wednesday, July 23, 2008 11:48 PM
>>>>> To: 'Greg Jaxon'
>>>>> Cc: sv-bc@eda-stds.org
>>>>> Subject: RE: [sv-bc] search rules for type vs interface
>>>>>
>>>>> But direction and kind can be implicit. If I remove interface from the
>>>>> code
>>>>> I've post then type integer wire will be used as port type - I do not
>>>>> need
>>>>> to write :input T i
>>>>>
>>>>>
>>>>> DANiel
>>>>> -----Original Message-----
>>>>> From: Greg Jaxon [mailto:Greg.Jaxon@synopsys.com] Sent: 23 lipca 2008
>>>>> 17:42
>>>>> To: Daniel Mlynek
>>>>> Cc: sv-bc@eda-stds.org
>>>>> Subject: Re: [sv-bc] search rules for type vs interface
>>>>>
>>>>> Daniel,
>>>>>
>>>>> I'm sorry to report that only the context can determine which
>>>>> definition
>>>>> of T applies in each circumstance.
>>>>> In the case you've asked about, T can only refer to the interface,
>>>>> whereas
>>>>> in "module top( input T i );", it can only refer to the typedef. The
>>>>> fact
>>>>> that this is beyond the capabilities of context-free scanners and
>>>>> parsers is
>>>>> worth noting.
>>>>>
>>>>> Greg
>>>>>
>>>>>
>>>>> Daniel Mlynek wrote:
>>>>>> interface T;
>>>>>> endinterface
>>>>>>
>>>>>> typedef integer T;
>>>>>>
>>>>>> module top (T i); //T is a type or T is an interface??????
>>>>>> initial $display("%b", i);
>>>>>> endmodule
>>>>>>
>>>>>> DANiel
>> ---------------------------------------------------------------------
>> Intel Israel (74) Limited
>>
>> This e-mail and any attachments may contain confidential material for
>> the sole use of the intended recipient(s). Any review or distribution
>> by others is strictly prohibited. If you are not the intended
>> recipient, please contact the sender and delete all copies.
>>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.