RE: [sv-bc] Modport expression examples

First, I want to say that I wish interfaces would disappear from the
language.

Now that I've got that off my chest, here's my reply:

modports are not creating module ports; they are access control lists.
Although modports borrow a lot of syntax and semantics from module
ports, they have their own set of rules. You should not assume any rule
for a module port/connection applies to a modport unless it is
explicitly mentioned.

Also, concerning your earlier statement about the default to a net type:
 
> I question this for two reasons. First, x is of type int, which is a
2-state type.
> The rules state that "input int x" should not be legal because it
defaults > to a net type and 2-state types are not allowed to be nets,
so the keyword "var" should need to be added.


This rule is backwards incompatible with Accellera SV, and no
implementation that I'm aware of disallows:

module dff(input bit clk, d, output q);

Regardless, modports do not allow you to specify data types or kinds.

Dave


> -----Original Message-----
> From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
On
> Behalf Of Bresticker, Shalom
> Sent: Monday, December 01, 2008 7:19 AM
> To: Jonathan Bromley; sv-bc@server.eda.org
> Subject: RE: [sv-bc] Modport expression examples
> 
> Jonathan,
> 
> Your answer brings up a more basic question that I should have thought
of.
> 
> The example has:
> 
> interface I;
> 	logic [7:0] r;
> 	const int x=1;
> 	bit R;
> 	modport A (output .P(r[3:0]), input .Q(x), R);
> 	modport B (output .P(r[7:4]), input .Q(2), R);
> endinterface
> 
> module M ( interface i);,
> 	initial i.P = i.Q;
> endmodule
> 
> I want to ask about the initial statement in module M.
> It has hierarchical references to the explicit port names in the
modport
> declarations.
> However, in the case of explicit port declarations in modules, you
cannot
> do this.
> You can only use these port names for port connections.
> 
> For example,
> 
> module m(.P(a));
> input a;
> endmodule
> 
> module top;
> initial $display(m.P);
> endmodule
> 
> This code is not legal. I can only use P to connect to m, as in the
> following instantiation statement:
> m m1(.P(0));
> 
> So how can I reference i.P and i.Q?
> 
> And if modport expressions work differently than explicit module port
> declarations, then its rules are very undefined.
> 
> > A modport expression is _not_ the same as an explicit port
> > declaration, despite the fact that the modport is at least in
> > some sense a description of part of a module's port list as I said.
> >
> > Given
> >
> >   interface I();
> >     ...
> >     modport M(input .P(E));
> >     ...
> >
> > the modport expression .P(E) says "when a module connects its
> > port "portname" to this modport in some instance of interface
> > I, the module's item portname.P should be connected not to
> > the internal object P of the connected interface instance,
> > but instead to the expression E in that instance".
> > It is perfectly sensible for a module's input port to be
> > connected either to a const int or to the literal '2',
> > surely.  I think the examples are OK.
> 
> Regards,
> Shalom
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> 
> 
> --
> 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.