Re: [sv-bc] Connection of parameterized interfaces

Here is why I read it as "legal":
There is no way for the formal port to declare precisely which "interface type" it expects.

Not only is there no syntax for specifying parameters there;
the definition of interface type makes it doubtful that the interface (template) name specifies one.
Recall, at the time this LRM section was written (but hopefully no longer), there was a notion of "instance-specific interface type".
Under this idea no two interface instances ever "have the same type" ("type" here used in the sense of strict type checking
for assignment compatibility).
In that world, only the interface instance's hierarchical path name would work as its type's unique identifier.

That world is, in fact, the simulation world. In simulation, interfaces can declare local class types whose identity is
tied to actual storage locations created uniquely by each instantiation of the class.  Instance-specific interface types
respect the type incompatibilities introduced on behalf of those classes. As we add (a subset of) classes to synthesis, this will
no doubt be added too.

So it was clear that, when written, this LRM section didn't mean what it said.
Since then, implementation efforts have made it a de facto standard that the incoming instance provides the interface port's type
and that the receiving down design may need further specialization at that time to express the correct usage of the interface.

Effectively, all interface ports are generic; but the formal port may use interface_identifiers and/or modport_identifiers to constrain
what can legally connect to it. The LRM should not, however, use the word "type" to describe this restriction - that was a casual
use of the term.

Greg Jaxon


On 6/5/2013 10:34 AM, Bresticker, Shalom wrote: