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

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

Correct.  And module ref ports and their last-write-wins semantics are
not supported in synthesis.

In synthesis, access to an interface variable via an interface-type
module port requires that a modport be used and that the modport impose
an 'input' or 'output' direction on the interface variable to override
the default 'ref' semantics.

An effect of imposing the 'output' direction is that, because an
'output' port is a continuous assignment, the module (according to the
"as-if" semantics) is the single driver of that variable.

-- Brad

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Jonathan Bromley
Sent: Monday, July 23, 2007 3:00 PM
To: Greg Jaxon; sv-ec@eda-stds.org; sv-bc@eda-stds.org
Subject: 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.



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