一切煩惱的根源來源于執念，串擾和噪聲則來源于電容兩端電壓差不能突變。串擾可以定義為一條Net電平變化導致鄰近的net電平的波動。這種波動可能對受害Net的時序帶來變化，甚至可能造成功能的錯誤。

在90nm，65nm及更先進工藝，串擾和噪聲的影響越來越嚴重，主要原因還是在于繞線更密，頻率更高，電壓更低。

串擾

串擾是一直困擾著后端和EDA工具的一個問題。做過先進工藝的同仁應該深有體會，在Place和CTS階段，時序已經優化得不錯，但是Route之后，引入了Delta Delay，時序立即惡化，需要通過幾輪Post-Route優化才能勉強恢復到Route之前的狀態，即便如此，功耗和面積也會有很大犧牲。其原因在于Pre-Route階段不存在真實的繞線，沒辦法精準預估繞線之間串擾的影響。

隨著機器算力的快速增長，以及EDA公司在逐漸普及AI技術，老本相信這個問題應該最終會得到解決，因為AI的本質在于預測。通過不斷地學習，建立在布局階段去預測布線之后串擾的深度學習模型，從而能夠在布局階段相對精準地預測串擾將會帶來的影響。或者更簡單粗暴一點，仗著算力夠用，在布局階段就直接用Detail Route Based的Placer引擎。

PT進行SI分析需要特別注意以下SI相關命令是否正確：

...

#使能Crosstalk/SI分析

set si_enable_analysis true

#指定composite aggressor模式

set_app_var si_xtalk_composite_aggr_mode statistical

#指定victim和aggressor窗口對齊模式

set_app_var si_xtalk_delay_analysis_mode all_path_edges/all_path

...

#確保讀入耦合電容寄生參數

read_parasitics -keep_capacitive_coupling ...

...

#在timing path中顯示Delta Delay一欄信息

report_timing -crosstalk

窗口

時序窗口是指信號在通過不同的路徑到達某條Net時，時間上有快有慢，最長路徑延時和最短路徑延遲之間的差值就是時序窗口的大小。如下圖所示中，信號線A1, A2, A3和V都有各自的時序窗口。對于信號線V來說，A1, A2, A3都與之有重疊窗口（overlapping timing window)，而A2和A3之前是沒有重疊窗口的，A1和A3可以認為有部分重疊窗口。那么在計算信號線V的Delta Delay時，將其分成3個階段：第1階段，A1和A2同時對V造成影響，Delta Delay = 0.12 + 0.14 = 0.26；第2階段，A1對V造成影響，Delta Delay = 0.14；第3階段，A3對V造成影響，Delata Delay = 0.23。這種情況下，信號線V的Delta Delay取最差值0.26。

需要注意的是，上面考慮的Net之間是同步的情況下，如果兩條Net相關的clock是異步的，處理的方式會有很大不同。假如是設成Async，那么計算Delta Delay采用的是無限時序窗口，考慮的是最悲觀的可能情況；假如是設成Logic Exclusive，那么只有在有重疊窗口的情況下才去計算Delta Delay；假如設成Physical Exclusive，無需考慮串擾的影響，不計算Delta Delay。假如Net相關的clock設置成False Path，處理方式和Synchronous相同，所以在設置Clock異步關系時要特別小心。總結如下表：

CRPR對Delta Delay的處理

以上圖中Path為例，在Clock Path的公共路徑上如果有串擾造成的Delta Delay，這一部分Delta Delay會不會被CRPR機制影響，進而被取消呢？答案是：在計算Setup時，Delta Delay不會被CRPR影響；而在計算Hold時，Delta Delay會被CRPR影響。原因在于：

（1）計算Setup時，Launch Clock和Capture Clock采樣一般發生在不同的時鐘沿，所以Aggressor對兩個時鐘沿的影響是不同的，考慮到最差的情況，這部分的Delta Delay不能被取消。

（2）在計算Hold時，Launch Clock和Capture Clock采樣一般發生在相同的時鐘沿，Aggressor對兩者的影響是一模一樣的，既然在公共路徑上，這一部分Delta Delay是可以通過CRPR機制取消的。

那么如何降低串擾的影響呢？從本文闡述可以看出，主要的方法還是隔離，例如Shielding和加大線間距等，另外一種有效的方式就是錯開特定走線之間的時序窗口。