Closed donn closed 2 months ago
[ERROR GRT-0226] Type2 ripup not type L.
suggest the problem is in the fastroute core.
The current incremental grt relies on running grt and rsz in the same script. This is because the internal structures that grt uses to estimate the parasitics and to define what nets are already routed are not present in the database.
To fix this issue, we would need to save the route segments of each net in addition to the route guides. This way rsz will get the correct data about connectivity between the nets.
If GRT and resizing happens in the same script, this works fine. However, this may be a waste of compute for some designs where GRT takes a non-trivial amount of time.
Most likely any fix is going to involve re-running both. Storing all the extra data in the db seems like a lot of overhead for a small benefit.
The error message should be better regardless.
fyi @kareefardi
If GRT and resizing happens in the same script, this works fine. However, this may be a waste of compute for some designs where GRT takes a non-trivial amount of time.
Most likely any fix is going to involve re-running both. Storing all the extra data in the db seems like a lot of overhead for a small benefit.
The error message should be better regardless.
Couple of questions:
You are storing the routing of each net twice - once in guides and again in segments. I don't have a quotative value but that isn't trivial.
I'm not sure what the value of this use model is. Would you explain further how this is a benefit.
I'm personally unconcerned. Would you like me to keep this issue open so you can track "The error message should be better regardless"?
Sure the message should be fixed.
@eder-matheus @maliberty I just noticed the commands read_global_route_segments
and write_global_route_segments
. Would rsz still need an iteration of GRT even with these commands?
Those were added for a contest and I don't know we'll keep them long term.
@kareefardi This PR will make it possible to estimate parasitics from the guides stored in odb: https://github.com/The-OpenROAD-Project/OpenROAD/pull/5758
Describe the bug
Running post-GRT timing optimizations fails with a cryptic error and later a stack dump (see log), but only in the event that the database has been written after global routing, OpenROAD exited out of, then the database is re-read.
If GRT and resizing happens in the same script, this works fine. However, this may be a waste of compute for some designs where GRT takes a non-trivial amount of time.
Expected Behavior
Whatever data global routing saves should be in Odb/more actionable error
Environment
To Reproduce
Concatenate the file to extract it.
./run_good.sh
is the example with both GRT and RSZ in the same script that works../run_bad.sh
is the example with GRT and RSZ in separate scripts that fails.repro.partaa.tgz repro.partab.tgz
Relevant log output
Screenshots
No response
Additional Context
No response