芯片后端寄生参数文件详解：ITF/ICT/TLUPlus/qrcTechFile/NXTGRD

如果你在数字后端流程里待过一阵，一定见过 PDK 目录下面密密麻麻躺着.itf、.ict、.tluplus、.capTable、.nxtgrd、qrcTechFile这些文件。刚接触提参的人，很容易把它们当成“EDA 工具自动生成的临时文件”，直到某一天工具直接飘红“Missing capTable”，或者 signoff 时序怎么都修不动，才意识到这些寄生参数相关文件，才是决定整颗芯片时序准确性的底层工艺字典。

这篇文章我会从一名做过流片、反复和这些文件打架的后端工程师视角，把这六类文件的来龙去脉、文件里到底存了什么、它们之间的转换关系、怎么配置进 ICC2 / PrimeTime / Innovus / Quantus 流程，以及我踩过的一些坑一次讲清楚。需要先说明一点：这里说的 ICT 不是华为 ICT 大赛那个 ICT，也不是信息通信技术的 ICT，而是芯片设计里 Cadence 工具链的互连电容表文件。如果你是因为“华为 ICT 大赛”搜到这篇，可以放心，本文讨论的是芯片后端提参，不是网络赛道知识。

1. 寄生参数文件是干什么的？先解决“为什么存在”

1.1 版图不只是几何图形，而是一堆“物理结构”

版图文件（GDS/OASIS）本质上只是一堆多边形坐标，它告诉你金属层画在哪里、通孔开在什么位置，但不会告诉你这根线有多厚、方块电阻是多少、周围介质层的介电常数是多少。GDS 里的一个矩形，在物理上可能是一层 300nm 厚的金属，也可能是一个 50nm 厚的屏蔽层；上面覆盖的材料可能是低介电常数（low-k）材料，也可能是普普通通的二氧化硅。这些信息必须要由工艺厂提供的技术文件来定义，否则工具根本无法计算这块多边形会带来多大的电容和电阻。

寄生参数提取要做的，就是把版图几何信息与工艺物理信息合并，算出一根线上真实的 R、C 值。这个值直接进入时序计算：线延迟大约可以粗糙理解成 R 乘以 C 的量级，互连变长、变密之后，延迟甚至会超过门延迟，成为路径时序的主导因素。

1.2 为什么不能靠工具“猜”？因为要匹配工艺库

有人会问：不是有 SPEF 或者 SDF 吗？为什么还需要这些源文件？因为 SPEF 是提取完之后的“结果文件”，而我们要的是“工艺输入文件”。没有正确的工艺输入，提参引擎完全不知道该给某一层金属设置多少电阻率，也不知道相邻金属之间的耦合电容该按哪个模型算。不同工艺节点、不同金属层堆叠，甚至是同一工艺的不同 corner，物理参数都可能差很多。用错了文件，轻则仿真结果偏差，重则 signoff 时序完全不可信。

1.3 两类角色要分清：源文件与编译文件

把这一堆文件拉直了看，其实分两大类。一类是“源文件”，以 ASCII 文本为主，工艺厂直接提供，比如 ITF、ICT，以及新一点的 NXTGRD，它们描述完整工艺参数，人可以读，工具也能读。另一类是“编译/加密文件”，是在源文件基础上生成的，比如 TLUPlus、capTable、qrcTechFile，它们被针对性地优化过，速度快、体积小，有些还做了加密，只给特定工具链使用。很多新手看到命名就晕，其实是没先分清这个层级。

2. 六大文件逐个拆：名字背后的真实角色

2.1 ITF：Synopsys 体系的“工艺白皮书”

ITF 全称 Interconnect Technology Format，是 Synopsys 体系最经典的互连工艺描述文件。你在 StarRC、PrimeTime、ICC/ICC2 流程里都会遇到它。ITF 是 ASCII 文件，里面按照金属层、通孔层、介质层分段描述工艺参数：每层金属的厚度、方块电阻、最小线宽、最小间距，每层通孔的电阻，介质厚度和介电常数等。

工艺厂一般会在 PDK 的 STARRC 目录下给出一份或多份 ITF。如果只给了 ITF，通常下一步需要使用 StarRC 或者其他转换工具把它编译成 TLUPlus，供 PR 和 STA 工具直接使用。值得注意的是，ITF 的文件内容对于 human 来说不算友好，但至少可以用文本编辑器打开检查，确认某一个工艺版本下金属厚度和介电常数的具体数值。

2.2 ICT：Cadence 体系的“工艺白皮书”

ICT 全称一般写作 Interconnect Capacitance Table，是 Cadence 生态的互连工艺描述文件。它和 ITF 做的事情高度相似，同样描述金属层厚度、宽度、间距、通孔电阻、介质介电常数等。它通常出现在 Cadence PDK 的 QRC 或 rcxt 相关目录下。

因为 ITF 和 ICT 分属不同公司，文件里的语法、关键字、单位体系完全不同，千万别指望把一个 ITF 后缀改成 .ict 就能在 Cadence 工具里用，两个文件虽然目的一样，但内容组织和读取方式差异很大。ICT 是源头文件，Cadence 的提参引擎一般不直接吃它，而是先把它生成成 capTable 或者 qrcTechFile 这种“技术表”文件，才交给后面的工具使用。

2.3 TLUPlus：Synopsys 实际签核时吃的“预制菜”

TLUPlus，常见后缀就是.tluplus，全称是 Table Look-Up Plus 的二进制工艺文件。它是从 ITF 编译出来的，里面包含了寄生参数提取所需的工艺数据，但做了压缩和加密，体积小、加载快，PrimeTime 和 ICC/ICC2 可以直接读取。它之所以叫“Plus”，可以理解为在传统查找表基础上做了更精细化的 3D 电容/电阻建模，能支撑更先进节点的精度要求。

实际项目中，你会看到xxx_max.tluplus、xxx_min.tluplus这种命名，分别对应该工艺角下互连 RC 的最大值和最小值。很多项目还会配套一个.map或者.itf.map文件，用来把设计里的物理层名和 TLUPlus 里的工艺层名做映射。没有这个映射，工具不知道设计里的 “M1” 该对应 TLUPlus 里的哪一层。

2.4 capTable 和 qrcTechFile：Cadence 家族的两代编译产物

capTable 是 Cadence 传统 RC 提取引擎（比如 Encounter 里的 rcxt）使用的工艺表文件。老一代的 PDK 经常会直接给一个类似xxx.capTable的文件。它也是从 ICT 生成的，需要用 Cadence 的capgen工具来生成。过去用 Encounter 跑提取时，-engine capTable是常见的配置方法。

qrcTechFile 则是 Cadence Quantus/QRC 引擎使用的技术文件，后缀一般就是qrcTechFile或.qrcTechFile。它同样由 ICT 生成，不过生成工具通常是genTechFile。相比 capTable，qrcTechFile 支持更复杂的 3D 场解模型、多介质层模型，精度更高。当前主流 signoff 提参中，Cadence 系工具基本都切换到 Quantus QRC 引擎，也就是用 qrcTechFile。所以如果你在 PDK 里同时看到 capTable 和 qrcTechFile，通常表示同一种工艺分别给两代引擎使用，不代表两个文件要同时配。

2.5 NXTGRD：先进节点里越来越多见的“新面孔”

NXTGRD 是近几年在先进工艺 PDK 里越来越常见的文件格式，后缀为.nxtgrd。它是 Synopsys StarRC NXT 系列工具引入的二进制格点工艺文件，可以理解为 ITF 的“下一代形态”。相比文本型 ITF，NXTGRD 在描述先进节点复杂金属形貌、双重/多重曝光效应、OPC 之后的非矩形截面时更准确，同时文件本身是二进制，加载和计算效率也更高。

实际项目里，有的 PDK 会直接提供.nxtgrd文件，StarRC NXT 可以直接读它来提取寄生参数；有的流程则会用它进一步生成 TLUPlus，供 PrimeTime 做 signoff 时序。所以你在 PDK 里看到.nxtgrd不要慌，它不是另一个孤立格式，而是 ITF 的升级版和补充版。老一点的文档可能完全没提这个格式，但新工艺中它已经占据了重要位置。

2.6 一张表总结六大文件

3. 文件里写的是什么？用伪 ITF 看懂核心参数

3.1 金属层：厚度、方块电阻、最小间距

拿一份 ITF 或 ICT 来看，最核心的内容就是金属层定义。以伪代码为例，金属层部分通常会包含这几类信息：

LAYER M1 { TYPE = CONDUCTOR; THICKNESS = 0.45u; RESISTIVITY = 3.2e-8; MIN_WIDTH = 0.1u; MIN_SPACING = 0.1u; }

其中 THICKNESS 决定金属截面积，截面积配合电阻率才能算出方块电阻；MIN_WIDTH 和 MIN_SPACING 决定提取引擎在哪个尺度的版图密度下进行查表。千万不要以为 “最小线宽” 只影响 DRC，它也影响寄生查找表的边界范围。如果版图上出现了比工艺文件最小值还细的线，提参工具要么报警，要么外推，结果可信度很低。

在实际 U 级工艺里，同一层金属还要区分横向和纵向厚度差异、金属表面粗糙度、籽晶层残余等因素，ITF 中对每层金属的电阻描述不只是一个简单的固定值，而是一个和宽度有关的查表关系。细线因为侧壁和晶粒结构影响，实际方块电阻和宽线不一样。这一点在先进节点特别明显，也是为什么用文本文件手工估算很容易翻车的原因。

3.2 介质层与介电常数：决定电容的主要变量

电容的核心公式大家都学过，平行板电容等于介电常数乘面积除以间距。互连线之间的电容既有正对的平板电容，也有边缘的 fringe 电容，所以介质层的厚度和介电常数必须被完整建模。ITF/ICT 里会对每一层介质给出 PERMITTIVITY，也就是相对介电常数，还会给出介质厚度。

先进工艺普遍使用 low-k 材料来降低层间电容，但 low-k 材料的介电常数往往不是均匀场，在刻蚀、CMP 之后局部介电特性会有变化。所以真正的提取不是用一个固定公式算所有线，而是用 3D 场解器预计算出一组“电容查找表”，再根据实际版图的宽度、间距、相邻层位置去查表插值。这就是为什么文件里除了厚度、介电常数之外，还包含大量查找表数据，而不是一个简单公式。

3.3 通孔与接触孔：电阻的隐形杀手

很多人只盯着金属，忘了通孔。通孔在版图上面积不大，但电流要从下层金属经过通孔到达上层，通孔电阻往往比同等长度金属线的电阻更集中。在 ITF/ICT 里，通孔层会描述单孔电阻、孔阵列、接触面积、上下金属搭接要求等。不同的通孔排布方式，最终提取出的电阻值差别很大。

实际项目里，如果通孔层的文件缺失或者版本不匹配，提取结果可能出现某段路径电阻异常偏大，进而导致 setup 违例修不掉。我遇到过把 VIA1 参数误写成 VIA2 参数的 PDK 版本问题，整条 2 层金属路径的电阻直接偏大 30% 左右，最后逐层核对工艺文件才发现。

3.4 单位体系：所有数值必须要有清楚映射

这类文件里最容易翻车的不是内容，而是单位。ITF 里长度通常用微米或米为单位，电阻率可能有“欧姆·米”和“欧姆·微米”的差异；ICT 里也存在类似的单位不统一风险。工具内部一般会严格按照文件头声明或者默认单位体系换算，但如果你用脚本手工处理过这些文件，一定要先搞清楚原始单位。

我曾经见过有人图省事，把 ITF 里的 0.5u 在脚本里当成 0.5 微米，但实际上文件头声明的是 0.5e-6 米，自己再加一次换算就会造成 1000 倍误差。这类错误一旦进了提参结果，完全看不出来，因为工具不会报错，只是所有电阻偏大或偏小。所以确认单位比确认文件路径更重要。

3.5 为什么用查找表而不是解析公式

现在的寄生提取已经极其依赖查找表。一个原因是版图中线网之间耦合电容与间距的关系不是简单的 1/d，而是受侧壁、屏蔽层、相邻金属层共同影响的非线性关系。另一个原因是 3D 场解器资源消耗大，不可能对每一个线网做实时有限元求解。所以工艺厂在 PDK 提供前，会先使用精确场解器在不同的线宽、间距、厚度组合下跑大量仿真，把结果整理成一张查表。提参引擎在工作时，只需要从版图中提取出几何关系，然后去查表插值。

这就是为什么 ITF/ICT 文件除了文本参数，还有些看起来像“无意义数字表”的内容。那些数字不是拍脑袋写的，而是 3D 场解的浓缩结果。理解了这一点，你就会明白为什么最好不要手改这些文件，改一个数字，等于把整个工艺数据库都污染了。

4. 拿到 PDK 后，怎么正确用起来

4.1 先做文件清单盘点

拿到一个新工艺 PDK，不要急着一股脑把文件路径写进脚本。先在 PDK 目录下找到寄生参数相关目录，通常叫starrc、rcx、qrc、extraction之类。把里面每个文件的性质和来源记录下来。我习惯用一张表格列出：

• 文件名和完整路径。
• 对应工艺角是什么（typ / Cmax / Cmin / RCmax / RCmin）。
• 格式是 ITF、ICT、TLUPlus、capTable、qrcTechFile 还是 NXTGRD。
• 该文件给哪个工具用。
• 如果是生成文件，它对应的源文件版本、生成工具版本。

这一步看似费时间，但能避免后面积累一批路径错误的配置脚本。

4.2 ITF/NXTGRD 到 TLUPlus 的转换思路

如果你的 PDK 只提供了 ITF，而你的 PR 工具要 TLUPlus，通常需要使用 Synopsys StarRC 或者其自带的转换工具来生成。流程大致是：用 StarRC 读入 ITF，完成必要的层次映射，然后输出一个 TLUPlus 文件。不同 StarRC 版本的命令名不完全一致，有的版本直接在安装目录下提供独立的转换命令。生成好的 TLUPlus 还要配套生成或者手工整理一个层映射文件，把设计里的物理层名如M1、V1映射到 TLUPlus 里对应的工艺层名。

如果 PDK 直接给了.nxtgrd，在新版本 StarRC NXT 里可以直接读取这个文件做提取，不需要先转成 TLUPlus。但如果你的签核流程是 PrimeTime 读 TLUPlus，还是要把.nxtgrd转成.tluplus。具体的命令名、参数、输出路径，建议以 PDK 附带的 README 或运行脚本为准，因为不同 gen 工具版本相差很大。

4.3 ICT 到 capTable / qrcTechFile 的转换思路

Cadence 生态下，如果只拿到 ICT，通常要先运行genTechFile生成 qrcTechFile。老流程里用capgen生成 capTable。命令通常是：

genTechFile -i process.ict -o qrcTechFile capgen -i process.ict -o process.capTable

不同 Cadence 版本参数会有差异，但大体思路就是“从纯文本源文件出发，生成工具链直接消费的编译文件”。生成之后的 qrcTechFile 会包含更完整的三维工艺描述，而 capTable 相对精简。命令行细节可以在 Cadence 工具帮助里再看一眼，但流程上必须先有这个转换动作。

如果你的 PDK 已经直接提供了 qrcTechFile 或 capTable，那就跳过转换，但要确认对应哪个 RC corner。很多 PDK 会给出typ、max、min多套，每套都能用，但服务于不同时序分析目的。setup 分析一般用 max 的 RC，hold 分析一般用 min 的 RC，不能一套 typ 吃到底。

4.4 在 ICC2 / PrimeTime 里的配置

Synopsys PR 和 STA 工具配置 TLUPlus 的统一思路是设置最大最小两个 TLUPlus 文件，以及一个映射文件。典型命令类似：

set_tlu_plus_files \ -max_tluplus /path/rc_max.tluplus \ -min_tluplus /path/rc_min.tluplus \ -tech2itf_map /path/layer.map report_tlu_plus_files

配置后必须report_tlu_plus_files确认工具真的读到了文件，并且层映射正确。很多工具版本支持一次配置、自动在多个 PVT corner 间切换，只要你在 SDC 或者 CORNER 里对应好。还有一点非常重要：TLUPlus 和映射文件最好使用绝对路径，避免在跑批量任务时因为工作目录切换找不到文件。

4.5 在 Innovus / Quantus 里的配置

Cadence 系配置 qrcTechFile 的方式因工具版本而异。比较常见的是在 innovus 里：

set_rc_tech_file -qrc_tech /path/qrcTechFile setExtractRCMode -engine qrc -effort signoff extractRC

如果是老的 capTable 流程，则可能是：

setExtractRCMode -engine capTable -file /path/process.capTable extractRC

用set_rc_tech_file配置之后，推荐用report_rc_tech_file之类的命令确认文件加载信息，同时看工具输出的 layer 列表和你设计里的 physical layer 是否一致。这一步能发现很多 Layer Mapping 问题。

4.6 快速验证提取结果

配置完不等于万事大吉。第一次在新流程上跑提参，我会选一个中规模 block，跑完提参之后看几个关键指标：

• 总电容（total capacitance）是否符合该 block 面积和工艺节点的经验范围。
• 关键路径上互连电阻的量级是否合理，比如 28nm 工艺下一段 100μm 的顶层金属电阻应该在几十欧姆量级，而不应该是几百欧姆。
• 有没有报出负电容、负电阻或者特别离谱的 coupling 电容。

如果这些数值异常，第一时间回去查文件版本、corner 选择、层映射，而不是去抄优化脚本。提参结果的量级检查，可以帮你节省一整天的 debug 时间。

5. 常见报错与排查技巧实录

5.1 文件存在但工具说找不到

很多时候脚本里写的是相对路径，或者变量没有 export 到当前 shell，导致工具报Can't open file。排查方法是先用ls -l确认真实路径，再在工具里直接打印变量值。别小看这个低级问题，我在 16nm 项目中曾经因为一个$RC_TLUPLUS变量在.bashrc里写错了一个下划线，横跨了两个目录路径，浪费了半天时间。最终就是把路径改成绝对路径并加了一个显式的puts才定位到。

5.2 层名对不上，界面里全是 M1/AP

最常见的问题是设计数据库里的层名和 TLUPlus/qrcTechFile 里的层名不一致。例如 Innovus 里顶层金属叫AP_TOP，TLUPlus 里叫AP，映射文件如果没配，工具会忽略或者报 layer not found。这类问题需要用映射文件把“设计层名”和“工艺层名”对应起来。检查方法很简单：report_tlu_plus_files之后，看 report 里列出的 layer 和你设计中的 physical layer 能否一一对上。多一个层少一个层都会影响提参精度。

5.3 工具版本和加密文件不兼容

TLUPlus 这类二进制文件是带版本信息的。新版本工具通常能读旧文件，但反过来经常不行。如果你在旧工具版本上遇到Invalid TLUPlus version或者Encryption key mismatch，基本只能重新生成匹配版本的 TLUPlus，或者请 PDK 支持更新文件。不要去尝试解密或者绕过，工具加密机制本身就是防止跨版本乱用，强行绕过很容易让结果不被 signoff 认可。

5.4 提取结果出现负电容/负电阻

看到负值不要慌张，先分清楚是哪来的。有的提取器对很小的耦合电容做数值处理时，插值可能会出现轻微的负值，通常在容差范围内，不会影响时序。但如果大量出现负电容，基本是工艺文件里的介电常数、金属厚度或者查找表出了问题。另一个原因是版图里有非曼哈顿几何（比如 45 度斜线），部分提参模型对这种形状支持不好。这时回到文件版本，先换官方推荐的 standard flow 再试，不要靠调求解器参数撞运气。

5.5 corner 文件别选错：max/min 不是越多越好

不同 corner 的 RC 文件要服务于不同时序检查。setup 一般看 max RC 和慢工艺角，hold 一般看 min RC 和快工艺角。如果一次性把 max、min 的 TLUPlus 都配进去，工具会根据电压温度自动选，但前提是 corner 定义正确。我在一个项目里发现脚本把rc_max.tluplus配到了-min_tluplus参数上，工具没报警，只是所有 hold 分析都用了过大的 RC，导致 hold 违例一大片。这种问题只靠人工盯配置很难发现，所以最好每跑完一个小模块就对比 max/min 的时序数据，看趋势是否合理。

5.6 一条自查清单

• 源文件和编译文件的工艺版本是否一致？
• 文件路径是否绝对路径？变量是否在当前 session 有效？
• 层映射文件里是否覆盖了所有金属层和通孔层？
• 工具的版本是否在 PDK 支持列表内？
• 是否在运行后执行了 report_tlu_plus_files / report_rc_tech_file 确认加载？
• 提参结果的总电容、关键路径电阻量级是否在预期范围？

6. 最后一些个人经验

这些寄生参数文件虽然名字又多又杂，但底层逻辑其实很清晰：每一家 EDA 都有“源文件 + 编译文件”两套体系，源文件描述物理，编译文件加速工具读取。你真正要做的，是在项目第一天建立一个非常明确的技术文件清单，记录来源，记录版本，记录转换命令，记录对应的 corner。我见过太多项目在 tapeout 前因为改了一版 PDK，导致 itf 和 tluplus 版本不匹配，最后整个 timing 基线全漂了，那种痛苦不值得再经历一次。

我个人还有个习惯：拿到新 PDK 后，先不跑完整 block，而是用一个小 module 把 ITF 或 ICT 到最终提参结果的链路完整跑一遍，确认每一层的厚度、电阻、电容解释都正常。这个流程虽然多花一个下午，但能避免后面因为文件配置问题反复横跳。寄生参数文件是后端最无聊、但又是最不容出错的部分之一，把所有不确定性消灭在项目前期，后面的 timing 收敛才会真正稳。