Re: [sv-bc] Interface use case examples

  Peter,

> I agree that the idea would be unpleasant if your three points
> were true but I believe my proposal is the opposite.

It's evident that I had not at all grasped what Peter proposed,
so I'd better start again :-)

After your last two messages I believe I have now got the point.
What I now understand you to be saying is:

- A module that wishes to connect to a modport should specify the full
   type of its interface port, using the form interfaceName.modportName

- interfaceName.modportName must exist. The entirety of that modport
   definition forms the "signature" of the modport to which our module is
   permitted to connect. All operations performed by our module on its
   port must conform with the declarations in the "specimen signature"
   modport that was specified in its module port list.

- An instance of our module may have its port connected to an
   instance of a different interface, provided that interface has
   a modport with identical signature to that of
   interfaceName.modportName.

First, my apologies to Peter that it took me so long to see what he
was saying. I think it's fair to say that he threw me off the scent by
describing this as a weakening of the checking rules. It's not; it
is (almost exactly as I have been requesting) a shift in the rules
to require strict matching of modports both for physical and
virtual connection..

I think this is quite interesting. If my understanding is right, every
modport
would have a perfectly straightforward statically-known type; however, the
name of that type would not be manifest, but instead would be a signature
obtained by a process akin to name mangling in C++ (but, as Peter
hinted in an earlier email, paying no regard to the lexical order of the
modport items - so they must be sorted in some deterministic way
to form the signature).

At present I haven't quite worked out whether you expect the modport's
name to form part of this signature. Support for multiple modport
instances in an interface would probably be easier if it did not.

Given the interpretation I've sketched above, then yes, I accept that
pretty much all the objections I raised in the previous couple of mails
are either wrong or irrelevant.

Better still, this (like any mechanism that depends on a statically
known type for modports, and requires type compatibility between
requiring and providing modports but not between their parent
interfaces) does NOT impose any run-time checking obligation
on a virtual interface, provided the virtual interface's data type
is the data type of such a modport.

I remain concerned that this approach is needlessly verbose,
requiring complete copy-paste repetition of the modport in
each interface that provides it, including the "specimen
signature" interface. This was my first and most obvious
motivation for requesting a means to declare modports
as a data type in a package.

I'm also troubled about the relationship between types,
interface definitions and instances. The data type signature
of your modports can be expressed only by having sight of
a complete interface definition. This can't go in a package,
of course, so we still have the same problem that we have
today: packages containing virtual interface declarations
cannot be fully processed stand-alone as they should be,
but depend on the properties of a separate design element.

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