Closed seldridge closed 2 years ago
This is pretty interesting. We might want to prefix the hierarchical name with the module name of the parent at which we want to start descending down. That should make all these cases unambiguous.
There's a larger problem here of what happens when the DataTap
module wants a port called bar
. That would shadow the bar
in the parent module that bar.r
wants to look into. We probably want GCTDataTap.bar.r
in this case.
This is fixed on main
, though I'm not sure exactly where/when. The current output with the correct XMR is:
module DataTap_impl_0(
output _0);
assign _0 = GCTDataTap.r;
endmodule
Currently, if you try to data tap into the current module, the generated XMR will have no hierarchy. I don't think this will resolve correctly. Instead, there should be an additional level of hierarchy.
Consider (and sorry for the verbosity) the following. This is trying to tap
~Top|GCTDataTap>r
:The generated XMR is:
And for confirmation that this is a problem, Verilator can't find
r
:However, if I instead tap
~Top|Bar>r
, everything works. This produces the following Verilog and Verilator is happy:(Also, who knew that Verilator could handle hierarchical references? To test this, I'm just using
firtool Foo.fir | verilator --lint-only /dev/stdin
.)