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

George_P · Oct 28, 2014

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 · Dec 10, 2014

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 · Dec 12, 2014

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.

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

George_P

Member level 2

englishdogg

Full Member level 5

layowblue

Advanced Member level 4

Similar threads

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

George_P

Member level 2

englishdogg

Full Member level 5

layowblue

Advanced Member level 4

Similar threads

Privacy & Transparency

Privacy & Transparency