做芯片后端的人早晚要跟一堆后缀名奇形怪状的文件打交道。itf、ict、tluplus、nxtgrd、qrcTechFile、capTable光是把名字念顺就得花两天。我第一次接触这些文件的时候PDK里塞了十来个类似的东西没人告诉你该用哪个也没人讲清楚它们之间到底是替换关系还是上下游关系。后来被坑了几次才慢慢理顺这些文件不是谁替代谁而是一条从工艺信息到版图RC提取的完整链条。这篇就把六类寄生参数相关文件的关系、用途和用法一次说透适合刚接触后端提取流程的工程师也给跨流程换工具的人做个参考。1. 寄生工艺文件的“家谱”六类文件到底啥关系1.1 先给六类文件画个像先看一张我习惯用的总览表把每一类的定位先钉住后面再展开。这张表我按“谁产生、谁消费、什么内容”的维度整理过跨过好几个项目都适用文件名全称/常见来源核心内容谁在用itfInterconnect Technology Format代工厂或三级PDK团队提供互连层几何参数、介质厚度、介电常数、方块电阻、通孔参数StarRC等工具用它生成tluplusictInterconnect Capacitance Table来源类似itf用表格方式描述电容随线宽/间距/厚度的变化关系同样用于StarRC生成tluplustluplusTLUSynopsys工具生成的工艺库文件提取引擎查表用的RC模型包含unit R/C、耦合电容曲线StarRC提取时直接引用nxtgrdCadence Quantus/QRC的工艺库文件类似tluplus的作用是Quantus提取引擎使用的工艺描述Quantus、旧版QRCqrcTechFileCadence QRC/Quantus的技术文件入口定义工艺层、映射关系、提取选项的配置文件Quantus运行时的输入capTable寄生电容表常见于Calibre xRC等工具的输出或中间文件每个net/节点对地电容、耦合电容的汇总用于后仿真、EMIR、交叉验证这表里最容易绕晕的是tluplus和capTable。tluplus是“工艺模型”不是某个net的提取结果capTable则更接近“结果文件”是整个设计或某条net线网的电容汇总。一个是菜谱一个是炒出来的菜别混。1.2 谁生成谁谁喂给谁我梳理这些文件时最管用的办法是把它们按“工艺信息来源 → 提取引擎库 → 提取结果”三层摆开第一层是代工厂给的工艺描述itf或ict。有些PDK给itf有些给ict有些两个都给但作用重叠。第二层是提取引擎实际用的库文件Synopsys体系里是itf/ict经过转换得到的tluplusCadence体系里是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. 工艺文件变成tluplusSynopsys签核提取的标准链路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工具里通常有对应的图形界面入口或命令行选项。实践中我一般走这样的流程确认itf/ict文件的版本与当前设计所用的工艺层叠一致准备一个layer map文件把设计数据库里的层名映射到itf/ict里的工艺层名在工具中分别生成max和min两套tluplus用工具自带的检查模式跑一遍看有没有“层未被映射”之类的warning把生成的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和qrcTechFileCadence玩家的两个老朋友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或MilkywayqrcTechFile或新版里的quantusTechFilelayer mapping文件提取控制文件或选项。4.2 一个典型的Cadence提取流程长什么样我按自己跑过的流程描述一下打开Quantus或复用已有的QRC环境指定qrcTechFile路径指定nxtgrd库路径有些流程里这一步是自动完成的配置层映射选择提取模式和精度选项比如是否提取耦合电容、是否包含寄生电阻等运行提取输出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生成tluplusCadence Quantus可以读入外部工艺文件生成自己的ngrd/qrcTechFileCalibre 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属于结果层。抓准这个逻辑再看到什么新格式都不慌。后端这行文件再多万变不离其宗。