前言——芯片由MPW试产进入量产阶段的时候，DFT可测性设计是前后端设计者都无法绕过的必修课。DFT的设计，既属于芯片功能设计的范畴，又对后端的设计流程有显性的影响。
前端设计者需要理解：
DFT可测性设计都做些什么？
是如何实现存储器、IO和逻辑的测试的？
DFT系统是如何搭建的？
DFT的IP如何与我的RTL设计配合？
后端设计者则需要理解：
DFT的IP对面积和时序有怎样的影响？
DFT mode的时钟树如何搭建，时序如何收敛？
这个系列旨在：
介绍DFT方面的基础知识和重要概念，帮助建立对DFT测试的初步印象；
主要面向前端设计介绍DFT对RTL设计的前置需求，让前端设计者更容易写出一步到位的DFT ready的RTL代码，减少因DFT测试需求不能满足而重复迭代修改的工作量；
MBIST存储器内建自测试
1. MBIST的含义与目的
MBIST是Memory Build-In-Self Test的简称，意为存储器内建自测试。“内建”的含义是指针对存储器的测试向量不是由外部测试机台（ATE：Auto-Test-Equipment）生成，而是由内建的存储器测试逻辑自动产生，并进行结果的对比。MBIST测试中，只需要从机台通过JTAG标准接口下达测试的指令，就可以从TDO接口获取测试结果。
为什么要进行内建自测试呢？原因主要有：
a）存储器在很小的面积内集成了很多存储单元，对ATE的测试成本过高，不适用于从外部灌入针对存储器的测试向量；
b）Memory测试的特殊性——需要测试的单元很多，但分布规整，可利用算法批量产生测试向量；
c）在线测试的需求——汽车电子的安全性，需求在芯片运行时仍保持在线测试（即不依赖测试机台，可集成于板级、芯片内或由软件调用，来实现随时随需的测试），随时排除可能出现的故障。
因此我们可总结出内建自测试的优势：因为测试向量由内部逻辑生成，相应模块可同被测试的存储器一同工作在内部的高速功能时钟下，而无需由机台慢速时钟移入测试向量，可节省大量的测试时间；另一方面，对比验证也同样交给内部逻辑自行完成，测试机台只需要收集测试结果，也可大幅减少测试时间。代价是内建自测试的逻辑对面积的占用很高，也不具备自由配置或更改测试向量的条件。
MBIST测试的框架由测试控制、硬件向量生成、比较器组成：
当测试控制模块接收到开始测试的指令后，首先会切换存储器的输入输出到测试模式，同时启动硬件向量生成模块开始产生和给出测试激励，同时计算存储器的输出期待值。存储器接收到测试向量之后，会间隔执行写/读/使能的操作，遍历测试所有地址下每个bit单元的写/读功能。最后，通过Q端输出的读取值，会与测试控制模块计算的期待值进行比较，是否正确的结果反馈到测试控制模块。
2. TESSENT MBIST逻辑的结构和原理介绍
TAP：Test Access Port
BAP：BIST Access Port
SIB：Segment Insertion Bit
TMB：Tessent Memory BIST Controller
Tessent MBIST结构基于IEEE 1687标准（TAP 仍基于IEEE 1149.1）。TAP的功能是由JTAG五组端口获取外部给予的测试指令，并转换到IJTAG扫描链上，并移位到其后的模块内；SIB可以开启或关闭其下对应的IJTAG扫描链，扫描链的开启意味着该部分Memory进入测试状态；BAP起到SIB下发到MBIST Controller的接口作用；MBIST Controller内含对Memory测试控制的状态机逻辑和生成向量的逻辑；Memory Interface包含了上节所述的选择输入输出的MUX；而结果比较电路，包括ROM的期待值，则可以位于MBIST Controller中（面积更优，时序和拥塞更差）或位于Memory Interface中（效果反之）；比较结果会汇总为测试结果，由IJTAG扫描链，经过TMB、BAP、SIB、TAP移出到TDO端口。
MBIST测试中的关键指示信号有RUN、GO、DONE信号，由MBIST Controller结合状态机和比较器的比较结果来给出。RUN信号指示当前Controller以及下属的Memory进入测试状态（MBIST Mode）；GO=1信号指示开始向下属的Memory输出测试向量，测试开始，=0指示测试有比较器报出Fail；DONE=1信号指示MBIST测试已结束。GO和DONE信号结合起来，可判定出当前Controller下属Memory的测试情况：
GO一直未拉高或DONE一直未拉高：Controller执行有误；
GO拉高后，DONE尚未拉高：Memory测试执行中，尚未出错；
GO拉高后在DONE拉高前回落：有Memory测试失败；
GO拉高后，DONE拉高：Memory测试正确通过。
GO信号根据用户需求不同，可以有以下输出方案：
全部测试信号汇总为一个GO信号移出，只指示设计的MBIST测试结果；
每个Memory对应一个GO信号移出，可具体指示哪一块Memory有故障；
每个Comparator对应一个GO信号移出，可细化到Memory的哪一位输出有故障；
若要具体到哪一位BitCell有故障，默认不能实现，需要调用Tessent的Diagnosis Feature。
3. RTL设计满足MBIST集成的前置需求
如上所示是Tessent MBIST逻辑的时钟和复位信号示意图。复位信号由TRST、TAP、SIB、BAP逐级提供给TMB和Memory Interface，只有在需要的时候，下一级才会由上一级拿到复位信号开始工作。时钟信号方面，TAP、SIB、BAP三者都在IJTAG扫描链上，因此工作在机台的慢速时钟（TCK）之下；TMB、Memory Interface则直接挂在待测试Memory的时钟源（FuncClk）之下，向量的产生和测试过程都是工作在高速时钟下，以节省测试时间和便于对memory进行全速测试。
因此我们可以很清楚地了解到，MBIST逻辑能正常工作，不依赖系统原有的复位，但需要保证Memory的时钟源准确有效。时钟网络中的时钟门控（Clock Gate）、时钟选择（Clock Mux）、时钟分频（Clock Divider）和晶振时钟（PLL），在功能模式下可能是正确有效的；但若未在代码设计时考虑到Memory在测试模式下的时钟路径，很有可能发现在电路切换到MBIST模式下之后，由于信号配置出错，或部分功能逻辑不能工作，而导致时钟路径不通，或时钟频率不匹配全速测试的要求。其结果是前端设计人员不得不返工修改代码，造成项目不必要的迭代。抑或由DFT工程师自行对电路结构进行ECO解决，但如此做的问题是代码难以达到完备标准，ECO修改工作需反复占用DFT工程师的工作时间，在每次项目更新、不同DFT工程师（如客户方）、和新老项目复用时都会造成重复劳动。
另外，虽然MBIST逻辑不依赖系统原有复位，但时钟相关的逻辑，例如我们CPU中的时钟分频电路和SOC平台中的时钟管理模块，仍需要正常工作来提供正确的时钟。因此，时钟相关逻辑需要拿到一个与功能模式相同的复位上升沿信号。而其它无关的逻辑，在MBIST测试中需要保证其复位一直为低，保证无关逻辑在测试期间不会由于信号翻转而产生过高的功耗。如上图SOC平台中的复位处理方法。
以下我们将以几个例子来说明测试模式下时钟路径上可能会遇到的问题：
案例1——时钟门控作为分频器
此案例中，时钟门控单元扮演了一个时钟分频器的角色。在功能模式下，时钟门控的使能信号E是通过CPU指令调配而产生的一个类似1G时钟的信号，从而产生门控后的时钟隔一拍通过的效果，即一个占空比是1:4的二分频时钟（设计的初衷是实现可由指令选择的不同分频时钟）。而在MBIST模式下，系统最多只能拿到一个复位上升沿信号，不能执行读写指令的操作，上述使能信号是不能获取的，因此时钟门控单元处于常开的状态，其后的逻辑没有时钟驱动。
解决时钟门控单元挡住时钟的问题，需要对时钟门控的E或TE提供正确的使能信号。如下图所示为当前对普通的时钟门控单元的处理方法（由工具完成）。对于Memory的前置时钟门控单元，E端前会加入一个MBIST模式选择的MUX（OR门实现），在mbist_mode=1时直接关闭时钟门控；与Memory时钟无关的门控单元不作处理。对全部时钟门控单元，TE端交给Scan_Enable信号控制，此处理方法可使E端前置逻辑变为可测。
对于本案例的解决方案，一种选择是直接在时钟门控之后加一级CKMUX，由外部/顶层提供测试模式下的分频时钟（一部分第三方IP选择此方案）；另一种选择是类似于上图的解决方法，但E端在MBIST模式下不是提供1‘b1，而是提供功能模式下类似的信号（此信号不再依赖读写指令的操作，可自动生成），从而在这里获得所需的二分频时钟。本案例中我们选择了第二种方法解决。
案例2——寄存器作为分频器
寄存器作为时钟二分频是一种非常常见的时钟结构，但该寄存器的复位信号，在功能模式下与其他寄存器是一致的，往往不会有针对测试模式的考虑，因而直接与其他寄存器共用同一个复位信号端口。这么做的结果是，在测试模式下，复位信号转交由机台提供的测试复位信号，MBIST模式下为0，时钟分频寄存器没有上升沿复位信号时，不能产生二分频时钟。解决方案是在分频寄存器的复位端加入一个MUX，dft_mode=1时，转接到芯片顶层的时钟管理模块的FUNC_RESET复位信号上，原有复位信号此时将接到芯片的SCAN RESET上，在MBIST模式下保持为0。
案例3——Clock Deglitch
Clock Deglitch结构用于消除时钟选择路径上的毛刺，在功能模式下，选择逻辑输出的两个使能信号是保证互斥，并且与时钟沿对齐，以此保证其后或门输出的时钟，不会有两个时钟上升沿交叠部分导致的时钟毛刺。该结构中（目前遇到的）存在不受系统复位控制的逻辑，例如产生使能信号的寄存器，其复位信号由MUX Change Control内部生成的这一情况。因此在测试模式下，该逻辑同样是不能工作的，即也无法输出正确的时钟信号。解决方法是在整个Clock Deglitch的输出时钟之后加一级CKMUX，跳过Deglitch结构，直接选择到预期的时钟输入源上。
此处注意，我们是否可以更改ICG的使能E信号，或是更改MUX Change Control的结构来产生同样的预期效果呢？这么做在逻辑上是可行的，但因为工具（Tessent / Spyglass）默认的处理方法的影响，并不是一个好的选择。Tessent工具在检查时钟路径的时候，是由Memory的CLK输入端向前追溯的，在追溯的路径上遇到的未作特殊定义的时钟门控ICG单元时，会按照案例1中讲过的处理方法，在ICG E端加一级MUX强制关闭门控。那么对Clock Deglitch结构来说，工具会同时处理两个ICG，或门会同时拿到两个时钟，无法输出正确的时钟。DFT工程师通过修改sdc文件和配置Tessent工具，可以规避这一情况；但这需要建立在工程师理解该Clock Deglitch的存在和预期要选择的时钟的基础上（换言之，一定需要Debug），无法实现DFT流程的自动化。因此，推荐选择上面所述的跳过整个Clock Deglitch的修改方法。
案例4——硬核IP产生的时钟
有很多第三方IP会集成硬核PHY，PHY有可能作为时钟产生源，为第三方IP内部的Memory和逻辑提供高速时钟信号。如上图所示，PHY提供的高速时钟源，在PHY Controller内部会经过比较复杂的选择和分频电路，产生多个预设频率可变的工作时钟。PHY Controller在dft_mode下通常是不能以功能模式的行为工作的，也就是说其后应该给出的时钟是无效的。一般第三方IP也会集成时钟MUX，用来在dft_mode下提供旁路的测试时钟，但也有未作周全考虑的IP，或前端设计中对第三方IP的逻辑部分做了修改的情况。此时，就需要如上图所示，对相应的时钟做旁路处理，由芯片顶层的PLL和Clock Manager模块提供额外的测试时钟，用来代替功能模式下由PHY侧提供的时钟。
案例5——测试模式下PLL时钟频率不匹配
通常PLL在功能模式下默认输出的频率是可能需要工作的最高频率。由于功能设计通常需要PLL时钟的输出频率可控可调，PLL的输入配置信号会交给其它模块产生和提供。在此过程中，前端设计有可能因忽略或出错，dft_mode下PLL输出时钟的频率不等于功能模式默认提供的最高频率。如上图，PLL1在dft_mode下输出的时钟频率未达到实际的最高频率，不能正确执行全速测试，PLL2则输出了过高频率的时钟，实测时会因为时序不满足而测试失败。
在完备的RTL设计中，应将PLL在dft_mode下的输出时钟控制于预期的最高工作频率上。如上图左所示，在dft_mode下PLL会拿到一组默认的配置信号，来产生预期的时钟。另外，在dft_mode下，也需要实现PLL频率的可调可控，那么通常会通过DFT工具加入的TDR（Test Data Registers）模块来旁路处理。如上图右所示，默认的dft_mode测试过程中，TDR处于无效状态，选择信号输出为0，PLL会输出最高工作频率；需要降频测试时，TDR会旁路原有的默认配置信号，产生新的配置信号，来控制PLL输出降频时钟信号。
总结
以上针对MBIST memory时钟的描述实际上也适用于需要做全速测试的逻辑部分（Scan：At-Speed）。对前端设计者来说，设计具备DFT设计的前提条件：
被测试逻辑的时钟信号在dft_mode下有效，频率正确；
与时钟信号有关的逻辑在dft_mode下能够正确工作（复位有效，旁路/选择正确等）；
SDC中对时钟源、时钟结构（即Generated Clock）描述准确无误；
前端设计在设计过程中，即需要对以上几点进行考虑和规划；设计完成后，也需要对设计在dft_mode下的时钟频率进行前仿验证，或执行Spyglass DFT检查。并且，交付的时钟结构文档和SDC是DFT工程师了解和判断时钟通路的必备依据，因此提供的SDC也应要包含准确的时钟描述。DFT完备的RTL设计，将会大幅缩减DFT工程师Debug和前端迭代RTL的工作量。