-
Notifications
You must be signed in to change notification settings - Fork 489
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
New "Incremental Routing" broke detailed routing #5137
Comments
DRT did not support incremental routing before this PR. So it's a bit inaccurate when you say "new incremental routing broke drt". Let me explain what used to happen before this PR:
So as you can see it did not work correctly before this PR. The other problem is that after the PR, DRT does not support FIXED routing. If you want the router to not touch FIXED nets I can work on that. However, the router will end up with nothing to do because for it will not touch the routed nets for the first 3 iterations. Could you specify what is the expected behavior for all nets; routed, fixed, without guides? |
From my (user) PoV, I wrote that issue description as such because "Incremental Routing" (as-in the feature named as such in the title of the branch that was merged that triggered the fault). And "broke drt" as in "broke the DRT step of the flow" because DRT is the step where things go wrong with that branch merged whereas before it would end up doing what I expect. I'm not sure how to inspect the ODB database directly so I usually look at the DEF that are written at the same time as the ODB to know what's going on. And so I have no idea about routing guides since those are not there. And what I see is that the route for And to be clear, given how those routes are changed, I don't think this is INTENDED behavior, I think something, somewhere ends up corrupting them and that wasn't happening before that branch was merged. Now for all I know the merge just triggers a pre-existing bug somewhere else, I have no idea, all I know is that it worked before and doesn't anymore. Ideally, what I expect is that if before going through GRT/DRT I have some wires that have |
Any news on this ? Any more info you need from our side ? |
No more info is needed for now. This week will be slow as several people at ETH Zurich. |
Describe the bug
I'm feeding into OpenROAD some partially routed design (I have a custom OpenDB script that manually routes some signal).
In the
DEF
at the input you can see for instance :With an older OpenROAD ( tested
4eceed4759ce048f57a5164253fcc32e688cd8ff
just before merging PR #5059 ), it works just fine, that routed net is unchanged at the output and the whole process takes like 15 seconds. ( There really isn't much to route in that test project ! ).Tested a newer OpenROAD ( all revisions after the merge of that PR, I did a git bisect, none work after that merge ), at the output the net has been changed :
Now, except for the first segment which is on
met4
, all the other segments are onmet3
instead of changing layer after each via !!!And now the routing process takes around 20 minutes ! That is 80 times slower ! Not 80% slower ... no, 80 times longer, that's just unusable and this is a trivial test project ...
Expected Behavior
Well I expect it to not modify the routing explicitely marked as
FIXED
in the input and I also expect it to not take forever to do it.Environment
To Reproduce
15-openroad-detailedrouting.zip
Added Openlane2 reproducible, should run on its own.
Relevant log output
No response
Screenshots
No response
Additional Context
No response
The text was updated successfully, but these errors were encountered: