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

Greg,

Thanks for your very interesting comments about static
and dynamic interfaces, and possible things between.

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

I'm probably being very dense, but I really don't understand
this.  When you say "ref ports have to be removed", what 
is the consequence?  Ref [mod]ports surely mean simply that
synthesis must do a cross-instance reference from a connected
module to the variable in question (the one inside the 
interface instance).  I don't see why this is any different 
from what happens when you synthesise a module with a port 
of interface type, in the absence of modports.  With no 
modport, or with a modport that has the effect of "ref":

* if precisely one connected module makes a procedural write to
  a variable in the interface, all is well;
* if precisely one connected module makes a continuous assignment
  to a variable in the interface, all is well;
* if more than one connected module (or, indeed, more than one 
  process in a single connected module) makes a procedural write 
  to a variable in the interface, then the design can't be 
  synthesized because synthesis can't resolve last-write-wins 
  from more than one process;
* if more than one connected module makes a continuous assignment
  to a variable in the interface, then simulation and synthesis
  should both reject the design at elaboration time as having
  multiple continuous drivers on a variable

So I can't see where the sim/synth mismatch comes from.  
Please forgive me if you need to explain to me the 
obvious problem that I've missed.

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

Only if virtual interfaces are permitted to be fully 
polymorphic.  If you lock a virtual interface to a
specific modport type, then its type checking can surely
be static and yet it can still be pointed to any
interface that exposes a modport of that type.  This,
I think, would be a reachable goal if modports could
be declared stand-alone as a special sort of class,
as I suggested in the "white paper" that is currently
the only content of Mantis 1861.

That paper was written on the understanding that ports 
in a modport are effectively all refs, but it could
easily be re-cast to accommodate the consensus position
that the modport represents a collection of variables
inside the connected module that is driven/received
by continuous assignment across the modport.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223                   Email: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web: http://www.doulos.com

This e-mail and any  attachments are  confidential and Doulos Ltd. reserves 
all rights of privilege in  respect thereof. It is intended for the use of 
the addressee only. If you are not the intended recipient please delete it 
from  your  system, any  use, disclosure, or copying  of this  document is 
unauthorised. The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.


> -----Original Message-----
> From: Greg Jaxon [mailto:Greg.Jaxon@synopsys.com]
> Sent: 23 July 2007 18:38
> To: Jonathan Bromley
> Cc: stuart@sutherland-hdl.com; sv-ec@eda-stds.org; sv-bc@eda-stds.org
> Subject: 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.