Open eder-matheus opened 2 months ago
I think this could be good for @bnmfw as he has been learning the PA code.
I don't yet have the full picture for the PA module, but from what I understand right now there is no way to incrementally change access to instances. The starting point of the PA is FlexPA::prep()
where every pin access is determined at once. Today me an @eder-matheus had a meeting where we saw that apparently during incremental DRT the whole PA flow is done from scratch.
Determining the Access Points of an instance could be done in a vacuum. initAllAccessPoints()
could be refactored to have a function responsible for determining the Access Points of an instance. (Right now it iterates over instances and then pins directly).
Determining the Access Patterns of an instance could probably be done in a vacuum. prepPatternInst()
already determines Access Patterns for a single instance. I'm still refactoring this part of code so I'm not 100% sure if it would be safe to call this function alone.
The problem starts in the instance rows. I still haven't got to this part of code so I'm speculating, once I'm more firm about this I will update this comment. genInstRowPattern()
is responsible for determining the used Access Patterns of a single row. Changing an instance and its Access Patterns might change the Access Patters used for the other instances in the row, therefore most probably major changes would have to be done to allow an instance to change in a row with minimal changes to other instances in the row.
An ODB callback starting from the top of DRT could be done that eventually reaches PA. From there:
Description
During incremental grt, the APs stored in odb can be invalidated when moving instances or changing their orientation. DRT should be able to update the APs for the iterms from modified instances incrementally, using the odb callbacks to understand what should be updated.
Suggested Solution
No response
Additional Context
No response