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

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


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