Re: [sv-bc] @* vs. always_comb

Yes, the tool must already have seen the interface declaration and the
particular instantiation of it.

By the way, I think the distinction between 'generic' and named
interface-type ports is not as significant as it seems on a first read.
There's not really so much difference between a generic interface-type
port that uses the 'interface' keyword and a named one that doesn't,
because typically interfaces are parameterized, and the particular
specialization of the instance that will be connected cannot be known
until elaboration time. (For example, just knowing the name of an
interface doesn't tell you the size of a particular instance of it.)
What's more, an interface can itself have interface-type ports, and so
on.

In my opinion, using an interface name instead of the 'interface'
keyword in a port declaration serves the following main purposes --

     1) Allows the user to separately compile a prototypical version of
the module, including error checking that the hierarchical references
across the port are to data objects or subroutines that will actually
exist in the eventual interface instance.  (This can't be done for all
such references, because they might, for example, be into a struct
variable of a type that depends on a parameter of the interface.
However, if the default value of that parameter doesn't provide a field
with the referenced name, it's a good bet that there will be a problem
at actual elaboration time, too.)

     2) Constrains the universe of possible instantiation hierarchies,
because the actual interface instance connected to the port is required
to be a specialization of the named interface.
 
     3) Documentation.

-- Brad

-----Original Message-----
From: Steven Sharp [mailto:sharp@cadence.com] 
Sent: Tuesday, December 13, 2005 6:36 PM
To: sv-bc@eda.org; Brad.Pierce@synopsys.COM
Subject: Re: [sv-bc] @* vs. always_comb


>From: "Brad Pierce" <Brad.Pierce@synopsys.com>

>Synthesis already handles hierarchical references just fine, including
>hierarchical function calls, as long as the references are into
>interface instances.

Does this apply to generic interfaces, or only ones where you have
seen the declaration of the interface?  The problems become a lot
easier if you get to see the interface declarations first.  References
to functions imported from packages don't cause problems for that
reason.

The term "hierarchical reference" may be too broad here.  Some cases
are more problematic than others.  A select of a member of a local
struct could be considered a hierarchical reference down into the
hierarchy of the struct, but clearly doesn't create the problems that
we are discussing.

The problems that Gord mentioned with hierarchical function calls in
always_comb blocks may not occur with hierarchical references into
non-generic interfaces.  I don't know.


Steven Sharp
sharp@cadence.com