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

Jonathan,

Here's an argument against "as-if" continuous assignment semantics for
'output' modport components and in favor of the idea that 'output' on a
modport variable merely imposes a single-driver restriction atop the
usual 'ref' semantics.

Consider --

   What about an interface variable that is written from within an
interface task that is enabled by a module?  That is, the module writes
to the interface variable via a side-effect of the interface task (not
via an output port of the task).  Let's suppose throughout that the
interface instance is connected to the module port using a modport.

   If the variable is not listed in the modport, the assignment uses
'ref' semantics -- multiple modules can enable the same interface task,
assigning to the variable with last-write-wins semantics.

   If the variable is listed in the modport as 'output', however, what
effect does that have on the assignment to it from within the task?

   One viewpoint is that the modport only effects dotted references
rooted in the name of the interface-type port, such as "ifc.o = ...",
but does not effect direct references from within the task such as "o =
...".

   The procedural assignment from within the task would be in conflict
with an implicit continuous assignment from "ifc.o" on the port
connection, but if 'output' were simply a single-driver restriction atop
'ref' semantics, then there would be no such conflict, because the port
connection itself would not count as a driver.

   Another viewpoint is that, somehow, listing the variable in the
modport causes the "o = ..." in the interface task body to be
interpreted as "ifc.o = ..." if the task is enabled by a module that is
using that modport.

-- Brad

-----Original Message-----
From: Jonathan Bromley [mailto:jonathan.bromley@doulos.com] 
Sent: Monday, July 23, 2007 6:28 PM
To: Brad Pierce; sv-ec@eda-stds.org; sv-bc@eda-stds.org
Subject: RE: [sv-bc] RE: [sv-ec] Inconsistencies in virtual interfaces
and modports

Brad,

Many thanks for your helpful response.

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

Indeed it does, in 2 of the 3 synthesis tools I can try that understand
interfaces.  It has been a long time since I tried to use an interface
*without* modports in synthesis - but I am sure that at some time in the
past I did so, in Synopsys tools, and got away with it.  Has this
restriction been imposed recently, or is it simply that my memory is
deceiving me?

Anyway, given all the clarifications from you and others, it's obvious
to me that your model of modport inputs and outputs creating continuous
assignments is the right one.  From the point of view of exposition in
the LRM, that also implies that the modport appearing in a module's port
list must create a group of variables, one for each input and output
member, in the module itself.

I'm sorry it has taken so long for the penny to drop with me.
However, I humbly suggest that there is some evidence that the LRM needs
some clearing-up!  And there remains the virtual interfaces
problem......

Thanks again to all
--
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

The contents of this message may contain personal views which are not
the views of Doulos Ltd., unless specifically stated.

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