企业官网建设流程全解析

1. 先理清角色：BSCAN、BAP和MBIST各管哪一段

做DFT做了十几年，我最常被刚入行的同事问的一个问题是：Tessent的MBIST明明自己就能生成控制器，为什么还要拉上BSCAN和BAP？这三样东西到底谁听谁的？

这个问题别看简单，真能讲清楚的人不多。很多人拿着Tessent的脚本跑通了流程，但脑子里始终没有建立起一张完整的“测试访问地图”，一旦遇到访问不到存储器、故障误报、时序收敛不过这类问题，就只能靠瞎试碰运气。

我习惯用一个城市交通的类比来拆解这三者的关系。边界扫描BSCAN（Boundary Scan）就像城市的主干道网络，它是芯片测试的公共基础设施，基于IEEE 1149.1标准搭起来的TAP（Test Access Port）控制器就是城市的总入口；MBIST控制器是要去干活的工作人员，它们负责对SRAM、寄存器堆这类存储器阵列执行March算法测试；而BAP（BScan Access Port）就是连接主干道和工作人员之间的“专用门禁通道”。

没有BAP，MBIST控制器虽然也能跑，但你必须把它的控制信号、数据信号、状态信号全部引到芯片顶层，一个个接出来，这在规模稍大的芯片里几乎是一场灾难。有了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里做回归测试时，会遇到几种典型现象：

• 现象A：BAP能收到指令但MBIST不启动。查看波形，BAP确实产生了go信号，但MBIST控制器的时钟没有翻转。十有八九是MBIST控制器的功能时钟被clock gating电路关掉了，DFT模式下需要强制打开。

• 现象B：MBIST跑完了但done信号永远回不来。检查BAP的状态寄存器，发现done已置位但外部无法读取。问题多半出在Shift-DR阶段的数据路径选择，BAP没有被正确选中，TDO上输出的还是Bypass寄存器的内容。

• 现象C：仿真里一切正常，但ATE测试时偶发超时。基本可以断定是跨时钟域握手不完整。回到RTL里加同步器，或者调整测试流程中的TCK频率。

这三种现象在我的项目里都出现过，各有各的坑，但定位思路是统一的：先信号连通性，再时钟域正确性，最后协议时序。

4.4 常见错误与修复套路

我整理了一张问题排查表，在多个团队里用过，反馈都还不错。

这张表对应的每一条都是真实发生过的事情，不是凭空列出来的理论可能性。

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. 后续扩展方向

如果你的设计规模继续变大，或者测试策略升级，这套BSCAN+BAP+MBIST的机制还有几个可以深挖的方向。

第一，层次化BAP。多die封装或者chiplet设计里，每个die都有独立的JTAG子系统，chip级需要一套统一的层次化访问机制。Tessent的HTAP思路就是为这个场景准备的，把各die的BAP访问汇聚到顶层统一的测试端口之下，通过指令路由逐级访问。这样做的好处是芯片级测试可以统一调度，但指令编码空间和路由逻辑的复杂度会明显上升。

第二，引入IEEE 1687（IJTAG）风格的访问机制。它的核心思想是让测试访问网络本身具有可配置性，通过Segment Insertion Bit来控制数据寄存器链的分段和跳过，访问灵活性比传统BAP更高。如果团队有长期演进计划，建议在BAP的寄存器接口设计上预留一些兼容冗余。

第三，把软件初始化流程标准化。测试访问链路的“用户”不只是ATE设备，还有芯片内置的软件自检（Software Self-Test）程序。如果把BAP的访问协议封装成固件函数库，支持在系统运行阶段动态触发MBIST，就能实现系统上电时的在线存储器自检。很多车规芯片和服务器芯片都有这个需求，也是一块值得提前布局的技术方向。

第四，诊断智能化。MBIST回读的原始故障数据只是一堆地址和数据，真正定位到物理失效原因，还需要结合存储器的物理布图信息做故障映射。把BAP回读的故障数据接入自动化诊断流程，完成从逻辑故障到物理坐标的映射，能大幅缩短良率提升周期。这块工具链支持已经越来越成熟，关键还是在设计阶段留好诊断数据接口。

第五，功耗与测试的协同优化。TSMC的N3、N5工艺下，测试功耗对电压降和热分布的影响越来越严重，可以说没有好的功耗约束，MBIST根本没法高并行跑。BAP天然支持分批启动的能力，如果结合芯片级功耗管理系统，让MBIST测试批次与电源域状态动态绑定，可以在保证测试覆盖率的同时把峰值功耗再压一个台阶。

以上几点，有精力的话值得逐步推进。我在多个项目的演进过程中就是按这个节奏迭代的，每一步都能看到实实在在的收益。