Looking up modport drivers from their loads

[jameshanlon]

Following on from #1510, I can now access the drivers for output modports of an interface.

What I am pondering is how to go about identifying uses of these outputs. For ports, it is straightforward because you can just look up the drivers via the ValueSymbol. But for interfaces, the connection depends on modports and member selection.

In the example from the issue:

interface I;
    logic l;
    modport mst ( output l );
    modport slv ( input l );
endinterface

module m(I.slv i);
    logic x;
    assign x = i.l;
endmodule

module n(I.mst i);
    assign i.l = 1 ;
endmodule 

module top;
    I i();
    m u_m(i);
    n u_n(i);
endmodule

modport I.l is driven by the continuous assignment in u_n (resolved by the DriverTracker logic).

Then, i.l appearing in u_m is a hierarchical reference with the slv modport specifier, referencing the input modport.

What I want to be able to do is look up the driver of i.l from a use of i.l, but it's not obvious how I should go about it.

My thinking so far is to follow the interface connection to the instance as in noteInterfacePortDriver, then identify the modport that is the driver and use that to do the driver lookup.

Any pointers appreciated!

[MikePopoloski]

If you operate on the underlying variable instead of the modport port I think this becomes much easier, since the drivers get propagated to the variable symbol. The modport itself is sort of a fiction that exists only to translate the lookups; you can have modports with explicit ports that don't actually exist as underlying symbols, like e.g.

interface I;
  logic a, b;
  modport m(input .foo({a, b}));
endinterface

module n(I.m i);
  assign x = i.foo[0];
endmodule

module top;
  I i();
  assign i.a = 1;
  n n1(i);
endmodule

In this case there's no good way to know that the driver of i.a references the same bit as i.foo[0] unless you look at the final propagated drivers / the actual interface symbols instead of the modport ports.

[jameshanlon]

Thanks @MikePopoloski, that's super useful.

[jameshanlon]

Having played around with this a bit more, I still can't quite achieve what I want to. (Or maybe I'm still taking the wrong approach...)

I take your point about operating on the interface variables rather than the modports, but I still can't see a straightforward way to go from a lsp / hierarchical expression (whether it be an lvalue or rvalue) and use that to resolve to the corresponding interface member variables without recursing through the modport connection expressions.

The ValueDrivers for the interface members point to the symbol that contains the driver, but the prefixExpression does not match the references.

[MikePopoloski]

Yeah, you do need to translate references to the modport ports you find in expressions via their connection expressions. It gets annoying when there's an outer select expression and the modport connection itself also has a select expression; DriverTracker::propagateModportDriver handles this but it occurs to me now that this should probably be represented in the AST somehow so that downstream consumers can just use it without thinking about it too hard. Not sure what that should look like though, I'm open to suggestions.

[jameshanlon]

Thanks - I'll have a go at getting this to work and let you know what I come up with.

[jameshanlon]

Sorry to drag this question out! But, going back to your previous comment regarding the connection expression in the modport port (modport m(input .foo({a, b}));).

In this case there's no good way to know that the driver of i.a references the same bit as i.foo[0] unless you look at the final propagated drivers / the actual interface symbols instead of the modport ports.

I must be missing something, but I can't see how the driver tracker resolves the bit positions of a and b in the concatenation {a, b} to link eg i.foo[0] to a. The code goes from an LSP referencing the modport, through it's connection expression, to the value symbols a and b using visitLSPs(). Calling getBounds on the terms in the expression just yields bounds for those values.

This same thing applies generally to connection expressions in port hookups and in assignments to/from concatenations. So how is it handled?

[MikePopoloski]

DriverTracker::propagateIndirectDriver "glues" the outer select expression onto the modport connection expression, so you get an LSP that's like {a, b}[0]. This is sort of hacky and probably doesn't fully work correctly. It's something I'm looking at right now, especially in the context of ref ports which need to work the same way.

Other regular ports (output, inout) don't have this same problem, because the assignment that happens internally to the port doesn't matter when considering how the external connection is driven. The external connection always counts as a continuous assignment to whatever the connection expression happens to be, so it's relatively straightforward.

[jameshanlon]

But the expression {a, b}[0] is not an LSP in itself. I would expect the LSPUtilities::visitLSPs() function called on that expression to visit b, which is the only LSP of the expression and it currently does not do.

[MikePopoloski]

Yeah, it seems to be broken for concats right now. That is how it should work though.

[MikePopoloski]

After looking at this more and fixing a few things, I believe the case with concatenations is now handled "correctly". The LRM is completely silent about how this is supposed to work and most tools I've tried don't support modport expressions at all or are riddled with bugs so there's not really a consensus anyway.

Modport expressions that are assignment pattern lvalues still don't count as an LSP themselves in slang (I can't figure out how that should even really work) so a write to such a modport port still counts as driving all of the members of the assignment pattern expression, even if the write expression includes some kind of selector that would exclude some of them.

This stuff is now exposed for downstream use via the LSPUtilities::expandIndirectLSPs method, which should hopefully Do the Right Thing for modport ports and ref ports.

[jameshanlon]

Thanks @MikePopoloski. That does clear things up now and I'm now seeing the behaviour I expeced.

On a related note, when I mentioned port connections before, I was thinking of a situation like the following, where concatenations apply variables to different load/driver ranges:

module x(input logic [1:0] x,
         output logic [1:0] y);
  assign y = x;
endmodule

module m(input logic a,
         input logic b,
         output logic c,
         output logic d);
  x ux (.x({b, a}), .y({d, c}));
endmodule

Or somewhat equivalently:

module m(input logic a,
         input logic b,
         output logic c,
         output logic d);
  assign {d, c} = {b, a};
endmodule

Am I correct in understanding that as far as slang is concerned, values that occur on the left-hand side of a continuous assignment are recognised as only being driven by the statement and there is no further link between the right-hand side values? This is something that I was wondering about doing with my netlist tool. Presumably the logic that you have added for handling modports could be applied to resolving this.

[MikePopoloski]

Yeah, there is no mechanism in the language for linking the two sides of the concat like that. The way expression evaluation works, the right hand side is evaluation, results in a flat bit vector, and then that bit vector is applied to the left hand side, at which point it will be decomposed again. Another way of looking at it is that the LRM does not provide for a concat to be part of a LSP.

With your example it seems clear that there is a correspondence between the variables, but it gets murky very quickly when there are different numbers of elements, nested concats within the elements, vectors of differing bit widths or with ranges reversed, differing total bit width such that an implicit conversion is applied, etc.

[jameshanlon]

Another way of looking at it is that the LRM does not provide for a concat to be part of a LSP

That's an interesting way of looking at it and also why I was curious when you mentioned it previously in this conversation.

Thanks for taking the time to answer my ponderings.