Intuition about SV modports

An important ambiguity in the SystemVerilog standard is what an output direction specifier in a modport declaration means. See, for example, comments in Mantis 2114.

Simulators are consistent with each other that the specifier has little meaning, that writing across a modport-type port is no different than writing across an interface-type port, namely, by reference.

In my opinion, this interpretation is contrary to intuition and to the very first paragraph of the LRM section on modports

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.

My intuition says a modport is just a way to declare a nested interface, implicitly instantiated by the enclosing interface instance.

For example, suppose interface IFC declares

modport mp(input x, output y, import f);

then it’s as if it had instantiated and declared

mp mp(.*);

interface mp(input … x, output … y);
function … f(…) = IFC.f(…); endfunction

where the … abbreviates replicated signatures.

If is connected to a down-design, that’s exactly what’s connected — the nested interface instance — and references to the x and y in it are references to those ports x and y. For example, if x is a variable input port, then you can’t assign to it, and so on.

When a down-design port is declared or, that just means that references across the port must go to the nested instance.

If GEN[5].mp is a generated modport, then connecting GEN[5].mp or the down-design imposing IFC.GEN[5].mp works out naturally, too.

Aside: There seems to be some vague family resemblance here with the prototype-based inheritance and delegation of JavaScript or Self.



  1. I don’t have an answer for the “what is a modport output” problem. I tried to articulate the question in the DVCon-2009 paper you cited, and I suspect there is no good answer that meets the needs both of virtual interface access and of RTL/synthesis connection. Consequently, I like the embedded-interface-instance idea very much because it allows the inner “modport-like” interface to make decisions about port direction in a straightforward way. But it won’t be very much use in practice unless it’s synthesizable, and I’m pretty sure that is not the case at present.


    • Not sure what you mean by “synthesizable”, because I was just trying to give an intuitive explanation of how modports (which, if ungenerated and without modport expressions, are already synthesizable) seem to be behaving today.

      Are you thinking of avoiding the use of ‘modport’ declaration syntax in future RTL by enhancing the language to allow a module port declaration such as “” or “” to accept, in addition to a modport “mp”, also an embedded interface instance “mp”?


    • By the way, it doesn’t solve your problems either, but, except for the ability of modports to allow direct writes of interface wires and to export functions from one module to another, maybe they could be more naturally expressed as static classes.

      Consider that, except for output wires, there’s no need (in the LRM) to list any of the signals. Read and write access could be granted via interface methods. For example, instead of “output v”, an interface task “write_v()” could be listed in the modport declaration.

      A static class declared there could define the same methods, granting the same access. It could still be communicated over a module port, such as

      module m(IFC ifc, …);
      typedef ifc.T T;
      … T::write_v(…); …

      But to me the more natural way would be to pass it as a type parameter

      module m#(type T)(…);


      instantiated as say

      IFC ifc();
      m#(ifc.T) m_inst(…);

      without any need to pass a reference to the interface instance.


  2. Brad,

    Steven Sharp has recently aired this notion, and I too have considered it. Broadly I agree with you. However, the extra layer of instance hierarchy will, I fear, make this intractable for synthesis.

    If synthesis tools could agree that this is what a modport really is, and we could come up with a set of synthesis-only restrictions on the inner modport-like interfaces to make that workable, then it would be a great approach that could have big benefits in practice. Aside from the issues you raise here, one of the big bugbears of modports is that they don’t have a clear life of their own as instances; this makes things very difficult when you want to reason about multiple modports of the same kind, or multiple connections to the same modport.

    I still prefer the idea outlined in Mantis 1861 (but then I would, since it was I who proposed it!!). In practice, though, the effect for the end user is much the same, I think.

    Thanks for the clear exposition.



    • But the issue is not just about synthesis tools. What is the resolution of Mantis 2114 that I mention in my opening paragraphs?


Tell me (anonymous OK)

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s