Liberty(俗称LIB和DB),是后端设计中重要的库逻辑描述文件,这里边包含了除过physical(当然也有一点点涉及)以外所有的信息,对整个后端设计实现有非常大的作用。借此机会,一起LIB做一个简单的理解和使用,闲话少叙,ICer Go!
liberty是S家创立并定义的文件格式,主要用于描述各种IP,std-cell等类别的逻辑信息,包括到不限于下列要素
当下的后端实现大部分都是UPF flow(PS:就算设计中只有一个pwer domain,也可以应用UPF flow),UPF flow 从RTL设计开始,到综合mapping,再到后端实现都需要统一规划。从RTL到GDS的每一步设计都需要使用“外挂”UPF的方式对设计进行干预和指引。通常而言,需要有以下的注意事项
通常而言,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会对下列类目产生影响:
在DC工具里边,S家提供了一个有好的命令,专门根治各种LIB缺失PG的问题。
命令的原理是这样:
是不是很简单,通过LEF里边的PG,反标到LIB里边而已。简单理解:PG 信息在LIB不是必选项,但一定是加分项。
理解PG LIB对UPF的重要性显然是整个问题的关键点,对于如何实现PG LIB的增量式生成,归根结底只是一个技术方法而已。
Synopsys Synthesis Tool Commands