1. 先理清角色BSCAN、BAP和MBIST各管哪一段做DFT做了十几年我最常被刚入行的同事问的一个问题是Tessent的MBIST明明自己就能生成控制器为什么还要拉上BSCAN和BAP这三样东西到底谁听谁的这个问题别看简单真能讲清楚的人不多。很多人拿着Tessent的脚本跑通了流程但脑子里始终没有建立起一张完整的“测试访问地图”一旦遇到访问不到存储器、故障误报、时序收敛不过这类问题就只能靠瞎试碰运气。我习惯用一个城市交通的类比来拆解这三者的关系。边界扫描BSCANBoundary Scan就像城市的主干道网络它是芯片测试的公共基础设施基于IEEE 1149.1标准搭起来的TAPTest Access Port控制器就是城市的总入口MBIST控制器是要去干活的工作人员它们负责对SRAM、寄存器堆这类存储器阵列执行March算法测试而BAPBScan Access Port就是连接主干道和工作人员之间的“专用门禁通道”。没有BAPMBIST控制器虽然也能跑但你必须把它的控制信号、数据信号、状态信号全部引到芯片顶层一个个接出来这在规模稍大的芯片里几乎是一场灾难。有了BAP所有对MBIST控制器的访问都通过JTAG的TDI/TDO串行链路完成顶层只需要保留标准的五根JTAG端口测试访问成本大幅降低。1.1 边界扫描是整个测试网络的“主干道”边界扫描本身解决了板级和芯片级的互连测试问题但它的价值远不止于此。BSCAN提供了一个极其重要的资源一条可以通过TAP控制器任意路由的串行移位通道。这条通道由TDI进、TDO出中间可以插入任意符合规则的测试数据寄存器。Tessent的BSCAN工具链做的核心工作之一就是把这个移位通道扩展成“可编程路由网络”。你可以把一个或多个自定义寄存器插入到TDI和TDO之间通过JTAG指令寄存器Instruction Register中的特定指令来选择激活哪一条数据路径。打个比方TDI到TDO之间是一条多车道的公路JTAG指令就是路口的指示牌。默认情况下你走Bypass寄存器这条捷径一条车道直通当你要访问MBIST时指令译码结果会把BAP的数据寄存器接入这条路数据就从TDI流进BAP、经过若干周期处理后从TDO流出。这个机制的意义在于芯片顶层在物理上只需要固定数量的JTAG端口不管内部挂了多少个BAP、多少个MBIST控制器对外的接口始终是TCK、TMS、TDI、TDO这四根TRST可选。实测下来这种方式对顶层布线的友好程度是直连方案完全没法比的。1.2 BAP是通往MBIST控制器的“专用门禁”BAP在Tessent的术语里通常指BScan Access Port它的本质是一个协议转换桥。MBIST控制器暴露出来的接口是并行总线风格的比如go信号、reset信号、si/si_so串行数据口、done/fail状态输出等而JTAG链路是串行的按位移入移出。BAP在这两者之间完成串行到并行、并行到串行的转换并且产生必要的握手时序。我记得第一次看BAP的RTL代码时内心感受就是“原来这么简单”。它的核心逻辑无非是一个移位寄存器用于接收来自TDI的命令和数据一组并行寄存器锁存配置值一个状态机负责产生MBIST控制器的启动和复位时序最后把MBIST回传的状态结果转换成串行位流从TDO送出。但简单归简单它是整个链路里最容易出问题的环节。因为BAP工作时钟通常来自TCK而MBIST控制器的工作时钟是功能时钟比如处理器的总线时钟这两个时钟域之间必须有可靠的同步机制。很多设计里BAP访问失败追根溯源都是这里埋的雷。1.3 MBIST控制器是存储器测试的“执行大脑”MBIST控制器接受BAP下发的指令后就开始独立运行。它内部包含地址发生器、数据发生器、读写控制状态机和结果比较器。运行过程中不占用JTAG链路资源所有读写存储器的操作都由它自主完成这是MBIST能并行测试大量存储器的根本原因。控制器支持的算法决定了故障覆盖率的水平。Tessent MBIST里常用的March类算法比如March C-、March LR、March SS从故障覆盖率角度看March C-能覆盖大部分固定故障SAF、转换故障TF和耦合故障CF而March SS在动态故障和复杂耦合故障上有更好的表现。算法越长测试时间越长覆盖率越高这是一个经典的工程权衡。MBIST控制器跑完后通过done信号通知BAP测试完成通过fail信号指示是否有故障故障地址和期望数据等信息则可以通过诊断寄存器串行回读。这些状态和信息最终都要汇入JTAG链路由外部测试设备解析。角色清晰之后下面我们来看这几者是怎么串成一条完整的链路的。2. 从TAP到存储器的完整访问链路拆解很多资料喜欢把JTAG访问MBIST的过程画成层级图但我觉得不如直接按信号流走一遍来得直观。一次完整的MBIST启动到结果回读大致经过四个阶段。2.1 指令移入与BAP的选择机制一切从TAP控制器收到一条指令开始。测试设备通过TMS和TCK把TAP状态机推到Shift-IR状态将一条特定编码的指令串行移入指令寄存器。这条指令的编码对应到设计里被使能的BAP通道——说白了就是告诉TAP接下来我要访问的是BAP编号N请把它的数据寄存器接到TDI和TDO之间这条移位通路上。Tessent在生成BSCAN网表的时候会为每个BAP实例分配一个唯一的用户指令编码。设计人员可以在Tessent shell里通过指定端口映射关系来定义这些指令。这里有一个实际工程中容易忽略的点指令编码的位宽和冲突检查。如果两个BAP被赋予了相同的指令编码JTAG访问时就会同时激活两条数据路径在TDO处产生信号冲突仿真阶段就会暴露问题但在某些静态检查不完善的情况下可能要等到硅片回来才能发现那个代价就不是几天能挽回的了。所以我的习惯是在集成BAP之前先整理一份全芯片的BAP指令编码分配表做成文档评审而不是完全依赖工具自动分配。工具确实会报冲突但人工评审一遍能发现工具不会报的问题比如将来要扩展的预留位。2.2 数据路径的串并转换与协议解析指令选通BAP后测试设备往TDI上送一串特定的数据位流。BAP内部的移位寄存器把这些位接收下来在Capture-DR或Update-DR阶段把并行数据锁存到配置寄存器里。配置寄存器通常包含几个字段操作码启动、复位、读状态、读诊断信息、存储器选择地址如果有多个存储器组、算法选择位等。Tessent生成的BAP位宽和字段布局可以在生成时配置但一旦定了前端验证环境和ATE测试程序都得跟着走所以早期规划非常重要。数据移入的位序也是个大坑。JTAG规范里规定数据从LSB还是MSB先移入在BAP配置里并不统一完全取决于工具生成的RTL实现。如果你在写验证用例或者ATE测试向量时把位序搞反了最常见的表现就是写入的控制字完全错位BAP状态机收到一个莫名其妙的操作码测试结果一塌糊涂。我的经验是拿到BAP生成报告后第一时间确认文档里标注的位序和字段位置在验证环境里跑一条“写全1再写全0”的配置用波形确认锁存值这一步能节省后面无数Debug时间。2.3 MBIST控制器的运行与状态回传BAP解析命令后向MBIST控制器发送并行控制信号。这里的握手逻辑直接决定后续时序是否可靠。以一个典型的启动过程为例BAP置位go信号同时给出复位释放时序。MBIST控制器检测到go有效后从IDLE状态进入初始化状态开始跑预设的March算法。这时JTAG链路处于空闲状态BAP只是默默地等待done信号拉高。MBIST控制器完成一轮测试后拉高done如果期间任何比较器检测到读写数据不一致fail信号会同步拉高。BAP捕获到这些状态后将其编码存入自己的状态寄存器。外部设备再次通过JTAG指令选中该BAP执行一次Shift-DR操作把这些状态位串行移位出来就完成了测试结果的读取。这里面的一个关键信号是fail捕捉机制。MBIST控制器可能在跑100万次读写之后第一次检测到故障但测试不会立刻停在那里等你读取。Tessent的MBIST控制器默认行为是跑完整个算法后再报告故障或者在fail时立即停止这可以通过配置选择。对诊断来说立即停止模式能保留故障现场效率更高代价是测试时间会因故障而缩短这在生产测试里会导致故障芯片的测试时间不可预期。两种模式各有利弊设计时要提前想清楚产品定位和质量要求。2.4 时钟域与复位域的第一次正面碰撞这条链路上所有看似“偶发”的诡异问题几乎都能追溯到时钟域或复位域的交叉。JTAG侧的TCK是独立测试时钟频率通常不高几十兆赫兹是常态MBIST控制器侧的时钟是功能时钟可能是几百兆赫兹甚至上GHz。BAP内部就必须做跨时钟域处理。常见的处理方式是异步FIFO加握手同步器。具体来说BAP把并行配置写入一个小的异步寄存器组用同步器打两拍保证TCK域的控制信号安全着陆到功能时钟域。MBIST侧返回的done/fail信号同理从功能时钟域同步回TCK域。我见过一个反面案例某团队为了省几千门面积在BAP的done信号同步上只打了一拍结果生产测试时偶尔出现漏报故障的情况。故障芯片在ATE上表现为“测试通过”但系统级测试又报错定位了整整一个月才怀疑到同步器头上。换成了标准的双触发器同步器后问题立刻消失。为了省这点面积丢测试可靠性是我见过最不划算的交易之一。复位域的问题同样隐蔽。JTAG的TRST复位和MBIST控制器的功能复位经常来自不同的复位源释放时间可能相差很远。如果BAP在功能复位释放之后立即尝试访问尚未复位完毕的MBIST控制器BAP状态机收到的是一个未定义状态的控制器应答访问过程就可能卡死。解决思路是给BAP增加一个“等待目标复位释放”的握手检查或者在测试流程里明确插入固定的等待周期。3. 为什么要用BAP直连模式与间接访问模式的设计权衡讲完链路回到一个根本问题既然BAP这个环节看起来增加了逻辑复杂度为什么不直接把MBIST控制器的信号引出来这个问题的答案在不同规模的设计里并不相同值得掰开揉碎讲清楚。3.1 直连模式在小型设计里的便利与局限直连模式也叫测试引脚直访模式下MBIST控制器的输入端——go、reset、时钟选择等信号——直接连到芯片的测试引脚上done和fail信号也直接输出。好处很直观控制逻辑最少时序最简单测试设备可以直接控制每一个信号没有任何协议开销。但这种模式有三个致命的局限。第一引脚数量消耗快。一个MBIST控制器的接口少说十几根信号多个控制器加起来引脚资源直接爆炸。第二每个控制器都要独立的引脚通道想并行测试多个存储器就需要成倍的引脚。第三也是最重要的一点这些控制信号在顶层要跨越大半个芯片布线时钟偏斜和信号完整性问题足以让后端团队崩溃。小型设计——比如单一SRAM的低功耗MCU——用直连模式完全合理我甚至会推荐这么做。但凡是设计里的存储器数量超过个位数或者芯片有明确的引脚复用要求直连模式就不划算了。3.2 间接访问模式在大规模SoC里的必然性间接访问模式也就是通过BAP和JTAG链路访问MBIST控制器解决的是规模化问题。存储器数量多了之后首要难题是端口复用。BAP把MBIST控制器的并行接口变成了一根串行位流芯片顶层永远只需要TDI和TDO两根数据线所有BAP共享。每增加一个MBIST控制器你付出的额外成本只是几根用于指令译码的选择信号而不是十几根并行数据线。我在一个28nm的SoC项目里管理过128个SRAM实例分属11个时钟域分布在10多个物理模块里。如果用直连模式光测试引脚就要新增上百根这在引脚预算严格的移动芯片上属于不可能完成的任务。改成BAP间接访问之后顶层测试逻辑的引脚占用只有原本的零头各模块内的MBIST控制器又不需要把信号穿越多个时钟域拉来拉去物理实现的工作量下降了一个量级。3.3 面积与布线开销的实际对比可以给一个直观的估算。单个BAP的逻辑规模通常在几百到一千门左右具体取决于配置寄存器的位宽和协议复杂度。一个支持完整命令集、带诊断回读接口的BAP大约相当于一个几百门的同步状态机加移位寄存器。以28nm工艺为例这样的BAP在实际物理实现后面积大约是几百平方微米跟动辄几十万门起步的CPU核心相比完全可以忽略。相比之下直连模式下每个MBIST控制器至少需要额外的大型输出缓冲驱动引脚每个引脚的ESD保护和IO电路面积都要计入成本。128个控制器每人平均多5个接口引脚就是640个IO这还没算绕线拥塞和时序收敛的代价。两个方案的成本曲线在此彻底分叉直连模式的边际成本线性上升BAP模式的边际成本几乎为一条平坦的直线。3.4 功耗与测试并行的权衡BAP间接访问还有一个容易忽略的好处测试功耗控制。MBIST跑起来是很耗电的所有存储器同时翻转瞬间功耗可以拉爆常规测试电源。通过BAP逐个启动MBIST控制器可以在软件层面精确控制“同一时刻最多有多少个存储器在跑测试”实现测试功耗的软件可编程控制。Tessent的MBIST支持分簇调度BAP作为调度通道天然适合做这种控制。我在一个功耗敏感的IoT芯片项目里通过BAP按顺序启动各存储器的MBIST把峰值测试电流压到了上限的70%以内良率测试的稳定度提升明显。有一个重要提示不是说BAP访问模式就一定省功耗而是它给了你控制功耗的能力和自由度。4. Tessent流程里的落地实操配置、接入和验证理论讲再多最后还是要在Tessent工具流程里落地。我给出一套经过多个项目验证的实操路径可以照着执行。4.1 配置MBIST控制器的接口定义Tessent shell里定义MBIST控制器时需要指明接口信号清单。一个典型的配置片段类似set_config -out ff -rst sync ../rtl/top.v set_config -interface functional_clock create_mbist_config -memory_instance sram_inst_0 \ -algorithm {march_c_minus} \ -interface {go reset si so done fail}这里的接口定义决定了MBIST控制器暴露出来的端口集合。go是启动信号reset是复位si是串行数据输入so是串行数据输出done和fail是状态标志。这些信号集合就是后续BAP要对接的“并行引脚”。值得提醒的是Tessent的MBIST接口模式选项里除了标准并行接口还有memory BIST的串行接口模式。选择哪种模式会影响MBIST控制器内部逻辑的复杂度也会影响BAP的设计。我个人的倾向是如果你的设计里BAP是现成的标准结构就优先用标准并行接口兼容性最好如果追求最少的BAP逻辑规模再考虑串行化接口。4.2 BAP的例化与连接Tessent工具链在插入BAP时的具体操作路径有很多种取决于版本和license但核心逻辑是一致的。你需要把BAP的数据端口与MBIST控制器的接口一一对应连接起来。工具通常提供了半自动化的连接方式通过命令指定MBIST控制器实例和BAP实例的映射关系工具会自动完成信号连接。连接完成后BSCAN网表与MBIST网表会被合并成完整的DFT网表在顶层形成TAP到BAP到MBIST控制器的完整通路。这里有一个我反复踩过的坑MBIST控制器的时钟定义。在Tessent MBIST里控制器的时钟一般分成测试时钟和功能时钟两套。测试时钟由TAP侧的TCK提供功能时钟则来自芯片内部的功能时钟树。BAP里的同步逻辑必须清楚区分这两个时钟域否则工具在生成SDF文件做门级仿真时时序检查会爆出大量的violation。4.3 用Tessent shell做访问验证时的典型现象接入完成后Tessent提供了一些测试命令允许你通过TAP接口向BAP发送访问序列。你在Tessent shell里做回归测试时会遇到几种典型现象现象ABAP能收到指令但MBIST不启动。查看波形BAP确实产生了go信号但MBIST控制器的时钟没有翻转。十有八九是MBIST控制器的功能时钟被clock gating电路关掉了DFT模式下需要强制打开。现象BMBIST跑完了但done信号永远回不来。检查BAP的状态寄存器发现done已置位但外部无法读取。问题多半出在Shift-DR阶段的数据路径选择BAP没有被正确选中TDO上输出的还是Bypass寄存器的内容。现象C仿真里一切正常但ATE测试时偶发超时。基本可以断定是跨时钟域握手不完整。回到RTL里加同步器或者调整测试流程中的TCK频率。这三种现象在我的项目里都出现过各有各的坑但定位思路是统一的先信号连通性再时钟域正确性最后协议时序。4.4 常见错误与修复套路我整理了一张问题排查表在多个团队里用过反馈都还不错。现象可能原因排查方法修复方向访问BAP指令无响应BAP指令译码未连接到TAP数据路径Trace指令译码输出到BAP使能端的连接检查BSCAN网表的用户指令定义MBIST完成但无done输出done同步器失效或状态寄存器锁存条件错误波形中观察done原始信号是否翻转更换或补强同步器检查锁存逻辑配置数据错位位序定义与测试向量不匹配对比BAP配置寄存器位图与测试序列统一位序定义重生成ATPG向量多BAP同时访问冲突指令编码冲突或使能信号互斥不完整检查全芯片BAP指令分配表重新分配指令编码增加互斥逻辑测试功耗超标多MBIST控制器并行启动检查BAP调度序列的启动间隔调整软件控制序列分批启动这张表对应的每一条都是真实发生过的事情不是凭空列出来的理论可能性。5. 诊断与调试协同机制中最容易翻车的几个细节前面把链路和流程讲清楚了最后这部分全是我自己的经验教训。这些细节在Tessent标准文档里不一定写得很醒目但往往决定项目成败。5.1 复位释放与TCK的微妙时序复位释放是一个被讨论得最多但仍然持续坑人的问题。原因很简单JTAG端和功能端的复位源经常不是同一棵树。在同时存在TRST复位和功能复位比如Power-on Reset的设计里复位释放的相对时序决定BAP能否正确初始化。如果TRST已经释放而功能复位还没释放BAP内部的状态机已经开始跑它试图访问MBIST控制器时对方却还处在复位状态这个访问必然失败。解决这类问题我推荐在BAP设计阶段就增加一个复位域同步逻辑BAP内部所有涉及MBIST访问的状态机必须检测到MBIST控制器的复位已经释放之后才能收到go有效信号。这东西可以等MBIST控制器的reset_out信号返回后做同步处理。很多顶级SoC的DFT架构确实是这样实现的。5.2 多存储体调度时的BAP冲突一个BAP挂多个MBIST控制器的情况非常常见尤其在追求面积效率的设计里。此时一个BAP需要具备某种仲裁能力或者在测试流程里约定好“同一时间只激活一个控制器”。Tessent生成的BAP支持这种多挂载但访问时序要格外小心。某个控制器的done还没回来你就去启动另一个控制器前一个控制器的结果就会丢失。我见过有团队在ATE测试程序里犯这个错误导致首批芯片的MBIST测试故障率看起来异常差点误判为产品良率问题。最终发现他们自己写测试序列时少等了一个周期纯软件问题硬生生浪费了两周的分析时间。建议做法在BAP的配置寄存器里增加一个“忙闲状态”只读位外部设备在发送启动命令之前先轮询这个位。虽然典型的做法是检查done标志再启动下一个但忙闲状态位能更完整地反映控制器当前生命周期状态。5.3 诊断数据回读的带宽瓶颈MBIST测试通过与否只是最基本的需求真正的难点在于故障位置的精确诊断。生产测试环境里你能接受的时间是毫秒级但通过JTAG串行回读故障地址和期望数据每一bit都是时钟周期级别的消耗。举个例子一个地址深度为4096的SRAM跑March C-算法后如果发现故障需要回读的信息包括故障地址12 bit、期望数据比如32 bit、实际数据32 bit再加上头部协议开销总共大约80到100 bit。按10MHz TCK频率计算一个故障的完整诊断回读需要10微秒左右看起来不慢但如果一个晶圆上有几百颗芯片都出现故障累计诊断时间就会显著延长。解决思路有三条。第一在BAP内部增加简单的多周期数据打包逻辑减少协议开销第二用并行BAP通过额外的数据引脚提升回读带宽代价是引脚消耗增加第三在测试程序里合理抽样只针对部分故障芯片做完整诊断其余只做通过与否的判断。5.4 实测中的波形观察建议最后分享一个调试经验波形检查时从哪个信号开始看。我见过不少工程师一上来就盯TDO的输出波形对着长长的串行数据猜测哪里不对效率极低。我的建议是倒着看先看MBIST控制器的状态机波形确认它是否真的运行起来了再看BAP到MBIST控制器的并行接口信号确认配置值是否正确锁存最后才回到JTAG链路确认指令译码和移位过程。这个倒查顺序的逻辑很简单JTAG链路是协议标准出问题的概率相对低MBIST控制器是存储器厂商提供的验证过的IP出问题的概率也低反而是中间这一层BAP属于定制逻辑而且横跨两个时钟域是整个链路里风险最集中的地方。从风险最高的环节开始排查定位速度是最快的。具体到波形窗口我会重点观察六个关键节点TCK上升沿对应的TDI采样点、BAP配置寄存器的Update-DR锁存沿、go信号到MBIST控制器侧的同步路径、MBIST的done信号回到BAP侧的同步路径、TDO输出的Shift-DR窗口、以及复位树的释放时刻。这六个节点看完了整个链路的健康状况就有数了。6. 后续扩展方向如果你的设计规模继续变大或者测试策略升级这套BSCANBAPMBIST的机制还有几个可以深挖的方向。第一层次化BAP。多die封装或者chiplet设计里每个die都有独立的JTAG子系统chip级需要一套统一的层次化访问机制。Tessent的HTAP思路就是为这个场景准备的把各die的BAP访问汇聚到顶层统一的测试端口之下通过指令路由逐级访问。这样做的好处是芯片级测试可以统一调度但指令编码空间和路由逻辑的复杂度会明显上升。第二引入IEEE 1687IJTAG风格的访问机制。它的核心思想是让测试访问网络本身具有可配置性通过Segment Insertion Bit来控制数据寄存器链的分段和跳过访问灵活性比传统BAP更高。如果团队有长期演进计划建议在BAP的寄存器接口设计上预留一些兼容冗余。第三把软件初始化流程标准化。测试访问链路的“用户”不只是ATE设备还有芯片内置的软件自检Software Self-Test程序。如果把BAP的访问协议封装成固件函数库支持在系统运行阶段动态触发MBIST就能实现系统上电时的在线存储器自检。很多车规芯片和服务器芯片都有这个需求也是一块值得提前布局的技术方向。第四诊断智能化。MBIST回读的原始故障数据只是一堆地址和数据真正定位到物理失效原因还需要结合存储器的物理布图信息做故障映射。把BAP回读的故障数据接入自动化诊断流程完成从逻辑故障到物理坐标的映射能大幅缩短良率提升周期。这块工具链支持已经越来越成熟关键还是在设计阶段留好诊断数据接口。第五功耗与测试的协同优化。TSMC的N3、N5工艺下测试功耗对电压降和热分布的影响越来越严重可以说没有好的功耗约束MBIST根本没法高并行跑。BAP天然支持分批启动的能力如果结合芯片级功耗管理系统让MBIST测试批次与电源域状态动态绑定可以在保证测试覆盖率的同时把峰值功耗再压一个台阶。以上几点有精力的话值得逐步推进。我在多个项目的演进过程中就是按这个节奏迭代的每一步都能看到实实在在的收益。