Finding timing paths that are hard to close timing (critical paths)-Synthesis-Backend

[George_P]

Hi,

I want to report the worst paths in a design. Worst means the ones that the synthesizer/backend-tool has a harder time to close timing for.

I DO NOT just want the ones with the smallest slack, because low slack doesn't mean this path makes timing-closure harder. E.g. a relaxed path might use low-drive strength cells and no LVTs and thus have similar slack with a much harder path.

Is there a way to identify the paths that give the tools a hard time during timing-closure (or synthesis)?

Thanks,
George

 

[englishdogg]

one of the ways to identify this is to deploy physical aware synthesis flows which all major EDA companies have to offer. This help you estimate upfront and identify further down issues up in the flow

 

[layowblue]

I'm assuming your design passed timing, cause otherwise it would be simply kicking up the violated paths.
Also, there might be a simple cmd in certain tools to report this. But I don't know it.
That said:
Although you said you don't want the smallest-slack ones, I believe the one you are trying to find should be very probably buried in the smallest-slack ones.
Then if I were you, I would try setting a worst/smallest slack threshold and pick up those paths below the threshold, and figure out the combo logic levels. This could all be done with tcl/perl scripts.
Routing delay is also a contributor, but I would ignore it as it is usually not that influential given floorplan is reasonable.