Re: [sv-bc] RE: [sv-ec] Inconsistencies in virtual interfaces and modports

Jonathan Bromley wrote:
>> [Stu] would like to add support for Jonathan's suggestion
> 
> I don't think I really *suggested* anything.
> 
>  [I]f we enforce that a modport output has the same 
> semantics as a module output, then we must forbid 
> writing to modport output variables via a virtual 
> interface (or permit continuous assign via a virtual
> interface, which seems fraught with difficulty).

I would also like to observe, without yet suggesting anything,
that we have two extremes of interfaces:
	- absolutely static ones, where every reference to
	  or through the interface can be fully resolved
	 (inlined) during design elaboration;
	- totally dynamic virtual interfaces with little
	  or no type-matching as references reach
	  actual destinations.

These clearly serve different purposes - one is suitable
for synthesis, the other is a very powerful simulation
and testbench facility.  I think the committee should
continue serving those separate masters as these features
are refined.  I have a hunch that there is still
an unplowed middle ground, though.  I am thinking about
a dynamically-selectable, homogeneous, aggregate of interface
instances, where the identity of individual instances in the
collection is blurred for the purposes of type-compatibility.
This might be a useful and synthesizable, mid point
between these extremes that would allow the expression
of switching network designs in high level synthesizable RTL.

> Personally I would prefer it if modport output was a
> synonym for "ref", and modport input a synonym for
> "const ref".  If you want the single-source behaviour
> you can easily get it by making a continuous assign
> to the modport output, instead of a procedural write;
> this works correctly today in two out of three 
> simulators I tried, whereas none enforces single-
> source if you make procedural assignment to a modport
> output.

This is a very frequently mentioned stumbling block
when interface designs are migrated from simulation to
synthesis.  Considering that all "ref" ports have to be
removed by the end of (separate compilation) synthesis,
making ref be the only behavior for "output" direction
leaves the feature specifying a simulation/synthesis
mismatch condition.  This does not advance the committee's
goal to improve tool correlation.

> But I sense that the consensus goes against my 
> preference; that's OK too, but we MUST then fix the 
> problem with virtual interfaces - and I have three 
> tool bugs to report :-)

It sounds like a virtual interface reference needs to
be burdened with a dynamic type-checking hook.

Just my humble opinions, as always
Greg Jaxon


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