Re: [sv-bc] nested interfaces as "interfaces to interfaces"

On 29/01/2011 03:04, Steven Sharp wrote:
> Taking Peter's first examples: [...]
> and showing how it could be done with interfaces inside interfaces
First, many thanks to Steven for describing - concisely and accurately,
as always - stuff that I have been promising but failing to put on paper
for many weeks.

I completely agree that this is a useful way to go with today's language
specification, and that it meets the likely needs (at least for
simulation-only users). I'd like to see how it would handle subprogram
import/export, but I'm fairly sure that can be done sensibly.

There are just two things about it that bother me. Neither is a
show-stopper.

The first is nicely illustrated in Steven's example:
>
> module foo (my_rs232_interface ifc, my_other_rs232_interface other);
>
> virtual rs_232 rs;
>
> virtual testpoint tp;
>

Oops, there's the first problem. We have the default specialization of
"virtual testpoint" here, I think. More generally, these inner
interface instances have the potential to suffer all the exact same
frustrations that we're trying to avoid: unwanted parameterization of
virtual interface types, data type finalized only by the properties of
an elaborated instance, problems relating to configuration... The
reason why it's still a good idea, though, is that it also offers the
potential to work around all these problems, if used carefully.

My second concern is not really a language issue at all, but relates to
the behavior of synthesis tools. As far as I'm aware, synthesis won't
cope with this idiom at present (whereas it is OK with modports, of
course). My original motivation for worrying about the data type of
modports was a (quixotic?) mission to raise the abstraction level of RTL
coding by allowing some kind of "inteface facade" to be captured in a
meaningful way, and I would be disappointed if any proposed solution
didn't support that for RTL design. If the synthesis folk can assure us
that, within reasonable limits, this usage is synthesisable, then I'd be
much happier. Without that assurance, I think we're effectively
abandoning interfaces for design in all but the simplest usage models.
"Reasonable limits" here might mean such things as:
- no virtual interfaces (obviously)
- the "inner interface" must have ports through which it can reach its
chosen signals;
- when connecting the inner interface to a port, you can traverse only
one extra level of hierarchy (enforcing the idea that the inner
interface is doing the job of a modport); ...
In other words, restrictions that guarantee the tool's ability to make
everything static, and to flatten an inner interface instance out into
its enclosing interface. These restrictions will not appear in the LRM,
of course, but a shared understanding of how they might work would much
increase the credibility of this "here's how to live with it" solution
and could usefully be described in an Interpretations document from the
committees.

Thanks

Jonathan Bromley

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