在實際項目中我們經常會遇到一條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的位置。