1. 先说清楚Tessent PDL 到底是什么以及它要解决什么问题芯片验证这个圈子尤其是做 DFT可测试性设计的朋友对 Tessent 这套工具链应该都不陌生。Mentor 当年靠它把 Scan/ATPG、MBIST、On-Chip Compression 这些做成了行业事实标准后来被西门子 EDA 收编之后产品线更新得也很快。PDLProcedural 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 工作重复度太高了扫描链插入、OCCOn-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_CTRLbit0 是GObit1 是RESET_Nbit2 是DIAG_EN状态寄存器MBIST_STATUSbit0 是DONEbit1 是FAIL期望签名寄存器EXPECTED_SIG32 位用 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_REGPDL 编译器的查找规则虽然灵活但如果大小写不一致报错信息会绕好几层排查起来相当耗时。所以拿到一份不熟悉的 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 SSNTessent 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 文件仿真需要 testbenchATE 需要向量格式这些文件之间靠工程师手工翻译。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 是一个很值得投入的方向。它不会一夜之间替你完成所有工作但会在每个迭代周期里持续帮你节省时间更重要的是它会逼着你把测试意图想得更清楚。这一点长远来看比任何工具技巧都值钱。