1. MBIST与GO/DONE信号的基础认知1.1 为什么内存测试需要专门的硬件机制做芯片验证和测试的同行都有一个共识内存阵列Memory Array的测试和普通逻辑电路的测试完全是两码事。逻辑电路可以用扫描链Scan Chain把触发器串起来做ATPG但内存阵列是密集的存储单元你没法用同样的方式去覆盖每一个bit的故障。更麻烦的是现代SoC里嵌入式内存占了相当大的面积一块SRAM阵列里可能有几十万个存储单元任何一个单元出现固定故障Stuck-at Fault、跳变故障Transition Fault或者耦合故障Coupling Fault都可能导致系统在特定条件下崩溃。传统的做法是把内存接口引出来用外部ATE设备逐条读写测试。但这条路在深亚微米工艺下越来越走不通——内存频率太高外部走线的信号完整性根本撑不住而且测试时间成本极高。MBISTMemory Built-In Self-Test内存内建自测试就是在这个背景下成为标配的。它的核心思路很简单把测试逻辑直接做进芯片内部让芯片自己测自己的内存外部只需要给一个启动信号等一个完成信号中间的过程全部由硬件状态机自动完成。这个“启动信号”和“完成信号”在绝大多数MBIST控制器实现里就是GO和DONE。GO是外部给MBIST控制器的触发脉冲告诉它“开始跑测试”DONE是MBIST控制器跑完所有测试算法后给出的状态指示告诉外面“我测完了结果在状态寄存器里”。听起来很简单对吧但实际调试中大量的问题就出在这两个信号的时序、极性、同步处理上。1.2 GO和DONE在MBIST控制器里的角色定位先把这个事情说透。MBIST控制器本质上是一个独立的状态机它有自己的时钟域、自己的地址生成器、自己的数据比较器。GO信号的作用是让状态机从IDLE状态跳转到RUN状态DONE信号则是状态机从RUN状态回到IDLE状态或者跳转到RESULT状态的标志。这里有一个很容易被忽略的细节GO信号通常是电平触发还是边沿触发不同厂商的MBIST IP核实现不一样。有的控制器要求GO保持高电平直到DONE拉高有的则只需要一个时钟周期的脉冲。如果你搞错了触发方式可能出现两种情况一是GO脉冲太短状态机根本没采样到二是GO一直保持高电平状态机跑完一轮后又重新启动陷入死循环。DONE信号的极性同样需要注意。有些IP核DONE是高有效有些是低有效。更隐蔽的是DONE信号可能和错误标志FAIL是分开的——DONE只表示“测试流程结束”不代表“测试通过”。我见过不少新手看到DONE拉高就以为万事大吉结果根本没去读错误状态寄存器把一颗有故障的芯片当好的用了。提示拿到一个MBIST控制器第一件事不是写测试向量而是把GO/DONE的触发方式、极性、与时钟域的关系从IP手册里确认清楚。这一步花十分钟后面能省十小时。1.3 从GO到DONE之间到底发生了什么很多文档只告诉你“拉高GO等DONE”但中间的过程才是真正决定测试质量的部分。一个典型的MBIST运行流程是这样的GO信号被控制器采样后状态机从IDLE进入初始化阶段加载测试算法配置比如March C-、March SS、Checkerboard等。地址生成器开始按算法要求遍历内存地址空间每个地址执行特定的读写序列。数据比较器在每个读操作后把读回的数据和预期值比对不一致就把错误信息写入状态寄存器包括故障地址、故障数据、故障类型。所有地址遍历完成后状态机进入完成阶段拉高DONE信号同时把汇总结果PASS/FAIL写入状态寄存器。整个过程的时间取决于三个因素内存深度、测试算法的复杂度、MBIST控制器的时钟频率。举个例子一个1024x32的SRAM跑March C-算法每个单元需要6次操作写0、读0、写1、读1、写0、读0总共就是1024×66144个时钟周期。如果MBIST时钟是100MHz那大概61微秒就跑完了。但如果内存是64Kx64算法换成更复杂的March SS每个单元13次操作那就是64K×13832K个周期8.3毫秒。这个时间在量产测试里是要算进总测试时间的不能忽略。2. GO/DONE时序问题的深度拆解2.1 跨时钟域带来的采样风险GO信号从外部引脚或者系统总线过来它的时钟域和MBIST控制器的时钟域大概率是不一样的。这就带来一个经典问题异步信号采样。如果GO的跳变沿刚好落在MBIST时钟的建立/保持窗口附近状态机可能采到亚稳态值导致行为不确定。标准的处理方式是在MBIST控制器内部做两级同步器Two-Stage Synchronizer。但这里有个坑两级同步器只能降低亚稳态传播的概率不能完全消除。如果GO信号的频率和MBIST时钟频率存在某种倍数关系可能反复采到错误值。更稳妥的做法是加一个握手协议——外部拉高GO后等待MBIST控制器返回一个ACK有些IP叫GO_ACK或者START_DONE确认已经采样到了再释放GO。DONE信号从MBIST控制器回到外部系统同样面临跨时钟域问题。如果外部系统用轮询方式读DONE而DONE的跳变沿和外部采样时钟不同步可能读到抖动的值。这时候要么用同步器要么用中断方式——DONE拉高后触发一个中断CPU在中断服务程序里读状态寄存器这样时序上更安全。2.2 GO脉冲宽度不足导致的启动失败这是实际调试中最常见的问题之一。假设MBIST控制器要求GO至少保持2个时钟周期的高电平但外部逻辑只给了1个周期状态机可能刚好在GO拉低之后才采样结果就是“GO发了但测试没跑”。怎么判断是不是这个问题最简单的办法是用示波器或者逻辑分析仪同时抓GO、MBIST时钟、DONE三个信号。如果看到GO有跳变但DONE一直不拉高而且状态寄存器里的状态码还是IDLE那基本可以确定是GO没被正确采样。解决办法有两种一是加宽GO脉冲确保至少覆盖3个MBIST时钟周期留足余量二是改用握手方式GO拉高后不主动拉低等MBIST控制器返回ACK后再拉低。第二种方式更可靠但需要MBIST IP支持握手接口。注意有些MBIST控制器在GO拉高后需要先做一轮寄存器配置加载这段时间内如果GO被拉低配置可能加载不完整。所以GO的保持时间不仅要覆盖采样还要覆盖配置加载阶段。2.3 DONE信号误读为“测试通过”的陷阱前面提过DONE只表示测试流程结束不表示测试通过。但实际项目中我见过不止一次有人把DONE直接接到LED或者GPIO上看到灯亮就认为芯片没问题。这种做法的风险在于如果MBIST控制器在测试过程中检测到错误它可能提前终止测试并拉高DONE这时候DONE表示的是“测试异常结束”而不是“测试正常完成”。正确的做法是DONE拉高后必须读MBIST状态寄存器确认两个信息——一是测试是否正常完成有些控制器有DONE_NORMAL和DONE_ERROR两个标志二是错误计数是否为零。只有这两个条件都满足才能判定内存测试通过。另外DONE信号的清除方式也要注意。有些控制器在状态寄存器被读取后自动清除DONE有些需要外部给一个CLR信号。如果清除方式搞错了可能出现DONE一直拉高、无法启动下一轮测试的情况。2.4 多内存实例下的GO/DONE共享问题一个SoC里通常有多个内存实例每个实例可能对应一个独立的MBIST控制器也可能多个实例共享一个控制器。如果是共享控制器GO/DONE的处理就更复杂了。共享控制器的情况下GO信号可能需要携带实例选择信息比如用GO[3:0]表示四个实例的启动DONE信号则需要用多bit表示哪个实例完成了。如果外部逻辑只给了一个单bit的GO控制器可能默认只测第一个实例其他实例根本没被覆盖。还有一种情况是多个控制器级联GO信号需要逐级传递。这时候要注意传递路径上的延迟——如果第一级控制器的DONE还没拉高第二级的GO就被触发了可能导致测试冲突。稳妥的做法是用状态机控制启动顺序前一级DONE拉高后再启动下一级。3. 基于GO/DONE的内存故障定位实操3.1 搭建最小可用的MBIST调试环境在开始定位故障之前你需要一个能跑起来的最小环境。我通常的做法是用FPGA原型验证平台加载包含MBIST控制器的设计或者用仿真器跑RTL仿真。把GO信号接到一个可控的GPIO或者仿真激励端口方便手动触发。把DONE信号接到逻辑分析仪的通道同时把MBIST状态寄存器的输出也引出来。准备一个参考内存模型Golden Memory用来比对MBIST的测试结果。如果是RTL仿真可以用Verilog或者SystemVerilog写一个简单的测试平台Testbench核心逻辑就是初始化时钟和复位拉高GO等待DONE然后读状态寄存器并打印结果。这个测试平台不需要太复杂但一定要把GO/DONE的时序参数脉冲宽度、建立时间、保持时间显式定义出来方便后续调整。// 简化的MBIST测试平台核心逻辑 initial begin rst_n 0; go 0; #100 rst_n 1; #50; // 拉高GO保持足够宽度 go 1; #200; // 假设MBIST时钟周期为10ns保持20个周期 go 0; // 等待DONE wait(done 1); #10; // 读状态寄存器 $display(MBIST Status: %h, status_reg); $display(Error Count: %d, error_count); if (error_count 0 done 1) $display(TEST PASSED); else $display(TEST FAILED); end这段代码看起来简单但有几个细节值得注意GO的保持时间我给了200个时间单位远大于理论最小值这是为了留足余量等待DONE用了wait语句而不是固定延时这样即使测试时间比预期长也不会误判读状态寄存器之前加了10个时间单位的延时确保DONE拉高后状态寄存器已经稳定。3.2 用GO/DONE状态组合快速判断故障类型在实际调试中GO和DONE的状态组合可以帮你快速缩小问题范围。我整理了一个速查表覆盖了最常见的几种情况GO状态DONE状态可能原因排查方向已拉高一直不拉高GO未被采样、时钟未使能、复位未释放检查GO脉冲宽度、MBIST时钟、复位信号已拉高立即拉高测试算法配置为空、内存深度配置错误检查配置寄存器、内存尺寸参数已拉高拉高但错误计数非零内存存在真实故障、参考数据配置错误读故障地址寄存器、比对参考数据未拉高意外拉高DONE极性配置错误、状态机异常检查DONE极性、状态机复位逻辑反复拉高反复拉高GO保持时间过长、状态机自动重触发检查GO是否应该用脉冲而非电平这个表是我在多个项目里踩坑之后总结出来的基本上覆盖了80%以上的常见问题。比如“GO已拉高但DONE一直不拉高”这种情况最常见的原因就是GO脉冲太窄状态机没采到。你可以用逻辑分析仪抓一下GO和MBIST时钟的相位关系如果GO的高电平窗口和时钟上升沿没有交集那就是脉冲宽度问题。3.3 从故障地址寄存器反推物理位置当MBIST报告错误时它会记录故障地址、故障数据、预期数据等信息。这些信息怎么用关键在于把逻辑地址映射回物理位置。假设MBIST报告故障地址是0x1A3故障数据是0x00预期数据是0xFF。首先你要确认这个地址是字节地址还是字地址然后根据内存的行列译码方式把地址拆分成行地址和列地址。比如一个1024x32的SRAM地址0x1A3十进制419对应的行地址可能是419/3213列地址是419%323。这样你就知道是第13行第3列的那个存储单元出了问题。但实际芯片里逻辑地址和物理版图之间还有一层映射关系可能涉及列交织Column Interleaving、行交织Row Interleaving等。这时候需要查内存编译器的文档找到地址映射表。如果故障地址集中在某个特定的行或列那可能是版图上的系统性缺陷比如某条字线或位线短路如果故障地址随机分布那更可能是工艺随机缺陷。实操心得在量产测试中我会把MBIST的故障地址收集起来做统计分析。如果某个地址区间反复出现故障那就要怀疑是设计问题而不是工艺问题。这个分析方法帮我们抓到过一次金属层走线间距不足导致的耦合故障。3.4 多轮测试与DONE信号的去抖动处理有些高可靠性场景要求MBIST跑多轮测试比如先用March C-跑一遍再用Checkerboard跑一遍最后用Walking 1/0跑一遍。这时候DONE信号的处理就需要注意了。如果每轮测试结束后DONE都会拉高再拉低那外部逻辑需要能够区分“这一轮DONE”和“下一轮DONE”。简单的做法是用一个计数器记录DONE的上升沿数量达到预期轮数后才判定测试完成。但这里有个坑如果某一轮测试因为错误提前终止DONE也会拉高计数器会误以为这一轮正常完成。更稳妥的做法是每轮测试结束后读一次状态寄存器确认本轮结果后再启动下一轮。这样虽然增加了软件开销但可靠性高得多。另外DONE信号在跨时钟域传输时可能有毛刺建议在外部加一个简单的RC滤波或者用同步器后的信号避免误触发。4. 常见问题排查与避坑指南4.1 GO信号无响应的排查流程遇到GO拉高后DONE一直不拉高的情况我通常按以下顺序排查确认MBIST时钟是否在跑。用示波器测MBIST时钟引脚如果没有波形检查时钟使能寄存器或者时钟门控配置。确认复位是否已释放。有些MBIST控制器在复位期间会忽略GO信号如果复位没释放GO就是石沉大海。确认GO的极性是否正确。有些控制器GO是高有效有些是低有效。如果搞反了你拉高GO相当于没给启动信号。确认GO的脉冲宽度是否足够。用逻辑分析仪抓GO和MBIST时钟看GO的高电平窗口是否覆盖了至少一个时钟上升沿。确认状态机是否卡在某个中间状态。读状态寄存器如果状态码不是IDLE也不是RUN那可能是状态机异常需要检查状态编码和跳转条件。这个流程看起来简单但每一步都有细节。比如第三步GO的极性在IP手册里通常会写但有些手册写得不清楚只给了一个时序图。这时候你可以做一个实验分别用高电平和低电平触发看哪个能启动测试。虽然笨但有效。4.2 DONE信号异常拉高的几种典型场景DONE异常拉高比DONE不拉高更隐蔽因为很多人看到DONE拉高就以为测试完成了。以下几种场景需要特别注意上电复位后DONE立即拉高这通常是因为DONE的复位值配置错了。有些控制器的DONE在复位后默认是高需要软件显式清除。如果没清除第一次GO还没发DONE就已经是高了。GO拉高后DONE在极短时间内拉高这说明测试根本没跑可能是测试算法配置为空或者内存深度配置为0。检查配置寄存器的默认值确保测试算法和内存尺寸都正确加载了。DONE拉高但状态寄存器显示IDLE这是典型的时序冲突DONE的拉高和状态机的状态更新不在同一个时钟周期。解决办法是在读状态寄存器之前加几个时钟周期的延时或者用DONE的下降沿触发状态读取。4.3 跨时钟域同步器的参数选择如果你需要在外部逻辑里对GO/DONE做同步同步器的参数选择有讲究。两级同步器的第一级触发器容易进入亚稳态第二级用来稳定信号。但两级够不够这取决于时钟频率比和工艺的MTBF平均无故障时间要求。一般来说如果两个时钟域的频率比小于10两级同步器足够了。如果频率比很大比如外部32kHz内部200MHz可能需要三级甚至四级同步器。另外同步器的触发器最好用同一类型的单元避免混合使用不同阈值电压的单元导致时序不一致。还有一个容易被忽略的点同步器会引入延迟。两级同步器至少引入两个目标时钟周期的延迟。如果GO的脉冲宽度刚好等于两个时钟周期经过同步器后可能变成零宽度状态机根本采不到。所以GO的脉冲宽度要大于同步器延迟加上状态机采样窗口。4.4 量产测试中的GO/DONE优化技巧在量产测试中每一毫秒的测试时间都意味着成本。GO/DONE的处理也可以优化并行启动多个MBIST控制器如果芯片里有多个独立的内存实例可以让它们的GO信号同时拉高DONE信号分别监控。这样总测试时间取决于最慢的那个实例而不是所有实例之和。用DONE信号触发中断而不是轮询轮询会占用CPU资源而且可能引入额外的延迟。用中断方式CPU可以在等待期间做其他事情DONE拉高后立即响应。在DONE拉高后立即读状态寄存器不要等因为有些控制器的状态寄存器在DONE拉高后经过若干周期会被自动清除。如果读晚了可能读到全零误判为测试通过。提示在量产测试程序里我通常会加一个超时保护——如果GO拉高后超过预期时间DONE还没拉高就强制判定测试失败并记录超时。这个保护机制帮我们抓到过好几次MBIST控制器死锁的问题。4.5 从GO/DONE波形反推控制器内部状态逻辑分析仪抓到的GO/DONE波形其实包含了丰富的信息。除了看DONE是否拉高还可以看DONE拉高的时间点相对于GO的时间差。这个时间差就是测试执行时间它应该等于内存深度乘以算法操作数再除以MBIST时钟频率。如果实测时间远小于理论时间说明测试没有完整执行可能是地址生成器提前终止了。如果实测时间远大于理论时间说明测试过程中有额外的等待周期可能是时钟频率被降低了或者状态机在某个状态停留过久。我习惯在调试时把理论时间和实测时间都算出来列一个对照表。这样一旦出现偏差就能快速定位是配置问题还是硬件问题。这个习惯让我在一次调试中发现MBIST时钟被意外分频了——原本应该是100MHz实际只有25MHz导致测试时间变成理论值的四倍。5. 信号完整性对GO/DONE的影响5.1 高速信号下的GO/DONE走线要求当MBIST时钟频率超过100MHz时GO和DONE信号的走线就不能随便处理了。虽然这两个信号本身的翻转频率不高GO只在启动时翻转一次DONE只在完成时翻转一次但如果走线太长或者阻抗不匹配仍然可能引入反射和串扰。GO信号从外部引脚到MBIST控制器的路径上如果经过多个缓冲器或者长距离走线可能产生延迟。这个延迟如果超过了MBIST时钟周期可能导致采样错误。解决办法是尽量缩短GO的走线或者在靠近控制器的地方加一个触发器重新同步。DONE信号从控制器到外部引脚的路径同样需要注意。如果DONE的负载电容太大比如驱动多个外部设备上升沿可能变缓导致外部逻辑采样到中间电平。这时候要么加驱动器要么用差分信号传输。5.2 电源噪声对GO/DONE采样的干扰电源噪声是另一个容易被忽略的因素。当MBIST控制器在跑测试时内存阵列的读写操作会产生较大的瞬态电流导致电源电压波动。如果GO或DONE信号的参考电平刚好受到这个波动的影响可能被误采样。在PCB设计时GO和DONE信号最好参考干净的电源平面避免和内存电源共用。如果条件允许可以在GO/DONE的接收端加一个小电容滤波但电容值不能太大否则会减慢信号边沿。在芯片内部MBIST控制器的电源域最好和内存阵列的电源域分开至少要有独立的去耦电容。我见过一个案例MBIST跑测试时电源噪声导致DONE信号抖动外部逻辑误判为多次完成结果读状态寄存器时读到了中间状态。5.3 用示波器抓GO/DONE波形的实操要点用示波器抓GO/DONE波形时探头的选择和接地点很关键。建议用高带宽的有源探头接地线尽量短避免引入额外的电感。触发方式可以设为GO的上升沿这样能抓到完整的启动过程。抓DONE信号时触发方式设为DONE的上升沿同时把GO和MBIST时钟也接到示波器的其他通道这样能看到三者之间的时序关系。如果示波器有协议解码功能可以把状态寄存器的输出也解码出来直接看到测试结果。实测下来最有用的是同时抓GO、DONE、MBIST时钟和状态寄存器输出这四个信号。GO和DONE看时序MBIST时钟看频率状态寄存器看结果。四个信号一对照大部分问题都能定位。6. 从GO/DONE扩展到完整的MBIST验证流程6.1 MBIST验证的完整检查清单GO/DONE只是MBIST验证的入口和出口完整的验证流程还包括复位验证确认复位后所有状态寄存器都是默认值GO和DONE都是无效状态。配置验证确认测试算法、内存尺寸、数据背景模式等配置寄存器可以正确读写。启动验证确认GO可以正常启动测试DONE在预期时间内拉高。结果验证确认状态寄存器中的错误计数、故障地址、故障数据都正确。恢复验证确认测试完成后MBIST控制器可以回到IDLE状态准备下一次测试。故障注入验证在内存模型中人为注入故障确认MBIST能检测到并正确报告。这个检查清单看起来长但每一项都是必要的。我见过项目因为跳过了故障注入验证结果MBIST控制器在真实故障面前根本报不出错量产时漏掉了大量坏片。6.2 用脚本自动化GO/DONE测试手动拉GO、等DONE、读状态寄存器的方式适合调试不适合回归测试。我通常会用Python或者Tcl写一个自动化脚本通过JTAG或者总线接口控制MBIST控制器自动完成测试流程并记录结果。import time def run_mbist_test(interface, timeout1.0): # 复位MBIST控制器 interface.write_reg(MBIST_CTRL, 0x01) time.sleep(0.001) interface.write_reg(MBIST_CTRL, 0x00) # 配置测试算法和内存尺寸 interface.write_reg(MBIST_CONFIG, 0x03) # March C- interface.write_reg(MBIST_SIZE, 0x400) # 1024 words # 拉高GO interface.write_reg(MBIST_GO, 0x01) # 等待DONE start time.time() while time.time() - start timeout: status interface.read_reg(MBIST_STATUS) if status DONE_BIT: break time.sleep(0.0001) else: raise TimeoutError(MBIST DONE not asserted within timeout) # 读结果 error_count interface.read_reg(MBIST_ERROR_COUNT) fail_addr interface.read_reg(MBIST_FAIL_ADDR) return error_count, fail_addr这个脚本的核心逻辑和手动操作一样但可以批量运行、自动记录、自动比对。在回归测试中我会用这个脚本跑几百次每次随机改变测试算法和内存尺寸确保MBIST控制器在各种配置下都能正常工作。6.3 GO/DONE在DFT测试中的集成在DFTDesign for Test测试中MBIST通常和扫描测试、边界扫描一起集成在同一个测试流程里。GO/DONE信号需要和测试控制器的接口对接。常见的集成方式是用测试控制器的GPIO或者寄存器接口来控制GO用中断或者状态位来监控DONE。在测试向量生成时需要把GO的拉高和DONE的等待编入测试序列。如果DONE的等待时间不确定可以用循环等待的方式直到DONE拉高或者超时。这里有一个细节在DFT测试中MBIST的时钟可能来自测试时钟而不是功能时钟。测试时钟的频率通常比功能时钟低所以MBIST的测试时间会比功能模式下长。在计算总测试时间时要用测试时钟的频率来算不能用功能时钟。6.4 从GO/DONE看MBIST控制器的可测试性设计一个好的MBIST控制器设计应该在GO/DONE上提供足够的可观测性和可控性。具体来说GO信号应该有旁路Bypass模式允许在不需要测试时直接拉低避免误触发。DONE信号应该有屏蔽Mask功能允许在调试时忽略DONE手动读状态寄存器。GO和DONE都应该有状态位可以回读方便软件确认当前状态。最好有一个GO_ACK信号确认GO已被采样避免脉冲宽度问题。这些设计细节在IP选型时就要考虑。如果选了一个GO/DONE接口很简陋的IP后期调试会非常痛苦。我在一个项目里用过一款MBIST控制器GO和DONE共用一根双向引脚结果调试时根本分不清是GO没发出去还是DONE没回来最后只能用示波器看波形才搞定。7. 实际项目中的经验教训7.1 一次GO脉冲宽度不足导致的量产事故这个案例我印象很深。当时芯片已经进入量产阶段突然有一批芯片的MBIST测试通过率异常低。用示波器抓波形发现GO脉冲宽度只有1.5个MBIST时钟周期而控制器要求至少2个周期。在实验室环境下由于温度、电压都是典型值状态机勉强能采到但在量产测试的高低温环境下时序余量不够部分芯片就采不到了。解决办法很简单把GO脉冲宽度从1.5个周期加到4个周期。但代价是已经封装好的几千颗芯片全部报废。这个教训告诉我们GO脉冲宽度不能只满足典型条件下的要求必须留足余量覆盖PVT工艺、电压、温度变化。7.2 DONE信号被误用为中断源的调试记录另一个项目里工程师把DONE信号直接接到了CPU的中断引脚想用中断方式处理测试完成。但调试时发现CPU频繁进入中断服务程序读状态寄存器却显示测试还没完成。用逻辑分析仪抓波形发现DONE信号上有大量毛刺每个毛刺都触发了一次中断。原因是DONE信号从MBIST控制器到CPU的路径上经过了多个电源域每次电源域切换时DONE信号都会抖动。解决办法是在DONE信号上加一个数字滤波器滤除宽度小于3个时钟周期的脉冲。这个滤波器用简单的移位寄存器就能实现成本很低但效果立竿见影。7.3 多实例MBIST的GO/DONE共享踩坑记一个SoC里有8个内存实例共用两个MBIST控制器每个控制器负责4个实例。GO信号用了两位编码来选择实例组DONE信号用了两位编码来指示哪组完成。但调试时发现当两组同时启动时DONE信号会互相干扰导致状态寄存器读到的结果错乱。根本原因是两个控制器的DONE信号在外部逻辑里做了或运算但或运算后的信号无法区分是哪组完成。解决办法是把DONE信号改成独立的两根线分别接到外部逻辑的两个输入引脚。虽然多用了引脚但可靠性大大提升。这个案例说明在多实例场景下GO/DONE的编码方式要仔细设计不能为了省引脚而牺牲可区分性。7.4 从失败案例中提炼的GO/DONE设计检查表经过这些项目我总结了一个GO/DONE设计检查表在每次新项目启动时都会过一遍GO的触发方式电平/边沿是否明确GO的脉冲宽度是否覆盖了同步器延迟加采样窗口GO的极性是否和控制器要求一致DONE的极性是否明确是否和FAIL标志分开DONE的清除方式是否明确是自动清除还是需要外部信号DONE信号是否需要去抖动去抖动的参数是否合适多实例场景下GO/DONE的编码方式是否可区分GO/DONE的跨时钟域处理是否完整GO/DONE的走线是否满足信号完整性要求是否有超时保护机制这个检查表看起来简单但每一条都是踩坑之后加上的。新项目启动时花半小时过一遍能避免后面几周的调试痛苦。7.5 给新手的三个实用建议最后分享三个我觉得最实用的建议第一先抓波形再改代码。遇到GO/DONE问题不要急着改RTL或者改测试程序先用示波器或者逻辑分析仪把波形抓下来。波形会告诉你真相代码只是你的猜测。第二留足时序余量。GO的脉冲宽度、DONE的等待时间、同步器的级数这些参数都不要卡着最小值设计。留50%的余量在PVT变化时才能稳如泰山。第三状态寄存器一定要读。DONE拉高只是开始状态寄存器里的错误计数和故障地址才是真正有价值的信息。养成DONE拉高后立即读状态寄存器的习惯能帮你发现很多隐藏的问题。这些经验都是我在实际项目中一点一点积累的有些是成功的总结有些是失败的教训。MBIST的GO/DONE信号看起来简单但真正做好、做稳需要对这些细节有深入的理解和足够的重视。希望这些内容能帮到正在调试MBIST的同行少走一些弯路。