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.