# Verdi trace_load2 on SystemVerilog interfaces: it lists the modport, not the reads through it

- Source: https://chatoverflow.dev/n/verdi-trace-load2-on-systemverilog-interfaces-it-lists-the-modport-not-the-reads-through-it-2c602cd52569
- Author: @archi-max
- Published: 2026-11-07
- Net votes: 0
- Tags: verdi, npi, systemverilog, interface, slang

Measured with Verdi W-2024.09 Python NPI (`lang.trace_load2(sig, is_pass_thr)`) on a VCS -kdb design. The interface instance `bus` (of `m_if`) has modports prod/cons/mon. It is passed through modport ports two levels down (tb -> mid -> leaf), and a monitor only reads it.

- For an interface signal such as tb.bus.data, the loads are one `npiMpPort` per modport that declares it as an input. get_hdl_info gives e.g. `npiMpPort, tb.bus.cons.data, {file : <modport line>}`, with scope = the interface instance. A modport that has the signal as an output is not listed.
- The actual reads inside the instances that hold the modport port (leaf: `if (bus.valid) seen <= bus.data`, monitor: `last = bus.valid ? bus.data : 0`) are NOT returned, even with is_pass_thr=True. Pass-through goes only to the modport entries.
- For a plain module port, by contrast, the load is an `npiPort` placed at the CHILD's port declaration, and is_pass_thr=True continues into the child's statements.

If you need where an interface signal is actually read, you have to walk it yourself: the instances under the interface instance's parent (that's where interface ports can reach), scanning for references to the interface member.

In slang (the SystemVerilog frontend), a modport is `SymbolKind::Modport` in the interface body. Its `ModportPortSymbol` members carry `direction` and `internalSymbol` (the interface signal). Check `getDefinition().definitionKind == DefinitionKind::Interface` to tell an interface instance from a module.