2026年芯片设计DFT工程师高频面试题包含详细解答

芯片设计DFT工程师高频面试题

【精选近三年60道高频面试题】

【题目来源：学员面试分享复盘及网络真题整理】

【注：每道题含高分回答示例+避坑指南】

1.画一下标准的JTAGTAPController状态机，并解释Shift-DR和Update-DR阶段的具体动

作。（基本必考|背诵即可）

2.Stuck-atFault和TransitionFault有什么区别？在生成ATPGpattern时两者有何不同要求？

（极高频|重点准备）

3.解释一下ScanChain中的LockupLatch的作用，通常插在哪里？如果不插会导致什么后

果？（基本必考|需深度思考）

4.什么是OCC（On-ChipClockController）？为什么做At-speedtest时必须用到它？（极

高频|重点准备）

5.详细说明TestCompression（测试压缩）的基本原理，EDT（XOR树）是如何处理

Unknown(X)态的？（常问|需深度思考）

6.BoundaryScan（边界扫描）中，EXTEST和INTEST指令的区别是什么？（常问|背诵即

可）

7.MBIST（MemoryBIST）的常用算法有哪些？MarchC-算法是如何覆盖大部分Memory故

障的？（极高频|重点准备）

8.什么是TransitionDelayFault的Launch-Off-Shift(LOS)和Launch-Off-Capture(LOC)？现

在工业界为什么多用LOC？（极高频|需深度思考）

9.解释一下BridgingFault和Cell-AwareFault模型，为什么在先进工艺（如3nm/5nm）下越

来越重视Cell-Aware？（常问|网友分享）

10.在你最近的一个流片项目中，DFT的总体架构是怎么设计的？为什么这样选型？（基本

必考|考察实操）

11.介绍一下你在项目中是如何处理多时钟域（Multi-ClockDomain）的ScanChain插入的？

（极高频|考察实操）

12.如果你的设计中包含了大量的SRAM，你是如何规划MBIST的分组（Grouping）和调度

（Scheduling）来平衡测试时间和功耗的？（重点准备|考察实操）

13.针对项目中包含多种电源域（Multi-PowerDomain）的IP，DFT设计在隔离单元

（IsolationCell）和电平转换器（LevelShifter）处需要做哪些特殊处理？（常问|需深度

思考）

14.详细讲讲你是如何做HierarchicalDFT（分层DFT）的？Top层和Block层的数据和控制信

号是如何对接的？（极高频|考察实操）

15.在以往的项目里，你遇到过最难的测试覆盖率（Coverage）提升瓶颈是什么？你是如何

突破的？（基本必考|反复验证）

16.你们项目的Scanchainlength一般设置多长？这个长度是基于哪些维度（如测试仪器的通

道、测试时间等）评估出来的？（常问|考察实操）

17.讲一个你在项目中做TestPowerReduction（降低测试功耗）的具体案例，采用了哪些技

术？（常问|需深度思考）

18.如果设计中有很多异步复位信号，在Scan模式下你是怎么处理它们的以避免时序违例

的？（极高频|考察实操）

19.你们的芯片中有用到MemoryRepair技术吗？硬修复（HardRepair）和软修复（Soft

Repair）在流程上有什么区别？（常问|重点准备）

20.遇到第三方IP加密无法看到内部RTL时，你是如何对它进行DFT集成和测试的？（常问|

考察实操）

21.你在项目中是如何规划JTAG引脚复用（PinMux）逻辑的？如何保证上电复位后引脚状态

的安全性？（常问|考察实操）

22.说说你在项目中生成ATPGPattern后，是如何规划VCS带时序仿真（GLS）的？遇到过

仿真挂死的情况吗？（基本必考|考察实操）

23.你们项目做At-speed测试时，PLL的频率是多少？你是如何确保测试时钟路径上的时序收

敛的？（极高频|需深度思考）

24.在你最近做过的项目中，DFT逻辑大约占了芯片总面积的百分之几？你是如何向前端争取

资源或者优化DFT面积开销的？（学员真题|考察软实力）

25.回顾你做过的最复杂的一个芯片，如果让你重新做一次该项目的DFT架构，你会做哪些优

化？为什么？（基本必考|需深度思考）

26.项目里有用到IEEE1687(IJTAG)吗？相比于传统IEEE1149.1，它在复杂IP网络管理中

解决了什么痛点？（常问|网友分享）

27.如果在插入ScanChain后，后端的同学跑来告诉你DFT引入了大量严重的HoldTime

Violation，你会如何协助排查并解决？（极高频|考察实操）

28.运行ATPG时，发现某一个Block的覆盖率只有85%，远低于99%的目标，你的

Troubleshooting思路是什么？（基本必考|重点准备）

29.遇到ATPGDRC报出大量的D1规则违例（Clockruleviolations），一般是什么原因导致

的？如何Fix？（极高频|考察实操）

30.如果Zero-delay的仿真过了，但是SDF反标后的Gate-levelsimulation在ScanShift阶段跑

飞了，你第一步检查什么？（极高频|需深度思考）

31.怎么定位和修复由于Xstate（未知态）传播导致的ATPG覆盖率急剧下降问题？你会用到

哪些工具命令？（重点准备|考察实操）

32.当ATE测试机台上报出ScanChain断链（ChainBroken），只能读出全0或全1时，你会

如何协助测试工程师进行SiliconDebug？（基本必考|考察实操）

33.机台测试反馈只有在高温和降压（LowVDD）环境下才会随机出现MBISTFail，你怀疑

是哪方面的问题？如何排查？（反复验证|需深度思考）

34.在排查ATPGPattern的SimulationMismatch时，你是怎么从波形上定位到具体的那个触

发器和出错时间的？（常问|考察实操）

35.若芯片回片测试发现TransitionFaultPattern良率极低，但Stuck-atPattern良率正常，你

认为可能是什么原因？（重点准备|需深度思考）

36.怎么处理设计中存在的CombinationalLoop导致的DFTDRC报错？直接切断会有什么风

险？（极高频|重点准备）

37.前端设计人员不小心把一个时钟信号当成了数据信号连到了寄存器的D端，这在DFT阶段

会引发什么问题？你该怎么发现并让他修改？（学员真题|考察软实力）

38.如果工具在插OCC的时候由于时钟网络过于复杂导致插入失败，你会如何通过手动干预

来解决？（网友分享|考察实操）

39.ATE反馈某几条Pattern的功耗极大，导致IRDrop引起了测试良率损失，你会如何在

ATPG阶段修正这个问题？（极高频|需深度思考）

40.当测试向量在机台上出现Flaky（时过时不过）的情况，你会从机台环境、测试向量还是

芯片物理特性方面去着手？（反复验证|考察抗压）

41.发现BoundaryScan连通性测试在板级（Boardlevel）测试时总是Fail，但芯片内部仿真

都没问题，可能是什么原因？（常问|需深度思考）

42.在处理AnalogIP的DFT测试时，如果模拟团队没有提供数字化的BIST，你一般怎么处理

与数字逻辑接口部分的测试？（常问|考察实操）

43.如果后端的布局布线（P&R）改变了ScanChain的顺序，导致跟你的ATPG数据库对不

上，你怎么通过流程来重新同步（ScanReordering）？（极高频|考察实操）

44.怎么排查并修复由于Tri-statebuffer（三态门）在ScanShift时出现总线冲突（Bus

Contention）的问题？（基本必考|重点准备）

45.若在生成Pattern时发现Pattern数量爆炸（Patterncountinflation），超出了ATE机台的内

存容量，你有哪些手段来压缩或截断？（极高频|考察实操）

46.你有没有处理过ClockGatingCell在Testmode下无法打开导致的覆盖率问题？你是怎么

强制干预的？（重点准备|考察实操）

47.当网表进行ECO（EngineeringChangeOrder）修改后，你如何最高效地验证DFT逻辑

是否被破坏，而不必重跑全套流程？（常问|考察实操）

48.遇到过最奇葩、最难解的一个DFT相关的Bug是什么？最后是怎么Fix的？（基本必考|考

察抗压）

49.假如流片时间紧迫，发现某个非核心模块的MBIST设计有致命缺陷，不改会影响流片，改

了会拖延Schedule，你会怎么跟项目经理建议？（学员真题|考察软实力）

50.你怎么看待芯片前端设计（RTL）人员抱怨DFT约束太严，导致他们代码难写的情况？如

何平衡？（常问|考察软实力）

51.测试机台上发现Holdtime问题导致Scanshiftfail，芯片已经封装好了，你还有没有办法

能让测试继续进行下去？（重点准备|需深度思考）

52.如果发现测试向量覆盖到了FalsePath或者Multi-CyclePath上的逻辑，导致机台测试失

败，你在生成向量前应该怎么做？（极高频|考察实操）

53.在使用Tessent或TetraMAX等EDA工具时，有没有遇到过工具自身的Bug？你是怎么向原

厂提Case并找Workaround的？（学员真题|考察抗压）

54.在处理多个时钟同频异相的情况下，Scanchain的连接和时序约束该怎么写才能避免出

错？（常问|重点准备）

55.当前Chiplet技术和2.5D/3D封装非常火热，这对DFT（特别是Die-to-Die互联测试）带来

了哪些新的挑战？（常问|需深度思考）

56.你有没有了解过StreamingFabric或者SSN（SiliconSynchronousNetwork）技术在超大

型SoCDFT测试中的应用？（网友分享|重点准备）

57.近两年AI在EDA工具（如AI驱动的ATPG或自动节点修复）中开始应用，你觉得这会取代

部分DFT工程师的工作吗？（常问|考察软实力）

58.面对未来车规级芯片（AutomotiveIC）苛刻的DPPM要求和ISO26262标准，DFT工程师

在LogicBIST上需要做哪些技术储备？（学员真题|需深度思考）

59.如果让你带几个新人做DFT，你会怎么给他们规划前三个月的技术成长路径？（常问|考

察软实力）

60.我问完了，你有什么想问我的吗？（考察软实力|考察抗压）

【芯片设计DFT工程师】高频面试题深度解答

Q1：画一下标准的JTAGTAPController状态机，并解释Shift-DR和Update-

DR阶段的具体动作。（基本必考|背诵即可）

❌不好的回答示例：

JTAG状态机大概有十六个状态，主要分为数据寄存器分支和指令寄存器分支。复位

状态是Test-Logic-Reset，然后进入选择DR或者选择IR。Shift-DR阶段就是把测

试数据串行移位进去，Update-DR阶段就是把移位进去的数据更新到对应的系统寄

存器里。平时工作中我们直接用EDA工具自动生成JTAG模块，很少去手动画这个

状态机，只要知道它是通过TMS信号在时钟沿触发跳转的就可以了，具体的细节我

记不太清了。

为什么这么回答不好：

1.基础薄弱：作为DFT工程师的基本功，未能准确说出状态跳转的关键边沿，会显得理论功

底不扎实。

2.细节缺失：对Shift-DR和Update-DR的解释过于宽泛，没有点出防止毛刺产生的双级寄存

器结构设计的核心目的。

3.态度问题：用“工具自动生成”作为借口掩饰知识盲区，给面试官留下浮于表面、缺乏底层

Debug能力的负面印象。

高分回答示例：

1.JTAGTAPController是一个16状态的有限状态机，受时钟TCK和模式选择TMS控制。正

常状态机复位在Test-Logic-Reset，空闲在Run-Test/Idle。核心分为DR分支（Select-DR-

Scan）和IR分支（Select-IR-Scan）。

2.当状态机进入Shift-DR阶段时，在TCK的每一个上升沿，TDI上的数据会被采样并移入当

前选定的数据寄存器（如边界扫描寄存器）的串行移位级。同时，移位寄存器中原有的最

末位数据会在TCK的下降沿从TDO移出。这是一个纯串行移位操作，通过多周期循环将

完整的测试向量打入链中。在实际项目调试机台断链问题时，确认Shift阶段时序是最关键

的第一步。

3.数据在Shift-DR阶段处于不断滑动的状态，会产生大量瞬态值。为了避免这些无效值干扰

芯片内部的正常逻辑运行，设计上采用了影子寄存器（ShadowRegister）结构。当状态

机TMS改变跳转进入Update-DR状态后，在TCK的下降沿，移位寄存器中已经准备好的稳

定数据会被并行锁存到更新寄存器（UpdateLatch）中，最终平稳地输出给系统并行逻

辑。深刻理解这一机制，使得我们在处理复杂芯片引脚控制和内部状态读取时，能够精准

定位时序和状态异常。

Q2：Stuck-atFault和TransitionFault有什么区别？在生成ATPGpattern时两

者有何不同要求？（极高频|重点准备）

❌不好的回答示例：

Stuck-atFault就是节点卡在0或者卡在1的故障，属于静态故障，跟时钟频率没啥

关系。TransitionFault是跳变故障，分为慢上升和慢下降，属于动态故障，主要是

测时序的。生成Pattern的时候，Stuck-at跑起来比较快，只要把状态打进去再抓出

来就行了。但是Transition比较麻烦，需要用到两个时钟脉冲，一个用来触发跳

变，另一个用来捕获跳变结果。具体工具怎么配置我也说不太清楚，反正是要设置

不同的faultmodel让工具自己去跑。

为什么这么回答不好：

1.描述肤浅：仅停留在字面概念的解释，未能深入到物理缺陷层面去剖析两种故障模型的本

质差异。

2.缺乏实操细节：对于ATPG生成要求，没有提及Launch和Capture的关键时序关系，也未

提到时钟控制的复杂性。

3.表现被动：将复杂性推给“工具自己去跑”，缺乏对后端流程控制和Pattern覆盖率优化的主

动思考。

高分回答示例：

1.Stuck-atFault（固定故障）模拟的是芯片制造过程中的短路或断路缺陷，如节点硬连到

VDD（SA1）或GND（SA0）。这是一种静态模型，测试时只需将预设激励通过Scan

Chain移入（Shift），给一个Capture时钟，再移出（Shift-out）比对即可。而Transition

Fault（跳变故障）模拟的是因局部阻抗变大引起的延时缺陷（Slow-to-Rise/Slow-to-

Fall）。它是动态模型，必须在芯片的真实工作频率（At-speed）下进行测试验证。

2.在ATPGPattern生成时，两者的策略有本质区别。Stuck-at通常使用单脉冲测试，对时钟

频率无严格要求，测试仪可以低速运行。而TransitionFault的生成需要严格的双脉冲序

列：首先需要一个Launch动作激活跳变，紧接着在一个系统周期后给出一个Capture时钟

捕获跳变后的结果。为了达到真实频率，通常需要结合芯片内部的PLL和OCC（On-Chip

ClockController）来产生高速的Burst时钟脉冲。

3.在处理千万级门规模的项目时，过渡故障的覆盖率往往比固定故障难提升。我们在跑

TetraMAX或Tessent时，针对TransitionFault，会特别关注时序例外（FalsePath/Multi-

cyclePath）的SDC约束转化。如果不严格屏蔽这些异步或多周期路径，虽然Pattern能生

成，但在ATE机台上实测时会导致大面积的误杀（FalseFailure），从而严重影响芯片良

率。因此，精准清洗时序约束是生成高质量跳变测试向量的前提。

Q3：解释一下ScanChain中的LockupLatch的作用，通常插在哪里？如果不

插会导致什么后果？（基本必考|需深度思考）

❌不好的回答示例：

LockupLatch主要是用来解决ScanChain里面的时序问题的。在一条很长的扫描

链里，如果跨越了不同的时钟域，或者时钟树综合的时候Skew比较大，数据移位的

时候就会出错。通常工具会自动把它插在两个不同时钟域的寄存器之间。如果不插

这个Latch，肯定会发生HoldTimeViolation，导致扫描链断掉，移位的数据全

错，最后ATPG测试就完全做不了了。大概就是起到一个缓冲数据的作用。

为什么这么回答不好：

1.原理不清：没有准确指出LockupLatch是如何通过改变时钟沿来解决HoldTime问题的，

缺乏底层逻辑支撑。

2.位置描述模糊：仅仅说“跨时钟域”是不够准确的，同频同相但Skew较大的同一时钟域模

块间同样需要。

3.缺乏工程视角：完全依赖工具自动插入，没有展示出人工检查、约束和Debug这类时序违

例问题的工程经验。

高分回答示例：

1.在大规模SoC的ScanShift阶段，所有寄存器串联成链，前一级的Q端直连后一级的SI

端。如果发送端（Launch）和接收端（Capture）的时钟树由于物理距离远产生极大的

ClockSkew，且接收端时钟早于发送端时钟到达，就会引发严重的HoldTimeViolation。

LockupLatch正是为了从架构层面消除这种移位过程中的保持时间风险而存在的。

2.其核心原理是利用半个时钟周期的相位差进行时序宽限。通常我们使用低电平透明的

Latch。它被串接在发送端触发器（上升沿触发）之后、接收端触发器（上升沿触发）之

前。当时钟为高时，发送端输出新数据，但Latch关闭，保持旧数据给接收端；当时钟变

为低时，Latch打开透传新数据，此时接收端已完成采样。这样人为引入了半个周期的

Holdmargin，极大缓解了后端CTS（时钟树综合）的压力。

3.在具体的物理实现中，LockupLatch通常插在跨时钟域的边界处，或者同一个时钟域但跨

越较大物理Block（如Top到Sub-block）的交界点。在过去的项目流片经验中，如果在网

表缝合阶段漏插了跨层次的LockupLatch，会导致后端在Scanmode下报出上千条难以

修复的Hold违例。为了确保万无一失，我们会在DFT综合后跑一遍专门的DRC规则检

查，并在网表交付前进行零延迟的Gate-LevelSimulation，确保Shift操作的绝对稳定。

Q4：什么是OCC（On-ChipClockController）？为什么做At-speedtest时

必须用到它？（极高频|重点准备）

❌不好的回答示例：

OCC就是片上时钟控制器。做测试的时候，芯片外部测试机台的时钟频率比较低，

没办法达到芯片内部真实的工作频率。所以我们需要在芯片里面放一个OCC模块。

在Shift阶段，OCC把低速时钟选进去让数据慢慢移位；到了Capture阶段，OCC

就把内部PLL产生的高速时钟切过来，打两下脉冲去测试Transition故障。反正就

是个用来切时钟的MUX逻辑，必须得有它才能做At-speed测试，不然没法测真实

速度。

为什么这么回答不好：

1.结构认知扁平：将复杂的OCC简单等同于一个MUX，忽略了其内部的移位寄存器控制

链、同步逻辑和脉冲截取电路。

2.时序风险未提：没有提到低速与高速时钟切换时可能产生的Glitch（毛刺）问题以及OCC

是如何避免它的。

3.缺乏场景深度：未说明在多时钟域下多个OCC之间如何协同工作以避免测试时的时序冲

突。

高分回答示例：

1.OCC（On-ChipClockController）是实现芯片实速测试（At-speedTest）的核心基础

IP。由于ATE（自动测试设备）机台受限于通道带宽和探针引脚电容，通常只能提供

10MHz~50MHz的低速测试时钟。而现代SoC内部运行频率往往高达几GHz。OCC的作用

就是桥接这两种时钟环境，实现低速移位和全速捕获。

2.在具体机制上，OCC不仅包含时钟选择MUX，更核心的是其无毛刺切换（Glitch-free）逻

辑和精密的脉冲门控网络。在ScanShift模式下，OCC透传外部低速ATE时钟，完成测试

向量的串行灌入；当进入Capture阶段，OCC通过内部由测试向量控制的移位寄存器链

（通常称为ClockChain），精准截取内部PLL输出的2到3个高速时钟脉冲（Launch和

Capture脉冲），作用于内部逻辑以检测Transition或PathDelay故障。

3.在实际项目落地时，插入OCC是一项极具挑战的任务。我们需要对系统时钟树进行细致

的梳理，不仅要保证OCC在测试模式下的控制信号同步，还要确保插入OCC后不会对芯

片Normal模式的功能时序造成惩罚。面对包含数十个异构时钟域的复杂芯片，我们会严

格规划OCC的分布，通过设置ClockGrouping和排他性约束，防止不同频率的OCC在

Capture瞬间互相干扰导致总线冲突或假性错误，从而保证ATPG覆盖率和良率。

Q5：详细说明TestCompression（测试压缩）的基本原理，EDT（XOR树）

是如何处理Unknown(X)态的？（常问|需深度思考）

❌不好的回答示例：

测试压缩就是因为芯片越来越大，测试向量太多机台存不下，所以要压缩。原理就

是在扫描链前面加个解压器，后面加个压缩器。解压器把机台少量的引脚数据变成

很多条内部短链的数据，压缩器再把内部数据压回少量引脚。至于EDT怎么处理X

态，应该是用XOR树或者什么逻辑把它屏蔽掉吧，如果X态传到压缩器里可能会污

染整个测试结果，具体工具内部怎么算的我没有深入研究过，主要就是用命令配置

一下压缩比。

为什么这么回答不好：

1.原理含糊：未能准确指出解压利用的是测试向量中的“无关项（Don'tCares）”这一核心数

学依据。

2.痛点解析不足：对X态（未知态）的危害理解不深，没有说清楚X态为什么会破坏XOR树

的签名。

3.缺乏对策：未能回答出EDT技术中经典的X-Masking（X屏蔽）机制，错失了展示底层技

术理解的加分项。

高分回答示例：

1.随着芯片规模向百亿级晶体管迈进，传统的Scan测试会导致测试数据量和测试时间呈指

数级爆炸，远远超出ATE机台的内存限制。TestCompression技术应运而生，其核心数学

原理是：在生成的ATPG测试向量中，真正用于激活和观测特定故障的有效位（Care

Bits）往往只占极小比例（1%~5%），剩下的大量位都是无关项（Don'tCares）。解压

器（Decompressor，如PRPG）利用这一特性，通过连续向内部数量庞大的短扫描链广

播展开数据；而压缩器（Compactor，通常是MISR或XOR树）则将多条短链的响应进行

空间压缩输出。

2.在压缩架构中，最致命的威胁就是UnknownState（X态，如未初始化的RAM或跨时钟域

信号未同步）。因为压缩器主要是由XOR（异或门）网络构成，XOR的特性决定了只要

输入端有一个X态，输出必然是X。这意味着一个X态就会污染与其异或的所有正常响应

信号，导致整个测试周期的故障观测性（Observability）大幅降低，覆盖率骤降。

3.为了解决这一痛点，EDT（EmbeddedDeterministicTest）引入了精密的X-Masking（X

态屏蔽）机制。在生成Pattern时，如果ATPG引擎预判某条内部ScanChain在特定周期会

移出X态，它会通过解压网络专门下发一组Masking控制信号。这组信号会在X态进入

XOR压缩树之前，利用AND门或专属的Mask逻辑强制将其屏蔽（置0），从而保护其他

并行扫描链上的有效测试响应不受污染。在项目调优时，我们会高度关注DRC报出的X

源，优先从RTL代码或测试点插入层面根除X态，把X-Masking作为最后一道防线。

Q6：BoundaryScan（边界扫描）中，EXTEST和INTEST指令的区别是什

么？（常问|背诵即可）

❌不好的回答示例：

边界扫描主要用于PCB板级测试。EXTEST和INTEST是JTAG里面两个不同的指

令。EXTEST是外部测试，主要是测芯片跟外部引脚连接的板子上的连线有没有断

开或者短路。INTEST是内部测试，就是通过边界扫描链去测试芯片内部的逻辑功

能。实际操作中EXTEST用得比较多，INTEST用得少，因为芯片内部一般都用普

通的Scan测试了，用边界扫描去测内部太慢了。只要记住一个是对外测，一个是对

内测就行了。

为什么这么回答不好：

1.数据流向不清：没有结合BoundaryScanCell（BSC）的具体数据流向来解释两种指令的

作用机制。

2.时序隔离未提：未说明在执行EXTEST时内部逻辑是如何被隔离保护的，以及INTEST时

外部引脚的隔离状态。

3.专业度不够：虽然通俗，但缺乏工程严谨性，未能体现出对1149.1标准底层架构的深刻

掌握。

高分回答示例：

1.在IEEE1149.1边界扫描标准中，EXTEST和INTEST是两条核心指令，分别用于解决芯片

外部（PCB级）和芯片内部的互连与逻辑测试问题。理解它们的区别，关键在于分析

BoundaryScanCell（BSC）在Update和Capture阶段的数据流向隔离机制。

2.EXTEST（外部测试）主要用于验证PCB板上芯片间的互连是否存在开路或桥接故障。执

行时，测试数据通过Shift-DR装载进BSC。在Update阶段，数据强制打到芯片输出管脚上

驱动外部网络；在Capture阶段，接收端芯片的BSC捕获其输入管脚上的电平。在此期

间，芯片内部的核心逻辑被完全隔离，系统状态处于安全挂起模式。

3.INTEST（内部测试）则是通过边界扫描引脚对芯片内部核心逻辑进行低速测试。执行

时，数据流向反转：Update阶段BSC将测试激励施加给内部核心逻辑的输入端；Capture

阶段BSC捕获内部核心逻辑产生的运算结果。同时，为了防止测试过程干扰外部系统，

输出引脚通常会被维持在高阻态或上一稳定状态。尽管现代芯片内部多采用高速ATPG测

试，但INTEST在某些不具备高速机台的低成本筛选场景，或裸片（BareDie）初步功能

验证阶段，依然发挥着不可替代的兜底作用。

Q7：MBIST（MemoryBIST）的常用算法有哪些？MarchC-算法是如何覆盖

大部分Memory故障的？（极高频|重点准备）

❌不好的回答示例：

MBIST是专门用来测SRAM的。常用算法有棋盘算法、全0全1读写，还有就是最经

典的March算法。MarchC-应该是用得最多的一种，它就是一遍一遍地对内存地

址进行正向和反向的读写操作。比如先全部写0，然后读0写1，再读1写0这样反复

走几遍。通过这种来回的读写跳变，就能把SRAM里面的短路、断路或者临近单元

的干扰故障都测出来。具体它是怎么一步步覆盖的，过程比较长，我大概只记得个

轮廓。

为什么这么回答不好：

1.算法描述不专业：用“来回读写跳变”等通俗词汇，未能准确描述March算法的“Element”步

骤和地址递增/递减顺序。

2.故障模型缺失：没有点出MarchC-能够精准覆盖的具体故障模型名称（如SAF、TF、

CFin、CFid等）。

3.缺乏深度解析：未能解释为什么需要正向和反向两次遍历，错失了展现对存储器物理结构

理解的机会。

高分回答示例：

1.MBIST主要用于检测片上SRAM/ROM的制造缺陷。除了早期的Checkerboard（棋盘格）

用于测漏电，当前工业界占绝对主导地位的是March系列算法，其中MarchC-是兼顾测

试覆盖率和测试时间（复杂度为10N，N为地址深度）的黄金标准。

2.MarchC-算法由6个核心步骤（Elements）组成，能够完美覆盖固定故障（Stuck-at

Fault）、转换故障（TransitionFault）、地址解码故障（AF）以及绝大部分的耦合故障

（CouplingFault）。其标准执行流程为：1)任意顺序写全0初始化；2)地址正向递增，

执行读0写1操作（触发并检测0->1跳变及相关耦合）；3)继续正向递增，执行读1写0

（覆盖1->0跳变）；4)地址反向递减，执行读0写1；5)继续反向递减，执行读1写0；6)

任意顺序读0结束验证。

3.其设计的精妙之处在于对耦合故障（CouplingFault）的严密覆盖。因为在SRAM的物理

排布中，干扰单元（Aggressor）可能位于受害单元（Victim）的物理高地址或低地址。

通过步骤2和3的正向遍历，我们覆盖了低地址干扰高地址的情况；紧接着利用步骤4和5

的反向递减遍历，则将高地址干扰低地址的漏网之鱼一网打尽。在实际项目中，针对先进

工艺（如5nm以下），我们还会在MarchC-的基础上叠加Retentiontest（保持测试）或

者Back-to-back读写，以筛选出细微的漏电或操作余量（Margin）不足的脆弱Cell。

Q8：什么是TransitionDelayFault的Launch-Off-Shift(LOS)和Launch-Off-

Capture(LOC)？现在工业界为什么多用LOC？（极高频|需深度思考）

❌不好的回答示例：

LOS和LOC都是测Transition延时故障的方法。LOS是最后一个Shift时钟顺便当做

Launch脉冲，然后立刻给一个Capture时钟。LOC是Shift完了之后，专门给两个

Capture时钟，第一个当Launch，第二个当Capture。现在工业界都用LOC，主要

是因为LOS的最后一个Shift和Capture靠得太近了，ScanEnable信号要在真实速

度下瞬间拉低，这个时序太难收敛了。后端的同事根本搞不定这个SE的高速布线，

所以大家都妥协用LOC了，虽然LOC生成的Pattern多一点。

为什么这么回答不好：

1.表达略显口语化：描述概念时缺乏学术严谨性，没有清晰说明两个脉冲在系统功能上的本

质区别。

2.视角单一局限：仅将原因归结于“后端同事搞不定”，没有从全芯片物理设计的功耗、面积

以及测试覆盖率的多维视角进行客观评估。

3.缺少架构级认知：没有提到LOC机制是如何与现今广泛采用的OCC（片上时钟控制器）

架构完美契合的。

高分回答示例：

1.在实速测试（At-speedTest）中，LOS（Launch-Off-Shift）和LOC（Launch-Off-Capture

/Broadside）是两种主流的向量施加策略。LOS机制下，跳变跃迁是由最后一次Scan

Shift操作触发的，紧接着相隔一个系统周期施加Capture脉冲；而LOC机制下，Shift阶段

完全结束后，系统保持静态，随后连续施加两个At-speed周期的时钟，第一个时钟作为

Launch激活跳变，第二个时钟执行Capture。

2.尽管LOS的ATPG算法相对简单，且能获得极高的覆盖率（因为它能打破原本功能逻辑的

约束生成向量），但目前工业界（特别是大型SoC）几乎清一色采用LOC策略，核心痛

点在于ScanEnable（SE）信号的物理实现极限。在LOS中，SE信号必须在一个高速系

统周期内完成从高电平（Shift态）到低电平（Capture态）的跳变并稳定到达全芯片百万

级寄存器，这要求构建一棵与时钟树规模相当的极高速SE树，带来不可承受的面积和功

耗开销。

3.相比之下，LOC策略完美规避了这一物理瓶颈。在LOC中，SE信号可以在低速移位结束

后从容地拉低，经过多个周期稳定后，再由内部OCC精准释放两个高速Capture时钟脉

冲。这种机制不仅对后端物理布局极其友好，而且由于Launch脉冲完全走的是系统的真

实功能路径（FunctionalPath），它能有效避免LOS可能引发的过度测试（Over-

testing）导致良率误杀。为了弥补LOC覆盖率略低的短板，我们通常会辅以额外的测试点

插入（TestpointInsertion）来优化内部节点的控制性和观测性。

Q9：解释一下BridgingFault和Cell-AwareFault模型，为什么在先进工艺

（如3nm/5nm）下越来越重视Cell-Aware？（常问|网友分享）

❌不好的回答示例：

BridgingFault就是桥接故障，指的是芯片里面两条挨得比较近的走线不小心短路

连在一起了，会导致信号互相干扰，比如线与或者线或逻辑。Cell-AwareFault是

最近比较火的概念，就是不仅仅看门与门之间的连线，还要深入到标准单元内部去

测里面的管子坏没坏。在先进工艺下，晶体管做得太小了，很多缺陷都在Cell内

部，传统的Stuck-at只能测外面，测不到里面，所以良率就不达标，必须得跑Cell-

Aware才能把那些隐藏的坏片挑出来。

为什么这么回答不好：

1.原理剖析不够深：对Bridging的解释尚可，但对Cell-Aware的解释流于表面，没有提到内

部模拟仿真到数字模型提取的关键流程。

2.缺乏数据和标准支撑：未能引用DPPM（每百万缺陷数）等汽车电子或高可靠性领域的严

苛标准来论证技术驱动力。

3.未提及代价与平衡：没有指出引入Cell-Aware后对ATPG运行时间、内存及Pattern数量的

巨大冲击及应对策略。

高分回答示例：

1.BridgingFault（桥接故障）模拟的是芯片物理版图中两条相邻的互连线因制造偏差发生

短路而产生的寄生逻辑（Wired-AND/Wired-OR）。它属于Inter-cell（单元间）缺陷。而

Cell-AwareFault（单元感知故障）则将测试粒度下沉到了标准单元内部（Intra-cell），针

对FinFET/GAA工艺中复杂的内部晶体管漏电、内部桥接或通孔（Via）开路等缺陷进行

精准建模。

2.随着半导体工艺迈入3nm/5nm节点，物理尺寸的极限微缩导致了一个严峻的客观事实：超

过一半以上的制造缺陷发生在了StandardCell内部，而非Cell之间的走线上。传统的

Stuck-at和Transition模型将Cell视为一个不可见的黑盒，仅在端口处施加约束，这会遗漏

大量内部微观缺陷。特别是在车载芯片（ISO26262）追求极低DPPM甚至0DPPM的严

苛要求下，传统模型带来的TestEscapes（漏测风险）是无法容忍的，这就是Cell-Aware

成为标配的核心驱动力。

3.在具体的工程实施中，引入Cell-Aware并非毫无代价。首先需要Foundry或第三方库提供

商预先运行大量的SPICE级模拟仿真，提取内部缺陷并生成包含复杂激励要求的UDSM库

文件。在ATPG生成阶段，工具需要满足这些特定组合序列才能激活内部缺陷，这会导致

内存消耗呈指数上升，Pattern体积急剧膨胀。因此，在实际流片时，我们会采用分级覆

盖策略：先跑基础模型拿到99%的底座覆盖率，然后再开启Cell-AwareTop-off模式去捕

捉那最后0.5%的致命内部缺陷，从而在测试时间和测试质量之间取得最优平衡。

Q10：在你最近的一个流片项目中，DFT的总体架构是怎么设计的？为什么这样

选型？（基本必考|考察实操）

❌不好的回答示例：

最近的项目是个多核的芯片。DFT架构主要就是常规的那套东西：用Tessent工具

插了ScanChain，为了压缩测试时间加了EDT。里面有几十块SRAM，就按工具

默认的配置挂了MBIST。时钟控制器OCC也是工具自动插的。引脚复位主要是用

JTAG，按照1149.1标准搭的TAPController。选型的原因主要是因为大家都这么

做，工具流程很成熟，出问题的概率比较小，我们只要照着公司的标准脚本跑就行

了，稍微改改端口匹配。

为什么这么回答不好：

1.千篇一律，毫无亮点：描述过于套路化，像流水账，没有体现出“该特定项目”的复杂性和

针对性设计。

2.缺乏架构级思考：一句“大家都这么做”直接否定了自己在架构选型中的主观能动性和技术

评估能力。

3.忽略约束与折中：真实的架构设计一定包含着面积、引脚、测试时间等物理资源的博弈，

回答中完全没有体现这一点。

高分回答示例：

1.在我最近主导的一个7nmAI加速器芯片项目中，面积和测试时间的矛盾极为突出。该芯

片包含极高密度的SRAM集群以及复杂的异步时钟网络，外部可用测试引脚被严苛压缩到

了仅剩6个。基于这种极端的物理约束，我摒弃了传统的扁平化设计，主导制定了一套自

顶向下的HierarchicalDFT（分层DFT）混合架构。

2.在逻辑测试层面，为了应对庞大的逻辑门数量，我们引入了带多路复用的Test

Compression技术，配置了100倍的高压缩比EDT网络。针对6个可用引脚，我们设计了

动态复用逻辑，通过JTAG指令实时切换引脚状态，分时复用Scanin/out与MBIST的诊断

接口。在存储测试层面，针对超过2000块零散分布的SRAM，我摒弃了全局总线架构，

改为采用Shared-Bus与Ring网络结合的分布式MBIST架构。通过将相邻SRAM物理聚合并

进行精细的并行度调度（Scheduling），成功避免了全开测试时的IRDrop越界风险。

3.这种架构选型的核心价值在于最优的资源平衡。它不仅将庞大的顶层网表ATPG运行时间

从数天缩短至几个小时，大幅提升了迭代效率；更关键的是，通过严格的功耗隔离设计和

分布式的OCC管控，我们确保了实速测试时芯片峰值功耗被严格控制在封装允许的TDP

范围之内，最终一次性实现硅后点亮，机台实测良率达到了预期指标。

Q11：介绍一下你在项目中是如何处理多时钟域（Multi-ClockDomain）的

ScanChain插入的？（极高频|考察实操）

❌不好的回答示例：

遇到多个时钟域的时候，最简单的办法就是把所有的时钟都强行连到一个统一的测

试时钟上去，但是这样会破坏原来的时钟树。所以一般是让工具按照时钟域来分

Chain。一个时钟域分配几条扫描链，互不干扰。如果有的时钟域寄存器太少不够

凑成一条链，就把它跟别的链拼在一起，中间插上LockupLatch防止时序出问题。

具体怎么连工具里的命令配一下Clockdomainmix就行了，剩下的工具会自动搞

定。

为什么这么回答不好：

1.颗粒度粗糙：只提到了工具的Mix命令，没有讲清楚在拼接不同频率或不同相位的时钟域

时的核心工程痛点。

2.策略缺乏灵活性：没有考虑到全芯片平衡ScanChain长度以缩短整体测试时间的全局优

化意识。

3.忽视后端实现风险：没有提及多时钟域混合时可能导致的时钟树网络极度拥堵和功耗问

题。

高分回答示例：

1.在大型SoC项目中，动辄几十个独立时钟域的交织是DFT面临的常态。在处理Multi-Clock

Domain的ScanChain规划时，我的核心策略是“隔离优先，平衡为辅，时序绝对安全”。

盲目混合所有时钟域会给后端的CTS（时钟树综合）带来毁灭性灾难。

2.在具体实施上，首先我会对所有时钟域进行容量评估。对于门数量巨大的主频时钟域（如

CPU核或GPU总线），我会严格采取Intra-Clock（域内闭环）策略，为其独立分配多条并

行的ScanChain，坚决不允许跨域串扰。而对于数量众多但体量极小（如几十个触发

器）的低速外设时钟域或RTC域，单独拉链会导致严重的引脚和通道浪费。针对这部分，

我会采用Inter-Clock（跨域级联）混合策略，将它们拼接成几条长链。在级联的关键物理

节点，我不仅会强制工具插入下降沿触发的LockupLatch以保证半周期的HoldMargin，

还会刻意将时钟频率相近或物理位置（Floorplan）相邻的域组合在一起，最大程度减少

跨区域走线。

3.这种精细化管控的价值在硅后测试中得到了验证。通过严格约束时钟域混合，我们在提供

高度均衡的链长（最大程度压缩了整体Shift时间）的同时，使得后端CTS在Scan模式下

的时序收敛时间缩短了30%，且在实际机台实测中，彻底杜绝了因多时钟域Skew飘移引

发的断链危机。

Q12：如果你的设计中包含了大量的SRAM，你是如何规划MBIST的分组

（Grouping）和调度（Scheduling）来平衡测试时间和功耗的？（重点准备|

考察实操）

❌不好的回答示例：

SRAM太多的话，肯定不能所有的Memory一起跑MBIST测试，那样芯片功耗会爆

掉，电源可能都被拉垮。所以要给它们分组。分组一般就是按照物理位置，把挨得

近的几个SRAM分给同一个BISTController去管。调度的意思就是让它们排队测，

比如先测组A，测完了再测组B，也就是串行测试。虽然这样测试时间会变长，但是

比较安全。有时候为了省点时间，也会挑几个功耗小的组同时并行跑一下，这就靠

感觉调了。

为什么这么回答不好：

1.标准主观随意：“靠感觉调”是非常不专业的说法，缺乏科学评估功耗阈值和测试周期的量

化依据。

2.调度维度单一：仅仅提到了串行和并行，没有深入到Pipeline（流水线）交织调度这种高

级的优化技术。

3.未考虑物理约束：只提物理位置，忽略了不同电源域、不同时钟域以及布线拥堵

（RoutingCongestion）对BISTController分配的决定性影响。

高分回答示例：

1.面对包含数千个SRAM实例的超大规模SoC，MBIST规划是一场关于面积、测试时间与热

功耗（ThermalTDP）的极限博弈。我的规划逻辑建立在精准的物理反馈与量化分析之

上。

2.在Grouping（分组）阶段，不仅要考虑物理分布（Floorplan），还要严格遵守电源域和

时钟域的刚性边界。为了降低控制器面积和布线拥塞，我会将同频率、同电源域且物理相

邻的SRAM挂载到同一个Shared-BusController下。同时，针对关键路径上的高速Cache

SRAM，为了避免MBIST复用逻辑带来过大的时序惩罚（TimingPenalty），我会为其单

独配置专用Controller甚至采用Fast-BIST直连方案。

3.在Scheduling（调度）阶段，核心挑战是如何在IRDrop安全阈值内压榨出最短的测试时

间。我会协同前端功耗分析团队，获取各个SRAM集群全速读写时的峰值功耗特征。据

此，构建一张二维并行度矩阵：将功耗互补的Block配置为并行执行（Parallel），而将总

功耗可能越界的超大Block强制约束为串行执行（Sequential）。更进一步，在高级流片

中，我会引入Token-based（基于令牌）的动态流水线调度策略，让不同Controller在时间

轴上错位激活，实现功耗波峰的智能削平。这种精细调度使我们在上一个项目中，在确保

零动态压降失效的前提下，将整体存储测试时间硬生生压缩了40%。

Q13：针对项目中包含多种电源域（Multi-PowerDomain）的IP，DFT设计在

隔离单元（IsolationCell）和电平转换器（LevelShifter）处需要做哪些特殊

处理？（常问|需深度思考）

❌不好的回答示例：

现在很多芯片都有好几个电源域，比如CPU一个电压，外设一个电压，有的还能关

断。DFT在处理这些的时候挺麻烦的。扫描链要是穿过不同电压域，就必须加Level

Shifter把电压转平，不然识别不了电平。如果穿过可以关断的电源域，那就得注意

了，测试的时候千万不能把电源关了，不然链就断了。对于隔离单元Isolation

Cell，我们一般就是把它当成普通的逻辑门一样，用工具默认设置跑生成向量就

行，只要能连通就行。

为什么这么回答不好：

1.风险认知致命：说“测试的时候千万不能把电源关了”暴露了对低功耗测试（LowPower

Test）中不同PowerMode覆盖率要求的无知。

2.缺乏控制策略：没有说明在ScanShift和Capture阶段，DFT控制逻辑应该如何介入并强制

接管IsolationCell的使能信号。

3.边界处理模糊：未提及UPF（UnifiedPowerFormat）文件在DFT流程中的导入和跨域约

束验证。

高分回答示例：

1.在引入动态电压频率调节（DVFS）和电源门控（PowerGating）的先进SoC中，电源域

的交界处是DFT最容易踩坑的深水区。若不加特殊干预，IsolationCell（隔离单元）和

LevelShifter（电平转换器）会阻断ScanChain，并在低功耗模式测试时引发灾难性的X

态传播。

2.我的核心处理原则是“全场景的确定性控制”。针对IsolationCell，其功能逻辑是在电源关

断时输出稳定的0或1。在DFT的ScanShift阶段，必须通过顶层的TestMode信号强制将

其打开（Bypass），确保测试数据能穿透不同的电源域畅通无阻；而在Capture阶段，如

果是为了验证电源关断逻辑的正确性（Power-AwareTest），则必须允许UPF控制信号

重新接管IsolationCell，并精准预测由此产生的X态边界，利用工具配置X-Masking屏蔽掉

被关断域传出的无效响应。

3.针对LevelShifter，最大的挑战在于其不对称的时序延时。当跨越悬殊的电压差（例如从

0.6V域传导到1.2V域）时，在低速移位时可能没问题，但在At-speed高速捕获时极易引

发Setup违例。因此，在物理链网连线时，我会尽量避免让同一条ScanChain频繁横跳于

不同电源域之间；对于不可避免的跨域，我会强制在其前后紧贴放置LockupLatch或流水

线寄存器。结合后端导入的完整UPF文件做前置DRC检查，这一系列操作确保了我们在

各个Low-Power模式下都能实现无死角的故障覆盖。

Q14：详细讲讲你是如何做HierarchicalDFT（分层DFT）的？Top层和Block

层的数据和控制信号是如何对接的？（极高频|考察实操）

❌不好的回答示例：

分层DFT主要是针对大芯片做的，因为直接在Top层做的话EDA工具跑不动。做法

就是先把大的模块（Block）单独拿出来，在里面把扫描链、MBIST什么的都插

好，把Pattern也生成出来。然后在Top层，再做一些剩下的胶水逻辑的DFT。对接

的话，就是把Block底层的接口通过Wrapper引到Top层，然后在Top层分配几个物

理引脚跟它们连起来。相当于搭积木一样拼在一起，最后在顶层验证一下连通性就

可以了。

为什么这么回答不好：

1.细节严重缺失：完全没有提到分层DFT最核心的技术机制——WrapperChain（如Core

Wrapper）的边界隔离作用。

2.控制对接模糊：对于时钟、复位、测试模式控制信号（如TestMode）等全局关键信号如

何在上下层分配未做说明。

3.未体现并行优势：没有讲明采用分层DFT为团队协作（Shift-left）带来的并行开发效率提

升。

高分回答示例：

1.面对包含数千万等效门的设计，传统的Flat扁平化流程会导致内存溢出和极其漫长的迭代

周期。HierarchicalDFT（自底向上分层DFT）是我们突破这一瓶颈的利器。它的核心理

念不仅是“化整为零”，更是通过标准化的边界隔离实现“即插即用”。

2.在Block级别的操作中，我会在网表周边全面插入WrapperCell构建CoreWrapper链（如

遵循IEEE1500标准）。这一步至关重要，它就像给Block穿上了一层防弹衣，在进行内

部测试（INTEST）时能完全隔离外部干扰。Block内部完成自己的EDT压缩链和MBIST插

入，并生成独立的灰盒（Gray-box）或黑盒模型（TestModel）及测试向量。

3.在Top层对接时，考验的是资源调配的统筹能力。数据流层面，通过顶层的MUX网络将各

个Block的ScanIn/Out动态映射到有限的芯片物理引脚上；控制流层面，通过顶层的

IJTAG网络（IEEE1687）统一广播TestMode、时钟和复位等全局设置，精准选通特定

Block的Wrapper指令。这种分层架构彻底解耦了设计依赖，使得我们能够让多个子模块

的DFT验证在RTL阶段就提前并行启动（Shift-left）。在某次紧急流片中，即使有个别

Block的网表频繁ECO修改，由于外层Wrapper未动，Top层无需重跑，为整个项目抢回了

至少两周的宝贵收敛时间。

Q15：在以往的项目里，你遇到过最难的测试覆盖率（Coverage）提升瓶颈是

什么？你是如何突破的？（基本必考|反复验证）

❌不好的回答示例：

我遇到过最难的一次是有一个多媒体模块，覆盖率跑到88%就怎么也上不去了。目

标要求是至少98%。当时找了很久原因，发现里面有很多第三方买来的IP，代码是

加密的，工具看不透里面，还有很多RAM外围没有加Bypass逻辑，导致信号传不

过去。突破的方法其实也比较暴力，就是跟前端设计的人去吵架，让他们把那些黑

盒IP都加上测试点，然后RAM加上Bypass。他们改了代码之后，我再跑一遍，覆

盖率就蹭蹭上去了，没用什么特别复杂的命令。

为什么这么回答不好：

1.甩锅思维严重：把解决问题的核心归结于“找前端吵架修改”，这展现了极差的跨部门沟通

意识和软技能。

2.缺乏自身技术纵深：对于黑盒IP，DFT工程师应该有TestModel处理方案，而不是只会要

明文代码或强加测试点。

3.方案过于粗糙：RAMBypass虽然有效，但没有提到更高级的方案如MacroTest或

MemoryShadowing，显得手段单一。

高分回答示例：

1.在我负责过的一款高可靠性工控芯片中，TransitionFault的覆盖率卡在92%达到了死胡

同，距离车规级要求的98%相去甚远。经过仔细审视ATPG的冗长Log，我定位到两个核

心瓶颈：一是存在深层嵌套的算术逻辑单元中生成了大量无用的X态；二是部分高速接口

模块中充斥着复杂的组合逻辑环（CombinationalLoops）和不可测的异步多时钟路径。

2.为了突破这一僵局，我没有简单地要求前端重写代码，而是采用“软硬兼施”的策略分层剥

离问题。在“软”的层面，针对复杂的组合环，我深入研究了工具的DRC报告，通过编写精

细的Tcl脚本，在ATPG约束中手动指定关键节点的Cut-point（切断点），在不影响实际逻

辑推导的前提下强行阻断了环路报错；对于跨时钟域路径，利用假路径（FalsePath）清

洗掉大量无效的测试冗余。在“硬”的层面，针对X态传播重灾区，我利用工具自带的

TestabilityAnalysis机制，精确评估了观测度最弱的Top50个节点，精准插入了极少量的

ObservationTestpoints（观测测试点），将面积开销控制在千分之一以内。

3.同时，针对部分模拟黑盒IP导致的阴影区，我为其周边手工构建了详尽的TestWrapper边

界模型，成功找回了周围几万个数字门的能见度。通过这套组合拳，我们没有对前端原本

干净的架构做任何大手术，仅用两周时间，硬是将过渡覆盖率拉升到了98.3%，平稳跨过

了量产审核的红线，这让我深刻体会到精准诊断比盲目增加测试逻辑更重要。

Q16：你们项目的Scanchainlength一般设置多长？这个长度是基于哪些维度

（如测试仪器的通道、测试时间等）评估出来的？（常问|考察实操）

❌不好的回答示例：

链长一般就设置个一两百个寄存器吧，有时候也设置三百个，主要看芯片大小。如

果芯片比较大，寄存器多，那链就得长一点。评估维度的话，最重要的肯定是测试

时间了，链越长，数据移位进去花的时间就越多。机台通道也有关系，机台能接几

根线，我们就分几条链。一般工具都会有个默认的长度建议，我们就照着那个值填

进去，如果最后时间算出来超时了，大不了再把压缩比调高一点就行了。

为什么这么回答不好：

1.缺乏精确的量化思维：回答的数值（100-300）对于现代引入EDT压缩技术的大型SoC来

说通常是严重偏离实际的。

2.推导逻辑倒置：应该是由机台能力和测试时间倒推链长，而不是“链长了就去调高压缩

比”这种马后炮操作。

3.维度的片面性：只谈了时间和通道，遗漏了最重要的制约因素之一——ScanShift期间巨

大的动态功耗可能烧毁芯片。

高分回答示例：

1.确定ScanChain的长度并不是拍脑袋的经验值，而是一个需严格求解的多元方程的最优

解。在现代采用了EDT压缩架构的项目中，内部短链（InternalChain）的长度通常规划在

100到400个触发器之间，而外部机台看到的等效长链长度则往往达到数万甚至更高。这

个数值的制定基于三个铁性维度的严格评估。

2.第一维度是“机台通道数与封装引脚限制”。假设目标ATE机台分配给我们16个Scan

Channels，在总触发器数量确定的情况下，通道数直接框定了外部链条的数量下限，进

而反向约束了压缩器的比例规划。第二维度是“绝对测试时间成本（TestCost）”。我们会

根据量产部门给出的每秒测试成本指标，设定一个总的Pattern移位周期上限。内部链越

短，每次Shift所需周期越少，但如果链划分得极短，就需要极高的EDT压缩比，这会带来

严重的布线拥塞。

3.第三维度，也是最容易导致流片翻车的维度——“Shift期间的热功耗（IRDrop）”。当所有

寄存器同时进行高频状态翻转时，瞬态电流是正常运行时的几倍。如果单链极长或者并行

链过多，供电网络会瞬间崩塌。因此，我们在前期会提取后端的功耗网格分析

（Redhawk等工具）报告，计算出安全翻转率阈值。在一次千万级门规模的项目中，正

是基于精准的功耗摸底，我们放弃了追求极限短链（200位），折中选定在350位的安全

长度，完美规避了机台上因掉电导致的良率灾难。

Q17：讲一个你在项目中做TestPowerReduction（降低测试功耗）的具体案

例，采用了哪些技术？（常问|需深度思考）

❌不好的回答示例：

做测试的时候因为所有的触发器都在同时翻转，功耗会非常大。为了降低功耗，最

常用的方法就是在跑生成Pattern的工具里加一条限制功耗的命令，比如把翻转率限

制在20%以内，这样工具自己生成的0和1就不会跳变得那么厉害了。还有就是机台

测试的时候，让外面的时钟频率跑得慢一点，把时间拉长，功耗自然就降下来了。

这主要是为了防止芯片在测试的时候温度过高被烧坏，一般就这两招。

为什么这么回答不好：

1.措施极为低级：仅仅依赖于降频（这会影响At-speed测试真实性）和工具命令，没有体现

出任何架构级别的功耗控制策略。

2.牺牲测试质量：单纯限制Pattern翻转率通常会导致Pattern体积暴增和覆盖率下降，没有

提到这其中的折中与处理。

3.缺乏实战说服力：没有具体案例的支撑，听起来像是背诵课本上的基础概念，缺乏资深工

程师的实操厚度。

高分回答示例：

1.测试功耗往往是决定大规模芯片能否顺利通过量产测试的生死线。在我经历的一个5G基

带芯片项目中，由于采用了极其密集的数字信号处理阵列，首次ATPG仿真显示Scan

Shift阶段的峰值功耗达到了系统正常模式的3.5倍，后端电源网络根本无法承受，必须进

行深度的TestPowerReduction。

2.为此，我主导实施了一套多层级的功耗抑制架构。首先在硬件架构层面，我引入了基于

Block的动态时钟门控（ClockGating）控制策略。在测试模式下，我没有粗暴地全开时

钟，而是结合内部的测试使能网络，在Shift阶段强制锁死无关功能模块的ClockGating，

确保只有数据正在流动的链路发生翻转。其次，针对占大头的Capture功耗，我在测试控

制器中设计了交错发射（StaggeredFiring）逻辑，让同一电源域下不同OCC释放

Capture高速脉冲的时间强制错开半个纳秒，瞬间将峰值电流波峰削平了30%。

3.在软件Pattern生成层面，我并没有简单地全局限制翻转率（这会导致Pattern数激增），

而是开启了Low-PowerATPG的高级特性（如AdjacentFill机制）。对于测试向量中的无

关项（Don'tCares），工具不再采用常规的随机填充，而是智能复制相邻的有效位，从

而在物理链路上最大限度维持电平平稳。这套软硬结合的综合方案，不仅让最终的实测峰

值功耗牢牢控制在了安全余量之内，更令人惊喜的是，Pattern数量仅仅增加了不到8%，

堪称一次完美的功耗收敛战。

Q18：如果设计中有很多异步复位信号，在Scan模式下你是怎么处理它们的以

避免时序违例的？（极高频|考察实操）

❌不好的回答示例：

异步复位信号在做扫描测试的时候很讨厌，因为它随时可能让寄存器清零。所以在

进Scan模式之前，我们必须把它们处理掉。最普遍的做法就是用一个MUX。把异

步复位的引脚和测试模式的使能信号接进去。只要TestMode拉高，进入了测试状

态，就强制把异步复位信号给拉高或者拉低屏蔽掉，不让它起作用。这样寄存器在

移位的时候就不会被乱复位了。等测试完了，回到正常模式，再把它切回原来的异

步控制就行了。

为什么这么回答不好：

1.毁坏了故障覆盖面：粗暴地在整个测试期间强行屏蔽异步复位，意味着这些复位引脚及其

内部树状逻辑的故障（Stuck-at）将完全无法被观测和测试。

2.没有区分Shift和Capture：未说明在Shift防干扰与在Capture激活复位逻辑之间的精细时序

切换需求。

3.缺乏DRC排错经验：没提到工具是如何报复位规则错误（如C3/C4违例）以及如何从根

本上化解的。

高分回答示例：

1.异步复位/置位（AsynchronousReset/Set）信号如果不加约束，在ATPG生成和测试时就

像一颗定时炸弹。如果移位（Shift）期间复位信号随机翻转，会导致扫描链断裂；但如果

在整个测试期间将其死死屏蔽，又会造成大量涉及复位逻辑的TestEscapes（漏测），降

低整体覆盖率。

2.对待这些不受控信号，我的核心策略是“Shift屏蔽，Capture放开”。在架构植入阶段，我

们会利用TestMode（测试模式）和ScanEnable（扫描使能）两个信号构建可控逻辑

（通常使用MUX或特定的控制门）。当ScanEnable为高（处于Shift阶段）时，强制将异

步复位端固定在无效电平（如高电平），确保测试数据能像平稳的水流一样毫无阻碍地灌

入所有寄存器。

3.关键的精细操作发生在Capture阶段。当ScanEnable拉低准备捕获时，我们将复位控制

权交还给由顶层测试仪引脚直接控制的信号，或者由特定触发器构成的控制链。这样，

ATPG引擎就可以在生成Pattern时，通过有意识地控制这些引脚，专门在某几个特定周期

施加复位脉冲，以此来检测复位树本身的跳变与固定故障。在实际调试中，我会重点关注

工具报出的C级（如C4：复位信号不能由移位后的触发器稳定控制）DRC错误，通过彻

底肃清这些违例，我们不仅保证了移位的绝对安全，还额外找回了大约1.5%的边缘控制

逻辑覆盖率。

Q19：你们的芯片中有用到MemoryRepair技术吗？硬修复（HardRepair）

和软修复（SoftRepair）在流程上有什么区别？（常问|重点准备）

❌不好的回答示例：

用过MemoryRepair。因为现在芯片里的SRAM很大，生产的时候难免有坏的，不

修的话这颗芯片就只能扔了，太浪费钱。硬修复就是用激光去烧断芯片里面备用的

保险丝（eFuse），把坏的地址永久替换掉，这个是在机台上直接操作的。软修复

就是不用激光烧，每次芯片上电的时候，跑一遍BIST，把查出来的坏地址动态写到

寄存器里去屏蔽掉。软修比较麻烦，每次开机都要花时间重新算，硬修搞定了一劳

永逸，我们项目里两种都用过。

为什么这么回答不好：

1.概念混淆模糊：将硬修复局限于物理“激光烧录”，忽略了现代广泛使用的电可编程eFuse

（无需外部激光介入）的技术演进。

2.缺失上下游联动：没有讲清楚修复信息（RepairSignature）在BIST提取、机台计算、再

到烧录的完整数据闭环流程。

3.软修复理解不深：认为软修复只是每次上电重算，没有提到在先进封装（如Chiplet）或

车载动态监测中的关键自适应价值。

高分回答示例：

1.在高阶SoC（特别是含有百兆级LLCCache的芯片）中，MemoryRepair（内建自修复

BISR）是挽救良率的生命线。不论是硬修复还是软修复，其核心思想都是通过内部预留

的冗余列（RedundantColumns）或冗余行来替换检测出的缺陷单元，但两者在干预时机

和数据固化途径