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

 
Thanks for the description of the intent of modports. I agree with you
that the intent of
of direction specification restricting the access can be followed
regardless of the 
implementation. Access to modport port input variables and modport port
output variables can be enforced.
I am still not clear with interface modport tasks accessing interface
variables.
Can a task present in a modport be able to access in *any way* any
interface variable or
is the access restricted by the modport directions for the variables if
present in the modport?

Francoise
    '

-----Original Message-----
From: Rich, Dave [mailto:Dave_Rich@mentor.com] 
Sent: Tuesday, February 27, 2007 8:10 PM
To: Steven Sharp; Francoise Martinolle; Mark.Hartoog@synopsys.com;
sv-bc@eda-stds.org
Subject: RE: [sv-bc] Are modport port directions enforced?

Unfortunately, most of the interface section is still in its description
by example form from Superlog. No one has had the stamina to re-write it
in a more IEEE-like normative form.

First, let's get the modport/no modport confusion out of the way. You
can ALWAYS create a modport that has the same behavior as an interface
with no modports (The reverse is not true because of modport expressions
and exports).

interface data_if ();
logic [31:0] d;
wire w;
modport in  (input d);
modport out (output d);
modport implicit_modport (ref d, inout w); // See 20.2.2
endinterface: data_if

So let's assume we always have a modport for the purposes of this
discussion.

Now let's take a look at "access" rights. The only clue the LRM provides
is in 20.4 " To restrict interface access within a module, there are
modport lists with directions declared within the interface. The keyword
modport indicates that the directions are declared as if inside the
module."

I think most people take that to mean, from the connected module's
perspective, the access rights are the same as if each object in the
interface were a separate port. For wires, we have come to the
understanding the direction is ignored for simulation and just a
suggestion for synthesis tools.

However for variables, there is stricter language. Even removing the
rules for single continuous drivers, we have from 19.12.1: "Assignments
to variables declared as an input port shall be illegal." and
"Procedural or continuous assignments to a variable connected to the
output port of an instance shall be illegal."

These rules can be followed irrespective of the underlying
implementation creating an implicit continuous assignment to a local
variable or using a local name for hierarchal reference. So a module
cannot make any assignment to variable declared as an input in the
modport of a connected interface port, and no one can make an assignment
to variable declared as an output in the modport of a connected
interface port except from that connected module.

The LRM section on virtual interfaces is muddier, but I think the same
rules apply. Remember that you can only make procedural assignments to
virtual interface variables. From the perspective of the reference to
that virtual interface's modport, you should not be able to assign to a
variable declared as an input. Nor should you be able to assign to any
virtual interface variable if there is another continuous assignment to
that interface variable. 

On the issue of access rights to variables called from tasks where the
modports don't list the all the signals that the tasks refer to: 

My interpretation is that when you call a task via interface port, you
are using a local name for hierarchical reference, just like a ref port.
So once the task is called, it the same as if you used the actual
hierarchical reference. This is the same a class method that has access
to local members of its class, even though the caller of that method
does no have access to those members directly.


Dave


> -----Original Message-----
> From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
On
> Behalf Of Steven Sharp
> Sent: Tuesday, February 27, 2007 1:15 PM
> To: fm@cadence.com; Mark.Hartoog@synopsys.com;
sv-bc@server.eda-stds.org;
> sharp@cadence.com
> Subject: RE: [sv-bc] Are modport port directions enforced?
> 
> My understanding of interfaces was as follows:
> 
> An interface instance is much the same as a module instance, with some

> exceptions.  One of those is the ability to pass it through a port.
> Since there is no concept of copying an instance, this means you are 
> actually passing a reference to the original instance through the
port.
> This reference can effectively be used as the starting point for an 
> XMR into the interface, to access the objects encapsulated in it.
> This gives the same effect as if the variables in it had been passed 
> through ref ports, and the nets through inout ports.
> 
> I am now hearing an alternate interpretation that seems to be based on

> the way that synthesis tools handle interfaces, by breaking them down 
> into their component parts and treating them like a lot of ordinary 
> ports.  Interface ports without modports would treat the variables and

> nets as ref/inout ports because that is what the rules say to do, not 
> because that is what passing a reference to an entire interface would 
> do.  Interface ports with modports would create the equivalent of 
> separate input/output/whatever ports for each port connection, 
> complete with implicit continuous assignments.
> 
> I can certainly see how that viewpoint is convenient for synthesis, 
> since it is expressible by decomposing it into older constructs.
> But synthesis only has to handle a subset of interfaces.  I don't 
> think that this viewpoint extends well to all the things that you can 
> do with interfaces.
> 
> For example, you can have tasks in interfaces that are used to access 
> the objects in the interface.  These tasks can be called from 
> different modules where the interface has been passed.  If passing the

> interface is making copies of the objects in the interface, then which

> object is the task supposed to access?  Does it access the copy that 
> is visible to the module doing the call?  I am not sure how that would

> be implemented, and it probably wouldn't have the expected behavior.  
> But if it accesses the original object in the original instance, then 
> you are back to ref behavior.  Then direct accesses to the objects and

> accesses through tasks would not have consistent behavior.
> 
> As another example, what happens if you take an interface passed 
> through a module port and assign it to a virtual interface?  If the 
> interface passed through the port is a reference to the interface, 
> then the meaning is clear.  The virtual interface now refers to that 
> same original interface.  But if passing the interface through ports 
> has created copies of some of the objects in it, what objects does the

> virtual interface reference?  Does it reference the copies in the 
> module with the interface port?  Again, that seems rather nasty to 
> implement, and probably not the expected behavior.  But if it accesses

> the original interface instance, then you are back to the interface 
> port being treated as a reference to the instance.  You are back to 
> ref behavior, and you have inconsistencies between accesses through 
> the interface port, and through a virtual interface that has been 
> assigned the same interface.
> 
> This second issue may not have existed in 1800-2005, since you could 
> not have a modport variant of a virtual interface.  But I believe this

> has now been added to the next draft.  Perhaps Dave Rich can comment
on
> how he expected this to work.
> 
> We seem to have two different underlying models of how interfaces are 
> supposed to work, and they are not compatible.  Different parts of the

> LRM description seem to have been based on different models, so they 
> can't be reconciled with each other.  Perhaps there is some other
model
> that encompasses all these semantics in a consistent way, but I don't 
> see it.
> 
> Steven Sharp
> sharp@cadence.com
> 
> 
> --
> 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.