★ FEATURED ARTICLE 数字IC这行做久了会发现前端验证跑得再漂亮进了后端出了网表很多问题才会真正冒头。后仿Post-Layout Simulation就是把带时序信息的门级网表拿回来重新跑一遍看看真实电路在延时、建立保持、时钟树偏差这些约束下还能不能按设计初衷工作。很多人对它的印象是慢、卡、X态满天飞但恰恰是这一关能拦住大量流片后才会暴露的问题。这篇东西我从后仿要准备的文件、环境怎么搭、四阶段怎么推进、到X态和时序违例怎么查按我自己走过一遍的流程完整写下来适合刚接触门级仿真的初级验证同学也适合前端设计想搞明白自己写的RTL过了综合之后会变成什么样的朋友。1. 后仿到底在仿真什么从RTL到门级的认知切换后仿的核心目标不是重新验证功能逻辑功能逻辑在前仿阶段应该已经收敛了。它真正要确认的是三件事时序相关的行为是否和静态时序分析STA的结论一致、综合与布局布线有没有引入功能性的错误、以及复位、时钟、跨时钟域这些结构在真实延时下是否还成立。搞清楚这个定位后面所有的操作取舍才有依据。1.1 前仿与后仿的本质差异在哪前仿跑的是RTL代码仿真器执行的是行为级描述延时通常只有代码里写的#延时或者干脆是零延时。这种方式跑得快、调得爽但它看不到标准单元本身的门延时、连线延时、时钟树上的偏斜。换句话说前仿世界里所有信号传播都是理想瞬间完成的。后仿跑的是综合或布局布线之后生成的门级网表里面全是标准单元实例与门、或门、触发器等和它们的连线。这时候每个单元有一个延时值每根线有一个延时值这些数值统一放在SDFStandard Delay Format文件里。仿真器通过SDF反标把这些延时值灌进网表对应的路径上仿真出来的波形才接近真实芯片。差异的根源就在这——从理想零延时切换到每根线都带延时。我见过不少新人以为后仿就是换个网表文件跑一跑结果一开跑全是X或者时序违例刷屏完全不知道从哪下手。本质原因就是没意识到延时引入后信号到达时间全变了原来靠组合逻辑直接穿过去的路径现在可能差了几百皮秒。1.2 后仿的三个层次零延时、单元延时、SDF反标实际工程里后仿不是一步到位的通常分三个层次递进这是被无数项目验证过最省时间的做法。第一层是零延时网表仿真。只加载门级网表不给任何延时SDF不反标。这一步的目的是确认网表本身功能正确、testbench能对上网表、端口和层次名没错。它跑得最快基本等同于用门级网表再跑一遍前仿。第二层是单元延时仿真Unit Delay。用delay_mode_unit或者让所有单元统一延时一个单位。这一步是为了在引入真实SDF之前先看看延时存在时功能崩不崩能快速定位是不是某些路径对延时敏感。第三层才是SDF反标仿真也就是真正的后仿。把后端给出的SDF文件反标进去做min/typ/max不同corner的仿真。到这一步时序违例、X态、亚稳态问题才会集中出现。提示很多团队为了省机时会跳过第二层直接上SDF结果一出问题就分不清是网表错、testbench错还是时序错。分层推进虽然多跑两次但总调试时间反而更短。1.3 为什么后仿绕不开SDF和标准单元库SDF文件描述的是延时标准单元库的仿真模型描述的才是功能。网表里每个实例AND2X1 u1 (...)要能仿真必须找到对应库里的AND2X1模块定义。这个定义里既有逻辑功能也有specify块描述的时序检查setup/hold/recrem和路径延时。所以后仿环境的三大件是门级网表、标准单元仿真模型库、SDF文件。缺一个都跑不起来。库文件一般由工艺厂或IP供应商提供注意要拿到和综合/PR所用库版本一致的仿真模型版本对不上会出现实例找不到或者时序检查参数错误的情况这是后仿环境搭建里最常见的坑之一。2. 后仿流程的整体设计与文件准备后仿的成败八成在准备阶段就决定了。文件拿错、版本对不上、corner选错后面怎么调都是白费功夫。我把整个流程拆成拿文件、对版本、选库、搭环境四步按这个顺序走能避开大部分返工。2.1 需要向后端索要哪些文件从后端PR那边你至少要拿到下面这几类文件我会做一个清单每次对照着收门级网表PR完成后的.v文件通常是扁平化flatten或者保持层次的看你们流程。建议要带层次的方便反标时定位实例。SDF文件由PrimeTime或PR工具write_sdf生成。注意问清楚是哪种cornerbc_wcbest-case/worst-case还是OCV是单个文件还是min/typ/max三个。时序约束SDC虽然仿真不直接用SDC但排查违例时要拿它对照看哪些路径是被真正约束的。标准单元仿真模型.v或.vhd工艺库提供。存储器、IO、模拟IP的仿真模型这些通常用行为级模型替代PR网表里可能是黑盒需要单独挂模型。memory初始化文件$readmemh用的.hex或.mem。拿到文件以后第一件事不是急着跑而是记录每个文件的生成时间、版本号和corner标签。后仿最怕的就是用了三天前旧版本的SDF配今天的新网表反标直接报实例找不到。2.2 网表与SDF的版本对齐为什么这么重要网表和SDF是强绑定的。SDF里每一条延时记录都绑定了一个具体的实例路径名比如chip_top.u_core.u_alu.u_adder_0.sum_3。如果网表重新综合过实例名或者层次结构变了SDF里的路径就在网表里找不到反标会提示大量 annotation failed。我踩过的坑是这样的后端为了修一个时序违例重新跑了PR并出了新网表和新SDF但中间的版本管理没做好我拿的是新网表配旧SDF反标日志里几千条失败我当时还以为是仿真器配置问题查了半天才发现是版本错配。从那以后我养成习惯网表和SDF必须来自同一次PR结果且记录同一个timestamp。2.3 仿真库怎么选和映射标准单元库一般会提供多种仿真模型带时序检查的完整模型、不带时序检查的简化模型、以及不同电压温度条件下的模型。后仿通常用带specify时序检查的完整模型这样setup/hold违例才能被仿真器报出来。库映射是通过-y和libext或者-v选项告诉编译器的。# VCS 里指定库搜索路径和文件后缀 vcs -full64 -sverilog \ -y ${LIB_DIR}/verilog \ libext.v \ -v ${LIB_DIR}/verilog/tsmc28_stdcell.v \ ...Xcelium 的写法类似xrun -64bit -sv \ -v ${LIB_DIR}/verilog/tsmc28_stdcell.v \ -y ${LIB_DIR}/verilog \ libext.v \ ...需要留意的是如果库是按工艺角分目录的tt/ff/ss仿真模型本身可能是一样的只是SDF不同。别把库和SDF的corner搞混库模型决定功能SDF决定延时。注意有些工艺库的仿真模型内部会include其他文件路径写的是相对路径。建议把库目录结构原封不动拷到工程里不要打散否则include找不到文件。3. 环境搭建与关键参数配置环境搭建是整个后仿里最考验细节的部分。同样一份网表和SDF配置对了跑得又快又准配置错了要么半天跑不完要么报一堆假违例。这一章我把编译选项、SDF反标配置、时序检查开关这三块讲透。3.1 编译选项的实际含义与选择后仿编译跟RTL仿真的最大区别就是必须打开负延时支持和精度设置。下面这几个选项我会逐一解释为什么需要选项作用必要性neg_tchk允许时序检查使用负值例如负的setup必须库模型常常有负值-negdelay允许负延时SDF里可能出现负延时必须否则反标报错sdfverbose打印详细的SDF反标信息建议排查反标问题必备notimingchecks关闭所有时序检查分阶段用功能验证阶段开delay_mode_path使用路径延时模式后仿推荐maxdelays/mindelays选择使用SDF里的max或min延时按corner切换neg_tchk和-negdelay这两个是最容易被忽略的。工艺越先进库里的setup时间越可能是负值因为时钟到数据路径的延时差异不打开这两个选项编译或反标阶段就会直接报错或警告很多人第一次遇到一脸懵。精度设置也很关键。网表SDF里的延时精度可能是1ps甚至10fs而你的仿真时间精度如果设成1ns延时全部被舍入成0那后仿就跑了个寂寞。// testbench 顶部设定时间精度 timescale 1ns/1ps // 时间单位1ns精度1ps一般后仿建议1ps/1ps或1ps/10fs跟SDF的精度对齐。同时仿真器的-timescale选项可以覆盖但要小心不要和文件内的timescale冲突。3.2 SDF反标的三要素配置SDF反标用的是系统任务$sdf_annotate它的完整签名是$sdf_annotate(sdf_file, module_instance, config_file, log_file, mtm_spec, scale_factors, scale_type);sdf_fileSDF文件路径module_instance要反标的模块实例通常是DUT顶层config_file反标配置文件可指定忽略某些路径或指定模块对应的库单元log_file反标日志一定要留出问题全靠它mtm_specMINIMUM/TYPICAL/MAXIMUM对应corner一个实际配置写出来长这样initial begin $sdf_annotate(../sdf/chip_top_max.sdf, tb_top.u_dut, ../cfg/sdf_annotate.cfg, ../log/sdf_max.log, MAXIMUM); end三要素里module_instance最容易写错。它必须是网表里真实存在的层次路径且SDF里的路径是相对于这个实例的。如果SDF生成时是相对于chip_top的你反标时传的是tb_top.u_dut那就要确认tb_top.u_dut和chip_top是否对应否则路径匹配会失败。提示反标日志里如果出现 Failed to annotate 或 Cannot find module先别改仿真器配置先去日志里看是哪个实例名对不上八成是层次名或者版本问题。3.3 时序检查开关什么时候开什么时候关时序检查setup/hold/recovery/removal是后仿能报出违例的关键但它也是仿真变慢和假违例的主要来源。我的策略是分阶段开关零延时和单元延时阶段用notimingchecks全关专注功能。SDF反标第一次跑全开把所有违例都收上来看整体情况。收敛阶段针对已知会违例但设计上可容忍的路径用配置文件或$setuphold的notifier选择性关闭。全关时序检查会漏掉真实问题全开又会因为大量异步路径上的假违例把日志淹没。所以更精细的做法是用SDF的配置文件指定某些路径不检查// sdf_annotate.cfg 示例 PATH tb_top.u_dut.u_async_bridge.* TIMING_CHECK OFF反过来如果库模型是简化版没有specify块那即使开了时序检查也报不出违例这时候要确认库文件版本对不对。4. 实操全流程与分阶段推进理论讲完进入实操。我把整个后仿分成四个阶段每个阶段有明确的通过标准和退出条件这样做的好处是问题不会跨阶段累积调试范围可控。4.1 阶段一零延时空跑先让仿真能起来这个阶段的目标只有一个让仿真能跑起来并且功能对得上前仿。具体步骤建一个后仿的编译脚本加载网表、库、testbench暂不反标SDF。编译时加notimingchecks避免库里的时序检查报错。检查编译日志有没有实例找不到missing module、端口不匹配port mismatch。跑一小段激励对比波形和前仿是否一致。这个阶段最常遇到的问题就是库实例找不到。原因通常是库文件没加载全或者某个IP的行为模型没挂上。看到日志里 Module SRAM_512X32 not found就去补对应的存储器模型。另一个常见问题是顶层端口名对不上。PR网表的顶层端口名可能和后端改了名或者综合时加了_post_syn后缀testbench直接例化就会报错。这种情况要么改testbench例化要么让后端保持端口名一致。这个阶段的通过标准编译无error仿真能跑完预设激励关键输出和前仿一致。4.2 阶段二单元延时跑通功能零延时通过后进入单元延时阶段。这个阶段给所有单元加一个统一的延时看看功能在延时存在时是否还成立。# 在编译选项里加上 delay_mode_unit或者更精细一点用delay_mode_distributed配合库里的延时。这一步能快速暴露那些靠组合逻辑瞬间穿透的错误比如门控时钟、异步复位释放、组合循环等功能上本来就有隐患的结构。我实测下来很多在前仿里因为零延时显得刚好能work的时序竞态在单元延时下就会现出原形。这一步花不了多少时间但收益很大。通过标准功能依然正确没有因为延时引入而产生新的X态或错误输出。4.3 阶段三SDF反标与时序收敛真正的后仿从这一步开始。操作要点把扩展名编译选项从delay_mode_unit换成delay_mode_path并去掉notimingchecks。加入$sdf_annotate指定max corner先跑。编译时加neg_tchk、-negdelay、sdfverbose。跑全激励或关键场景。第一次SDF后仿通常会有几个典型现象现象一波形大面积X态。这多是因为寄存器初始状态未复位或者存储器模型没初始化。处理办法是确认复位序列完整存储器用$readmemh初始化。现象二时序违例刷屏。日志里大量 setup violation。要先分类是真实违例还是异步路径假违例。真实违例要反馈给后端或前端假违例用配置关闭。现象三仿真跑得极慢。SDF反标后延时变多变密事件数量爆炸。后面第6章会专门讲加速。这个阶段可能要反复多轮min/typ/max三个corner都要跑。我的经验是先把max跑通max时序最紧问题最多max收敛了min和typ一般问题不大。4.4 阶段四全芯片回归与X态清理最后一个阶段是全芯片长激励回归。这一步跑的是接近真实工作场景的激励目标是零X态、零未解释违例、功能与前仿一致。X态清理是耗时最多的部分。X态会沿着组合逻辑传播一个源头的X可能污染一大片。定位方法用波形的 X tracing 功能从X出现的点往源头追。常见源头未初始化寄存器、多驱动、总线冲突、存储器未初始化、时序违例引起的notifier触发。我的做法是先冻结功能把X态当成独立问题清单逐条清。清完X态再看时序违例因为有些违例是X态引起的假象X清掉了违例也跟着少了。通过标准全激励零X违例清单已评审且可解释输出对比前仿一致。到这里后仿才算真正收工。5. 常见问题与排查技巧实录后仿的问题五花八门但翻来覆去就那么几类。我把实际遇到过的典型问题整理成速查表再挑几个展开讲排查思路。5.1 X态排查从波形反追源头X态是后仿头号麻烦。它出现的根本原因是某个信号既不是0也不是1仿真器无法确定。常见来源有这些触发器上电未复位初始值就是X。多驱动冲突两个源同时驱动一根线。case语句没写default遇到X输入时输出X。存储器读取未初始化地址。时序违例触发notifier把输出打成X。排查顺序我一般是先在波形里定位X最早出现的时间点和信号然后逐级往输入方向追直到找到那个源。多数时候追到源头会发现是复位没覆盖到某个模块或者某个使能信号在复位期间是X。心得加defineX_ASSERT之类的宏在关键模块里用 assertion 主动检测X比事后追波形效率高得多。我后来在关键路径上都加了X检测assertionX出现时直接报出模块名和时间点。5.2 时序违例分清真假再动手时序违例分真实和假违例。判断方法看违例路径是不是跨时钟域且已经做了同步处理。如果是多半是假违例SDF给的是最坏延时实际同步器设计上可容忍用配置关闭。看违例路径是不是被测时钟域之外的时钟驱动。如果是异步时钟仿真器不知道频率关系会报违例也是假违例。剩下的才是真实违例要检查STA报告是否也报了同样路径。如果STA没报而仿真报了可能是SDF corner选错了或者仿真激励里的时钟频率和约束不一致。真实违例的处理路径是反馈后端修时序或者前端改逻辑或者调整约束。仿真阶段能做的是记录、分类、暴露别指望在仿真里调掉。5.3 性能优化让后仿跑得快一点后仿慢是通病但可以优化。以下手段我实测有效减少dump波形范围。只dump关键模块和关键时间段用$dumpvars的分层参数。关闭不必要的timing check。收敛阶段只保留关心的路径。用行为模型替代大块IP。PLL、模拟IP、大容量memory用行为模型仿真速度能提升数倍。分块仿真。把大芯片拆成几个子模块分别后仿最后做一次顶层的短激励集成验证。多核仿真。VCS的-fgp和Xcelium的-mce能利用多核。缩短激励。回归激励只保留必要的场景长激励放最后一次性跑。这里要强调加内存换时间在服务器充足时是最直接的方案但也要注意单进程内存上限别跑到一半被OOM杀掉。5.4 常见问题速查表现象可能原因排查方向反标日志大量 Failed to annotate网表与SDF版本不匹配 / 层次名不对核对timestamp和层次路径波形全X复位序列不完整 / 存储器未初始化检查复位覆盖和$readmemh时序违例刷屏异步路径假违例用配置关闭CDC路径仿真极慢事件爆炸 / 波形dump太大减少dump、关检查、换行为模型端口不匹配报错网表顶层端口名变化对比前后端口名延时全部为0timescale精度不匹配对齐1ps/1ps负延时反标失败缺-negdelayneg_tchk补编译选项6. 我在后仿上踩过的坑和攒下的效率技巧前面讲的都是流程和配置这一章纯粹是我自己这些年积攒下来的经验很多是文档里不会写、但实际会让你少熬几个通宵的东西。第一个习惯是每轮仿真都留完整日志。编译日志、反标日志、仿真日志、违例日志分门别类存好按corner和日期命名。后仿一轮可能几个小时出了问题想复现很难日志就是你唯一的证据。我曾经因为没存反标日志重跑一遍多花了大半天。第二个是把SDF反标配置参数化。用脚本变量控制cornermin/typ/max和延时模式一个命令切换别手工改。CADENCE和Synopsys的流程里都可以用环境变量或者Makefile参数实现。切corner时最容易出错的就是漏改某个选项参数化能避免。第三个关于X态别急着用notimingchecks一把关。时序检查关掉确实能让X少很多但也把真实问题藏起来了。正确顺序是先开着检查把问题收全分类之后再选择性关。我见过有人图快全程关检查最后上板挂了还在纳闷。第四个是关于SDF的max/min选择要跟STA对齐。仿真跑max cornerSTA也要看setup的最坏情况仿真跑min corner对应hold的检查。如果仿真跑max而STA看min两边结论对不上你会白折腾。这个对齐关系建议在项目启动时就和后端、STA同学确认清楚。最后分享一个加速小技巧别在整芯片上跑长激励。把激励分段用检查点checkpoint或者事务级建模TLM的方式在前端就验证过的功能后仿阶段只需要验证时序敏感的那部分。整芯片长激励留给最后收尾那一两次。这套做法让我们的后仿机时省了一大半同时覆盖度靠分块仿真 一次顶层集成来保证。这套流程跑顺了之后后仿其实没有传说中那么可怕。真正难的是第一次跑通之前把文件、版本、选项、corner这几件事理清楚。把这些基础打牢后面就是耐心地一轮轮收敛X态一条条清违例一条条分类没有捷径但也没有玄学。
阅读完成 · 觉得有帮助？
