企业官网建设流程全解析

做芯片后端的人，早晚要跟一堆后缀名奇形怪状的文件打交道。itf、ict、tluplus、nxtgrd、qrcTechFile、capTable，光是把名字念顺就得花两天。我第一次接触这些文件的时候，PDK里塞了十来个类似的东西，没人告诉你该用哪个，也没人讲清楚它们之间到底是替换关系还是上下游关系。后来被坑了几次才慢慢理顺：这些文件不是谁替代谁，而是一条从工艺信息到版图RC提取的完整链条。这篇就把六类寄生参数相关文件的关系、用途和用法一次说透，适合刚接触后端提取流程的工程师，也给跨流程换工具的人做个参考。

1. 寄生工艺文件的“家谱”：六类文件到底啥关系

1.1 先给六类文件画个像

先看一张我习惯用的总览表，把每一类的定位先钉住，后面再展开。这张表我按“谁产生、谁消费、什么内容”的维度整理过，跨过好几个项目都适用：

这表里最容易绕晕的是tluplus和capTable。tluplus是“工艺模型”，不是某个net的提取结果；capTable则更接近“结果文件”，是整个设计或某条net线网的电容汇总。一个是菜谱，一个是炒出来的菜，别混。

1.2 谁生成谁，谁喂给谁

我梳理这些文件时，最管用的办法是把它们按“工艺信息来源 → 提取引擎库 → 提取结果”三层摆开：

• 第一层是代工厂给的工艺描述：itf或ict。有些PDK给itf，有些给ict，有些两个都给，但作用重叠。
• 第二层是提取引擎实际用的库文件：Synopsys体系里是itf/ict经过转换得到的tluplus；Cadence体系里是qrcTechFile配合生成的nxtgrd。
• 第三层是提取完拿到的结果：常见的SPEF、DSPF，以及Calibre流程里的capTable。

以Synopsys的链路为例，典型方向是：

itf/ict → tluplus/tlu+ → StarRC提取 → SPEF

以Cadence链路为例，典型方向是：

qrcTechFile → nxtgrd → Quantus提取 → SPEF

这里有个容易忽略的点：同一个工艺下，流片厂可能只给你一种格式的工艺描述，但你手里的工具可能正好不认它。所以“互转”几乎是每个后端工程师迟早要面对的事。

1.3 为什么同一份信息有这么多格式

这个问题我当年也问过。一个28nm工艺的层叠参数就那些，至于搞出五六种文件吗？答案是：商业工具体系、历史路径和代工厂习惯共同造成的。

Synopsys和Cadence长期竞争，各自定了一套工艺文件格式。代工厂为了让自家PDK通吃市场，往往会同时提供多套格式，或者委托第三方PDA团队转制。再加上老设计里遗留的QRC与XRC之争，格式就越来越多了。理解这段“家谱”的意义在于：不要试图找出某种“最正确”的格式，而是搞清楚当前设计流程需要用哪一个，以及怎么把已有的文件安全地转过去。

2. itf和ict：同一个工艺信息的两种写法

2.1 itf里到底藏了什么

itf是明文的ASCII文件，用文本编辑器就能打开看结构。早期PDK里经常能翻到，主要包含几类信息：

• 各金属层的厚度、最小宽度、侧壁角度；
• 各介质层的厚度和介电常数；
• 每层金属的方块电阻；
• 通孔的电阻和电容信息；
• 单位定义，常见的是微米制（M微米）或纳米制。

一段简化的itf内容大致长这样：

RESISTANCE M1 : 0.25 OHM/SQ M2 : 0.22 OHM/SQ VIA1 : 5.0 OHM/VIA GEOMETRY M1 : WIDTH = 0.09 THICKNESS = 0.33 M2 : WIDTH = 0.09 THICKNESS = 0.33 CAPACITANCE OXIDE : THICKNESS = 0.35, ER = 4.1

不要小看这个文件，提取结果的精度很大程度取决于这里的数值。比如同样是0.09微米的M1，厚度写0.33还是0.35，边缘电容差能到好几个百分点。在先进工艺下，这一步的误差会直接反映到时序收敛上。

2.2 ict用“查表”替代公式

ict的全称是Interconnect Capacitance Table，从名字就能看出来，它把电容计算的结果事先按线宽、间距、平行长度等变量做成了一张张的查找表。提取引擎不再实时套物理公式，而是按坐标直接查表再插值，速度更快，也更适合复杂三维结构的近似。

ict里的表格通常以某个“基准单元”为参照，记录一组线宽/间距组合下的电容值。这种表格化思路在实际使用中非常友好，尤其是对耦合电容的处理，比纯几何公式要直观得多。但其代价是：表里的数值只对特定工艺角有效，换了温度、换了电压，或者换了metal stack版本，表就要跟着换。

2.3 收到itf/ict之后，落地前先核三件事

我每次拿到这类文件，不会急着去生成tluplus，而是先回答三个问题：

第一，单位对不对。很多灵异RC结果都是单位换算导致的，看起来数值很大或很小，一查发现itf用的是微米而提取引擎按米或纳米处理了。

第二，层名全不全。数一下设计中会用到的金属层、通孔层是不是都在文件里。少了一层往往不是报错，而是那条net的寄生被静默丢掉。

第三，有没有多个角。代工厂有时只给典型角，有时给了typ、min、max三个角。如果只拿典型角的工艺文件跑全corner，那你后面的时序分析就是在自欺欺人。

3. 工艺文件变成tluplus：Synopsys签核提取的标准链路

3.1 tluplus在提取引擎里是干什么的

tluplus是StarRC提取时真正读取的工艺模型文件。它的作用可以类比成一个“充电宝”：itf/ict是说明书，tluplus是充好电可以直接用的电池。StarRC在计算版图上每条线的电阻、对地电容、耦合电容时，不是现算物理参数，而是不断查tluplus里的表，再结合版图几何做插值和修正。

tluplus里面大量内容就是不同线宽、间距组合下的单位电容、单位电阻，以及描述侧壁电容、边缘电容的曲线参数。它比itf更进一步，因为它是面向“查表优化”过的结构，解析速度快得多。

这里要强调一个常见误解：很多工程师以为拿到了tluplus就等于拿到了寄生参数结果。不对。tluplus是库，SPEF才是结果。你拿tluplus没法直接看到某条net的RC，必须跑完提取工具才有。

3.2 从itf/ict生成tluplus的标准姿势

生成tluplus这件事，在StarRC工具里通常有对应的图形界面入口或命令行选项。实践中我一般走这样的流程：

1. 确认itf/ict文件的版本与当前设计所用的工艺层叠一致；
2. 准备一个layer map文件，把设计数据库里的层名映射到itf/ict里的工艺层名；
3. 在工具中分别生成max和min两套tluplus；
4. 用工具自带的检查模式跑一遍，看有没有“层未被映射”之类的warning；
5. 把生成的tluplus与PDK里附带的参考文件做diff，或做数值比对。

如果你在GUI里操作，通常需要填写的核心选项包括：选取工艺文件、指定layer map、选择corner、指定输出文件名。命令行方式则需要查对应版本手册里的选项名，不同版本差异不小，我建议第一次用的时候先走GUI，至少能看到所有选项的含义。

3.3 map文件：layer mapping的隐性关键

生成tluplus也好，后面跑StarRC提取也好，真正的关键不在tluplus本身，而在map文件。设计数据库里叫M1的层，在GDS里可能是211层；工艺文件里叫METAL1；第三方PDK里可能叫M1_RDL。如果map不对，提取工具要么报错，要么更可怕——不报错，只是静默忽略某些层。

我见过最典型的案例是：一个设计在某些net上完全没有任何寄生电容，查了一圈，最后发现map文件里把两层金属映射到了同一个提取层，另一层被覆盖掉了。这种问题靠肉眼看SPEF很难发现，必须从头检查map。

所以，map文件应该被当成和tluplus同等重要的签核文件来管理。每次工艺文件更新，map也要跟着核对，别只换tluplus不换map。

3.4 max/min两套tluplus怎么跟corner搭配

签核流程里，tluplus通常有成对的两套：一套标称max，对应工艺慢角、高温、高压下的电阻较大、电容较大的情况；一套标称min，对应工艺快角、低温、低压下的电阻较小、电容较小的情况。

实战中的搭配逻辑：

• setup检查用max RC，配合库的slow/slow角，这是最悲观的建立时间条件；
• hold检查用min RC，配合库的fast/fast角，这是最悲观的保持时间条件；
• 做功耗或IR分析时，通常用典型的RC，不需要两个角都跑。

如果把max的tluplus用到hold分析上，大概率会让结果过于乐观，流片回来的芯片hold出问题。这是我自己趟过的坑，也和不少同行交流过，大家都有类似经历。

4. nxtgrd和qrcTechFile：Cadence玩家的两个老朋友

4.1 qrcTechFile是“入口”，nxtgrd才是“引擎”

Cadence的Quantus（以及它前身QRC）体系下，qrcTechFile和nxtgrd的关系很容易被搞混。简单说：qrcTechFile是给人看的、可配置的入口文件，nxtgrd是给引擎用的工艺库，类似tluplus之于StarRC。

早期QRC时代，qrcTechFile通常是一个ASCII文本，里面定义了各层的物理和电气信息；工具会用它处理出二进制格式的.nxtgrd，供后续提取时读入。到了Quantus时代，很多PDK直接同时提供qrcTechFile和nxtgrd，运行提取时qrcTechFile作为输入，底层的提取引擎再调用nxtgrd里的模型数据。

所以你在跑Quantus时看到的输入往往是：

• 设计数据库（OA/LEF/DEF或Milkyway）；
• qrcTechFile（或新版里的quantusTechFile）；
• layer mapping文件；
• 提取控制文件或选项。

4.2 一个典型的Cadence提取流程长什么样

我按自己跑过的流程描述一下：

1. 打开Quantus或复用已有的QRC环境；
2. 指定qrcTechFile路径；
3. 指定nxtgrd库路径（有些流程里这一步是自动完成的）；
4. 配置层映射；
5. 选择提取模式和精度选项，比如是否提取耦合电容、是否包含寄生电阻等；
6. 运行提取，输出SPEF或DSPF。

这里面最容易出问题的环节是第3步和第4步。有些版本里nxtgrd路径写错不会直接报“文件不存在”，而是等跑到一半才报一堆奇怪错误，非常浪费时间。所以我在跑之前一定会先确认这两个文件的修改时间和工艺版本，别拿错PDK里的旧文件。

4.3 nxtgrd使用中容易翻车的几个点

第一，工艺角不一致。nxtgrd里可能只包含typ角，但后端工程师手里同时跑了一堆corner，提取时工具拿不到对应角的ngrd，有时会静默用默认角。这种坑很难一眼发现，但影响很大。

第二，层名与设计数据库不匹配。Cadence流程里，物理层的名称来自工艺库，而设计数据库里的技术文件是另一套。两者之间的映射如果只做了routing层而漏了via层，最后通孔的寄生会完全缺失。

第三，qrcTechFile版本太旧。Quantus新版本对qrcTechFile的语法有调整，旧文件在新版本上打开可能提示兼容问题。换工具版本时，最好用PDK里配套的工艺文件，而不是拿着两年多前的旧配置硬跑。

5. capTable：不起眼却决定提取结果能不能信的电容表

5.1 capTable到底是从哪来的

capTable这个文件在不同工具链里含义不太一样，我接触最多的是Calibre xRC流程里输出的capTable文件。xRC在做寄生参数提取时，除了输出SPEF，也常常会生成一个电容表文件，里面按net列出总对地电容、耦合电容，或按器件管脚列出等效电容。

这个文件的价值不在“看数字”，而在“做验证”。因为很多设计流程里，你根本不会直接把capTable交给后端或签核组，SPEF才是大家要用的。但capTable的信息密度高，非常适合拿来快速判断提取是否正常。

在有些EMIR工具流程里，capTable也可能会被当作工艺文件的代称，比如动态压降分析工具需要一份“电容模型表”。遇到这种用法，要先看工具手册里对capTable的定义，别默认它一定是xRC的输出。

5.2 拿capTable和SPEF对照，快速定位异常

我常用的一个快速验证套路是：对同一条关键net，先用capTable看它的总电容，再从SPEF里挑出这条net的Ctot做对比。正常情况两者应该很接近，差距在几个百分点以内。

如果差异很大，排查方向一般是：

• capTable和SPEF是否来自同一次提取、同一个corner；
• 提取时是否选了不同的耦合电容模式；
• 是否有一方经过了RC压缩或合并。

我遇到过一次capTable显示正常但SPEF数值偏大的案例，后来发现是SPEF生成时把耦合电容重复计算了。这种问题如果没有capTable做交叉比对，光看时序报告根本定位不到。

5.3 几种提取模式对capTable数据的影响

提取工具里通常有几种电容模式：

• 无耦合模式：只算net对地电容，速度快，但结果偏乐观；
• 耦合模式：把net之间的耦合电容也提取出来，结果更真实；
• 详细网表模式：可以输出更精细的RC网络，capTable里也会颗粒度更细。

做时序签核时，必须用耦合模式，否则串扰分析就是空中楼阁。做早期评估或快速迭代时，用无耦合模式节省时间可以理解，但生成的文件要打上标记，别跟签核数据混淆。

6. 混合工具链里的文件互转与一致性排查

6.1 后缀不同不代表内容不相通

现实项目里，你可能拿到的是代工厂提供的nxtgrd，但公司标准流程却走StarRC；或者PDK里只有itf，领导却让你用Quantus跑。这时候你唯一的出路就是做文件互转。

Synopsys和Cadence的工具都提供从itf/ict生成各自工艺库的能力。常见做法是：

• StarRC可以从itf/ict生成tluplus；
• Cadence Quantus可以读入外部工艺文件生成自己的ngrd/qrcTechFile；
• Calibre xRC可以通过其tech file流程引用外部寄生工艺文件。

但互转不是“点一下就完事”的。转换过程中最容易丢的信息是“不同corner的具体参数”，其次是“通孔参数的映射”。我建议互转完成后，一定拿一个已知容值的简单结构做对比，而不是直接整套设计跑完再看结果。

6.2 层映射表自查清单

不管是哪种工具、哪个文件，层映射问题几乎是最常见的“幽灵问题”。我每次排查寄生异常，都按下面这个清单过一遍：

• 设计中用到的所有routing层是否都在map里；
• 所有via层是否都有定义，且孔与孔的阵列信息是否正确；
• 是否有两层被映射到了同一个提取层；
• dummy fill层是否需要参与提取，还是应该在map里显式排除；
• 顶层厚金属、RDL、焊盘开窗等特殊层有没有被误处理；
• 命名大小写是否敏感，映射不到时工具是warning还是silent ignore。

不要小看第六点。silent ignore是最恶心的，因为工具完全“帮”你忽略了问题，你只有在后仿真看到一堆零寄生时才会察觉。

6.3 一次典型排查：从文件缺失到提取异常

我前阵子帮同事救过一个项目，现象是某个模块的SPEF整体电容比预估小了一半。排查链路我记得很清楚：

第一步，先看log。发现有一堆“M5 not found in layer map”的warning。同事说之前也看到过，但一直没处理。

第二步，打开map文件，发现M5这一层确实没写进去。原因是PDK更新后新加了M5的层号，但map文件是从旧PDK复制过来的。

第三步，检查itf，确认M5的工艺参数在里面。然后把map文件补上M5的映射，重新生成tluplus并重跑提取。

第四步，对比新SPEF和参考值，M5相关net的电容恢复正常。

这个案例没什么高深技术，但充分说明一个道理：提取前的文件检查做得越细致，后面排查越轻松。那条warning如果一开始就处理掉，后面就不会浪费半天。

6.4 一致性验证的“灰盒”方法

所谓灰盒，就是不完全依赖工具自检，也不等到全芯片跑完，而是构造一些简单结构来做对照。我常用的有两类：

第一类是长线验证。取一段固定长度、固定宽度的走线，比如1微米宽、1000微米长的单根线，提取后看单位长度电容是否落在手册合理区间。如果偏离超过5%，回头查工艺文件；

第二类是耦合验证。画两条平行走线，改变间距，提取后看耦合电容随间距的变化趋势是否符合预期。如果趋势不对，多半是itf/ict里的介质厚度或介电常数填错了。

这两类测试跑起来都很快，十分钟内能出结果，但能救你一星期。

6.5 版本管理：寄生工艺文件是签核资产

最后说点管理层面的经验。很多设计团队对RTL代码做版本控制做得很严，但对itf、tluplus、qrcTechFile这些文件的管理却很随意。其实这些文件的版本变更，对签核结果的影响可能比一次代码改动还要大。

我现在的做法是：

• 每个项目单独建一个“RC-techfile”目录，记录文件来源、版本、获取日期；
• 任何文件更新都要走评审，更新后必须重新跑一遍长线验证或简单结构验证；
• 在签核报告里记录所用文件的确切版本号，方便事后追溯。

这套做法不复杂，但在多个项目并行、PDK季度更新的时候，真的能省掉很多“到底用的哪个文件”的争论。

整理这些文件关系的过程中，我自己最大的一个体会是：别被后缀名和工具阵营搞晕，先分清楚哪些是工艺描述、哪些是工具生成物、哪些是提取结果。itf/ict和qrcTechFile属于描述层，tluplus和nxtgrd属于工具库层，capTable和SPEF属于结果层。抓准这个逻辑，再看到什么新格式都不慌。后端这行，文件再多，万变不离其宗。