verilator
Modport item not found (w/ --hierarchical)
I'm attempting to switch a build from monolithic to hierarchical verilation and am getting this error:
%Error: SomeIntf.sv:31:15: Modport item not found: 'data'
: ... note: In instance 'foo.bar.baz'
If I run verilator without --hierarchical verilation completes. I get this error for every modport member of a number of interfaces (possibly every interface in the design, I'm not sure). The in instance message is a red herring as this interface is not instantiated at that scope. I think this may be AstNode::instanceStr() going off the rails and finding the first scope or module in the backp chain from an interface. Side question: if I'm right, is it possible to make instanceStr() know and report that it doesn't know what's going on instead of yielding incorrect scope information?
I see that LinkDotIfaceVisitor::visit(AstModportVarRef*) is throwing the error because findIdFallback() fails to give us a symbol table. This is where I start to get fuzzy about what's going on. If MODPORTVARREF belongs to a IFACE and IFACEs are not concrete / instantiated and therefore don't have symbol tables like the CELLs that point at IFACEs, what should findIdFallback() return?
When I compare against t_hier_block which also does --hierarchical with interfaces inside of a hier_block module, this modport var ref:
Breakpoint 2, LinkDotIfaceVisitor::visit (this=0x7fffffffc250, nodep=0x555556eefba0) at ../V3LinkDot.cpp:1956
1956 ../V3LinkDot.cpp: No such file or directory.
(rr) p AstNode::dumpGdb(nodep)
This=MODPORTVARREF 0x555556eefba0 back=0x555556eed200 headtail=this iterpp=0x7fffffffc088
Fileline = t/t_hier_block.v:20:38:
MODPORTVARREF 0x555556eefba0 <e1095> {f20bm} data INPUT -> VAR 0x555556ee57a0 <e8750> {f18aq} @dt=0x555556fb00c0@(G/w8) data [VSTATIC] VAR
is able to get a symp:
(rr) p symp->m_parentp
$10 = (VSymEnt *) 0x5555570c02d0
via the first fallback symbol table:
(rr) p m_curSymp->m_fallbackp
$4 = (VSymEnt *) 0x5555570c02d0
(rr) p AstNode::dumpGdb(m_curSymp->m_fallbackp->m_nodep)
This=CELL 0x555556fb45a0 back=0x555556fb4240 next=0x555557001440 headtail=0 user1p=0x5555570c02d0
Fileline = t/t_hier_block.v:145:13:
CELL 0x555556fb45a0 <e2114> {f145an} u1=0x5555570c02d0 sub2__DOT__in_ifs -> IFACE 0x555556ee5560 <e7107> {f17al} u1=0x5555570c0360 u4=0x1 byte_ifs L4 [LIB] [1ps]
My (failing) example has the same symbol table fallback chain (MODPORT -> CELL -> NETLIST). So now I'm wondering why my CELLs symbol table is missing entries (or something)
I'm still trying to both reduce this problem into a test_regress test and understand what's gone wrong via the debugger. However, if anyone has any suggestions on what is going on here or how to isolate the problem, that would be greatly appreciated.
Are the interface instances "above" the hier split point, "crossing" it (which won't work as not supported - but you seem to say you're not doing this), or "below", or both above and below?
if I'm right, is it possible to make instanceStr() know and report that it doesn't know what's going on instead of yielding incorrect scope information?
Would be helpful, yes.
Are the interface instances "above" the hier split point, "crossing" it (which won't work as not supported - but you seem to say you're not doing this), or "below", or both above and below?
They are above and below, but not crossing.