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

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.