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

From: Jonathan Bromley <jonathan.bromley_at_.....>
Date: Fri Jul 20 2007 - 04:33:08 PDT
> [Stu] would like to add support for Jonathan's suggestion

I don't think I really *suggested* anything.  I was merely
pointing out two things: first, the LRM is not as explicit
as it might be, and (perhaps as a consequence) tools don't
seem to be doing The Right Thing; and second, that if we
enforce this notion 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).

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.

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 :-)

I can't attend either EC or BC meetings next week, but 
regardless of whether I'm there I would much value it
if this could be floated up onto the agenda some time soon.
-- 
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.
Received on Fri Jul 20 04:36:47 2007

This archive was generated by hypermail 2.1.8 : Fri Jul 20 2007 - 04:38:22 PDT