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

Stu,

I'm not clear what you mean by "single source semantic". 

Maybe you mean that, for example, if an interface variable is listed in
two modports as an 'output', then it would be illegal for both of those
modports to be used with the same interface instance?  For example, it
would be illegal to have a modport like

        modport mp(..., output a, ....)

for some interface variable 'a' and then to write

        IFC ifc();
        bot1 inst1(ifc.mp, ...);
        bot2 inst2(ifc.mp, ...);

If an 'output' variable in a modport implies an output port in the
receiving module, then such restrictions follow immediately from the
restrictions on multiple continuous assignments to variables, since an
output port is a continuous assignment.

If an 'output' variable in a modport, however, implies only a ref port
in the receiving module, then, yes, the LRM needs to be much more
explicit about which additional restrictions 'output' imposes on the use
of this ref port.  And the LRM should remove the claim that

  "The keyword modport indicates that the directions are declared as if
inside the module."

An output declaration inside the module implies continuous assignments
to the parents of its instances.

Maybe 'output' on an interface variable in a modport indicates that, if
the modport is used with an instance of this interface, then the only
way to write to the interface variable of that instance is via that
modport, and moreover, that such a modport can be imposed at most once
per interface instance?

The above example would remain illegal under that rule, even if no
longer because multiple continuous assignments to a variable are
illegal.
 
-- Brad
 
-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Stuart Sutherland
Sent: Thursday, July 19, 2007 10:35 PM
To: sv-ec@eda-stds.org; sv-bc@eda-stds.org
Subject: RE: [sv-bc] RE: [sv-ec] Inconsistencies in virtual interfaces
and modports


I would like to add support for Jonathan's suggestion that the standard
be more explicit that variables used in interfaces have a single source
semantic.  This has been my expectation all along, and I teach that rule
in my training courses.  Students, read "users", agree that this is an
important semantic restriction on the use of variables.  In fact, this
very topic came up in a class I was teaching today, and the student
asking the question wanted assurance that the use of variables in an
interface would enforce the single-source coding style required in their
design work.

The same semantic restriction needs to be enforced when uwire is used in
an interface.

Stu
~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
Sutherland HDL, Inc.
stuart@sutherland-hdl.com
503-692-0898
 

> -----Original Message-----
> From: owner-sv-bc@server.eda.org
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Jonathan Bromley
> Sent: Wednesday, July 18, 2007 6:01 PM
> To: sv-ec@server.eda-stds.org; sv-bc@server.eda-stds.org
> Subject: [sv-bc] RE: [sv-ec] Inconsistencies in virtual interfaces and

> modports
> 
> With (muted) apologies for following-up my own post...
> 
> > 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
> 
> Of three major simulators:
> - One doesn't error on multiple explicit continuous assigns
>   to a variable - not even when both assigns are in the same
>   scope as the variable itself -  so it's no big surprise 
>   that it also doesn't error on multiple writes to a 
>   variable in an interface via "output" modports.
> - Two correctly report multiple explicit continuous assigns
>   to a variable, but do NOT report any error on multiple 
>   writes to an interface variable via "output" modports.
> 
> So there is *absolutely no* de-facto support for the consensus opinion

> I mentioned in the earlier post, but there is strong de-facto support 
> for the "output === ref" position that I mistakenly took earlier in 
> the discussion.
> 
> Do I simply submit bug reports to three vendors, or do we need some 
> LRM clarification?
> --
> 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.


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