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

From: Jonathan Bromley <jonathan.bromley_at_.....>
Date: Fri Mar 02 2007 - 01:32:02 PST
Françoise,

> I was just trying to tell Jonathan that there are
> visible differences in a ref versus an output port.

I agree (and I *think* I already understood!).  However, 
as I've already pointed out, there are legal orderings 
for the action of a continuous assignment that would 
give no visible difference between ref vs. output in 
the way a target variable is updated.

> In summary, modport port directions for variables
> should be enforced by a simulator.
> modport port directions for nets are not enforced.

Sorry to restate this, but that's not the whole story.

  interface I;
    logic L;
    modport MP(output L);
  endinterface : I

  module M(I.MP mp);
    initial ... mp.L = <something>; ...
  endmodule : M

  module Top1;
    I inst_I();
    M inst1_M(inst_I.MP);
    M inst2_M(inst_I.MP);
  endmodule : Top1

Within M, the syntax "mp.L" looks very much like a
reference to the L inside I.  Indeed, if the modport
were *not* used, then there's no doubt that it would
be exactly a reference to the variable and thus 
two instances of M connected to the modport is OK.  
If, however, the "modport output" enforces the usual 
rules for an output port, then having two instances
of M is illegal because it represents two continuous
drivers on Top1.inst_I.L

This issue is not directly related to enforcement of
direction by the modport.  It is an issue on which
tools currently disagree.  Dave's position seems to be
that the no-multiple-driver rule should be enforced
when a modport is used in this way, just as if there
were a continuous assign across the modport; I 
completely agree, but it needs defining.

Suppose, then, that we accept this and so we are
permitted only one instance of M:

  module Top2;
    I inst_I();
    M inst_M(inst_I.MP);
  endmodule : Top2

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 ?
-- 
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 Mar 2 01:32:28 2007

This archive was generated by hypermail 2.1.8 : Fri Mar 02 2007 - 01:32:54 PST