在实际项目中我们经常会遇到一条timing path级数特别多，可能是一两页都翻不完。此时，我们大都需要手工去数这条path上到底有哪些是设计本身的逻辑，哪些是PR工具插入的buffer和inverter。

数字IC后端手把手培训教程 | Clock Gating相关clock tree案例解析

如果这样的timing path上大部分都是纯逻辑单元，比如与门，或门，异步等逻辑单元，而且每部分的delay都比较正常，此时如果timing 存在violation，我们需要反馈给前端进行逻辑的优化。

如果这样的timing path上存在较多的buffer和inverter，说明当前的timing violation主要原因并非设计本身的问题，而是后端PR阶段floorplan，placement做的不合理导致的，这时候需要我们后端工程师来进一步分析解决。

今天小编分享一个自动化脚本来获取具体timing path中的逻辑深度和buffer，inveter数量。这个proc又是一个非常好的脚本练习资源。

proc report_logic_depth {timing_path} { set total_logic_depth [get_property $timing_path num_cell_arcs] set bufinv 0 foreach_in_collection tp [get_property [get_property $timing_path timing_points] pin] { if { [get_property $tp object_type]“pin” && [sizeof_collection [filter_collection [get_cells -of_object $tp] "is_buffertrue||is_inverter==true"]]} { incr bufinv }} return [list $total_logic_depth [expr $bufinv/2]]}

Usage:
The procedure returns a list of two elements: the total logic depth and number of buffers/inverters in the path. You can use this to compute the logic depth without buffers and inverters.

Example:
set logic_depth [report_logic_depth [report_timing -from startpoint/CK -to endpoint/D -collection]]
puts “Total logic depth of path: [lindex $logic_depth 0]”
puts “Count of buf/inv in path: [lindex $logic_depth 1]”

Output:
Total logic depth of path: 35
Count of buf/inv in path: 8

这里我们拿咱们社区T12nm a55项目place的一条timing report来分析path的合理性。这是一条从reg到memory的timing path，layout路径如下图所示。

**【思考题】**当ananke_core的关键路径出现在memory相关的路径上，我们应该如何进一步提升电路的最高工作频率？

innovus 119> set x [report_logic_depth [report_timing -to u_vcpu/u_cpu/u_ananke_dcu/u_ananke_dcu_rams/u_ananke_l1d_tag_dirty_rams/u_dtag_bank/A[3] -collection ]]

14 4

说明这条timing path上buffer和inverter的数量是4级，并没有特别多。当然我们还可以把startpoint对应的reg摆放到更靠近memory的位置。