Re: [sv-bc] Weakly typed virtual interfaces?

From: Steven Sharp <sharp@cadence.com>
Date: Fri Sep 10 2010 - 21:07:27 PDT

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.

This makes me wonder how much of the desired functionality could be
achieved by actually doing that.

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.

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.

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.

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

Steven Sharp | Architect | Cadence

P: 508.459.1436 M: 774.535.4149 www.cadence.com

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Fri Sep 10 21:07:56 2010

This archive was generated by hypermail 2.1.8 : Fri Sep 10 2010 - 21:10:29 PDT