任何一个用Tessent做过DFT项目的工程师大概都有这样的经历打开Tessent的文档最先记住的是MBIST、SSN、Scan这些大块头关键词可真正到了生成测试向量、调试覆盖率的阶段几乎所有流程都会回到同一个载体——PDL。PDL的全称是Procedural Description Language名字听起来很学术但用大白话说它就是Tessent用来描述“怎么测”的语言什么时刻给时钟、什么时候拉复位、扫描链怎么装载、响应在哪个窗口采样。没有它工具生成的测试数据就是一堆没有播放脚本的乐谱。这篇文章我打算把Tessent的PDL好好拆一遍。不仅讲清楚它是什么、为什么需要它还会把我在实际项目里踩过的坑、验证过的方法、调试时常用的套路都整理出来。内容主要面向刚接触Tessent的DFT工程师也适合那些已经把Tessent跑通、但PDL部分一直靠工具自动生成、遇到问题不知道从哪里下手的同学。你可以把它当成一份从“能用”到“会用”的PDL实践笔记。1. PDL到底是什么Tessent测试流程的“脚本语言”1.1 从需求说起为什么需要描述测试流程芯片制造出来之后要用ATE自动测试设备去验证它有没有物理缺陷。ATE不会自己猜芯片该怎么工作它需要一份明确的“动作清单”第几个周期把某个引脚拉高第几个周期给时钟第几个周期检查输出。把这份“动作清单”标准化、程序化就是PDL存在的最大理由。我经常跟新同事打一个比方测试向量pattern是一串数据PDL是播放这些数据的“唱片机”。比如扫描链测试你可以先算好要移入0和1的组合但如果没有PDL去控制shift时钟和scan enable信号这些数据根本不知道什么时候应该进入芯片、什么时候应该被观察。无论是SCAN、MBIST还是Boundary Scan最终的测试执行都离不开类似的过程描述。Tessent之所以把PDL单独作为一个概念提出来是因为它要解决一个现实问题同一个设计在仿真阶段、在ATE阶段、在芯片返回后的硅调试阶段测试流程必须保持一致。如果每个阶段都手工写一套时序早晚上出偏差。PDL作为一种“过程描述语言”尽可能把测试时序和被测对象解耦让同一份PDL可以被Tessent Shell解析也可以被转换成不同pattern格式去跑仿真或者上机。1.2 PDL与Tessent Shell的分工定位很多同学会把Tessent Shell和PDL混在一起理解这很正常因为我们在终端敲命令的时候看到的都是同一个Tcl脚本环境。但它们在逻辑上是两层东西Tessent Shell是工具的运行环境负责加载设计库、执行命令、管理数据库PDL则是一套基于该环境的过程化描述规范负责定义测试流程。用我自己的项目经验来说Tessent Shell就像一个操作系统的shell你可以在这套shell里面执行Tessent的所有命令而PDL更像是一组高层的、可复用的API专门用来描述测试器时序。比如在Shell里你会用read_netlist去读网表用add_clocks去定义时钟信号而PDL里更关心的是某个测试步骤中的force、measure、capture动作在哪个周期发生。从工程实践看Tessent的标准做法是让工具自动生成大部分PDL。你配置好时钟、复位和测试模式之后Tessent MBIST会自动写出内存BIST控制器的PDLTessent Scan也会自动写出扫描测试流程的PDL。但这不意味着工程师可以完全不去理解PDL。一旦出现仿真失败、pattern在细粒度调试时不匹配、或者需要手写自定义时序不懂PDL就只能干瞪眼。2. PDL的核心语法与实现原理2.1 基础结构过程、时序与变量我在项目里接触到的PDL本质上是一段Tcl脚本。它有过程定义、变量赋值、条件判断和循环语法风格跟普通Tcl几乎一样。如果你会Tcl上手PDL会非常快。一个典型PDL块通常由几个部分组成首先是变量声明用来表示信号名、周期、位宽等信息然后是过程定义每个过程描述一个完整的操作序列最后是过程调用把定义好的测试流程串起来。Tessent的工具库里其实已经预置了很多标准过程你在自己的脚本里更多是“调用”而不是“重新发明”。我之所以强调“过程”这个概念是因为PDL和普通RTL测试bench最大的不同就是它把测试器相关的行为封装起来了。你不需要关心每一个电气细节只需要调用类似“装载扫描链”“产生一个BIST时钟”“等待测试完成”这些高层过程。Tessent在解析这些过程时会结合测试器的波形信息把它展开成真实的事件序列。这也是PDL简洁又专业的原因。2.2 常用命令集与执行逻辑每个Tessent版本的PDL命令集大体相近但细节会有差异。我不建议死记文档里的命令全名更好的方式是熟悉那几条核心动作类型force把某个信号强制为0或1或者任意值。measure在某个时刻采样某个信号的输出值。pulse给时钟或复位信号一个脉冲。wait等若干个时间单位或周期。capture执行一次捕获操作通常用于扫描测试的捕获阶段。load_unload执行扫描装载/卸载的流程是扫描测试里最常用的动作之一。我来给一段很朴素的示意代码展示PDL看起来是什么样的不同版本可能有修饰差异但思路不变proc my_scan_shift {} { variable period 10 variable scan_en [get_port scan_en] variable clk [get_port clk] force scan_en 1 force clk 0 for {set i 0} {$i 100} {incr i} { pulse clk $period } force scan_en 0 pulse clk $period measure scan_out }这段代码的好处是直白先把扫描使能拉高连打100拍移位时钟然后把扫描使能拉低打一拍捕获时钟最后采样输出。实际项目里的PDL会比这个复杂很多因为还涉及多时钟、锁存窗口、安全隔离逻辑等但从执行逻辑上看无非就是这么几类动作的组合。2.3 PDL与TCL的融合细节PDL既然是Tcl之上的描述语言那Tcl的杀手锏——变量替换、表达式计算、循环、数组——自然都带进来了。这在处理可配置流程时非常有用。举个例子我做MBIST的时候经常需要根据内存实例的数量自动生成多个BIST控制器的测试流程。我会在Tcl里先用foreach循环遍历所有BIST控制器名称然后为每个控制器生成一段PDL过程。这样做的好处是项目里新增一块内存时不需要手改PDL只要更新配置文件再重新生成一遍。另一个Tcl的实用之处是可以通过数组管理信号关系。比如把内存名字存为数组下标把对应的地址、数据、控制信号名字作为数组值后面生成PDL时统一引用。这样既减少了拼写错误也方便后期维护。我强烈建议在大型SoC项目中这么干否则PDL文件会膨胀到让人没法阅读。3. PDL在MBIST和SSN场景中的实战记录3.1 一个典型的MBIST测试流程配置MBISTMemory Built-In Self-Test是Tessent里非常常用的一块PDL在其中的角色主要是定义BIST控制器如何启动、等待、读取结果。我之前做的一个项目里有几十个SRAM实例Tessent MBIST把它们分成了多个BIST域。我给每个域写一段PDL过程很简单先给BIST控制器复位然后启动BIST接着等待RUN_DONE信号拉高最后捕获FAIL状态和故障日志。整个过程用高层过程描述看起来比RTL testbench还要简洁。proc run_mbist_start { } { reset_bist enable_bist wait until {run_done 1} capture_fail_log }当然实际中不存在一个叫wait until的通用命令但Tessent的PDL库里确实有类似的等待机制可能是用循环加measure去轮询。千万别小看这个轮询如果你的时钟或复位信号没有在变量里定义清楚工具在生成事件时就会报一串时钟冲突错误。我在第一次跑通MBIST流程时就花了整整两个下午在处理这类时钟定义不一致的问题。还有一个关键点是MBIST中的内存BIST时钟往往不是普通功能时钟可能是独立的BIST时钟域。PDL必须明确描述BIST时钟的启动和停止时序。如果你在PDL里只定义了功能时钟那仿真时BIST控制器可能一直处于死等状态run_done信号永远拉不高。3.2 通过SSN提升并行度时PDL的相应调整SSN全称Streaming Scan Network是Tessent用来提升芯片测试并行度的网络架构。简单理解它把多个测试接口的数据通过一条高速串行链路流式传输从而减少测试引脚数量、降低测试时间。SSN和PDL的关系非常密切因为SSN执行测试时需要通过PDL描述流式数据的装载、控制和捕获。跟传统扫描测试不同的是SSN的移位过程不再是一个core独立一个shift时钟而是多个core共享同一条串行链路。所以PDL中的移位长度、数据位宽、通道掩码都需要根据SSN配置动态计算。我在第一次适应SSN时犯过一个错沿用老式scan的PDL模板没有考虑SSN协议通道结果仿真波形里出来的数据全部串位。后来我把PDL里的位宽参数改成根据SSN配置宏动态赋值并重新生成了标准PDL问题才消失。这里给一个建议在使用SSN时尽量优先使用Tessent自动生成的PDL不要手动去拼SSN协议的事件序列。因为SSN的状态转移非常容易出错手动写一两个通道还行通道一多错误概率成倍上升。3.3 从PDL到pattern的完整工具链PDL不是孤立存在的它在Tessent工具链中处于很核心的位置。简单梳理一下我常用的流程先配置好环境变量把Tessent的安装路径和license搞定然后启动tessent_shell读入库文件、门级网表执行DFT插入或MBIST集成接着在Shell里加载或生成PDL最后运行ATPG生成pattern并对pattern做仿真验证。聊到这里顺便回答很多新手会问的“Tessent安装包”问题。Tessent本身是商业EDA工具安装方式一般是获取正式安装包和license文件后在Linux服务器上解压、设置TESSENT_HOME环境变量、把$TESSENT_HOME/bin加到PATH里然后启动工具。不要花精力去找什么破解版或绿色版安全和稳定才是DFT工作流的第一位。在整个流程里PDL文件是链接“设计意图”和“最终pattern”的中间层。工具根据PDL生成pattern时会把每个force、measure动作映射到具体的测试周期。如果你在PDL里写的时钟周期是10ns但仿真环境里给的约束是8ns最终生成的pattern时序就是错的这种错误非常隐蔽往往要到硅片测试时才会暴露出来。4. 实操中的常见问题与排查方法4.1 问题速查表我在Tessent PDL调试过程中积累了一张速查表记录遇到的问题、可能原因和解决办法。这里整理成表格方便大家直接对照现象可能原因排查思路PDL解析报错提示命令不存在版本不匹配或未加载对应过程库检查tessent_shell版本用help确认命令加载TDK标准库仿真时所有输出都是X态PDL中时钟或复位没有明确定义确认PDL变量中的时钟名核对时钟周期和初始电平MBIST流程卡在waitrun_done不拉高BIST时钟未启动或启动时序不对检查PDL中BIST时钟的pulse事件是否覆盖整个等待区间SSN数据串位/错位SSN通道位宽配置错误用自动生成的SSN PDL不要手写核对channel mask生成的pattern在仿真器里出现setup violationPDL中的时序窗口与库单元约束不匹配对比PDL的时钟沿与仿真库的时钟沿调整force/measure的相对位置设备上测试不稳定时好时坏PDL中measure的采样点靠近信号跳变沿把采样点往窗口中间移动避开竞争区pattern文件太大仿真时间不可接受扫描链移位次数过多或时钟周期过短考虑增加SSN并行度优化PDL中的移位事件这张表只是起点真正的排查过程往往需要结合仿真波形和Tessent的调试命令一起看。4.2 两个让我印象极深的坑第一个坑是PDL里时钟周期和RTL仿真不一致。当时我做一个SoC级别的验证PDL里定义的功能时钟周期是20ns但RTL仿真环境里测试bench把时钟周期改成了10ns结果生成的pattern在仿真时大面积出现setup和hold冲突很多功能模块的输出变成了X态。我当时第一反应是约束文件有问题查了半天才发现是PDL里的周期定义和测试bench不一致。后来我养成了一个习惯每次跑流程前先用Tcl打印出PDL里所有时钟变量的值再和仿真环境比对确认一致才继续。第二个坑是SSN通道掩码漏配。某个项目里有6个core通过SSN并行测试我沿用单core的PDL模板结果前两个core测试正常后面四个core的扫描输出全部和预期不符。这个问题的表象看起来像scan chain物理连接断开但实际只是SSN的PDL通道掩码只覆盖了前两个core。改成自动生成的SSN PDL后一切恢复正常。这件事给我的教训是涉及多通道并行时人脑的可靠性远不如工具自动生成不要为了省事去复制旧脚本。4.3 给新手的几条避坑建议如果你想减少在Tessent PDL上浪费的时间下面这几条建议可以帮到你第一重生成胜过手写。Tessent工具可以自动生成大多数PDL手写只在需要自定义时序或排错时使用。手写前先看看工具生成的标准PDL风格别自己发明一套命名。第二学会看事件展开结果。PDL解析后工具一般会生成展开的测试事件报告。这个报告能直接告诉你某个force在哪个周期生效、某个measure在哪个周期采样。我每次遇到怪问题时第一件事就是看事件展开很多模棱两可的疑问都会瞬间清晰。第三把变量集中管理。不要在一个超长PDL里到处散落信号名用Tcl数组或字典统一管理信号映射。这样既方便复用也减少拼写错误。第四版本要固定。Tessent版本升级后PDL库的接口可能有变化。同一个PDL文件在旧版本能跑新版本不一定能跑。项目里最好统一工具版本并保留每次生成PDL的完整环境记录。最后再分享一点个人体会。刚开始用Tessent时我总觉得PDL是工具自动生成的“附属品”只需要关心pattern结果。但踩过几次坑之后我改变了看法PDL才是整个DFT测试流程里最贴近“测试意图”的一层。它既是工具和ATE之间的翻译官也是工程师检查测试时序合理性的直接抓手。愿意花时间把PDL吃透的人后面遇到硅片调试和良率分析时会明显比别人从容。