Re: [sv-bc] Modport expression examples

From: Steven Sharp <sharp_at_.....>
Date: Mon Dec 01 2008 - 17:10:50 PST
>From: jonathan.bromley@doulos.com

>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".

This description suggests that there is an item
portname.P inside the module, that is connected to E
in the interface instance.  I don't view it that way.

I would say that portname gives you access to items
inside the interface I, or in this case a modport
of interface I.  The reference to portname.P is a
reference to the item P inside the interface or the
modport, not to an item inside the module.

That item P inside instance I is an alias for the
expression E inside instance I.  The modport provides
that aliasing.

But I agree with the main point, which is that P is
what the module sees, and E is what is connected to
the "other side" of P (the side outside the module).
If you want to use the view of a modport as a set of
port connections, then P is the port seen inside the
module and E is what is connected to the module port.
 
>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.

Yes, I agree.

It is strange that the port directions are declared in
the interface, but are the directions as viewed from the
module.  Then when you accept that the directions are as
viewed by the module, the modport expressions seem backward.
The .P is the external name as viewed by the interface, not
as viewed by the module.  It is more like the internal name
when viewed by the module.  The .P in the modport declaration
is more like the .P in an instantiation than the .P in a port
declaration.


Steven Sharp
sharp@cadence.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Mon Dec 1 17:11:28 2008

This archive was generated by hypermail 2.1.8 : Mon Dec 01 2008 - 17:11:42 PST