Re: [sv-bc] Weaker Interface Type Checking

From: Jonathan Bromley
Sent: Monday, August 30, 2010 12:56 PM
To: Maidment, Matthew R
Subject: Re: [sv-bc] Weaker Interface Type Checking

From Peter Flake:

This proposal is that interfaces should not be checked for
compatibility by name and parameter settings, but by the names and
types of the items used. For virtual interfaces, this would require
a run-time check, but the result could be cached to avoid a
performance hit. It might also require an extra level of indirection
in data structures, since there would be no guarantee that compatible
interfaces are identical.

As a consequence, it should be possible to use a modport from a
different interface, provided that the names listed are of compatible
types and directions.
This addresses several Mantis issues: 2545, 2845 and some of 1861, as
discussed in the presentation on Feb 26th.

I hesitate to disagree with Peter whose background with interfaces is so much deeper than mine, but this is almost diametrically opposed to the stance I personally would wish to take. I would instead prefer to see a strongly, statically typed mechanism that allows me to specify just those features of an interface that are relevant to the connection I wish to establish, and thereby connect to any interface instance that can be statically proven to exhibit precisely those features as a subset. This, surely, can be achieved by having some shared type-like definition, specifying the features of my desired connection, which an interface can choose to implement.

As a side-note I might point out that this notion is not wildly different from the suggestions currently being considered by EC for Java-style multiple inheritance in classes.

Run-time type compatibility checking severely limits my ability to reason about the correctness of parts of my design or testbench in isolation. Shared definitions provide exactly that power to isolate one part of a system from another.

Thanks,

Jonathan Bromley

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