Metal Spacing violation between interconnect and macro (sky130)

[Dolu1990]

Description

Hi,

Got Detailed Routing step failing on multiple "violation type: Metal Spacing". They all seem of the same nature, comming from the interaction between the power network and the routed connection to openram macro pin.

Here are some screen shot to illustrate. Failing one :

Location of one violation (bbox in blue) : violation type: Metal Spacing srcs: inst:GSharePlugin_logic_mem_counter net:net162 bbox = ( 2175.18, 1227.87 ) - ( 2177.33, 1228.15 ) on Layer met4

Seems to me, that the presence of the power network (the chunky strips comming from the top) push the pin connection to go too close to the macro, generating the violation.

Note that were there is no power strip, the connection to the macro doesn't generate any violation. Happy connections :

Expected Behavior

Routing not going as close to the macro to avoid the violation, but i know very little about asic design. Or maybe there would be a config to avoid the power strip going that close to the macro ?

Environment report

OpenLane Container (903a86a):/openlane$ python3 ./env.py issue-survey
open_pdks dd7771c384ed36b91a25e9f8b314355fc26561be
WARNING: issue-survey appears to be running inside the OpenLane
container.

This makes it difficult to rule out issues with your
environment.

Unless instructed specifically to do so, please run this command
outside the OpenLane container.
---

Kernel: Linux v5.15.0-84-generic
Distribution: centos 7
Python: v3.6.8 (OK)
OpenLane Git Version: 903a86ab59095207f3a096aeff8c8b8af899497c
pip: INSTALLED
python-venv: INSTALLED
---
PDK Version Verification Status: OK
---
Git Log (Last 3 Commits)

903a86a 2023-10-09T07:48:41+03:00 Update OpenROAD (#2009) - Kareem Farid -  (grafted, HEAD -> master, origin/master, origin/HEAD)
---
Git Remotes

origin	https://github.com/The-OpenROAD-Project/OpenLane.git (fetch)
origin	https://github.com/The-OpenROAD-Project/OpenLane.git (push)

Reproduction material

Manualy packaged : issue.zip

let's me know if you would like anything else.

Relevant log output

[INFO]: Running Detailed Routing (log: designs/nax/runs/run_4/logs/routing/27-detailed.log)...
[ERROR]: There are violations in the design after detailed routing.
[ERROR]: Total Number of violations is 18
[ERROR]: Step 27 (routing) failed with error:
-code 1 -level 0 -errorcode NONE -errorinfo {
    while executing
"throw_error"
    (procedure "quit_on_tr_drc" line 7)
    invoked from within
"quit_on_tr_drc"
    (procedure "detailed_routing_tritonroute" line 19)
    invoked from within
"detailed_routing_tritonroute {*}$args"
    (procedure "detailed_routing" line 2)
    invoked from within
"detailed_routing"
    (procedure "run_routing" line 32)
    invoked from within
"run_routing"
    (procedure "run_routing_step" line 7)
    invoked from within
"run_routing_step"} -errorline 1
[INFO]: Saving current set of views in 'designs/nax/runs/run_4/results/final'...
[INFO]: Generating final set of reports...
[INFO]: Created manufacturability report at 'designs/nax/runs/run_4/reports/manufacturability.rpt'.
[INFO]: Created metrics report at 'designs/nax/runs/run_4/reports/metrics.csv'.
[INFO]: Saving runtime environment...
[ERROR]: Flow failed.
[INFO]: The failure may have been because of the following warnings:

[Dolu1990]

It may be due to some bad sram LEF files. I will check and update this issue.

[vijayank88]

@Dolu1990 Just check your configuration on how much halo and channel space given?

[Dolu1990]

@vijayank88

By "halo and channel space" do you refer to the "automatic macro placement" config ? Or something else ?

( in my case, the macro placement is done manualy via the MACRO_PLACEMENT_CFG file )

FetchCachePlugin_logic_banks_0_mem 200 200 R0
FetchCachePlugin_logic_banks_1_mem 1200 200 R0
BtbPlugin_logic_mem 200 800 R0
GSharePlugin_logic_mem_counter 1800 800 R0

Thanks ^^

[maliberty]

It looks like your power stripes terminate too close to the macro. I think in OL that's FP_PDN_HORIZONTAL_HALO & FP_PDN_VERTICAL_HALO

[Dolu1990]

Hi,

It looks like your power stripes terminate too close to the macro. I think in OL that's FP_PDN_HORIZONTAL_HALO & FP_PDN_VERTICAL_HALO

It is set to default (10um), and apparently is ignored by the tool. (?) If i understand well, the power strip should not come closer than 10um from the macro ?

Here is another screenshot with :

set ::env(FP_PDN_HORIZONTAL_HALO) "40"
set ::env(FP_PDN_VERTICAL_HALO) "40"
set ::env(PL_MACRO_HALO) "2 2"
and everything else pretty much vanilla

Looking at other github issues, i can see that it seems the same as :

• https://github.com/The-OpenROAD-Project/OpenLane/issues/1262

Which should have apparently fixed with 4a99e88667b0840531ca0096c4fa0da8f80d6cb1 :

• https://github.com/The-OpenROAD-Project/OpenLane/pull/1267

But I'm using a even more recent version of openroad :

• https://github.com/The-OpenROAD-Project/OpenROAD/commit/bdc8e944cd08ba8edebeca19fa531bd026690330

[maliberty]

@donn @kareefardi I'm not clear whether this is an OL issue or an OR one. Would you verify that OL is correctly handling this variable?

[Dolu1990]

Keep in mind, i'm pretty much a newb when it come about ASIC XD Let's me know if you need any more info / help / stuff to reproduce.

[Dolu1990]

I had to write some doc, so regenerated everything from scratch (upstream default branch of openlane / openram). So here is updated openlane/designs/nax which can be used to reproduce the issue. It should fail in step 27 as bellow, with the error reported in openlane/designs/nax/runs/xxx/reports/drt.drc :

[STEP 27]
[INFO]: Running Detailed Routing (log: designs/nax/runs/run_2/logs/routing/27-detailed.log)...
[ERROR]: There are violations in the design after detailed routing.
[ERROR]: Total Number of violations is 19
[ERROR]: Step 27 (routing) failed with error:
-code 1 -level 0 -errorcode NONE -errorinfo {
    while executing
"throw_error"
    (procedure "quit_on_tr_drc" line 7)
    invoked from within
"quit_on_tr_drc"
    (procedure "detailed_routing_tritonroute" line 19)
    invoked from within
"detailed_routing_tritonroute {*}$args"
    (procedure "detailed_routing" line 2)
    invoked from within
"detailed_routing"
    (procedure "run_routing" line 32)
    invoked from within
"run_routing"
    (procedure "run_routing_step" line 7)
    invoked from within
"run_routing_step"} -errorline 1

nax.zip

[kareefardi]

@donn @kareefardi I'm not clear whether this is an OL issue or an OR one. Would you verify that OL is correctly handling this variable?

@maliberty It is passed to define_pdn_grid as follows:

define_pdn_grid \
    -macro \
    -default \
    -name macro \
    -starts_with POWER \
    -halo "$::env(FP_PDN_HORIZONTAL_HALO) $::env(FP_PDN_VERTICAL_HALO)"

Is this the correct way to handle it and get the effect described above?