Re: [sv-bc] Interface use case examples

Replying to Jonathan Bromley's message of Friday.

Please accept my apologies for a brain failure, and Bromley is nearer
to here than Bradford!

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

(1) By removing the need for a generic "interface" in a module
header, it supports design-by-contract to a modport of given names,
types and directions.

(2) I would not allow your use case:

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

Therefore I3.M is not compatible with the other two because the names
do not match. If you do not want to use S with I1 or I2, you should
define new modports without S, say I1.N and I2.N.

(3) By removing the need for a generic "interface" in a module
header, the proposal allows local reasoning about compatibility.

The specification of a modport can be seen in the named interface
that is visible to the current scope. This named interface may
differ between e.g. the module header and the module instance, but
the modport would be compatible provided all the names, directions
and data types match.

Peter Flake

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