PERC初探暨小试牛刀

早在2010年，Mentor Graphics明确将Calibre PERC定位为“最完整可程序电子规则检查工具”，此声明预示着PERC已经完成开发并投入市厂。时至今日，PERC已经走过了15年的历程，并且已经深入到众多工艺节点，尤其是一些复杂的工艺节点，这里用一篇小文章，抛砖引玉，一起来认识这个正值青春少年的精神小伙：PERC。闲话少叙，ICer GO！

什么是PERC（What）

Calibre PERC（Programmable Electrical Rules Checking）是传统的ERC检查的升级版本，基于ERC的原理，裹胁着插上了可编程（programmable）的翅膀。在传统基本的ERC检查基础上，提供了更加丰富多彩的客制化检查方法。

为何要使用PERC（Why）

芯片的规模成几何级数级别增长，更多复杂的设计被导入，同时芯片的生产/制造的成本越来越高，芯片的检查更加需要格外注意（成本和时效性的要求），必要的甚至是一些激进的检查都慢慢映入芯片签收的事业。对于基于GDS结果的PERC静态检查，可以从电气特性和电路特征的维度入手，用户撰写一些ERC规则，可以很好的其甄别出，最终TO GDS数据库的电气问题，从而有助于提升芯片设计质量。

何时使用PERC（When）

和常规的TO类似，PERC属于LV signoff的一部分，但是由于很多的PERC都是用户自己撰写的，FAB并不会做强制。但是用户出于对自己设计的理解，作为内部的TO signoff，还是需要做到合并到芯片的TO LV checklist里边的。考虑到项目的继承性和延续性，PERC的脚本可以不断地加强和完善，用户的每一次TO都会无形中多了更安全的一层检查，对于项目的质量一定会有相当的把控。所以：TO的时候，是需要完成既定的PERC检查的

PERC的使用场景（Where）

基于PERC和IC设计的基础理论，PERC通常可以在以下的场景里边使用

• 基于source：
  • ESD结构检查
  • EOS检查
  • Multiple power domains check
• 基于layout：
  • Point-to-Point resistance
  • Current Density (CD)
  • Voltage-Dependent DRC
  • Hot gate/diffusion identification
  • Layer extension/coverage
  • Device matching

以上都是基于检查场景的分类，从PERC的运转流程上看，无论是source还是layout，在Calibre里边都会转换成spice netlist（PS：常见的LVS也是如此），然后工具基于对spice netlist的读取，执行PERC的rule进行相关项目的检查。这种静态的分析方法是基于电气特性，对于特征电路结构进行的分析，对于IP设计或者全芯片的特定检查目标，都有非常好的效果。（PS：可以理解，PERC之于GDS，犹如STA之于网表/SDF）

PERC的终端用户（Who）

鉴于PERC的强大静态分析功能，在芯片的设计中，通常需要以下的工程人员注意：

• 设计人员：

  • 模拟设计：IP设计级别
  • 芯片LV签收人员（chip sigoff）：全芯片级别，此处强调IO和全局连接的影响

• FAB RSF维护人员：提供基于自家工艺节点的PERC常规检查。譬如

  • P2P
  • IO PG cell distance check etc.

PS：和常规的静态LV检查类似，工程人员对于FAB的PERC检查文件，是需要逐级，逐步收敛的。

如何使用PERC进行检查（How）

对于传统的LVS/DRC/ERC，大部分情况下，终端用户只是把FAB的LVS/DRC/ERC 的RSF文件，进行简单的配置（如版层，是否full-chip，top-desig等），然后就可以直接用了。丹斯无论是那种检查，其核心的语法都是基于Calibre的SVRF （Standard Verification Rule Format）语法。

同样的，PERC也是基于SVRF语法实现的，由于PERC可编程的特性，基本是需要用户自己去进行实际编写的。所以用户需要熟悉SVRF的一些基本语法。

PS：由于PERC是基于电气性能和拓扑连接的分析，PERC和LVS有很多共同之处，这个后面会做介绍。

但是由于SVRF这套语法缺乏灵活的控制和判断结构，所以为了适应PERC可编程的要求，Calibre提供了一套TVF （ Tcl Verification Format ）机制，这个可以视为是SVRF语境下的一个内嵌语法（native），可以通过一定的提示词在SVRF调用TVF。由于这个内嵌语法系统是Tcl-based的原因，对于PERC来讲，这样就打通了TCL脚本和SVRF的最后一道屏障。

所以，具备下列条件的工程人员就可以完成PERC检查规则的编写：

• 电路设计的结构基本原理：ESD结构，模拟连接拓扑结构等
• LVS和ERC检查规则和原理。
• TCL语法知识
• spice语法基础

由此可见，PERC对工程人员的要求比较多，对模拟，tooling以及TCL 编程等都是要有一定熟悉的。当然，并不是说不同时具备上述要求的工程人员是无法完成PERC的规则编写的，相反，PERC提供了一个非常好的思维角度，不同工作范畴的人员，在进行紧密的沟通后，通过相互学习和借鉴，出具一套系统级别的PERC检查规则，这种先进的检查方式必然可以有效提升芯片的整体设计质量。

PERC rule介绍

基于上述介绍，PERC需要一定的组织结构，才能将上述特性实现出来，所以，这里需要先简单的介绍以下PERC rule的基本结构

PERC rule的基本结构

如上述PERC是一种类似LVS的电气特性检查，所以一个完整的rule需要下列元素

• 输入数据的类型、路径、顶层设计（topcell），SVDB等声明：和LVS一样的声明手段
• PERC的属性配置：PERC起头的专属配置，（PS：以PERC为前缀，和LVS/DRC等命令加以区别）
• PERC的具体规则配置：TVF格式的检查规则撰写，以perc::*命令为主进行构建。（PS：需要提前加载指定的的Calibre PERC package）

PERC rule的运行

和其他的静态LV检查类似，Calibre提供了专属的PERC运行命令，类似于LVS/DRC，PERC可以分为hierarchy和flatten两种方式进行运行

从PERC的运行机理上看，PERC可以对电路结构，以及基于电路结构的和电气特性对电路进行分析。这样会诞生两种不同的检查方式。

• hierarchy mode

  # shell
  calibre -hier [-hcell hcell.list] -perc perc.rule |& tee perc.hier.log
  

• flatten mode

  # shell
  calibre -perc perc.rule |& tee perc.hier.log
  

和LVS/DRC类似，不同模式下的结果可能会出现差异。只是维度问题，并非结果分歧。

基于PERC的机理，PERC是针对spice netlist的分析，可以提供电气连接上的分析（类似LVS），同时也可以提供spice topology的拓扑的分析。这里结合上述讲解，分别对两种分析逐一做以介绍。

基于电气特性的PERC分析

1. 配置SOURCE：

• SOURCE 的文件路径
• SOURCE 的顶层设计
• SOURCE 的文件系统，通常为spice

• 配置SVDB：（Standard Verification Database Directory）

2. PERC专属配置：

• PERC 数据输入源类型选择：SOURCE | LAYOUT

• PERC的报告路径

• PERC对device的属性声明 (可选)

  • 语法：PERC PROPERTY device_abber device_property
  • 默认PERC不会记录跟着任何器件的属性，除非此处声明。
  • Calibre结合spice的语法，将device做了一下分类（节选）：

  

  device对应的属性，有如下的规定（节选）：

  

  用户需要结合自己PERC rule的需求来配置相应的device property。

• 选取PERC具体的规则检查

  语法：PERC LOAD TVF_function INIT init_proc SELECT check_proc

如前述，PERC的检查规则都写入到TVF的function内，PERC针对一个完整的TVF function，对其中的不同的proc进行选取。

INIT字段是对数据库的初始化进程，SELECT是对数据的进一步检查进程。INIT是可选项，但是PERC提供了大量的给init使用的命令，可以有效地对设计数据进行规范，譬如：net，device等的客制化定义。用户有了这些定义后，对于后面的检查会比较方便，如果没有这些定义，后期的cehck_proc可能会缺失一个合适的起点数据。

按照PERC运行机制，PERC启动的第一个动作就是做INIT，而后基于INIT的结果，再使用check_proc做具体检查。

• TVF的PERC规则描述

TVF section声明语法：

TVF FUNCTION func_name [/*# tcl commandpackage require CalibreLVS_PERCproc init {} {……}proc check_proc {} {……}
*/]

使用TVF function声明，指引PERC对于其中的语句使用TCL parser进行处理，结合导入的TCL package: CalibreLVS_PERC，TVF里边的所有TCL命令都可以调用perc:😗 命令进行处理。

• Init proc： esd_init

这里使用了esd_init来对数据进行初始化，这里的命令对PG，port等三类net进行归类，加之net path声明，所有穿越R的net也可以继承port上的net 名称。

• check proc: rule_1

这个proc对于init后的数据进行处理，这里的proc并没有给出argu，可以理解为，在esd_init运行完，就会去运行rule_1的proc，查验符合条件的device，如果这个device具备下列属性

pmos或者nmos类型
mos的gate连接到了非PG的port上

基于net path机理：如果这个net 没有穿越任何R，或者穿越的R对于的电阻小于200 ohm，都属于连接到非PG的port上net（Pad），详见下图：

• 无论是Pad net还是Pad net（net path）都是被考察的对象
• X1的mos到Pad net有200的电阻
• X2的mos到Pad net有50的电阻
• X3的mos到Pad net没有电阻

所以最后的结果是：X2和X3的device符合PERC的检查规则，PERC以CHECK FAILED结果报告出来，汇总在perc.rep：

PS：这里返回的C2（X2）和C3（X3），因为目前是hierarchy的模式，所以就报告在了hcell C2和C3上了。

此外，用户需要理解，PERC本质上还是对于spice的数据进行各项的查验。这个和Calibre直接对GDS进行数据遍历的DRV是不一样的：DRV主要是基于GDS的物理数据结构进行遍历，两者的命令方式也不尽相同：一个是重点是静态分析，一个则侧重在交互处理。

基于电路结构的PERC分析

如上描述，PERC可以将spice的整体读入，使用PERC对spice分析本身就是一件手到擒来的事情。譬如：针对std-cell的spice/cdl，对每一个cell，进行device的用量统计。

对于std-cell的设计，通常而言只会存在mos结构：PMOS和NMOS，（PS：diode 例外）但是用户一般很难从GDS/lib中感受到每一个stdcell的mos用量，尤其是常见的同样功能，但是驱动能力不同的差异；抑或是不同工艺库，在同样驱动下，其设计上的mos管子数量是否有做过优化等。这个看起来比较麻烦的事情（std-cell 数量比较多），对于PERC而言，一个TVF function就可以很好的解决。

解题思路

• 使用hierarchy模式，同时给入hcell list，确保每个stdcell都会被覆盖到
• 每个std-cell只会用到两种mos，但是pmos和nmos数量并不会一样，很多时候是驱动的考量。（PS：由于pmos和nmos天然的特性，为了维持一致的驱动力，往往pmos会比nmos用量更多一些，最小驱动除外，这个从报告中也可见一斑。）

PERC的检查规则如下

• SOURCE声明：

  • SYSTEM: spice
  • PATH和PRIMARY：使用env进行传递。使用可配置思路可以方便指定spice

• PERC声明：

  • 使用SOURCE 作为输入

  • 加载TVF function： perc_lib

• INIT：跳过

• Check rule：check_device （TCL proc）。具体涉及到的命令

  	perc::get_cellsperc::get_nameperc::get_placementsperc::get_instancesperc::typeperc::subtypeperc::inc
  

最终报告

通过这个表单，用户可以快速获取所有std-cell的pmos、nmos以及other device 的数量，从而可以对std-cell的设计规模有一定的显性的了解。PS：PERC命令效率非常高，秒级速率
具体的脚本不在这里赘述，有兴趣的同学请移步知识星球下载试用。

【敲黑板划重点】

PERC是一个高效的静态检查手段，用惯了FAB的RSF的同学，可以尝试一下这个SVRF/TVF组合而成的高级检查手段，这年头，如果是能写几个PERC的童鞋，那放到哪里都是能吹上一吹的。(*^_^*)

参考资料

Mentor Calibre® PERC™ User’s Manual
Mentor Standard Verification Rule Format (SVRF) Manual