[sv-bc] 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.

Recent discussion of the semantics of a modport element with
output direction has converged on the idea that modport output
to a variable in the interface represents a continuous 
assignment to the variable from something in the connected
module.  I'm fairly sure that most tools currently get 
this wrong, but we'll let that pass.

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.