maliberty
commented
1 month ago At what point in the flow is your image from? Trying to narrow down where in the flow the problem starts is helpful.
Open jeffng-or opened 1 month ago
maliberty
commented
1 month ago At what point in the flow is your image from? Trying to narrow down where in the flow the problem starts is helpful.
stefanottili
commented
1 month ago 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.
jeffng-or
commented
1 month ago At what point in the flow is your image from? Trying to narrow down where in the flow the problem starts is helpful.
This is after the CTS step, but the path after GRT is effectively the same
maliberty
commented
1 month ago Are you using global placement with -timing_driven? If not you should turn it on.
jeffng-or
commented
1 month ago 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.
jeffng-or
commented
1 month ago 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.
stefanottili
commented
1 month ago The fan out cone needs some more refinement to be really useful: 1) draw the flight lines bottom up, from least to most critical 2) get an adjustable filter to get rid of the not so critical ones ..
But it’s the only way that I know to visualize both connectivity and timing criticality.
maliberty
commented
1 month ago 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?
stefanottili
commented
1 month ago 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. Useful visualization is more than "just" showing the one critical path and the clk skew at its input and output ff.
jeffng-or
commented
3 weeks ago @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. Timing-driven option seems to be the way to go. -timing_driven_net_reweight_overflow can be changed to decrease runtime.
oharboe
commented
5 days ago maliberty
commented
5 days ago Its more helpful to show the macros than the placement blockages
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