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

Brad Pierce wrote:
> Jonathan,
> 
> Here's an argument against "as-if" continuous assignment semantics for
> 'output' modport components and in favor of the idea that 'output' on a
> modport variable merely imposes a single-driver restriction atop the
> usual 'ref' semantics.

Offered, I presume, as further consciousness-raising not as a firm
counter-argument, right?

> Consider --
> 
>    What about an interface variable that is written from within an
> interface task that is enabled by a module?  That is, the module writes
> to the interface variable via a side-effect of the interface task (not
> via an output port of the task).  Let's suppose throughout that the
> interface instance is connected to the module port using a modport.
> 
>    If the variable is not listed in the modport, the assignment uses
> 'ref' semantics -- multiple modules can enable the same interface task,
> assigning to the variable with last-write-wins semantics.

This is a typical simulation start point.
But then the designer must begin migrating to synthesis, and
there we seek to make all cross-module communication explicit
using module ports.

>    If the variable is listed in the modport as 'output', however, what
> effect does that have on the assignment to it from within the task?

Here's an argument saying it could have some effect: Although
a modport declaration is not a guarantee that the interface
has instances which will be passed via port connections, it does
signal that this is a possible use for the interface, so the
name "o" is constrained by the worst case that can legally happen
if the modport API is exercised to its fullest extent.

In that worst case, there is a live continuous driver of "o".
If procedural assignments to "o" occur inside the task, this
needs to be treated "as if" o had such external drivers.

>    Another viewpoint is that, somehow, listing the variable in the
> modport causes the "o = ..." in the interface task body to be
> interpreted as "ifc.o = ..." if the task is enabled by a module that is
> using that modport.

That is the only synthesizable interpretation we have for such
a reference.  It acknowledges that cross-module communication
is being used, and makes that explicit in the hierarchy.  As
you know this is not always a welcome discovery to the design
authors.  Like time 0 initialization, it is another area of
simulation semantics that was convenient during early work, but
whose details must be settled by either the designer himself
or a point-tool for simulation-synthesis migration.  There is no
one right way to replace last-write-wins semantics - unless we
specify some particular async bus resolution component whose behavior
matches simulation semantics.  Having that would extend synthesis'
semantic reach to cover this difficult case.  I'm not a EE, so
I don't know if there are conventional solutions to this problem,
or if they would be considered suitable for automatic inference.

Greg


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