Understanding incremental detailed routing when placement changes

[gatecat]

I'm trying to work out the current state of post-DRT antenna fixups. When just trying a remove_fillers, repair_antennas, filler_placement, detailed_route sequence after detailed routing, I get a bunch of failures around pin access issues, so I thought I'd look at a more minimal example of DRT after placement changes ignoring the antenna fixer per se.

If I modify the existing incremental drt regression test thus:

source "helpers.tcl"

read_lef testcase/ispd18_sample/ispd18_sample.input.lef
read_def testcase/ispd18_sample/ispd18_sample.input.def
read_guides testcase/ispd18_sample/ispd18_sample.input.guide
detailed_route -output_drc results/ispd18_sample.output.drc.rpt \
               -output_maze results/ispd18_sample.output.maze.log \
               -output_guide_coverage results/ispd18_sample.coverage.csv \
               -verbose 0

# set net [[ord::get_db_block] findNet "net1231"]
# odb::dbWire_destroy [$net getWire]

set units [[ord::get_db_block] getDefUnits]
set inst [[ord::get_db_block] findInst "inst5821"]
$inst setLocation [expr round(42.6 * $units)] [expr round(42.75 * $units)]

detailed_route -output_drc results/ispd18_sample.output.drc.rpt \
               -output_maze results/ispd18_sample.output.maze.log \
               -output_guide_coverage results/ispd18_sample.coverage.csv \
               -verbose 0
set def_file [make_result_file ispd18_sample_incr_placement.def]
write_def $def_file

Then DRT (perhaps understandably, I don't know what the contract should be here?) doesn't notice the placement change and leaves the net as-is, now wrongly routed. If I uncomment the code that also unroutes the relevant net, then it is correctly re-routed based on the new placement as you'd expect.

I guess I have two questions here:

• Is post-DRT antenna fixing something that's expected to work yet?
• Is my minimal example tcl showing expected behaviour, if not, is it something that would help with making post-DRT antenna work if fixed?

[maliberty]

@osamahammad21 please respond

[osamahammad21]

Is post-DRT antenna fixing something that's expected to work yet?

Yes it has been tested and should be working. If you encounter an issue, please file a github issue with more details so that we could work on it.

Is my minimal example tcl showing expected behaviour, if not, is it something that would help with making post-DRT antenna work if fixed?

Yes this is the expected behavior for this case. As a rule, DRT only routes/reroutes unrouted nets. It doesn't touch already routed nets. So on the second call of detailed_route, DRT detects all nets as already routed so it does nothing. To let DRT reroute the desired net "net1231", you need to clear the net routing by uncommenting the commented lines.

[gatecat]

Thanks. As far as antenna fixing does, it's good to know it should work. So I have a better place to work on, what's the recommended flow sequence? Eventually I got it to work with the following changes to flow.tcl (e.g. on aes_sky130hd) - note that pre-GRT antenna fixup commented out so actually it has something to do:

diff --git a/test/flow.tcl b/test/flow.tcl
index a9bcb2717..f6a31b144 100644
--- a/test/flow.tcl
+++ b/test/flow.tcl
@@ -208,7 +208,7 @@ write_verilog -remove_cells $filler_cells $verilog_file
 ################################################################
 # Antenna repair
 
-repair_antennas -iterations 5
+# repair_antennas -iterations 5
 
 check_antennas
 utl::metric "GRT::ANT::errors" [ant::antenna_violation_count]
@@ -251,6 +251,36 @@ write_db $routed_db
 set routed_def [make_result_file ${design}_${platform}_route.def]
 write_def $routed_def
 
+## ****
+
+remove_fillers
+
+global_route -start_incremental -allow_congestion
+repair_antennas
+global_route -end_incremental -allow_congestion
+
+filler_placement $filler_cells
+
+set drt_ant_repair_db [make_result_file ${design}_${platform}_drt_ant_repair.db]
+write_db $drt_ant_repair_db
+
+# Run pin access again after inserting diodes and moving cells
+pin_access -bottom_routing_layer $min_routing_layer \
+           -top_routing_layer $max_routing_layer
+
+detailed_route -output_drc [make_result_file "${design}_${platform}_ant_fix_route_drc.rpt"] \
+               -output_maze [make_result_file "${design}_${platform}_ant_fix_maze.log"] \
+               -no_pin_access \
+               -save_guide_updates \
+               -bottom_routing_layer $min_routing_layer \
+               -top_routing_layer $max_routing_layer \
+               -verbose 0
+
+set repaired_db [make_result_file ${design}_${platform}_repaired_drt.db]
+write_db $repaired_db
+
+## ****
+
 ################################################################
 # Extraction

But if there's a more recommended way of doing things, I'd be interested to know.

[osamahammad21]

I'd say you pretty much got it right. I would recommend against running pin_access as a separate command if there is nothing to do after pin access and before detailed routing (to avoid overhead needed by both commands).

[osamahammad21]

Also, there is no guarantee that antenna violations would be fixed after running this flow for one iteration. You may need to run it for multiple iterations until you get 0 antenna violations. Something like this:

check_antennas
while { [ant::antenna_violation_count] != 0 } {
# repair_antennas flow
check_antennas
}

[gatecat]

Thanks, I've created #5565 which reproduces the issue I'm seeing