如何進行physical aware synthesis的分析

如何進行physical aware synthesis的分析，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

一切都是發展的需要，工藝更新給整個半導體行業帶來了巨大的挑戰，從生產設備到EDA到芯片設計實現無不在被澤科技之光時氣喘吁吁。下圖是從DAC15 Andrew B. Kahng講synthesis 的slide上摳的圖，這幅圖直觀地呈現了從65nm到16/14nm，物理實現尤其是 STA 需要考慮的由工藝進步引入的因素。

在芯片設計實現這一截，P&R工程師對工藝帶來的挑戰感受會更直接，綜合跟 STA 跟 DFT 也都有新的點跟方法學的更新，但大都被 EDA 工具嚴實地包了起來，就拿綜合來說，相對于傳統綜合而言最大的更新莫過于physical aware synthesis，但對于大部分綜合工程師而言，這一點似乎只是一件水到渠成的事兒，你用或不用，flow 就在那里，不吼不叫。驢今天就自己淺顯的認知，就這一點做一個簡單的論訴。

為什么要做physical aware synthesis？

最根本的目的就是減少前后端的迭代次數，前后端迭代次數多的根本原因是 correlation 差，而 correlation 需要從timing 和 congestion 兩個方面來看：

Timing

綜合優化的對象是 timing path，而 timing path delay = net delay + cell delay，90nm之前由cell delay 主導，而進入65nm net delay所占比例日漸增加，進入40之后幾乎跟cell delay平分秋色，所以從40 開始physical aware synthesis 被硅農熟知，因為physical aware synthesis在優化過程中可以看到更精確的net delay。

為什么logical synthesis 不能精確計算net delay?

這就要回看一下傳統綜合是如何估算 net delay 的。傳統綜合俗稱logic synthesis，它根據WLM 來估算net delay。WLM (wire load model) 由foundry 提供，WLM通常包括面積系數、電容系數和單位長度的電阻系數，以及一個用于估計net 長度的表格，表的index是 fanout，直白地說就是將net 的長度模擬成fanout 的函數。

看下圖：按照WLM 來計算，blue 到red 的所有net 長度都一樣，net delay也一樣，而實際上 net 行走的姿勢五花八門，根本就不可能一樣，缺點顯而易見。另一個缺陷是WLM 的單位電容電阻是一個常值，無法模擬不同layer RC 值的差異，而工藝進入16nm 之后，必須要考慮 layer aware 的 net delay，進入7nm 之后除了layer 還要考慮VIA對net delay的影響，為什么要考慮VIA？ 因為VIA delay占的比重已不容忽視。

在40甚至28，依然有人在用傳統的方式來做綜合，做法簡單粗暴加時鐘周期30%甚至更多的過約，這樣做是可以cover net delay，但是實在是過猶不及。據統計在一顆芯片里80%以上的線都是短線，為了cover那不到20%的線，付出的代價就是更大的面積及更多的功耗，當然如果你不在乎，那就無所謂了，畢竟任性是你們土豪的特性之一！

Physical aware synthesis 如何更精確的計算net delay？

要精確計算net delay必須要知道net的行走姿勢，而要知道net 的行走姿勢必需要知道：它來自哪里？要去向何方？這就需要知道cell 的位置，cell 位置確定了之后，綜合工具會做global 繞線，根據global 繞線的結果來估算net delay。cell 位置由placement 確定，所以如今綜合工具都集成了 placement 引擎，這也是做 physical aware synthesis 的關鍵所在。目前大概有兩種做place的方式：

• 做完優化跟mapping之后，再做place，操作對象是std cell。

• 在elaborate 之后優化之初就做place, 即所謂的 early physical, 早期階段針對module 做palce，mapping之后再以std cell為對象做place。

下圖是谷歌上隨便找的一張圖，只為顯示什么是module place,  從Layout 上看每一個顏色對應一個 module, 對應于RTL中的 hierarchical, 所以 module place 的QA 對 PPA 會有很大影響。綜合工具基本都按 translation + optimization + mapping 三大步來走， 所有結構的選擇跟大部分優化的動作都在 optimization 這一步完成，如果可以在 optimization 時就知道 module 的位置信息，優化會更有的放矢會更能『精準打擊』，所以 Early physical 十分必要。現在看到的趨勢是把更多的物理信息拿到前端來，越早考慮物理信息得到的結果會越好。

結論：physial aware synthesis根據真實的物理信息，用跟 P&R 一致的 place 引擎跟 global route 引擎，可以精確估算 net delay，并且是layer 跟VIA aware的。通常physical aware synthesis 只需過約時鐘周期5%~10%即可，用于conver legalization跟detail route 的影響。

Congestion

同樣由于工藝進步，集成度提高，單位面積上要走的線驟增，所以 congestion 成了一個從RTL 設計就要開始關注的問題，否則到了繞線的時候繞不通，前面所做的一切都成了無用功。很顯然，logical 綜合是無法考慮 congestion 的，要在綜合階段做congestion 優化必須要 physical aware synthesis.

其實不論PPA還是congestion主導決定權都在進實現之前，架構算法設計，才是真正決定一切的『權貴』，所以才說實現是個沒有靈魂的工種，只要按著 設計/EDA/foundry 定的規則往下走就可以，切忌的就是『發揮』。

于congestion 綜合工具能做的基本只有兩件事兒：選結構跟推cell。至于選結構，一個用爛的例子就是把一個大MUX 拆成多級MUX 用于解congestion。推cell 這一點完全依賴于EDA 工具，如果你不知道如何做，那就找AE要變量或 option 讓工具在綜合做place 時將 congestion 嚴重區域的cell 推散。除此之外，還有一點可以人為干預，禁用或讓工具少用size 小的復雜cell 比如x1的 AOI/OAI。

要特別說明一點，在16之后，layer 的影響特別大，所以綜合用的 DEF 一定要有special net 部分，也就是你的power plan，讓工具在綜合時清楚地知道哪些layer 的繞線資源已經被占用。

關于如何進行physical aware synthesis的分析問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。