企业官网建设流程全解析

3D IC 的 Memory-on-Logic 堆叠，是这两年被问得最多、也最容易在测试环节翻车的一类结构。逻辑晶圆和存储晶圆各自单独测都是好的，键合到一起之后，测试访问路径突然变得又长又窄，ATPG 的 pattern 传不进去，JTAG 链断在中间某一层，良率数据拿不到，最后只能靠猜。这篇内容就是围绕这个场景展开的：Memory-on-Logic 堆叠结构下，DFT 到底该怎么设计，ATPG 和 JTAG 这两条主线怎么打通，工程上哪些坑是必须提前埋好测试结构的。适合做 3D IC DFT、测试架构、以及负责堆叠良率分析的工程师参考，也适合刚接触 3D 测试、想搞清楚"为什么堆叠之后测试难度陡增"的读者。

1. Memory-on-Logic 堆叠给测试带来的结构性变化

1.1 从 2D 到 3D，测试访问路径发生了什么

在传统 2D 芯片里，DFT 工程师的假设很朴素：所有待测逻辑都在同一个 die 上，扫描链、压缩逻辑、JTAG TAP 控制器都在同一块硅片上，测试激励从芯片引脚进来，经过几级多路选择就能到达目标寄存器。路径短、可控、可预测。

到了 Memory-on-Logic 堆叠，这个假设直接被打破。逻辑 die 在下，存储 die 在上，两者通过微凸点（micro-bump）或混合键合（hybrid bonding）连接。逻辑 die 上的 DFT 结构还在，但存储 die 上的测试访问必须穿过键合界面。键合点的数量是有限的，通常远少于两个 die 内部各自需要的测试信号数量。这就带来第一个核心矛盾：测试带宽被键合界面卡住了。

我习惯把这种结构类比成两栋楼之间只有一部窄电梯。楼里各自的走廊再宽，货物要跨楼运输，就只能挤这部电梯。DFT 设计要做的，就是让跨楼运输的货物尽可能少、尽可能规律。

具体到信号层面，跨 die 的测试访问通常依赖几类通道：一是键合点直接引出的测试信号，数量受限于凸点预算；二是通过 IEEE 1838 定义的 Die-to-Die 接口，用少量引脚串行化传输；三是复用功能路径，把测试数据塞进正常的数据通道里。这三类通道的选择，直接决定了后续 ATPG 和 JTAG 的实现方式。

1.2 键合界面为什么是测试的死穴

键合界面的问题不只是"线少"，还有"线不可靠"。微凸点在键合过程中可能出现空洞、偏移、冷焊，混合键合虽然密度高，但对表面平整度和颗粒极其敏感。这些物理缺陷反映到测试上，就是跨 die 路径的间歇性失效。

更麻烦的是，键合之后如果发现某条跨 die 测试路径坏了，你没法像 2D 芯片那样简单换个引脚。键合是不可逆的（至少量产阶段不可逆），所以 DFT 设计必须假设"部分跨 die 连接会失效"，并让测试结构具备一定的容错和诊断能力。

这就引出一个关键设计原则：跨 die 测试路径要可观测、可旁路、可分段。不能设计成一条黑盒通道，坏了就整颗报废。实际工程中，我会在跨 die 接口上插入边界扫描单元和旁路多路选择器，让每一段都能单独测、单独隔离。

1.3 存储 die 的测试需求与逻辑 die 的差异

逻辑 die 的测试以扫描链和 ATPG 为主，关注的是固定型故障、跳变延迟故障、桥接故障。存储 die 的测试逻辑完全不同，核心是 March 算法、数据保持、读写裕量、以及存储阵列的行列故障。

这两套测试语言本来就不一样。Memory-on-Logic 堆叠之后，如果存储 die 没有自己的 BIST 控制器，测试激励就得从逻辑 die 通过键合界面送过去，数据量大、速率要求高，键合界面根本扛不住。所以工程上的主流做法是：存储 die 自带 MBIST 和修复逻辑，逻辑 die 只负责触发和收集结果。

这个分工非常重要。它把跨 die 的测试流量从"海量测试数据"压缩成"控制命令加结果状态"，键合界面的压力瞬间小了一个数量级。我在项目里见过反例：为了省面积，存储 die 不做 MBIST，结果跨 die 测试通道成了瓶颈，测试时间翻了三倍，最后不得不改版。

2. 跨 die 测试访问架构的选型与取舍

2.1 IEEE 1838 到底解决了什么问题

IEEE 1838 是专门为 3D 堆叠测试定义的标准，核心是三个东西：Die Wrapper、Flexible Parallel Port（FPP）、以及串行的测试访问机制。Die Wrapper 给每个 die 包一层边界，让 die 在堆叠前后都能被独立访问；FPP 提供并行测试通道；串行机制则用少量引脚完成配置和数据传输。

它的价值在于标准化了"堆叠中如何单独访问某一层"这件事。没有 1838 之前，每家做 3D 测试都是自己定义私有接口，测试设备、EDA 工具、IP 之间互不兼容，换个供应商就得重做一套。1838 把这些接口统一了，ATPG 工具可以直接生成符合标准的 wrapper 和访问逻辑。

但要注意，1838 不是万能的。它定义的是访问架构，不定义测试内容。你的 ATPG pattern、MBIST 算法、修复策略，还是得自己设计。而且 1838 的串行访问在层数多的时候，配置时间会累积，需要权衡。

2.2 并行访问与串行访问的工程权衡

并行访问的优点是快，测试数据可以同时打到多个 die 上；缺点是吃引脚、吃凸点。串行访问省引脚，但配置和传输时间长，尤其是需要反复切换测试模式的时候。

实际项目里，我一般这样取舍：

混合方案是主流。扫描链数据量大，走并行通道；模式配置、MBIST 启动、结果读取走串行。这样既控制了引脚数，又不至于让测试时间失控。

有个细节容易被忽略：并行通道的时序收敛。跨 die 的并行通道经过键合点，寄生参数和 2D 芯片完全不同，建立保持时间要重新约束。我见过项目因为没做跨 die 时序约束，ATPG pattern 在仿真里过、在硅上挂，排查了两周才发现是键合路径的延迟没建模。

2.3 测试访问架构对 ATPG 的约束

ATPG 工具在生成 pattern 时，需要知道测试访问路径的模型。如果跨 die 路径被建模成黑盒，工具就没法把故障传播到可观测点，覆盖率会掉得很难看。

正确做法是把跨 die 访问结构完整地描述给 ATPG 工具，包括 Die Wrapper 的边界单元、FPP 的多路选择、以及串行访问的移位逻辑。这样工具才能把跨 die 路径当作普通逻辑来处理，生成有效的 pattern。

这里有个实操经验：跨 die 路径的故障模型要单独定义。键合点的失效模式和普通逻辑门不一样，可能是电阻性开路、间歇性短路。用标准的 stuck-at 模型覆盖不到这些，需要补充桥接故障和延迟故障模型。我在项目里会专门为跨 die 接口生成一组定向 pattern，不依赖随机 ATPG。

3. ATPG 在堆叠结构下的实操要点

3.1 扫描链如何跨 die 组织

扫描链跨 die 是 Memory-on-Logic 测试里最棘手的问题之一。逻辑 die 的扫描链本来在片内闭环，现在要延伸到存储 die 的边界，甚至穿过存储 die 的 wrapper。

主流做法有两种：一是扫描链不跨 die，每个 die 的扫描链独立，通过 wrapper 和访问架构分别测试；二是扫描链跨 die 拼接，把两个 die 的扫描链串成一条长链。

第一种方案测试时间短、故障隔离好，但需要更多的测试访问通道。第二种方案省通道，但一条链上任何一段坏了，整条链都不可用，诊断困难。

我倾向于第一种，尤其是在量产阶段。理由很简单：3D 堆叠的良率本来就比 2D 低，如果扫描链跨 die，一个键合点坏了可能导致整条链失效，良率损失被放大。独立扫描链虽然通道开销大，但故障隔离能力强，诊断数据也干净。

如果确实要用跨 die 扫描链，务必在键合界面插入可旁路的边界单元。这样某一段坏了，可以旁路掉，剩下的链还能继续测。

3.2 测试压缩在跨 die 场景下的适配

测试压缩（如 EDT、DFTMAX）在 2D 芯片里是标配，能把 pattern 数量压一个数量级。但跨 die 之后，压缩逻辑的位置很关键。

如果压缩逻辑只在逻辑 die 上，存储 die 的测试数据要先通过键合界面送到逻辑 die 的压缩器，再解压。这会让跨 die 通道的带宽需求暴增，因为压缩前的数据量是压缩后的几倍甚至十几倍。

正确做法是在每个 die 内部各自做压缩，跨 die 只传压缩后的数据和控制信号。这样键合界面的带宽压力最小。代价是每个 die 都要有独立的压缩器和解压器，面积开销增加，但相比测试时间和良率损失，这个代价是值得的。

还有个坑：压缩器的种子（seed）管理。跨 die 场景下，多个压缩器需要同步，种子要统一管理。如果种子配置错了，pattern 解压出来是乱的，测试结果完全不可信。我在项目里会专门做一组种子校验 pattern，在正式测试前跑一遍，确认压缩链路正常。

3.3 覆盖率收敛的难点与定向 pattern 补充

跨 die 结构的覆盖率收敛，难点不在逻辑本身，而在跨 die 路径的可控性和可观测性。随机 ATPG 很难覆盖到键合点的故障，因为这些点的控制路径太长、观测路径太窄。

我的做法是分三步：

1. 先用标准 ATPG 跑一遍，看覆盖率基线，识别出跨 die 路径相关的未覆盖故障。
2. 针对这些故障，手动或半自动生成定向 pattern，专门激励和观测跨 die 接口。
3. 把定向 pattern 和随机 pattern 合并，做最终覆盖率验证。

定向 pattern 的设计要点是：让跨 die 信号在尽可能多的组合下被激励。比如键合点的开路故障，需要让信号在两个方向都翻转；桥接故障，需要让相邻信号处于不同逻辑值。这些用随机 ATPG 碰运气效率太低，定向生成更靠谱。

覆盖率目标方面，跨 die 接口我一般要求 99% 以上，比片内逻辑的 98% 更严。因为跨 die 接口的故障影响面更大，一个键合点坏了可能让整个堆叠失效。

4. JTAG 在 3D 堆叠中的链路设计与调试

4.1 多层 TAP 控制器的级联方式

JTAG 在 3D 堆叠里的角色，从"芯片级调试接口"变成了"堆叠级配置和诊断总线"。每个 die 都有自己的 TAP 控制器，这些 TAP 怎么级联，直接决定了调试效率。

标准做法是把各层 TAP 串成一条链，TCK、TMS、TDI、TDO 依次穿过。但这样有个问题：如果某一层的 TAP 挂了，整条链都不可用。而且串行链的配置时间随层数线性增长。

改进方案是星型或混合拓扑：用一个顶层 TAP 控制器做仲裁，各层 TAP 可以独立选择。这样坏了一层不影响其他层，配置时间也短。代价是顶层要多一些控制逻辑。

我在项目里更倾向混合拓扑：顶层 TAP 负责全局控制，各层 TAP 通过一个可配置的旁路网络连接。正常测试时用串行链，诊断时切换到独立访问模式。这样兼顾了效率和可诊断性。

4.2 跨 die JTAG 信号的时序与信号完整性

JTAG 的 TCK 频率在 2D 芯片里可以跑到几十兆甚至上百兆，但跨 die 之后，键合点的寄生电容和电阻会让信号边沿变缓，时序裕量急剧缩小。

实测经验：跨 die 的 TCK 频率通常要降到片内的三分之一到一半。具体降多少，取决于键合工艺和走线长度。混合键合的寄生参数比微凸点小，能跑更高频率；微凸点则要保守一些。

除了降频，还要注意信号完整性。跨 die 的 TMS 和 TDI 是单端信号，容易受串扰影响。我一般会在键合界面附近加施密特触发器整形，必要时用差分信号传输再转单端。TDO 是输出方向，驱动能力要足够，否则顶层收不到干净的数据。

还有个容易忽略的点：跨 die JTAG 信号的上电顺序。如果某一层 die 还没上电，它的 TAP 输入是高阻，可能把整条链拉乱。所以要么保证上电顺序，要么在 TAP 输入加隔离单元。

4.3 用 JTAG 做堆叠后诊断的实战流程

堆叠之后的诊断，JTAG 是最重要的工具。我通常按这个流程走：

1. 链路连通性检查：先跑 IDCODE 读取，确认每层 TAP 都能被访问。如果某层读不到，先查供电和时钟，再查键合连接。
2. 边界扫描测试：用 EXTEST 模式检查跨 die 的互连。这一步能发现键合点的开路和短路。
3. 内部扫描访问：通过 TAP 配置各层的扫描链，跑简化的 ATPG pattern，确认逻辑功能正常。
4. MBIST 触发与结果读取：通过 TAP 启动存储 die 的 MBIST，读取通过/失败状态和故障地址。
5. 修复验证：如果 MBIST 报了可修复故障，触发修复逻辑，再跑一遍确认修复生效。

这个流程里，第 2 步和第 4 步最容易出问题。边界扫描测试需要正确的 BSDL 描述，如果 BSDL 和实际键合映射不一致，测试结果就是错的。MBIST 结果读取要注意时序，存储 die 的 MBIST 完成信号跨 die 传回来有延迟，读太早会拿到无效数据。

5. 工程实践中踩过的坑与应对

5.1 键合偏移导致的测试路径失效

键合偏移是量产中最常见的缺陷之一。微凸点偏移几个微米，可能造成接触电阻增大甚至开路。反映到测试上，就是某些跨 die 路径间歇性失效，测试结果忽好忽坏。

排查这种问题的难点在于：它不是稳定失效，用普通的功能测试很难抓到。我的做法是在跨 die 路径上加入可编程的延迟和裕量测试。通过 JTAG 配置不同的时序裕量，观察路径在什么条件下开始失效。如果裕量明显小于设计值，基本可以判定是键合质量问题。

另一个手段是多次采样。对同一路径连续测多次，统计失效频率。间歇性失效的频率和键合质量强相关，可以作为工艺监控指标。

5.2 测试模式切换时的竞争与死锁

3D 堆叠的测试模式很多：逻辑扫描、MBIST、边界扫描、互连测试。模式切换时，如果控制信号跨 die 传输有延迟，可能出现竞争，甚至死锁。

我遇到过一次典型死锁：逻辑 die 已经切到扫描模式，存储 die 还在 MBIST 模式，两边状态机互相等待，JTAG 链卡死。最后只能重新上电。

解决办法是模式切换要握手。逻辑 die 发出切换请求后，要等存储 die 确认，再真正切换。握手信号走独立的跨 die 通道，不和其他测试信号复用。这样虽然多占一点资源，但避免了死锁风险。

5.3 测试时间与良率数据的平衡

3D 堆叠的测试成本本来就高，如果测试时间再失控，量产经济性就没了。但测试时间压太狠，良率数据又不准，可能放过坏品。

我的经验是分层测试策略：堆叠后先做快速连通性和 MBIST 测试，把明显坏的筛掉；对通过的样品再做完整扫描测试和参数测试。这样大部分坏品在快速测试阶段就被拦截，完整测试只跑在好品上，平均测试时间大幅下降。

快速测试的覆盖率不用追求很高，但必须能抓到键合缺陷和存储阵列的硬故障。这两类故障占了堆叠失效的大部分，抓住它们，良率数据就有意义。

5.4 从硅后数据反推 DFT 设计改进

硅后测试数据是 DFT 设计改进的金矿。我会重点看三类数据：跨 die 路径的失效分布、MBIST 的故障类型分布、以及 JTAG 链路的错误日志。

如果跨 die 路径失效集中在某些区域，可能是键合工艺的均匀性问题，也可能是 DFT 结构在这些区域的冗余不足。如果 MBIST 报的故障以单比特为主，说明存储阵列质量不错；如果多比特故障多，可能是行列驱动或电源问题。

JTAG 错误日志能反映链路设计的健壮性。如果某层 TAP 经常掉线，要考虑是不是该层的时钟或复位设计有问题。这些信息反馈到下一版 DFT 设计，能显著提升堆叠良率。

6. 面向量产的 DFT 设计检查清单

6.1 堆叠前必须确认的 DFT 事项

在键合之前，每个 die 的 DFT 结构必须单独验证通过。这一步不能省，因为堆叠后再发现问题，返工成本极高。

我会确认这几项：扫描链在片内完整闭环，压缩逻辑工作正常，MBIST 在存储 die 上独立跑通，JTAG TAP 能正常读写 IDCODE，边界扫描单元的描述和实际引脚一致。这些都在堆叠前验证，堆叠后只需要验证跨 die 部分。

还有一项容易漏：跨 die 接口的 DFT 结构要在堆叠前做环回测试。把跨 die 的输出环回到输入，验证接口逻辑本身没问题。这样堆叠后如果跨 die 测试失败，可以确定问题在键合，不在接口逻辑。

6.2 堆叠后测试流程的固化

堆叠后的测试流程要固化下来，形成标准操作。包括上电顺序、时钟配置、JTAG 链初始化、各测试模式的进入和退出顺序、以及结果判定标准。

流程固化不只是写文档，还要在测试程序里体现。我见过项目因为测试程序里模式切换顺序写错，导致批量误判。后来把流程做成状态机，每一步都有确认，才稳定下来。

流程里要包含异常处理：如果某一步失败，是重试、跳过、还是标记报废。这些策略要提前定好，不能到量产了还在临时决定。

6.3 良率分析与 DFT 迭代的闭环

良率分析不是测试的终点，而是 DFT 迭代的起点。每次良率波动，都要能追溯到具体的测试项和故障类型。这要求测试数据有足够的粒度，不能只记录通过/失败。

我会在测试程序里记录每个测试项的结果、失效的具体路径或地址、以及测试时的环境参数。这些数据积累起来，就能看出趋势，指导 DFT 结构优化。

闭环的关键是快速迭代。从良率数据发现问题，到 DFT 设计修改，再到新版本验证，周期越短越好。3D IC 的迭代成本高，更需要精准定位问题，避免盲目改版。

6.4 常见问题速查表

这张表是我从多个项目里总结出来的，实际排查时按这个顺序走，能省不少时间。当然每个项目情况不同，具体问题还要结合硅后数据具体分析。

7. 写在最后的一点个人体会

3D IC 的 Memory-on-Logic 测试，说到底是在"有限的跨 die 资源"和"无限的测试需求"之间找平衡。DFT 工程师的价值，不在于把测试做得多么完美，而在于用最小的跨 die 开销，拿到足够可信的良率数据。

我做了几个堆叠项目之后，最大的体会是：测试架构要在设计早期就介入。等到逻辑和存储都设计完了再考虑怎么测，往往已经晚了，跨 die 通道不够、wrapper 没预留、MBIST 没集成，这些问题后期补代价极大。早期介入，哪怕只是多留几条跨 die 测试线，后面都会轻松很多。

另一个体会是：不要迷信标准。IEEE 1838 是好东西，但它不是即插即用的。标准给的是框架，具体怎么用，还是要结合自己的工艺、产品、测试设备来定。我见过生搬标准结果测试效率反而下降的案例，也见过在标准基础上做裁剪、效果很好的案例。关键是理解标准背后的意图，而不是照抄。

最后，硅后数据一定要认真看。仿真再完美，硅上总会有意外。那些意外里藏着下一版设计改进的方向，也藏着工艺和测试的深层问题。把数据用起来，DFT 设计才能真正迭代起来。