[sv-bc] Weakly typed virtual interfaces?

  Steven,

> I have done some thinking about modports as a separately declared entity
> that can be instantiated in different interfaces to provide a common
> "interface" to these interfaces. When I do that, they seem rather like
> a smaller interface instantiated in each of these interfaces.

I completely agree. Indeed, the more I thought about it
the more I found myself wondering whether this "port-like"
form of interface should not perhaps be the only way to
use them. After all, if you can instance one of these little
"access interfaces" inside a bigger interface, you could
equally well instance one inside a module - one of the
things I was aiming for.

 From a language point fo view, I guess the worry is that it
leaves us with the same old problem of a data type that's
defined not by a stand-alone type declaration but by the
properties of a design element. I'm sure I have not fully
grasped the ramifications of this, but aren't there some
"interesting" interactions with configuration and libraries?

> The larger interfaces could either access signals out of the smaller ones
> they instantiate using dotted names, or could connect their own signals
> (or expressions of their own signals) to signals in the smaller
> interfaces
> through ports of the instances.

I'd definitely favour the ported form. I think we're likely to be in
enough
trouble already with dotted names, without making life even harder for
synthesis.

> The smaller interfaces would all be of the same type and
> parameterization,
> so they would be compatible with the same virtual interface variables.
> Those virtual interfaces could then access the smaller interfaces in any
> of these larger ones, which encapsulate the common "interface" to them.

Right. And of course it opens the door to generate loops with instance-
by-instance parameterization, and many other things that either aren't
possible or aren't supported for modports.

> The syntax for attaching these smaller interfaces to ports, or assigning
> them to virtual interfaces would be the same as for modports. You would
> reference them using interface_instance.subinterface_instance, instead of
> interface_instance.modport_name.

Here's the part that might be a little tricky. The subinterface is
truly a layer
of hierarchy, whereas a modport probably isn't. (Is it? I don't really
know.)
Anyway, I suspect you're asking for something that is currently not
supported
for synthesis. If the synthesis vendors could promise support for such an
arrangement, I think it would work very well. They might need to impose
restrictions such as a limit on the depth of instance nesting (just one?).

> It would be possible for one of these larger interfaces to be passed its
> smaller interface through a port, instead of instantiating it. I don't
> know whether this is useful, but it is something you can't do with a
> modport.

I'm not sure about this - need to think about it some more.
> I haven't had a chance to consider exactly what capabilities this
> technique
> would allow. I haven't had a chance to look at your use case examples to
> see if it would satisfy them. I just wanted to toss this idea out there
> before too much gets invested in some new feature, in case this existing
> feature can already provide the desired capabilities.

The key question is "can it synthesise". From a simulation point of view,
I think almost all the things I would like to be able to do fall
naturally out
of your approach. The loss of modport direction would be a mild
disappointment (not a big deal, given its hazy current definition) and
the impact on subprogram import/export needs to be considered
carefully.

I had considered exactly this idea in the past, but rejected it early on
because I assumed that the extra level of hierarchy would preclude
synthesis. I'll go away and try to rework my various thought-
experiments to use these "access interfaces" instead of
modports, and see if everything works out OK.

Thanks

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