后端设计PG liberty的作用和增量式生成
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不是必选项，但一定是加分项。
【敲黑板划重点】
理解PG LIB对UPF的重要性显然是整个问题的关键点，对于如何实现PG LIB的增量式生成，归根结底只是一个技术方法而已。
参考资料
Synopsys Synthesis Tool Commands