The-OpenROAD-Project
extra blocks appear after linking
Describe the bug
During linking we seem to create additional blocks, which was causing a segfault in #7436 .
This seems to be related to this name compare which fails when the name contains an escaped charater: https://github.com/The-OpenROAD-Project/OpenROAD/blob/519227d1a0926e865af5887465991bc3c456e8aa/src/dbSta/src/dbReadVerilog.cc#L1052
Expected Behavior
No additional blocks due to incorrect compare.
Environment
v2.0-21734-g1c4c2db79d
To Reproduce
https://drive.google.com/file/d/1Pdtw2KAbSgkG2IO9rLblnTbYMzidjf_4/view?usp=sharing
tar xvf sc_issue_black_parrot_job0_asap7_asap7sc7p5t_rvt_floorplan.init0_20250526-173659.tar.gz
cd sc_issue_black_parrot_job0_asap7_asap7sc7p5t_rvt_floorplan.init0_20250526-173659
./run.sh
Relevant log output
Screenshots
Additional Context
No response
The run.sh seems to be running a whole bunch of steps. Is this the right script?
@maliberty yes, it's just initializing the floorplan, but I've reuploaded it with everything commented out: https://drive.google.com/file/d/1mPKRoMT1d0HtB0BtGOH3cI_s1HJ_KB8f/view?usp=sharing
I see that @precisionmoon added Verilog2db::processUnusedCells which is what is instantiating your extra block. The intended use model is for operator mapping where we get uninstantiated alternate implementations of operators from yosys. It appears in your case you just have an uninstantiated module in your netlist (bp_me_stream_pump_control$bp_multicore.cc.y\\[0\\].x\\[0\\].tile_node.tile.core.fwd_xbar.sink_comb\\[0\\].pump_control).
Is this intentional?
I see it is marked keep_hierarchy :
(* keep_hierarchy = 1 *)
(* src = "inputs/bp_multicore.sv:83614.8" *)
module \bp_me_stream_pump_control$bp_multicore.cc.y[0].x[0].tile_node.tile.core.fwd_xbar.sink_comb[0].pump_control (clk_i, reset_i, header_i, addr_o, ack_i, last_o, first_o, critical_o);
Should we limit unused modules to arithmetic modules with some attribute?
That would make sense. I believe there is one we use to know about the operator we are swapping.
I see that @precisionmoon added Verilog2db::processUnusedCells which is what is instantiating your extra block. The intended use model is for operator mapping where we get uninstantiated alternate implementations of operators from yosys. It appears in your case you just have an uninstantiated module in your netlist (
bp_me_stream_pump_control$bp_multicore.cc.y\\[0\\].x\\[0\\].tile_node.tile.core.fwd_xbar.sink_comb\\[0\\].pump_control).Is this intentional?
Looks like yosys might not have cleaned that one up, I'll have to take a look at that. @precisionmoon I think limiting the unused modules is a good idea. @maliberty I'm not sure the GUI knows what to do correctly with these "extra" modules, the whole run I had the images generated where empty. Is there something we need to do to make the GUI (and gui tcl commands) properly handle this case? or should the gui not display these, since they are not actually physical implementations but meant to be placeholders for the operator mapping?
The multiple tabs was intended for a 3D-IC demo usage and is lightly tested. I wasn't intending for it to show up here.
@maliberty after much poking around in synthesis it looks like when abc is called in yosys these modules outputs are left disconnected despite being corrected before the call. So it looks like an issue in yosys (a pretty bad one at that if I'm correct).
I think the action on this issue for OpenROAD is to add the checks for arithmetic modules on unused imports.
https://github.com/The-OpenROAD-Project/OpenROAD/pull/7626 should take care of limiting unused modules to arithmetic ones only.