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