odb: derating relocation from GRT to dbTechLayer

[gudeh]

• Implemented the insertion of derating (layer adjustment) into RUDY, using an average value from the routing layers. - Note: RUDY does not have access to layer information. Instead, derating values for each layer are set within GRT.
• Moved derating from GRT to dbTechLayer through the use of a code generator.

[github-actions[bot]]

clang-tidy review says "All clean, LGTM! :+1:"

[github-actions[bot]]

clang-tidy review says "All clean, LGTM! :+1:"

[github-actions[bot]]

clang-tidy review says "All clean, LGTM! :+1:"

[maliberty]

mock array should be quite readily predicted. I'm wondering why rudy w/weight-avg is showing >100% congestion.

[gudeh]

There are two things that influence the > 100% values: the derating itself, and the fact that RUDY is considering the presence of 2 nets per tile per blockage on the macros. Here you can see the case with 0 derating for reference. Notice RUDY values are actually lower when derating is 0.

RUDY:

GRT:

There are other examples where RUDY overestimates congestion due to derating, in the current format. I thought of a condition, prior to derating adjustment, to not add too much if the value is already high, but seems strange to do that, any ideas?

[maliberty]

When you consider the macro for track usage do you consider derating? If the macro blocks all the tracks, it should be blocking all the derated tracks not the underated tracks

[gudeh]

When you consider the macro for track usage do you consider derating? If the macro blocks all the tracks, it should be blocking all the derated tracks not the underated tracks

If you look at RUDYCalculator::calculateRUDY() you will notice I first calculate RUDY for the nets (different methods for supply versus signal nets), afterwards I loop over the instances to process the macros. Then only afterwards I adjust every tile based on the derating at dbTechLayer.

So, the derating and the macro blockages are processed separately. First, the blockages are handled, and then the derating is applied to all tiles, considering that RUDY values are stored on the tiles.

[gudeh]

I tried using a sigmoid function to reduce the derating addition on values that are already high. Some examples look better: -IBEX

-Mock-array

I am executing more examples right now.

You can see here how IBEX was overestimating without this new sigmoid function.

[maliberty]

@eder-matheus please advise on how derating and macros are handled in grt

[eder-matheus]

@eder-matheus please advise on how derating and macros are handled in grt

Regarding user-defined derating, GRT iterates through every tile of the gcell grid and applies the reduction percentage over the current resource value. With that, we avoid over-reducing the tile resources because it doesn't reduce anymore when it reaches zero.

For the macro obstructions, it iterates over every macro obstruction, gets the tiles overlapping with the obstruction, and sets the resources to zero when it is completely blocked. GRT will estimate how many tracks are blocked to define the reduction value when it is partially blocked.

[maliberty]

@eder-matheus do you think we can share the code/logic with rudy so there is one way to handle macros?

[eder-matheus]

@eder-matheus do you think we can share the code/logic with rudy so there is one way to handle macros?

I think @gudeh can explain better, but I understand that rudy doesn't see resources. It only considers the congestion in the tiles. Also, GRT looks at layers, while rudy doesn't have this capability.

I suggested to @gudeh to check if the tile already has 100% congestion and avoid adding the user-defined reductions to these tiles. This is what we do in GRT.

[gudeh]

For future reference, we have decided during a sync meeting to implement a generic function in ODB that can be called by GRT, RUDY, or any other process. This approach will provide us with a unified method for calculating congestion for the power grid, macro obstructions, and derating.

The difference among RUDY and GRT should be only for signal nets.

[github-actions[bot]]

clang-tidy review says "All clean, LGTM! :+1:"

[github-actions[bot]]

clang-tidy review says "All clean, LGTM! :+1:"

[github-actions[bot]]

clang-tidy review says "All clean, LGTM! :+1:"

[maliberty]

I think this is obsolete in light of #4927 - close?

[gudeh]

I think this is obsolete in light of #4927 - close?

I believe you are correct. With the new code structure I see no reason to relocate derating to odb.