RE: [sv-bc] Are modport port directions enforced?

Gord,

...
> > What happens if I now force Top2.inst_I.L?  Is that
> > force reflected in the value of mp.L as seen inside
> > Top2.inst_M ?
> 
> No, it wouldn't be due to the continuous assign
...
> I think that the answer is different if "L" was a net
...

All agreed.  But there's a nasty internal contradiction,
or at least a confusion, here....

* When a regular module has an output port that's connected
to an ordinary variable in the instantiating scope, we
all agree there's an implied continuous assignment from the
output-port variable or net **declared inside the module** 
to the variable **declared in the instantiating scope**.
All is clear; there are two distinct objects, linked by
unidirectional continuous assignment across the module boundary.

* When a module hooks to an interface without a modport,
and writes to a variable in the interface, it does so
by reference using a slightly unusual form of dotted name.
All is clear; there is precisely one variable, in the interface.

* When a module hooks to an interface's modport that has
an output to a variable in the interface, it drives that
variable by what looks - syntactically - like a reference.
THERE IS NO OUTPUT-PORT VARIABLE INSIDE THE MODULE.
Yet we all seem to be agreeing that there is an implicit
continuous assignment from such a thing to the variable 
in the interface.  In other words, we must imagine a
new phantom variable for each output in the modport,
and then have an implicit continuous assign from that
phantom variable to the real variable in the interface.

In the absence of any force on the interface variable,
we lose nothing by merging these two variables
so that they are one and the same - we revert to 
using a reference.  So we must conclude that the
main impact of "output <some_variable>" in a modport
is to prohibit any writing to that interface variable, 
other than from the one and only module connected 
to the modport.

This is, at best, curious and non-obvious.
I have not yet tried to reason about its impact
in the presence of virtual interfaces.
-- 
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.