1. 从一次流片前的时序惊魂说起去年冬天一个做车规MCU的团队在流片前两周找到我说他们的MBIST测试模式在ATE上跑不过扫描链能过但一进MBIST就报时序违例测试向量加载到一半就挂。他们第一反应是是不是Tessent生成的pattern有问题折腾了三天最后发现根因是MBIST的SDC约束压根没写对——测试时钟的create_clock和实际ATE给的时钟相位差了一个反相器延迟导致setup违例。这件事让我意识到Tessent MBIST SDC这个组合看起来只是工具约束的简单叠加实际上踩坑的人远比想象中多。这篇内容我想聊的就是Tessent MBIST和SDC约束之间那层容易被忽略的关系。Tessent是Siemens EDA原Mentor的DFT工具套件MBISTMemory Built-In Self-Test是其中负责存储器内建自测的模块而SDCSynopsys Design Constraints则是贯穿综合、DFT插入、布局布线到签核的时序约束语言。三者凑在一起核心要解决的问题是如何让MBIST测试模式下的时序在约束层面被正确描述从而保证DFT插入后的设计既能过DRC又能过时序签核还能在ATE上稳定跑通。适合读这篇的人有三类一是刚接触DFT、被MBIST SDC搞得一头雾水的数字后端或DFT工程师二是需要review MBIST约束质量、但自己不动手写的项目负责人三是做低功耗或车规芯片、对测试模式时序有额外要求的从业者。我会从约束的本质讲起把Tessent生成MBIST SDC的机制、手工补约束的判断逻辑、常见违例的排查链路以及几个真实项目里的经验教训都摊开说。不堆术语尽量用为什么这么写的方式讲清楚。2. MBIST SDC到底在约束什么先搞懂测试模式的时序模型2.1 功能模式与测试模式的时钟差异很多人写SDC的习惯是功能模式怎么写测试模式照抄一份改改时钟频率这个思路在MBIST上会出大问题。功能模式下时钟树是平衡的数据路径的时序关系由RTL逻辑决定但MBIST模式下时钟来源变了——通常由ATE直接驱动或者由片上PLL切换到测试时钟而且MBIST控制器内部有自己的时钟分频和相位控制逻辑。具体来说MBIST测试时的时钟有几个特点第一频率通常比功能模式低因为要留足存储器读写和比较的余量常见的是功能时钟的1/2到1/8第二时钟可能不是单一来源比如控制器时钟和存储器时钟可能来自不同pad第三测试模式下会有时钟切换clock muxing切换路径上的时序需要单独约束。SDC里描述这些差异的核心命令是create_clock、create_generated_clock和set_clock_groups。我见过最常见的错误是MBIST时钟用create_clock定义了但没加-add选项导致和功能时钟冲突工具直接忽略其中一个。正确的做法是给测试时钟单独命名并用set_clock_groups -asynchronous把功能时钟和测试时钟隔离开避免工具去检查两者之间的跨时钟路径。2.2 MBIST控制器的内部时序路径MBIST控制器不是一个黑盒它内部有状态机、地址生成器、数据比较器和时钟分频逻辑。这些路径在测试模式下是活跃的但功能模式下可能被bypass掉。如果SDC里只约束了存储器接口没约束控制器内部路径DFT插入后的时序分析就会漏掉一大块。Tessent在插入MBIST时会自动生成一部分SDC但自动生成的内容通常只覆盖工具自己插入的逻辑比如扫描链、边界扫描、MBIST控制器的标准接口。对于设计原有的逻辑在测试模式下的行为工具不会替你做判断。举个例子MBIST控制器输出的mem_read_en信号在功能模式下可能来自总线译码器测试模式下来自控制器状态机这两条路径的时序要求完全不同。自动SDC可能只约束了后者前者需要你手工补set_case_analysis或者set_mux_sel来告诉时序工具测试模式下这条路径不活跃。2.3 为什么SDC写错会导致ATE挂掉时序违例在仿真阶段可能看不出来因为RTL仿真不带SDF反标或者反标了但测试向量没覆盖到违例路径。到了ATE上时钟频率、电压、温度都是真实条件违例路径的建立或保持时间不够存储器读出的数据就会在比较器里出错表现为测试失败但DRC和仿真都过。更隐蔽的是有些违例只在特定pattern下出现。比如MBIST的March算法有多个阶段某些阶段地址跳变剧烈如果地址路径的约束漏了只有那个阶段的pattern会挂。排查时如果只看MBIST整体失败很容易误判为存储器本身有问题实际上是SDC漏约束导致的时序问题。3. Tessent生成MBIST SDC的机制与手工补约束的边界3.1 Tessent自动生成的SDC包含哪些内容Tessent在insert_dft或analyze_dft阶段会根据配置生成一份SDC文件通常命名为*_mbist.sdc或类似。这份文件里一般包含MBIST时钟的定义如果配置里指定了时钟端口、MBIST控制器接口的set_input_delay/set_output_delay、扫描链相关的时钟约束、以及部分set_false_path或set_clock_groups。但要注意Tessent生成的SDC是保守且局部的。保守体现在它倾向于把不确定的路径设为false path避免工具报违例局部体现在它只覆盖工具插入的逻辑不碰设计原有逻辑。这就留下了一个灰色地带设计原有逻辑在测试模式下的行为需要你根据测试架构来判断。3.2 哪些约束必须手工补根据我的经验以下几类约束几乎必须手工补第一类是测试模式下的时钟切换。如果设计里有clock mux功能时钟和测试时钟通过mux选择SDC里需要用set_case_analysis固定mux的select信号或者用create_generated_clock描述切换后的时钟。Tessent不会自动帮你做这个判断因为它不知道你的mux结构。第二类是存储器接口的时序例外。MBIST测试时存储器的读写时序可能和功能模式不同比如功能模式下存储器有流水线寄存器测试模式下bypass了。这时候需要对存储器接口路径设set_multicycle_path或set_max_delay。第三类是异步跨时钟路径。MBIST控制器和存储器可能在不同时钟域如果它们之间的握手信号没有同步器需要设set_false_path如果有同步器需要设set_max_delay -datapath_only。第四类是测试模式下的常量传播。测试模式下很多功能逻辑被disable比如CPU核、总线矩阵这些逻辑的输入需要设set_case_analysis为常量否则时序工具会去检查这些不活跃路径浪费运行时间还可能报假违例。3.3 自动与手工的衔接一个实际项目的约束清单我拿一个28nm车规MCU项目举例这个项目有8个SRAM实例、1个MBIST控制器、功能时钟200MHz、测试时钟50MHz。Tessent自动生成的SDC覆盖了大约60%的约束剩下40%是手工补的。手工补的部分包括测试时钟create_clock -name test_clk -period 20 -add加-add避免覆盖功能时钟set_clock_groups -asynchronous -group {func_clk} -group {test_clk}clock mux的set_case_analysis 1 [get_pins u_mux/sel]测试模式选测试时钟CPU核和总线矩阵的set_case_analysis 0 [get_pins u_cpu/clk_en]MBIST控制器到存储器的地址路径set_max_delay 15 -from [get_pins u_mbist/addr_reg*/Q] -to [get_pins u_sram/ADDR*]存储器数据输出到比较器的路径set_max_delay 18 -from [get_pins u_sram/Q*] -to [get_pins u_mbist/cmp_reg*/D]这些约束不是拍脑袋写的每一条都对应测试架构里的一个具体行为。比如地址路径的set_max_delay 15是因为测试时钟周期20ns地址需要在下一个时钟沿前15ns稳定留5ns给比较器采样。4. 约束写完之后验证与排查的完整链路4.1 用Tessent的DRC和时序报告做第一轮筛查SDC写完后不要直接扔给后端跑PR。先在Tessent里跑check_dft_rules和report_timing看有没有明显的约束冲突。Tessent的DRC会检查时钟定义是否完整、有没有未约束的端口、有没有冲突的case analysis。时序报告会列出测试模式下的关键路径如果发现某条路径的slack是负的先别急着改RTL先确认约束是否合理。我常用的一个技巧是在Tessent里用report_clocks和report_case_analysis把测试模式下的时钟和常量状态打印出来和测试架构文档对照。如果发现某个模块在测试模式下应该是disable的但报告里显示它还在活跃说明set_case_analysis漏了。4.2 后端PR阶段的时序签核MBIST模式要单独跑很多团队做时序签核时只跑功能模式测试模式用和功能模式差不多来搪塞。这是大忌。MBIST模式的时序必须单独跑因为时钟频率、时钟域、常量状态都不同。在PrimeTime或Tempus里需要读入MBIST的SDC设置测试模式然后跑report_timing。如果发现违例排查顺序建议是先看时钟定义对不对再看case analysis有没有漏然后看跨时钟路径有没有设false path最后才怀疑RTL或物理设计。我遇到过好几次违例的根因是测试时钟的create_clock没加-add导致工具把功能时钟和测试时钟合并了时序检查完全错乱。4.3 ATE失败后的回溯从pattern反推约束问题如果ATE上MBIST失败但仿真和时序签核都过了怎么排查我的做法是先看失败pattern对应的MBIST阶段比如是March C-的哪个元素然后反推那个阶段活跃的路径。用Tessent的report_pattern或者波形dump看失败时刻的地址、数据、控制信号再对照SDC看这些信号的路径有没有被正确约束。有一次一个项目MBIST在ATE上跑March C-的读-比较阶段失败但写阶段正常。查下来是存储器数据输出到比较器的路径漏了set_max_delay功能模式下这条路径有时钟周期余量测试模式下时钟频率虽然低了但比较器的采样窗口更窄导致保持时间不够。补上约束后问题解决。5. 几个真实项目里的坑与经验5.1 坑一测试时钟的相位关系被忽略前面提到的车规MCU项目ATE给的测试时钟和片上PLL输出的时钟有固定相位差但SDC里只定义了频率没定义相位。结果setup检查时工具按同相位算实际ATE上相位差导致违例。解决办法是在create_clock里加-waveform指定上升沿和下降沿时刻或者用set_clock_latency描述相位偏移。5.2 坑二MBIST控制器的复位路径没约束MBIST控制器通常有复位信号测试模式下复位由ATE控制。如果SDC里没约束复位路径的set_false_path或set_max_delay时序工具会去检查复位释放到第一个时钟沿的路径可能报违例。实际上复位释放是异步的不需要满足setup。补set_false_path -from [get_ports test_rst_n]即可。5.3 坑三多MBIST控制器的时钟域交叉大芯片可能有多个MBIST控制器每个控制不同的存储器组时钟域可能不同。如果控制器之间有握手信号需要仔细约束。我见过一个项目两个MBIST控制器共享一个测试时钟但各自有分频导致跨控制器路径的时序被误检查。最后用set_clock_groups把两个分频时钟设为异步问题解决。5.4 经验约束要跟着测试架构文档走我的习惯是每写一条MBIST SDC约束都在测试架构文档里找到对应的描述。如果文档里没写要么是文档不全要么是约束多余。这个习惯帮我避免了很多拍脑袋约束也让我在review别人约束时能快速判断合理性。6. 写给不同阶段工程师的实操建议如果你刚接触MBIST SDC建议先从读懂Tessent自动生成的SDC开始逐条问这条约束对应测试架构里的哪个行为。然后找一个简单设计手工补几条约束跑一遍时序看报告变化。不要一上来就改复杂项目的约束容易越改越乱。如果你是有经验的DFT工程师建议把MBIST SDC的检查清单化每次项目按清单过一遍。清单可以包括时钟定义、时钟组、case analysis、跨时钟路径、存储器接口、复位路径、测试模式常量。每项打勾后再签核。如果你是项目负责人建议在DFT插入阶段就安排一次SDC review让写约束的人和做时序签核的人坐在一起对一遍。我见过太多项目约束是A写的时序是B签的两人对测试模式的理解不一致最后流片前才发现问题。最后分享一个小技巧在Tessent里可以用write_sdc导出当前约束然后用文本diff工具和上一版对比快速定位改了哪些约束。这个在迭代阶段特别有用避免改了一条约束影响了另一条却没发现。