Liberty（俗稱LIB和DB），是后端設計中重要的庫邏輯描述文件，這里邊包含了除過physical（當然也有一點點涉及）以外所有的信息，對整個后端設計實現有非常大的作用。借此機會，一起LIB做一個簡單的理解和使用，閑話少敘，ICer Go！

LIB的簡單描述

liberty是S家創立并定義的文件格式，主要用于描述各種IP，std-cell等類別的邏輯信息，包括到不限于下列要素

area

cell delay timing: delay

transtion timing

noise

pin cap/trantion threshold

power: leakage, internal

PG info

…

可以看到，這里的要素很多，隨著工藝和timing model的演進，關于時序分析方面的擴展和追加信息會越來越多，這里不是討論的重點，這里不再贅述。

UPF flow的需求

當下的后端實現大部分都是UPF flow（PS：就算設計中只有一個pwer domain，也可以應用UPF flow），UPF flow 從RTL設計開始，到綜合mapping，再到后端實現都需要統一規劃。從RTL到GDS的每一步設計都需要使用“外掛”UPF的方式對設計進行干預和指引。通常而言，需要有以下的注意事項

設計：實例化不能帶有PG信息

前仿真：帶入UPF，確保上下電的功能可以被準確捕捉和驗證

綜合：帶入UPF和支持PG的LIB，完成低功耗設計實現和基于UPF的PG 連接

自動布局布線：帶入UPF和支持PG的LIB和LEF，完成低功耗物理實現。包括PG連接和布通

后仿真：帶入物理實現后的數據和UPF，關注power-domain的開關和低功耗器件（LS，isolaion，retention-cell）的功能正確性

通常而言，LEF都是帶PG信息的，否則，物理實現的時候，無法完成cell PG和power rail/mesh的有效連接，這個是物理實現的強需求，譬如：

對于liberty LIB，PG信息并非必選項，特別是在用戶不選擇UPF 設計流程的時候，或者只是要單一power domain的UPF設計的時候，不帶PG的LIB確實不會引起問題，所以對于一個比較老的工藝可能確實沒有提供帶PG信息的LIB。但當用戶采用了多power-doamin UPF flow是，原有的liberty就不能滿足設計需求了。

但是，這個問題確實不是硬傷（hard-problem）：因為GDS都是支持PG的，LIB只是對于GDS的抽取時，沒有帶入而已，所以從TO角度而言，這個確實是修正的，用戶只需要在原有的LIB里邊添加PG信息，就可以讓現在的設計完美支持UPF flow，這樣的方案，對于IP vendor不能很快的響應提供了非常不錯的解決之道

LIB中PG 信息的存在方式

既然LIB里邊對于設計的邏輯描述已經很清晰了，那么只要了解了PG在LIB里的存在方式，完全可以將一個不帶PG的LIB，轉換成一個帶PG的LIB。通常而言PG會對下列類目產生影響：

liberay scope 的PG 電壓定義：通常使用voltage_map 聲明，定義的電壓值，這里VDD和VSS可以看作會被后面引用的兩個變量名

- cell scope 的PG pin的定義對應電壓，

pin scope 的 pin對應的PG 信息：這個用于工具判別信號所屬的PG網絡，從而對UPF flow里的isolation或者LS做合規檢查，注意這里的output pin會有一個powerdown_function的描述，這個對于可關斷domain的功耗檢查有幫助

所以，基本上只要完成上述三個scope：libery/cell/pin就可以將一個不帶PG的LIB轉換為帶PG的LIB。所以，當遇到這樣一個LIB的時候，筆者就簡單開發了一個PY，完成了上述的功能，這個增量式生成就完成了，但是這個方法真的就是一個好方法嗎？很遺憾，當看到S家提供的命令后，這個PY直接被丟進了垃圾箱。

巧用命令實現PG LIB的增量式生成

在DC工具里邊，S家提供了一個有好的命令，專門根治各種LIB缺失PG的問題。

命令的原理是這樣：

是不是很簡單，通過LEF里邊的PG，反標到LIB里邊而已。簡單理解：PG 信息在LIB不是必選項，但一定是加分項。

編輯：黃飛