[sv-bc] Interface use case examples

To Peter Flake, and anyone else who's still following:

Rather than lengthily re-state my position,
which is probably well enough known, I have uploaded
a short paper "itf_uses.pdf" to Mantis 1861 to show
some use cases that I believe are fair game for the
interface concept. I hope these may provide a focus
for further discussion.

The first part of Peter's message nicely summarises
the artificial problems caused by the language's
confusion between modport definition and
modport instance. He then goes on to say...

> Jonathan Bradford has proposed allowing the modport
> declaration to be a stand-alone item in a package.

Perhaps I could point out that Jonathan Bradford
is a splendid fellow whom I hold in high regard,
but he isn't me (Jonathan Bromley) and I have no
idea whether he agrees with me or not about the
matter at hand.

> This [...] requires a substantial change
> to SystemVerilog products and documentation.

The change to documentation is long overdue
(the interfaces section of the LRM is a mess
even on its own terms). Any change would
be duty-bound to maintain backward compatibility,
so I'm not sure I see this as a fundamental
objection; we're talking about an enhancement
that must be accepted or rejected in the same
way as any other that's up for discussion.

> My proposal is to first solve the modport
> compatibility problem by weakening the type
> checking so that a match between port declaration
> and port connection is achieved if the types and
> names of all modport items match.

I find that a very unpleasant idea. Here's why:

(1) It weakens the language's expressiveness
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It would blow out of the water any hope I
might have of using interfaces and modports
to support design-by-contract at module
boundaries.

(2) It would make designs brittle
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Suppose I have three interfaces I1, I2, I3
all of which implement a modport M. The
three Ms are identical except that I3.M lacks
a signal S which is present in the other two.
Now, I write various modules that have ports
like (interface.M P) that do NOT use P.S.
So far, so good. Later, looking at I1 as an
example, I see signal S and modify one of the
modules to use P.S. It works fine with I2 as
well, so I'm happy. Later, someone tries to
connect this allegedly compatible module to I3.
The resulting problems will be obscure at best.
Strong typing of modports (or something of
the kind) would completely avoid this issue.

(3) It defeats local reasoning about compatibility
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Suppose I wish to make a change to some modport,
or write a new interface containing such a modport.
Where should I seek the specification of what it
must provide? That specification is now smeared
across the entire set of modules and virtual
interface variables that might choose to connect
to it.

> For virtual interfaces, such a table would
> have to be built for each new assignment and
> cached for the next time.

I don't understand how to make this work. I'm
so confused about it that I've written a separate
message about just that topic.

> Then the type/instance problem can be solved
> by allowing port connection modports to be in
> sub-interface instances. The sub-interface
> instances can be used to vary the connections.

You can do something like this today, but it's
distinctly clumsy - note that all the signals
that will appear in the modport must somehow
be ported into each of the sub-interface
instances. It also introduces an extra
level of hierarchy that may be troublesome
for synthesis (and this stuff must be
tractable for synthesis if it is to be any
use at all). It also has, historically,
been a useful way to find out what a compiler
crash dump looks like, although I'm sure all
the implementers have that completely sorted
out by now :-)

Thanks

Jonathan Bromley

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