綜合 | 設計讀入與檢查

• 2020 年 3 月 13 日
• 筆記

繼續碼綜合這一趴，可先回顧：《綜合 | 概述及 library 檢查》跟《綜合 | LEF, QRC, DEF》。在讀入lib, lef, qrc 之後下一步要讀入的就是設計，設計可能是：Verilog, VHDL, SystemVerilog幾種硬體描述語言的一種或多種的混雜。

綜合工具都支援讀入單個文件或讀入一個文件列表，綜合工具在讀入RTL 時，會做對應的語法檢查，並報出Warning 或 Error 等資訊，綜合工程師需要對每一類Warning 跟Error 做進一步確認，工具默認在讀RTL 時如果遇到錯誤會停下來，如果是初次進綜合工具，可以設變數讓工具一氣兒讀完，把該報的錯都報出來，找Designer 去確認修正。對於可忽略的Warning 可以不管，如果不想讓工具報這些可忽略的Warning 有對應的命令將其設掉，但是非常不建議，可以限制一下這類Warning 的個數，但不要全設掉；對於不能忽略的Warning, 則需要一個一個的去看，最好讓設計修掉。

在設計正確讀入之後，需要對設計做elaborate, elaborate 就是綜合三大步中的 "translation", 它將設計從Verilog, SV, VHDL 描述轉換成GTECH 描述，GETCH 是獨立於製程的『基本邏輯門』描述，每家都有自己一套獨立的GTECH 描述，相互之間不通用。在做elaborate 時，工具同樣會報許多Warning 或Error, 綜合工程師同樣要檢查每一項，而且十分建議把大部分Info 也過一下，可以從Info 給出的資訊得知RTL 中的結構被映射成了什麼。

通常，Elaborate 會做如下事情，如果需要在TOP 傳遞參數，也需要在這步完成。

• Builds data structures and infers registers in the design.
• Performs high-level HDL optimization, such as dead code removal.
• Identifies clock gating candidates.

在同步設計中，有三類錯一定要加倍小心：Latch, Loop, unresolve, 這三貨除非是設計意圖，否則一定要修掉，關於Loop 可回顧《點論 | 組合邏輯環 Combinational loop 知多少》。

通常，做完elaborate 之後都需要做一步uniquify, 對多次例化的module 做『克隆』, 工具在優化時，會根據每個例化的『外部環境』對『克隆體』進行優化，避免了相互牽扯，以充分享受『環境紅利』。

做完uniquify 之後，一定要做check_design, check_design 會報出許多Warning, 綜合工程師要對每一類Warning 知根知底，且對有害之處做修正。

如果read_hdl, elaborate, check_design 的結果都水清木明，都胸中有數，那恭喜你又進了一步。但每當提及設計，尤其是在綜合端，就不得不提及Coding sytle, 就不得不質問『什麼樣的RTL 算是好的RTL？』。

綜合工具它不能吃鐵絲拉笊籬，能做出什麼樣的結構極大程度取決於程式碼品質，Coding Sytle 並非老生常談，近些年隨著EDA 技術的發展，如何Coding 對工具更友好能更好地利用工具的能力已經發生了許多變化，關於這趴話題，一兩句說不清以後有機會碼一文。

關於『什麼樣的RTL 算是好的RTL』，在IC 圓桌派群里大家聊過許多，高老師也做了總結，搬運一些到這裡，僅供參考：

• RTL除了演算法架構的考慮，還要考慮最後的實現，才是好的RTL。
• 對中後端友好，PPA好的，具體來說就是，formal 容易過，對後端flow要友好，pr 實現相對簡單。
• 別人看的時候沒有一句一句的WTF, 但RTL 有時候可能走向兩個極端，太好的RTL你也會WTF, 如：充分利用可綜合語言特性及輔助綜合指令，極致精簡的實現，太差的是滿屏ctrl c+v 的痕迹，同樣會WTF.
• 最噁心的程式碼就是用軟體思維來寫。
• 對於程式碼的理解不透徹所有程式都強套幾個編程範式的永遠不是好程式設計師。
• 真正有硬體思維，適合寫RTL的人不多，很多人寫了挺多年，基本也只會加減乘除——最難的是硬體思維。
• 寫rtl不光要有硬體思維，還需要思維縝密，才能經得起驗證。基本功能正常，bug太多驗證很難收斂。
• 一般製程或者庫變化後，我都會對比看看，主要邏輯單元的時序怎麼樣，寫的時候有數，不該省的不要省，後期要少很多事情。
• HLS 如果想寫出很高品質的程式碼，還需要加速pragam, 感覺也是硬體思維，還不夠靈活，HLS 更合適軟體或者CS.
• 通常面試一個剛畢業的，你問他『你覺得設計環節什麼最重要』八九不離十的答案都是『寫好codes(無論是rtl, perl.)』。
• 『可以給architecture 足夠的support 能夠參與討論；可以寫很好的spec, 在spec 階段基本把design 構思完成，並有很大一部分已經具體細化； 能夠很好的和VE 溝通cover corner case 』，在這種廣義定義下，寫程式碼才算比較有競爭力。
• 一個能兼顧硬體實現的演算法 ，可以帶來一個順暢的rtl design, 遇到一個演算法。
• RTL 設計主要還是經驗，大概能預測之後可能的問題。如：sram 的製程不一樣，介面輸入和輸出的時延模型定義不一樣，導致之前的設計，時序就變得很緊張。總之，rtl如果能多考慮以後的時序問題，以後就會少麻煩，改流水線容易，改loop難。
• 先搭電路架構，再去用verilog 表達。
• 兩個人寫cache, 一個連最長路徑多少門都想到了，一個人就是實現功能，結果出來真的是差好多。
• 做架構就是這樣的，眼睛裡看的是matlab 的C, 腦子裡想的全是流水線，加法器，乘法器，並行度，然後才能輸出一份指令集。
• 很久以前，我遇到一個老工程師，寫verilog 是把所有訊號都寫成表達式。他寫的是usb 控制器，我就是從那個程式碼裡面領悟到了：寫RTL 真的必須用心感受所有訊號傳遞路徑，因為硬體所有訊號都是並行傳遞的。
• 硬體，任何器件，都是同時工作，多了一維。
• 大神寫的程式碼，要是不加註釋，你都看不懂是啥意思，ppa好，但是可讀性真的…
• 我第一家公司的技術總監寫RTL 都用宏拼，有個驗證說這裡不對，他畫了個圖說我的行為應該是這樣的，那個驗證一看：我去真是我理解的不對！近年應該有60 了，寫了好幾十年的RTL, 看著像火星文很短實現的功能又極其複雜。
• 太好的程式碼也會被吐槽，人家壓根寫的不是程式碼，是電路。