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

With (muted) apology for following-up my own post, I ha

-- 
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: Jonathan Bromley 
> Sent: 12 July 2007 13:23
> To: sv-ec@server.eda-stds.org; sv-bc@server.eda-stds.org
> Subject: [sv-ec] Inconsistencies in virtual interfaces and modports
> 
> 
> To BC because it's about interfaces and modports,
> and EC because it's about virtual interfaces.
> 
> I'm sorry to beat on this yet again, but I'm pretty sure that
> we have some inconsistencies that are already causing serious
> problems with understanding, and look likely to cause 
> inconsistency of tool behaviour too.
> 
> 
> My first problem is purely one of LRM verbiage: we have 
> nothing in the LRM that makes this situation clear, and
> far less do we have any clear statement of the consequence:
> that putting a modport-type port in a module's port list 
> implicitly creates a variable in the module, whose contents 
> are continuous-assigned to the variable in the interface
> and whose name is "modport_name.variable_name".
> 
> An unequivocal definition would have spared Brad Pierce 
> the trouble of setting my understanding straight in
> 
>   http://www.eda-stds.org/sv-bc/hm/6265.html
> 
> However, if we accept this interpretation (modport
> output represents a continuous assign) then we have
> a serious inconsistency relating to virtual interfaces.
> It is currently illegal to do continuous assignment to a
> target of the form <virtual_interface>.<interface_member>.
> But it *is* legal to write to such a target procedurally.
> If the virtual interface variable is bound to a modport,
> and the interface_member is a modport output, then
> we have an implicit continuous assignment.  I think
> that's broken.
> 
> Should we make it illegal to bind a virtual interface
> to any modport that has outputs?  That would be workable -
> it would still be OK to bind the virtual interface to
> a modport that provides a clocking.
> 
> Or should we struggle with legitimising continuous 
> assignment via a virtual interface?  We could have
> done it by appealing to procedural assign/deassign,
> but that's been deprecated now....
> 
> Thanks
> -- 
> 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.



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