Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Metal Spacing violation between interconnect and macro (sky130) #2030

Open
Dolu1990 opened this issue Oct 30, 2023 · 9 comments
Open

Metal Spacing violation between interconnect and macro (sky130) #2030

Dolu1990 opened this issue Oct 30, 2023 · 9 comments
Labels
blocked This issue is blocked on a bugfix or enhancement of another repository or tool bug Something isn't working OpenROAD An issue with an OpenROAD component

Comments

@Dolu1990
Copy link

Dolu1990 commented Oct 30, 2023

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 :
image

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
image

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 :
image

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 Dolu1990 changed the title Metal Spacing between power and macro connection Metal Spacing violation between mcon and macro (sky130) Oct 31, 2023
@Dolu1990 Dolu1990 changed the title Metal Spacing violation between mcon and macro (sky130) Metal Spacing violation between interconnect and macro (sky130) Oct 31, 2023
@donn donn added bug Something isn't working OpenROAD An issue with an OpenROAD component labels Nov 8, 2023
@Dolu1990
Copy link
Author

Dolu1990 commented Jan 9, 2024

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

@vijayank88
Copy link
Collaborator

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

@Dolu1990
Copy link
Author

Dolu1990 commented Jan 9, 2024

@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
Copy link
Member

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
Copy link
Author

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

Screenshot from 2024-01-10 13-37-13

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

Which should have apparently fixed with 4a99e88667b0840531ca0096c4fa0da8f80d6cb1 :

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

@maliberty
Copy link
Member

@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
Copy link
Author

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
Copy link
Author

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
Copy link
Collaborator

@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?

@donn donn added the blocked This issue is blocked on a bugfix or enhancement of another repository or tool label Sep 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked This issue is blocked on a bugfix or enhancement of another repository or tool bug Something isn't working OpenROAD An issue with an OpenROAD component
Projects
None yet
Development

No branches or pull requests

5 participants