The-OpenROAD-Project
Enhancement: Incremental pin access should track new instances and net changes
Description Incremental pin access does not currently account for cases where new instances are created or connections are changed. This can result in pin access information being outdated. These are the changes made in incremental GRT that need to be handled in incremental PA (modifiable):
- New instances are added
- Nets are created or destroyed
- Net connections change
Suggested Solution Update the incremental pin access logic to properly detect and update pin access information whenever there are the mentioned changes.
Isn't "Nets are created or destroyed" covered by "Net connections change"?
With regard to pin access:
Disclaimer: I have no idea what pin access does, just observe what the log says.
I've seen it's runtime go up and up with the larger the ispd24 testcases are. Matt fixed a gross runtime issue a while back, but calculating pin access is still slow.
All stdcell libs I've used in the last 25 years were designed with "pin on track" and "via on pin". Calculate the pin access for the couple of hundred cells once and be done with it, no ? No groups necessary, this should make life for incremental routing much easier, no ?
Any short explanation what pin access is struggling with welcome.
You've lived an easy life then. I suggest reading https://vlsicad.ucsd.edu/Publications/Conferences/377/c377.pdf
This issue is split into two fronts:
1. Creating new insts
PR #7703 has the create inst callback. There is already discussion on the PR regarding my takes on the issue. I'm surprised the PR does not pass the CIs, there is some investigation to be done but TL;DR: the create callback does not need to actually add PA data, it just needs to add the instance data to the rest of DRT. PA data can be calculated on post move.
2. Messing with connections
This feels to me like a corner case. Usually, some net connecting or disconnecting to a instance should not change their PA solution. Connections will only change PA if every instance under a unique instance has a change in that connection. If you have 3 instances with the same unique and one of them looses a connection PA should not care. I think the problem will mainly arise when there is only one instance of an unique type and then that loses and gets the connection.
For acc point and acc pattern generation I think the solution lies on the skipInstTerm functions. A new function on unique insts could be created to serve as the connection callback support. It would essentially operate in three steps.
- Save the skipInstTerm data we have on the instance.
- Calculate all the skipInstTerm of that instance again.
- If we see a difference, simply call the delete and add inst so we update the data as a whole.
I also think there is and argument to simplify the skipInstTerm logic altogether. This logic is good when PA is done in bulk, but it becomes tiresome when doing it incrementally. I suggest bench-marking how often some instance actually becomes skippable for PA. If they are not many I'd suggest to just not have skipInstTerms, just solve for every pin always.
I don't know if changing connections also causes a problem when considering rows of instances, but If that is the case I think just solving the row again can be simple solution.
