Clock Tree Latency Calculation Difference between reportClockTree & report_timing

The area you're working in is a common area of exploration for sure, I'm glad you raised it for discussion. I'd like to make a few observations here:

1) When any clock tree synthesis tool reports the latency (while the tree is being built or after the tree has been built), it has to make approximations about the neighboring wires because they haven't been routed yet. It is therefore conceptually difficult to know for sure what the parasitics are going to be, and the latencies reported are therefore approximate. So we can't expect the numbers reported by CTS, or by reportClockTree to align perfectly with with STA especially when the entire design isn't yet detail routed.

2) As I'm sure you've noticed, "reportClockTree" has 3 options for route estimation: "-preRoute | -clkRouteOnly | -postRoute". -preRoute is intended for a scenario that isn't used much anymore- where the clock net is routed after clock tree build. -clkRouteOnly aligns most closely the estimation that occurs during CTS- where all neighboring signal wires are approximated. I like using this option when I want to analyze or further optimize the clock tree prior to trialRouting the design after CTS. -postRoute should be used whenever the signal nets have been routed whether by trialRoute or NanoRoute.

3) Further complicating things is the fact that launch clock timing can differ from capture clock timing when your design has "set_timing_derate" -or- any number of smaller effects when you're timing the design with "setAnalysisMode -analysisType onChipVariation". That's important to keep in mind when you're seeking to compare latency between CTS and STA.

With these challenges in mind, it is of course always possible that you could be hitting a tool limitation associated with some nuance in the design (for example, your clock nets are routed with non-default rules and the CTS isn't extracting those accurately for some reason). Or that you might be able to do some things as a user to guide the tool for better alignment in this area (for example, you could provide a scale factor for the clock nets less than 1 after performing some analysis with the Ostrich parasitic correlation tool shipped with the software). It's difficult to say generally, but I hope these ideas might give you some food for thought.

Feel free to post back with additional information or questions.

Thanks,
Bob

The area you're working in is a common area of exploration for sure, I'm glad you raised it for discussion. I'd like to make a few observations here:

1) When any clock tree synthesis tool reports the latency (while the tree is being built or after the tree has been built), it has to make approximations about the neighboring wires because they haven't been routed yet. It is therefore conceptually difficult to know for sure what the parasitics are going to be, and the latencies reported are therefore approximate. So we can't expect the numbers reported by CTS, or by reportClockTree to align perfectly with with STA especially when the entire design isn't yet detail routed.

2) As I'm sure you've noticed, "reportClockTree" has 3 options for route estimation: "-preRoute | -clkRouteOnly | -postRoute". -preRoute is intended for a scenario that isn't used much anymore- where the clock net is routed after clock tree build. -clkRouteOnly aligns most closely the estimation that occurs during CTS- where all neighboring signal wires are approximated. I like using this option when I want to analyze or further optimize the clock tree prior to trialRouting the design after CTS. -postRoute should be used whenever the signal nets have been routed whether by trialRoute or NanoRoute.

3) Further complicating things is the fact that launch clock timing can differ from capture clock timing when your design has "set_timing_derate" -or- any number of smaller effects when you're timing the design with "setAnalysisMode -analysisType onChipVariation". That's important to keep in mind when you're seeking to compare latency between CTS and STA.

With these challenges in mind, it is of course always possible that you could be hitting a tool limitation associated with some nuance in the design (for example, your clock nets are routed with non-default rules and the CTS isn't extracting those accurately for some reason). Or that you might be able to do some things as a user to guide the tool for better alignment in this area (for example, you could provide a scale factor for the clock nets less than 1 after performing some analysis with the Ostrich parasitic correlation tool shipped with the software). It's difficult to say generally, but I hope these ideas might give you some food for thought.

Feel free to post back with additional information or questions.

Thanks,
Bob