在实际项目中我们经常会遇到一条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的位置。