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

Just a thought (but not a happy one):

If we establish a search order between the definitions and the type name spaces there will always be
a need to override it. So we should survey what syntax alternatives we have available to override
each search order.

For instance, if "definitions precede typenames" you'll have to explicitly indicate where you meant
to use the type identifier meaning:

We have the keyword "type" used to indicate when a parameter definition is to be read as a typedef.
(We also have the keyword "typedef" which has no legal uses inside an ansi-style port list, but it doesn't
have an obvious syntax as a modifier).

Either of these could be optionally used to disambiguate examples as blatant as Daniel Mlynek's (see start of thread).
Even in non-ANSI port lists, one might say:

module AMBIG( adatum, anifc );
  type T adataum;
  T anifc;
   . . .
endmodule

module AMBIG_ANSI( type T adatum, T anifc );
   . . .
endmodule

Do we have a complementary syntax for the opposite ordering?

module AMBIG( adatum, anifc );
  T adataum;
  interface T anifc;
  . . .
endmodule

module AMBIG_ANSI( T adatum, interface T anifc );
   . . .
endmodule

Of the two I favor the forms that use "type". Not because I like reading them,
but because there is already a better way to disambiguate these cases: use a
port direction declaration, or modifier on the individual port - i.e. don't rely on it
being inherited from a previous port in the ANSI-style list. For example, the keyword
type could be replaced above by "output" without loss of generality.
In this system "type" is only performing the job of a "default port_direction" keyword
when used before a user-defined type name.

It isn't pretty, but it suggests to me that the "definitions" space wins out here
over the typename space ( which is the same as the variable name space in SV).
I could be forgetting some corner of the grammar - this is just off the top of my head.

Greg

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