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

People generally agree that packages and user defined types are bound at parsing/compile time. That is why the LRM says: "The compilation of a package shall precede the compilation of scopes in which the package is imported" and "The declaration of a user-defined data type shall precede any reference to its type_identifier."

Instaniations of modules, programs and interfaces are bound at elaboration time, with an option of using a configuration to change the default binding rules.

Interfaces fall somewhere in between a type and a module like construct. Virtual interfaces are a type, but implementations appear to have decided to ignore the rule requiring types to be defined before they can be used in the special case of interfaces. This may have been because of pressure from users that somehow expected this behavior.

The LRM is very weak in the whole area of libraries and configurations. The LRM says you can create libraries using library mapping files (and other tool specific methods), but it fails to answer such simple questions as:

"If I use the library mapping file to map two packages of the same name in different libraries, how do I bind an import statement to a package of this name?"

Configurations don't apply to packages, so they cannot be used to answer this question.

Likewise, if you have two interfaces of the same name in different libraries, the LRM is completely silent about how a virtual interface reference to that interface name gets bound to an interface. There is nothing in the LRM to suggest that a configuration might apply to a virtual interface variable. Virtual interface types can apparently appear in packages and configurations are not suppose to apply to packages. (You could argue that virtual interfaces in packages violate the rule that packages cannot refer to anything defined in $UNIT, but at this point that train seems to have already left the station.)

Customers are running into issues with the whole question of how packages and virtual interface types get bound in multiple library situations. I suspect all vendors have created some (different) way for their customers to deal with this. So far the committee seems reluctant to spend time on this issue.

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Gordon Vreugdenhil
Sent: Monday, August 22, 2011 6:57 AM
To: Bresticker, Shalom
Cc: Greg Jaxon; Brad Pierce; Daniel Mlynek; sv-bc@server.eda-stds.org
Subject: Re: [sv-bc] search rules for type vs interface

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.

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

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