I don't see where these two opinions disagree.
Peter asks us to ignore the modport's provenance and consider only the
ensemble of types
which it brings together. Jonathon asks us to form an abstract modport
which might be
implemented by various interfaces. These two viewpoints sound like
they are describing
the same concept with maybe more emphasis from Jonathon on there being
a definite
external abstraction to which the implementations all refer, and
Peter's desire to let that
abstraction remain unstated, and therefore easier to form or reform as
needed.
At this point, some example code or a draft proposal with concrete
syntax would help
focus any further discussion.
Greg
Maidment, Matthew R wrote:
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.
--
This message has been scanned for viruses and
dangerous content by
MailScanner, and is
believed to be clean.
Received on Tue Aug 31 22:56:17 2010