Placement results in path that appears to lap macro #5971
Comments
|
At what point in the flow is your image from? Trying to narrow down where in the flow the problem starts is helpful. |
|
Give the “visualize the whole cone” feature a try. I found it very useful to explain why placers put cells in unintuitive locations. There are usually more things pulling at cells than you see by just looking at the critical path. |
This is after the CTS step, but the path after GRT is effectively the same |
|
Are you using global placement with -timing_driven? If not you should turn it on. |
No, the bazel var GPL_TIMING_DRIVEN is set to 0. I can run it with the option to see what changes. |
|
With GPL_TIMING_DRIVEN enabled, the previous WC path improved -1673 slack vs -6393. Here's what the path looks like now:
So, it's still looking like it's taking a lap around the macro. The fanout cone visualization looks like:
FWIW, the new WC path is -1930 slack. |
|
The fan out cone needs some more refinement to be really useful:
But it’s the only way that I know to visualize both connectivity and timing criticality. |
|
The data is organized by level rather than by criticality currently. We use the top 1000 paths to the pin of interest. Do you have a suggestion for a good default filter until it can be made user selectable? |
|
Anything that reduces the amount of data to a point that it's "fast to draw" and "useful" would help, so "user selectable level" would be nice, but criticality is obviously better. Even when there was a tight collaboration between RTL writer and P&R tool jockey, I was always surprised by the lack of knowledge about the "size of the cones", both # and location of starting/ending ff's of a cone and the routing that goes with it. There are only few RTL guy's (architects) that take the time to "to have a look" at how their netlist is placed. So anything that gives insight into why things end up where they are and "what else is critical" in the vicinity is helpful. No P&R tool that I'm aware of has "a nice way" to visualize "input/output cones color coded by criticality", so OR's cone viewing is a great first step, it just needs widespread usage and user feedback to get the proper refinement. |
|
@precisionmoon's input: All the cells in report_checks are std cells. There are buffers added by repair_design but their placements are already impacted by pre-placed non-buffer cells. |
Describe the bug
In megaboom v6, the resulting floorplan/macro/std cell placement results in paths that appear to "lap" one of the macros multiple times, which intuitively seems wrong:
Expected Behavior
I'm not sure where the exact issue is, so hopefully the development team can provide insight into it.
Environment
To Reproduce
Relevant log output
No response
Screenshots
No response
Additional Context
No response
The text was updated successfully, but these errors were encountered: