Tessent PDL详解：从DFT测试意图建模到MBIST与SSN实践-平芜编程栈

1. 先说清楚：Tessent PDL 到底是什么，以及它要解决什么问题

芯片验证这个圈子，尤其是做 DFT（可测试性设计）的朋友，对 Tessent 这套工具链应该都不陌生。Mentor 当年靠它把 Scan/ATPG、MBIST、On-Chip Compression 这些做成了行业事实标准，后来被西门子 EDA 收编之后，产品线更新得也很快。PDL（Procedural Description Language，过程描述语言）是 Tessent DFT 流程里一个相当底层、但价值极高的抽象层。

一句话说清楚它的定位：PDL 是连接"设计意图"和"测试意图"的一座桥。在传统的 DFT 流程里，RTL 设计做完之后，DFT 工程师要针对扫描链、MBIST 控制器、压缩逻辑写一大堆测试约束和时钟时序。这些约束散落在各种 do 文件、约束文件里，设计一改，约束就失效，维护成本极高。PDL 的核心思路是，把"测试行为"以过程化的方式描述出来，让工具能够基于设计的结构和 PDL 的语义，自动推导出底层 ATPG 和仿真需要的信息。

用工业界的行话来说，PDL 是一种**"可重定向的测试描述"**。什么意思呢？同一个 PDL 描述，可以通过不同的编译目标，生成仿真用的 testbench 激励，生成 ATE（自动测试设备）上的测试向量格式，甚至生成内建自测试（BIST）的寄存器配置序列。也就是说，你写一遍 PDL，后面无论是做验证、做 DFT sign-off、还是做量产测试程序开发，都能复用同一套语义，实打实地省掉大量重复劳动。

举个例子，假设你要验证一个 MBIST 控制器对内存阵列的诊断功能。传统做法是：从 spec 里抄寄存器地址、抄控制位定义，然后手写一段 testbench，拉高某个 CSR（控制状态寄存器），等测试完成，再读回 status。MBIST 控制器要是带了诊断模式、修复模式，这份 testbench 就是一场噩梦，因为你要模拟的时序和控制序列非常长。而用 PDL 写，它是一条run_bist()这样的高层命令，工具会根据编译目标把这条命令展开成对应的仿真激励或 ATE 波形。你维护的是"想做什么"，而不是"具体怎么实现"。

这个抽象层级对 DFT 工程师来说尤其重要，因为 DFT 工作重复度太高了，扫描链插入、OCC（On-Chip Clocking）约束、MBIST 控制器插入这些工作，每个项目几乎都要推倒重来一遍。PDL 的出现，让"测试意图"可以被标准化、模块化，也顺带让流程自动化成为可能。2018 年那篇著名的 Tessent PDL 概念论文里，作者反复强调了一个观点：PDL 的目标不是替代 ATE 向量描述，而是建立一套层级化的测试描述体系，把测试意图从具体实现中解放出来。

对入门的朋友，我建议先抛开复杂的工具选项，把 PDL 理解成"给芯片测试写的一套高级语言"。这套语言的编译器是 Tessent 工具链，它的目标平台可以是仿真器，也可以是 ATE。你关心的是测试流程的逻辑，而不是底层波形的每一个时钟沿。

2. PDL 在 Tessent 工具链里的真实定位：不只是脚本，而是一个语义层

单独看 PDL，不太容易理解它的分量。把它放回 Tessent 的工具链里面看，脉络就清晰了。Tessent 现在的 DFT 流程，核心是按照"意图驱动"的思路组织的，工具的输入不是我 10 年前入行时那种——把网表和约束文件一股脑丢进去，然后等结果；而是先描述设计结构和测试架构，再描述测试意图，最后工具自动完成实现和验证。

这里有一条非常重要的主线需要记住：Tessent 工具链的每一条可测试性规则、每一个 DFT 控制器、每一种测试时钟方案，几乎都对应着 PDL 中的一个语义集。

2.1 PDL 在仿真验证环节的意义

我们做 DFT 验证的时候，最头疼的是测试时序的理解和 testbench 的生成。PDL 在 Tessent 里有一个专门的编译路径，可以生成高效的仿真 testbench。它不仅仅是生成测试向量，还自动处理时钟同步、复位序列、握手信号这些烦人的细节。

我记得刚接触 Tessent 时，MBIST 的 testbench 生成是很让人头大的。MBIST 控制器插入之后，你要验证 LFSR（线性反馈移位寄存器）有没有正确生成伪随机地址序列，MISR（多输入特征寄存器）有没有捕获正确的签名。手动写这些激励，要跟设计者的时序 spec 对得非常仔细，稍微有一个信号晚了一个周期，仿真结果就对不上。用 PDL 之后，这些时序细节被封装在语义里了。我只要描述"开始测试、等待完成、检查签名"这个层次的行为，工具生成的 testbench 会按照它自己理解的时序语义处理时钟沿和握手信号。实测中，我基本不需要手动修改生成的 testbench，偶尔修改也是因为仿真环境里的某些时间单位设置不匹配。

有一个细节很多教程不会提：PDL 编译生成的 testbench，默认是"周期级"的，不是"事件级"的。什么意思呢？它在仿真器里看，每一个测试周期被定义得很明确，信号跳变只发生在对应的相位点上。这种 testbench 在调试时比较容易读，也方便做周期精确的断言检查。

2.2 PDL 在 ATE 向量生成侧的地位

DFT 流程的最终交付物，是能让产线测试机跑起来的测试程序。传统路径是 ATPG 工具直接流出 WGL/STIL/VCD 格式的向量，再用专门工具做格式转换和校验。PDL 路径则更干净，它作为高层次描述，可以编译到 STIL 这类工业标准格式，再由产线工程团队做最终适配。

这个路径对"可移植性"的贡献非常显著。同一个 PDL 文件，在项目初期可以生成 RTL 仿真用的 testbench，在项目后期可以生成 ATE 用的 STIL 文件。前后端用的是同一份测试意图描述，从根源上杜绝了两边理解不一致导致的问题。

我自己见过很多项目，仿真用的 testbench 和量产测试向量之间的一致性要靠一堆脚本来保障，脚本一改，两者就悄悄偏离。PDL 引入之后，这种偏离问题缓解了很多，至少在 MBIST 和部分可测性逻辑上是这样的。

对于做测试程序开发的朋友来说，PDL 还有一个隐藏的便利：它天然具备层级结构。你在 RTL 级定义了 PDL 过程之后，后端实现时可以通过继承和重定义来适配不同层次的实现。这一点在流片后的诊断和良率分析阶段尤其有用——测试工程师可以基于 PDL 抽象出他们关心的测试步骤，而不必钻进几千行 STIL 里找某个寄存器操作。

2.3 PDL 和 Tessent 其他组件的配合关系

具体到 Tessent 产品家族，PDL 并不是一个孤立的工具，它和以下组件紧密协作：

组件	和 PDL 的配合方式	我的实际体验
Tessent Scan/ATPG	扫描链测试意图用 PDL 描述，ATPG 自动生成测试向量	能自动处理 shift/capture 时序，DRC 检查提示更友好
Tessent MBIST	内存 BIST 控制器的指令序列、签名检查用 PDL 定义	直接调用高层的`run_bist`，省去大量手写寄存器操作
Tessent On-Chip Compression	压缩逻辑的测试映射和观测通道同样支持 PDL 语义	对 EDT 通道配置的验证更直观，不用在波形里找信号
Tessent Diagnosis	诊断数据格式和失效日志可以通过 PDL 定义标准路径	在良率提升阶段，诊断程序复用同一套测试意图，省时

表格里提到的这些，足以说明 PDL 不是脚本层的东西，它是嵌入在工具链基因里的语义层。工程师从"描述实现"升级到"描述意图"，参数化的流程才真正跑得起来。

3. 一段 PDL 是怎么诞生的：从寄存器操作到可复用测试步骤

我第一次用 PDL 的时候，最直观的感受是，这东西有点像硬件描述语言和 C 语言的混合体。它里面有"模块"的概念，也有"过程"的概念。一个 PDL 描述文件通常包括三个层面：信号声明、过程定义、调用序列。下面用一个简化的例子来拆解一下。

假设有一个 MBIST 控制器，控制逻辑里有三个寄存器：

控制寄存器MBIST_CTRL，bit0 是GO，bit1 是RESET_N，bit2 是DIAG_EN
状态寄存器MBIST_STATUS，bit0 是DONE，bit1 是FAIL
期望签名寄存器EXPECTED_SIG，32 位

用 PDL 描述"运行一次 MBIST 测试并等待完成"的过程，大概会长成下面这个样子（示例简化，字段名也做了专门化处理，具体项目中以工具支持的语法为准）：

proc run_mbist_with_diag { { diag_en 0 } } { # 先确保控制器处于复位状态 set MBIST_CTRL {.RESET_N = 0, .GO = 0} # 写入期望签名（如果提供了的话） # 在实际工程中，这里会自动编译成写寄存器的操作 if { $diag_en } { set MBIST_CTRL {.DIAG_EN = 1} } set MBIST_CTRL {.RESET_N = 1, .GO = 1} # 等待 DONE 变为 1，带超时保护 wait until { value_of MBIST_STATUS : DONE == 1 } timeout 100us # 检查是否失败 if { (value_of MBIST_STATUS : FAIL) == 1 } { error "MBIST failed" } }

这段代码里面的关键点，其实不是语法本身，而是它背后的语义：set寄存器字段是抽象的操作，工具会在后端编译时把抽象操作映射成具体的信号波形或 ATE 受控操作。这就是为什么一份 PDL 能同时服务仿真和 ATE 的原因。

在实际工程中，我写 PDL 的过程分这么几步：

从前端 Design Spec 提取寄存器列表和时序要求。这一步很重要，PDL 描述虽然是高层，但寄存器的位段含义不能错。
用文本编辑器或 VS Code 写好初始的 PDL 文件（Tessent 有语法高亮插件，虽然官方支持一般，但用起来舒服不少）。
用 Tessent 的编译命令做语法检查。不需要先做一个完整的网表，语法检查通过，说明描述本身没有低级错误。
将 PDL 编译到当前仿真用测试环境，跑一遍功能仿真。这一步看的是"行为逻辑"是否正确。
如果项目已经具备 DFT 网表，再编译到 ATE 格式做向量验证。

这个过程里最容易踩的坑是什么呢？寄存器字段的命名要跟设计里实际的名字一致，尤其是大小写和下划线习惯。有些 RTL 工程师喜欢mbist_ctrl_reg，有些喜欢MBIST_CTRL_REG，PDL 编译器的查找规则虽然灵活，但如果大小写不一致，报错信息会绕好几层，排查起来相当耗时。所以拿到一份不熟悉的 RTL 时，第一件事永远是去查寄存器描述文件，而不是凭记忆写字段名。

再分享一个非常实用的技巧：在早期仿真阶段，先用 PDL 生成一个"最小测试流"，一个 tool 启动、初始化、单个测试项完成、读状态的流程就够了。很多工程师上来就想把整个测试程序写完整，结果调试时一片混乱。小步快跑，把最基本的主干流程打通，后面加复杂功能时心里就有底了。

4. PDL 实战三项核心操作：测试意图建模、寄存器后门访问、ATPG 向量集成

光看例子和结构，还不足以体会到 PDL 的威力。我挑三个在项目里最高频的使用场景，展开说说具体怎么操作，以及为什么这样操作是合理的。

4.1 用 PDL 给测试步骤建模：抽象是一种生产力

很多 DFT 工程师在导入 PDL 之前，脑海里还是"波形图思维"。写 testbench 时，先画波形，再按波形写激励。PDL 会逼着你从"步骤思维"角度思考：定义一个测试步骤，它需要的前置条件是什么？它要访问哪些寄存器？它等待什么信号发生变化？它会输出什么结果？

我在做 MBIST 的诊断流程建模时，就深深体会到抽象的好处。MBIST 诊断往往要做多轮：先跑一个快速 pass/fail 判断，再进入逐地址扫描模式，找到具体失效单元。如果按波形写，这一套流程要写几千行。用 PDL 建模，整个过程被我拆成了三个过程：run_go_no_go、run_address_diag、read_sig_and_analyze。每个过程都清晰、独立，调试时直接对单个过程做单元测试，问题定位非常快。

建模还有一层更实际的好处——便于复用。同一个芯片可能有多个 MBIST 实例（比如不同大小的 SRAM 阵列），它们的 PDL 过程逻辑一样，只是寄存器基地址不同。我可以在 PDL 里用一个"实例上下文"来参数化基地址，调用时传入不同实例名，一套代码跑遍所有 SRAM。这在手写 testbench 的时代不可想象，那时候任何一个内存尺寸改变，都要手工修改几十处地址常量。

4.2 寄存器后门访问：仿真加速的利器

做仿真验证时，最常见的性能瓶颈是寄存器访问。CPU 要通过总线协议去写配置寄存器，一条写操作要等总线握手，几百个周期就过去了。在 DFT 流程里，我们往往不关心这段总线时序——我们关心的是配置成功之后的测试行为。

PDL 对这种情况有一个非常好的解法：后门访问。它在仿真模型里直接以"物理层次+信号名"的形式，强制赋值或者读取某个寄存器字段，完全绕开总线时序。仿真速度提升明显，尤其是在大量配置测试模式的场景下。

一个典型的后门访问写法大概是这样（示意语法）：

# 后门写入，绕开总线协议 force_reg /tb/dut/u_mbist_regs/MBIST_CTRL value 0x1 # 后门读取 set cur_val [read_reg /tb/dut/u_mbist_regs/MBIST_STATUS]

注意，后门访问最适合在"功能已经验证过总线通路"的前提下使用。如果你还在调试总线桥逻辑本身，用后门访问反而掩盖了问题。我的习惯是：验证阶段前期用前门（走总线协议）确认通路正确，后期做大批量回归时切到后门提速。

另外提醒一句，后门访问的层次路径是设计相关的，换了网表版本，层次名可能变化。建议在 PDL 里通过一个统一的"拓扑映射表"来维护这些路径，而不是散落在各个过程里，否则网表一更新，改起来想哭。

4.3 结合 ATPG 向量：让 PDL 成为胶水

项目里还有一类特别常见的工作：手动把 ATPG 生成的测试向量嵌入到仿真流程里做验证。传统做法是用 PLI 或者类似机制把向量文件灌进仿真器，然后手工管理时钟和观察窗口。PDL 在这里起到一个很好的"胶水"作用。

我可以写一个 PDL 过程：

proc apply_scan_pattern { pattern_file } { # 进入扫描移位模式 set SCAN_MODE {.MODE = 1} # 装载向量文件（工具会在编译时映射为加载行为） load_pattern $pattern_file # 产生 capture 时钟 generate_clock cycle 2 # 回到功能模式 set SCAN_MODE {.MODE = 0} }

这个过程的好处是什么呢？原来做同样的操作，我得在 testbench 里写 PLI 调用的 C 代码，还得关注向量文件的格式解析。现在用 PDL 抽象描述之后，向量装载和时钟产生这些底层细节被工具接管了。我可以把同样的过程复用在不同的测试模式里，只要传入不同的向量文件路径就行。

这里有一个非常实用的经验：不要把向量文件和 PDL 过程绑定死。PDL 过程尽量设计成"传入文件路径"的形式，这样在回归测试中，我可以循环调用多个向量文件。如果绑定死，后面加测试项时，又得去改 PDL 文件，失去了抽象的意义。

5. 梳理一下必须避开的 PDL 陷阱

讲了不少优点，但 PDL 不是灵丹妙药，它有自己的脾气。我在不同项目里踩过不少坑，挑几个典型的分享出来，帮大家省点时间。

陷阱一：把 PDL 当成万能的脚本语言用。PDL 面向的是"测试意图描述"，它的语义对象是寄存器、信号、时钟、时序约束。如果你试图在里面做复杂的字符串处理、文件解析、复杂的循环嵌套和数据结构组织，语法会非常别扭，而且工具调试体验很差。正确做法是：复杂逻辑留在外围脚本（如 Tcl、Python、Makefile）里，PDL 只做测试步骤的抽象和封装。

陷阱二：忽视时序上下文。PDL 里等待信号超时的描述，在仿真器里是仿真时间，在 ATE 上却是实际时间。同一个wait until在两种编译目标下的语义不完全相同。有些工程师在仿真环境里把超时写得很大，结果生成的 ATE 向量超时设置也不合理，测试时间被白白拉长。我建议在写 PDL 时，对超时参数做显式配置，仿真时稍微宽松一些，生成 ATE 前再收紧到合理值。

陷阱三：寄存器的初始化和复位依赖。有些测试步骤设计时，假定控制器处于一个确定的初始状态。但实际执行时，如果前一个测试步骤把控制器带到了别的状态，直接调用这个步骤，就会出现意外结果。PDL 过程设计时就要考虑状态独立性，建议在关键过程开头显式复位相关寄存器，哪怕复位操作看起来是冗余的。确定性是测试程序中最重要的品质，宁可多一点冗余动作，也不要留下状态污染的可能。

陷阱四：滥用后门访问。上面说了后门访问能提速，但有工程师为了省事，在设计中所有寄存器访问都用后门，导致仿真验证根本没有覆盖总线访问逻辑的问题。这个在 DFT 验证中还好，但如果 DFT 验证的功能还涉及 CPU 启动流程，后门一用，整体的启动时序就被绕开了。我的原则是：能在前门解决的问题，不轻易走后门；后门只用于提速和隔离故障处理。

陷阱五：PDL 版本和工具版本匹配问题。Tessent 工具升级后，PDL 编译器支持的语法和语义可能略有变化。尤其是一些修饰符、默认参数的处理方式，不同版本之间有细微差别。团队里如果有多个项目并行，建议锁定工具的版本，并在代码评审时确认 PDL 文件没有用到新版/旧版互不兼容的特性。

这些坑看起来都不深，但每一个都会在实际项目中浪费大量时间。特别是从手写 testbench 转型到 PDL 的工程师，往往会受到"惯性思维"的影响，把 PDL 当成 Tcl 或者 Verilog 来写，结果语法能用，但语义却偏离了工具预期，后期调试异常折磨。

6. PDL 对 DFT 流程自动化的真正贡献：以 mbist 和 ssn 场景为例

网友的搜索热词里，"tessent mbist"和"tessent ssn"出现频率很高。这两个场景，恰恰是能完整展现 PDL 价值的地方。

6.1 MBIST 场景下 PDL 怎么帮我们省时间

MBIST 本身的设计套路已经很成熟了，无非是地址序列发生器、数据背景发生器、MISR 签名分析。但"实现 MBIST 逻辑"和"验证 MBIST 正常工作"是两回事。后者在 PDL 出现之前，工作量非常庞大。

举一个真实项目的感受。某个 SoC 项目有 20 多个 SRAM 实例，每个实例都有自己独立的 MBIST 控制器，但控制器的配置接口基本一致。在没有 PDL 的流程里，我要为每个 SRAM 写一份几乎雷同的 testbench，唯一的区别就是寄存器映射地址不同。万一 RTL 里有一个 SRAM 的复位信号极性改了一下，我要把所有相关的 testbench 都改一遍，非常痛苦。

换成 PDL 之后，我写一个通用的 MBIST 验证过程，用一个参数表示"实例名"。每个 SRAM 只是参数不同，PDL 通过查找设计里的层次名和寄存器映射，自动把参数替换成正确的地址。RTL 改了 repo，我只需要重新跑一次编译和回归，不需要动 PDL 的主体内容。这就是语义化建模带来的实实在在的收益。

更进阶一点，PDL 还可以配合诊断反馈做"自适应测试"。MBIST 跑完诊断模式后，失效地址可以被反馈到测试流程里，决定下一步是进入修复策略还是继续全片测试。这种控制逻辑如果用传统 testbench 写，简直是想都不敢想的复杂度，但用 PDL 过程封装之后，流程清晰度好了很多。

6.2 SSN（Tessent SiliconSmart？还是其他？）场景中 PDL 的配合

关于"tessent ssn"，可能需要澄清一下。很多资料里 SSN 被指代为一种串行扫描网络或测试访问机制（具体要看语境和工具版本）。在当前较新的 Tessent 流程中，SSN 相关的方案往往涉及"测试数据的串行化传输"，目的是减少测试引脚数量、降低测试机通道需求。PDL 在这里的重要价值，是帮助定义串行访问的协议步骤。

在传统方案里，如果测试访问采用串行协议，那么验证这个协议本身就是一件大事：你要模拟时钟、数据移位、寄存器更新使能……这些统统要写到 testbench 里，而且不能出错。用 PDL 描述之后，这些串行协议步骤被封装成高层次命令。比如一个"写寄存器"操作，在 PDL 里可能就是一行赋值；工具遇到这一行，会按照协议自动生成一串移位时钟和位操作。

这种方式带来的最直接的好处，是DFT 工程师不需要精通串行协议的每一个时钟周期。只要协议本身的 PDL 库是经过验证的，上层使用者的效率会大幅提升。这也是我为什么一直强调，PDL 本质上是在降低 DFT 这个领域的"专业门槛"——当然，这不是说不需要懂底层，而是说你不必在每一个任务里都重复做底层工作。

对团队管理来说，这意味着角色分工可以更灵活：有经验的工程师负责建立和维护 PDL 库，初级工程师通过调用库来快速完成验证任务。这种模式在传统 testbench 流程里很难实现，因为手写 testbench 的经验很难完全沉淀成可调用的"库"。

6.3 PDL 对流程重构的长期影响

从行业趋势来看，PDL 的意义已经超越了工具层面。传统 DFT 流程存在一个很根本的问题：工具链和测试意图之间的连接特别薄弱。比如综合工具需要 SDC 约束，ATPG 工具需要 do 文件，仿真需要 testbench，ATE 需要向量格式，这些文件之间靠工程师手工翻译。PDL 要做的，就是把这些环节整合进统一的"意图层"。

我正在做的事情，是尝试在团队里推行"PDL 先行"的流程：在 DFT 架构设计阶段，先花一两周把 PDL 骨架写好，包括寄存器访问方式、时钟方案、测试模式控制、关键测试流程。然后把这份 PDL 作为设计评审的输入之一。这样做的好处是：设计评审时，大家讨论的不再是抽象的文字描述，而是可执行、可仿真的具体行为。任何协议误解和时序问题，在评审阶段就会被发现，而不是等到网表交付后再去反复迭代。

这个流程对新人来说也很友好——新人拿到一份 PDL 文件，通过读过程和注释，就能理解整个 DFT 的测试意图。这比读几百页的 Word 文档直观得多。

7. 最后分享一点个人心得：PDL 学习路线和工程习惯

很多朋友问我，学 PDL 应该从哪里入手。我的建议是，不要一开始就扎进语法手册，而是先理解你正在做的 DFT 测试流程本身：一个 MBIST 测试从开始到结束，寄存器之间是什么关系；一个扫描测试的 capture 过程对时钟有怎样的要求。这些理解越透彻，PDL 学起来越快。语法只是表面，语义才是核心。

具体的学习路径，我的经验是分三步：

找一份现成的 PDL 示例，最好是跟着 Tessent 工具一起安装的 demo 工程。先不看语法手册，尝试读懂每一行在做什么，然后运行仿真，观察它生成的 testbench 是怎么展开的。这一步的目的是建立"高层描述"到"低层波形"的映射感。
改写一个小场景，比如把 demo 里的 MBIST 控制器寄存器地址改了，或者增加一个诊断模式控制位。你会发现，PDL 代码的改动量非常小，但生成的 testbench 变化很大。这一步的目的，是理解参数的传递和流程的复用。
从零开始写一个简单的 PDL 过程，参考已有的库函数和模板。一旦你自己写出过一个能跑通的完整流程，整个语言的思维模式就打通了。

还有一点工程上的建议：在项目里建立 PDL 代码评审机制。PDL 文件很像"可执行的测试规格书"，如果写得混乱，后面维护会非常痛苦。我一般会要求下面这些评审标准：

过程命名是否体现了测试意图（run_mbist_diag好过proc1）
是否显式处理了复位和初始状态，会不会有状态残留
超时参数是否合理，是否区分了仿真环境和 ATE 环境
是否直接引用了具体的层次路径，而不是通过配置表间接引用
是否包含了必要的注释，解释"为什么要这样做"而不是"做了什么"

这些标准听起来很基础，但坚持执行之后，项目整体质量提升非常明显。团队里任何一个工程师接手其他人的工作，都能很快从 PDL 文件里理解测试流程逻辑。

对于还在观望的朋友，我的看法是：如果你做 DFT 相关工作超过一年，而且还在手动维护大量 testbench 和向量文件，那么学习 PDL 是一个很值得投入的方向。它不会一夜之间替你完成所有工作，但会在每个迭代周期里持续帮你节省时间，更重要的是，它会逼着你把测试意图想得更清楚。这一点，长远来看比任何工具技巧都值钱。