做DFT这么多年工具链里接触最多的就是Tessent这套东西。早年间用Tessent的时候打交道最多的是各种测试协议、pattern文件、诊断log说实话PDLProcedural Description Language一直是个让我又爱又恨的角色——爱的是它能把测试流程和时序写得清清楚楚恨的是刚上手那会儿没少被它的语法和层级关系折腾。这几年下来踩坑踩多了反而觉得PDL是整个Tessent流程里最值得花时间搞明白的一块。如果你也在做DFT、可测试性设计、或者刚接手Tessent相关的项目这篇东西就是写给你看的。我尽量不讲太多工具说明书里已经写烂的废话而是把PDL是什么、怎么用、在MBIST和SSN这些场景下怎么落地以及实际工程里怎么排查问题一次说透。尤其是那些文档里不会写、但项目里一定会遇到的坑我会多花点篇幅讲。1. PDL到底是干什么的为什么Tessent离不开它1.1 用一句话理解PDL的定位PDL的全称是Procedural Description Language直译过来是“过程描述语言”。名字听起来很学术但你把它当成“描述测试动作的剧本”就很好理解了。我们在Tessent里做DFT设计、插入扫描链、做MBIST、生成pattern最终目的都是为了让芯片在生产之后能被测试设备ATE正确测试。但测试不是简单地把一串01灌进去就行——你要告诉工具“什么时候拉高时钟”、“什么时候切换模式”、“扫描链怎么移位”、“capture窗口在哪几个周期”这些动作按什么顺序执行、每个周期信号怎么变化就是PDL干的事。在Tessent的体系里PDL负责把测试流程从一个抽象的意图比如“做一次capture”翻译成具体的、逐周期可执行的信号序列。它的存在让同一套测试描述可以适配不同的工具Tessent Shell、Tessent MBIST、Tessent Diagnosis等和不同的输出格式STIL、VCD、EVCD、WGL等这也是PDL最值钱的地方。1.2 PDL在Tessent工具链里的真实位置如果你用过Tessent应该对Tessent Shell不陌生。Tessent Shell是整个Tessent工具链的命令行交互入口而PDL就是运行在Tessent Shell环境里、由TCL语法扩展出来的描述语言。关键在于PDL不是单独存在的它是测试流程的“中间语言”。我画过一张图来给自己理顺关系文字描述就是这样设计侧RTL/网表 DFT约束 → Tessent DFT/Tessent Scan → 插入扫描链、压缩逻辑、MBIST控制器流程侧PDL描述Procedure Macro → 定义测试时序和操作 → 工具执行后生成PatternSTIL/WGL或激励文件VCD/EVCD执行侧生成的Pattern交给仿真器如Tessent的仿真环境或ATE完成测试或诊断。所以PDL是夹在“测试意图”和“最终pattern”之间的那层描述。你写得越规范后面工具生成的pattern就越可靠调试芯片时序问题时也能更快定位。1.3 从热词看需求PDL和MBIST、SSN的关联从近期的关注度来看很多人搜“Tessent PDL”的时候往往是在做MBIST或者SSN相关的项目。这个关联性很强MBIST场景Tessent MBIST会生成Memory BIST Controller而这些控制器的行为初始化、启动BIST、等待完成、结果判断会有一套标准的PDL描述。当你需要定制测试流程比如在BIST前后插入特定的握手时序改的就是PDL。SSN场景SSNStreaming Scan Network是Tessent近年主推的测试压缩/访问架构它用流式协议替代传统的TAMTest Access Mechanism接口。SSN的核心优势之一就是协议灵活、引脚少但这也让时序描述的复杂度明显上升——你靠的就是PDL精确描述SSN通道上的命令和数据流。所以你会发现PDL不仅是“会写就行”它直接决定了你在MBIST、SSN这类复杂DFT架构下能不能把设计跑通、跑顺。2. PDL语法核心拆解搞懂这两块就能上手2.1 两大基础单元Procedure和MacroPDL语法体系里最主要的两块就是Procedure过程和Macro宏。先看Procedure。它是PDL里最基本的时序定义单元描述“一段具体的、包含多个周期的测试动作”。比如你可以定义一个“初始化过程”proc initialize {} { set_signal test_clk 0 set_signal test_rst 1 repeat 5 { pulse test_clk } }这段PDL的意思是把时钟信号初始化为低电平把复位信号设置为高电平然后连续给5个时钟脉冲。这是最典型的PDL用法——用“信号赋值 周期动作”的组合来描述一段可执行的操作序列。Macro就不一样了。它不是新定义一段时序而是把已有的Procedure和其他动作组合成一个更高层的操作单元。举个例子你可以把“初始化 加载多个扫描链”打包成一个macromacro load_unload { initialize set_signal scan_en 1 repeat 10 { pulse test_clk } }调用这个macro就相当于按顺序执行了里面的所有步骤。宏的好处显而易见当你在写复杂的MBIST流程或者SSN协议序列时不用每次把几十行底层动作重新写一遍直接调用封装好的macro就行。而且宏可以嵌套也能接收参数复用性非常好。2.2 时序描述方式Cycle-Based 与 Event-BasedPDL支持两种时序描述风格这是很多新手容易搞混的地方。Cycle-Based基于周期每个时钟周期都明确列出信号的期望值。比如“这个周期扫描使能1时钟上升沿数据移位”这种描述方式。优点是好懂、直观缺点是在复杂的长流程里行数会爆炸而且和具体时序周期的耦合太强。Event-Based基于事件不关心每个周期只描述关键事件发生的顺序和时刻。比如“在第5个时钟上升沿之后拉高capture时钟在下降沿时读取响应数据”。Event-Based描述更接近真实硬件行为也更灵活特别适合SSN这类协议复杂、依赖事件对齐的场景。下面这段是Event-Based风格的一个简单示意proc capture {} { set_time_unit ns set_signal capture_ck -event {rise 5} set_signal capture_ck -event {fall 10} }它描述的是在5ns时刻capture时钟上升沿10ns时刻下降沿。工具会基于这些事件自动推算周期和时序关系。从工程实践角度看我的建议是如果你的设计时序比较规整、周期固定优先用Cycle-Based容易维护如果协议复杂、需要精确对齐多个信号的变化时刻就用Event-Based。两者混合使用在Tessent里也是允许的关键是整个team要统一风格不然review代码的时候会崩溃。2.3 数据接口定义set_signal与端口映射PDL要操作的对象是设计里的信号。在写PDL之前你得先把这些信号“声明”出来告诉工具哪些是时钟、哪些是复位、哪些是数据端口。这部分主要靠set_signal命令。最基础的用法是声明端口类型set_signal test_clk -port test_clk -type pdl_clock set_signal test_rst -port test_rst -type pdl_reset这里把test_clk声明为PDL时钟信号test_rst声明为PDL复位信号。声明之后PDL里才能对这两个信号做周期动作。不止如此PDL还支持把design内部信号映射到操作端口。这个在MBIST场景特别常用——你可能需要从控制器内部拉出一个状态信号用来判断BIST是否执行完毕。做法类似set_signal bist_done -pin bist_controller/bist_done这样就可以在PDL里轮询这个内部信号的状态实现“等待BIST完成”这种逻辑。很多复杂流程的实现本质上就是靠这些内部信号的暴露和访问能力。2.4 层次化调用与TCL能力的融合PDL本身是建立在TCL语言之上的这意味着你在PDL里可以使用TCL的控制流、变量、函数、正则表达式等一整套能力。举个例子如果你有多个类似的通道要逐个初始化完全可以用TCL循环来实现for {set ch 0} {$ch 8} {incr ch} { set_signal ssn_ch${ch}_enable 1 repeat 2 { pulse test_clk } }这里用了TCL的for循环和变量拼接把8个通道的使能动作统一完成。底层TCL能力大大减轻了PDL的重复描述负担也让PDL具备了“可编程”的灵活性。实际写代码时我经常把复杂计算放在TCL层完成PDL只负责时序动作这样两者各司其职代码清晰度会高很多。3. 实操从零开始搭一个Tessent PDL流程3.1 环境准备与基本配置在动手之前得先把环境搞定。假设你已经装好了Tessent工具套件如果还没装找公司的CAD或者IT支持流程走一遍就行这里不展开讲工具获取渠道并且license和库文件都已配置OK。进入Tessent Shell之后第一步是加载设计。常见的做法是读取门级网表read_verilog ./netlist/top_gate.v read_cell_library ./lib/tsmc28hpc_stdcells.lib然后设置基本的设计约束比如时钟频率、模式信号等这些约束会直接影响后面PDL生成pattern的质量add_clock -port clk -period 10 add_scan_mode -name scan_mode -enable_scan_enable scan_enable从这里开始设计已经进入了Tessent Shell的管理范围接下来就可以写PDL、跑了。3.2 用PDL定义一条完整的测试流程假设我们要对一个简单的扫描设计做一次“load_unload capture”的流程测试。先定义好时钟和复位信号set_signal test_clk -port clk -type pdl_clock set_signal test_rst -port rst_n -type pdl_reset然后定义一个初始化和一个load流程proc initialize {} { set_signal test_rst 0 repeat 2 { pulse test_clk } set_signal test_rst 1 } proc load_unload {} { set_signal scan_enable 1 repeat 10 { pulse test_clk } set_signal scan_enable 0 }最后定义一个capture过程proc capture_cycle {} { set_signal capture_clock 1 pulse test_clk set_signal capture_clock 0 }执行的时候直接在Tessent Shell里调用这些过程即可。当然真实的工程里你不会自己手动敲这些Tessent在生成IP和controller时会自动生成一套标准PDL文件。你需要做的通常是理解它、调整它、在它基础上扩展。3.3 MBIST场景下的PDL应用实例MBIST是PDL最常见的应用场景之一。Tessent MBIST生成的控制器对外行为会有一套完整的PDL描述用来定义BIST的启动、等待、结果读取流程。默认PDL大致长这样proc bist_start {} { set_signal bist_enable 1 pulse test_clk } proc bist_wait_done {} { while {[get_value bist_done] ! 1} { pulse test_clk } } proc bist_read_result {} { set_signal result_valid 1 set result_data [get_value bist_result_data] puts BIST result: $result_data }这三个procedure分别对应BIST的启动、等待完成、读取结果。在很多实际项目里你会遇到控制器时序不完全匹配的情况。比如芯片的前端逻辑需要一个握手信号才能启动BIST那就在bist_start里额外加一步置位握手信号的PDL。再比如有些项目需要在一个BIST完成后立刻触发下一个地址段的BIST这种连续执行的逻辑也能用PDL循环来实现proc run_all_bist {} { for {set segment 0} {$segment 4} {incr segment} { set_signal segment_addr $segment bist_start bist_wait_done bist_read_result } }这就是PDL可编程带来的好处——测试流程的控制逻辑完全由你掌握不限制于工具生成的固定模板。3.4 SSN场景下的PDL扩展思路SSNStreaming Scan Network是Tessent应对大规模SoC测试访问的一种架构思路。它通过流式协议把测试数据和命令广播给各个测试通道相比传统TAM能大幅减少测试引脚和布线资源。面对SSNPDL的挑战在于描述流式协议时的时序精度。比如你要往SSN总线上发一个命令就得精确控制命令有效信号、数据线和时钟的对齐关系。下面是一段Event-Based风格的SSN命令发送示意proc ssn_send_command { cmd_data } { set_signal ssn_cmd_valid 1 set_signal ssn_cmd_data $cmd_data set_signal ssn_clk -event {rise 0} set_signal ssn_clk -event {fall 5} set_signal ssn_cmd_valid 0 }关键点在于SSN的时序要求命令数据和valid信号在同一时钟沿附近达到稳定并且不同通道之间可能有相位差。用Event-Based方式描述会比Cycle-Based更灵活也更容易应对后端时序收敛后的相位偏移。从我的实践经验看SSN项目里PDL的调试往往不是语法问题而是协议理解问题。你得对着SSN协议的时序图把每个PDL事件翻译成实际的引脚电平变化这非常考验耐心。4. PDL调试与常见问题排查实录4.1 从报错信息快速定位PDL问题PDL报错信息在某些版本里并不友好但报错类型基本集中在这几类信号未声明PDL里用了set_signal没声明过的信号。这类错误最好排查——报错会直接给出信号名回到文件顶部补一条set_signal声明即可。时序检查失败Timing Check Failure信号变化顺序和工具检查规则冲突。比如你在时钟上升沿之后才设置数据但工具要求数据必须在上升沿之前稳定。这类问题需要回头对着时序图确认每个事件的前后关系。宏嵌套层数过多或递归调用宏嵌套本身没问题但不要搞出无限递归。遇到stack overflow的报错检查宏的定义有没有形成环。对比一下我之前遇到的最常见问题和解决思路问题现象可能原因优先排查路径Pattern仿真时数据不匹配PDL里信号时序顺序有误用波形图对比PDL事件和期望波形BIST流程卡在等待状态握手信号或ready信号未拉高检查PDL里对应信号的赋值时机SSN通道数据错位命令数据与时钟沿对齐不精确用Event-Based重写命令发送段STIL输出时报协议错误PDL描述的时钟组和ATE约束不一致检查时钟定义与STIL protocol的匹配性4.2 用Waveform级调试定位时序问题PDL调试和普通编程调试有很大区别——它不只是逻辑问题更多是波形对不上。一个比较高效的排查办法是在Tessent环境里生成VCD/EVCD波形然后用波形查看器打开把PDL里期望的信号变化节奏和实际波形对齐看。具体操作路径是执行完PDL流程后用工具把仿真波形导出然后逐周期比对。这里有一个很实用的习惯别一上来就盯着上千个周期的波形看先把关键节点的信号比如时钟、复位、scan_enable、capture_clock、bist_done挑出来看这几个信号的变化是否符合预期。等关键节点对上了再去排查具体的数据路径。4.3 在Tessent Shell里快速验证PDL片段写PDL的过程不建议“一把梭”写完整个文件再跑。Tessent Shell是交互式环境完全可以一段一段地执行、验证。比如你刚写完一个process直接在Shell里调用它然后立刻检查波形或者打印信号值source my_pdl.tcl initialize # 或者只调里面的一步 set_signal test_rst 1 report_signal_value test_rst这样能非常直观地看到每一条PDL语句的实际效果。发现问题时改一行、跑一次比写完几十行再整体调要高效太多。4.4 踩坑经验PDL中容易忽略的3个细节第一个坑是复位信号的处理。PDL里你可能想当然地认为“复位释放之后设计就稳定了”但很多设计在复位释放后还需要几个周期的稳定时间。如果不加足够的延迟周期后面紧接着的capture动作就会捕获到不稳定的值。第二个坑是时钟域交叉的建模。当设计里有多个异步时钟域时PDL中给不同时钟域分配时钟沿的方式要非常小心。如果两个域的时钟沿在PDL里被设成完全对齐而实际芯片是异步的那么生成的pattern在ATE上可能产生冲突。解决办法是把时钟沿设置成有微小的偏移或者在不同阶段分别驱动时钟。第三个坑是宏的参数传递中引号与花括号。TCL的变量替换规则会在这里捣乱。一个典型错误是忘记使用花括号导致变量提前展开# 错误变量在定义时就展开而非调用时 macro bad_example { pulse test_clk $num_cycles }改成# 正确用花括号延迟展开 macro good_example { num_cycles } { repeat $num_cycles { pulse test_clk } }这种细节问题没有编译器的强约束全靠经验积累。5. 进阶话题PDL与Pattern生成、诊断的联动5.1 PDL在Pattern生成流程中的角色PDL写完、验证完之后最核心的产出就是能被下游工具消费的Pattern文件。在Tessent流程里PDL会被“编译”成语义等价的事件序列再映射到具体的pattern格式。常见的有STIL面向ATE的行业标准测试语言结构清晰适合直接烧录到测试机。WGL另一种ATE格式在某些旧测试机台上还在用。VCD/EVCD面向仿真的波形转储格式主要用于功能验证阶段的调试。你在Tessent里用write_patterns之类命令导出这些文件时命令内部会执行“PDL语义解析 → 事件序列抽取 → 目标格式映射”这条链路。链路里的任何一环出问题最后产出的文件都会有偏差。所以PDL是源头源头的时序描述错了后面转成什么格式都ode错。5.2 诊断场景下PDL的辅助作用IC诊断Diagnosis是PDL另一个有趣的应用领域。当芯片失效时诊断工具会拿到ATE上记录的失效pattern然后反推是哪个逻辑单元的哪个故障导致的。而PDL在这里的作用是还原测试时的激励时序。因为诊断工具需要知道你当时是怎么把测试向量灌进去的Capture的窗口到底在哪里扫描链的移位时序是否符合预期。如果你在PDL里做了定制化调整比如加了额外的等待周期诊断的时候就必须对这些调整进行等价转换否则失效分析会偏。所以在项目关键节点比如流片前PDL的状态一定要冻结并且要和最终产出的pattern文件严格对齐。我经历过一次版本没对齐导致的诊断误判那滋味确实不好受。5.3 与Tessent SSN的深度结合实例SSN作为新一代测试访问架构在大型SoC项目里越来越普及。PDL与SSN的结合关键在于要把SSN的命令时序准确映射到每一个测试通道。举一个实际项目的例子某SoC里有8条SSN通道每条通道对应一组memory BIST控制器。传统做法是每条通道单独写一组PDL流程但这样维护成本高也容易引入不一致性。更优雅的做法是把SSN命令封装成一个可参数化的macro所有通道共用macro ssn_channel_command { ch cmd_data } { set_signal ssn_ch${ch}_cmd_valid 1 set_signal ssn_ch${ch}_cmd_data $cmd_data set_signal ssn_ch${ch}_clk -event {rise 0} set_signal ssn_ch${ch}_clk -event {fall 5} set_signal ssn_ch${ch}_cmd_valid 0 }这样任何一条通道的命令发送动作都走到同一个宏里修改协议时只需要改一处。这种“以宏为中心的PDL设计”思路是应对复杂DFT结构的关键。6. 团队协作与PDL代码规范6.1 命名规范让你三个月后还能看懂自己的PDLPDL代码写起来快但维护起来最容易翻车。建议从项目第一天就定好命名规则。时钟类信号用clk/ck结尾复位类用rst/rst_n模式控制类用mode/en/sel数据类用data/load/result。宏的命名用动词开头比如run_、send_、load_、capture_一看就知道这个宏干了什么事。过程procedure同理。命名这件事看起来无关紧要但DFT项目动辄几十个流程文件、几百个宏没有规范的命名后面接手的兄弟真的会崩溃。6.2 版本控制和评审要点PDL文件应当纳入版本管理并且在每个版本节点与pattern文件、诊断结果进行一对一的关联。提一个复盘技巧在发布pattern之前建立一个“PDL → pattern → 仿真结果”三级对照表每次修改PDL后都同步更新这个表。这样一旦出现问题能迅速定位是PDL改动引起的还是后端时序变化引起的。同时PDL的代码评审不要只看语法一定要让有DFT经验的人对照时序图逐段review。你写了一个看起来很顺的procedure可能和硬件协议根本对不上。6.3 我踩过的一个印象深刻的坑最后分享一个个人经历。某次项目里我在MBIST流程里加了一个“在启动BIST前先做一次全局复位”的PDL操作本意是想确保所有控制器处于干净状态。结果pattern仿真时某个存储器的初始化时序完全乱了——原因是复位操作把MBIST控制器内部的状态也一并清零了而控制器需要在上电后经过特定的初始化序列才能开始正常工作。这个问题的教训是PDL里的时序修改不能只从“测试逻辑”角度出发还要理解内部控制器的状态机行为。在改任何“看似安全”的全局操作前至少要对照设计文档确认这个操作不会影响后续流程依赖的内部状态。做DFT有时候觉得像是在做“织毛衣”——每一根线都要对得上错一根后面全乱。而PDL就是那本记录怎么织的说明书。把PDL吃透你的Tessent流程才能真正玩得转。
做DFT这么多年工具链里接触最多的就是Tessent这套东西。早年间用Tessent的时候打交道最多的是各种测试协议、pattern文件、诊断log说实话PDLProcedural Description Language一直是个让我又爱又恨的角色——爱的是它能把测试流程和时序写得清清楚楚恨的是刚上手那会儿没少被它的语法和层级关系折腾。这几年下来踩坑踩多了反而觉得PDL是整个Tessent流程里最值得花时间搞明白的一块。如果你也在做DFT、可测试性设计、或者刚接手Tessent相关的项目这篇东西就是写给你看的。我尽量不讲太多工具说明书里已经写烂的废话而是把PDL是什么、怎么用、在MBIST和SSN这些场景下怎么落地以及实际工程里怎么排查问题一次说透。尤其是那些文档里不会写、但项目里一定会遇到的坑我会多花点篇幅讲。1. PDL到底是干什么的为什么Tessent离不开它1.1 用一句话理解PDL的定位PDL的全称是Procedural Description Language直译过来是“过程描述语言”。名字听起来很学术但你把它当成“描述测试动作的剧本”就很好理解了。我们在Tessent里做DFT设计、插入扫描链、做MBIST、生成pattern最终目的都是为了让芯片在生产之后能被测试设备ATE正确测试。但测试不是简单地把一串01灌进去就行——你要告诉工具“什么时候拉高时钟”、“什么时候切换模式”、“扫描链怎么移位”、“capture窗口在哪几个周期”这些动作按什么顺序执行、每个周期信号怎么变化就是PDL干的事。在Tessent的体系里PDL负责把测试流程从一个抽象的意图比如“做一次capture”翻译成具体的、逐周期可执行的信号序列。它的存在让同一套测试描述可以适配不同的工具Tessent Shell、Tessent MBIST、Tessent Diagnosis等和不同的输出格式STIL、VCD、EVCD、WGL等这也是PDL最值钱的地方。1.2 PDL在Tessent工具链里的真实位置如果你用过Tessent应该对Tessent Shell不陌生。Tessent Shell是整个Tessent工具链的命令行交互入口而PDL就是运行在Tessent Shell环境里、由TCL语法扩展出来的描述语言。关键在于PDL不是单独存在的它是测试流程的“中间语言”。我画过一张图来给自己理顺关系文字描述就是这样设计侧RTL/网表 DFT约束 → Tessent DFT/Tessent Scan → 插入扫描链、压缩逻辑、MBIST控制器流程侧PDL描述Procedure Macro → 定义测试时序和操作 → 工具执行后生成PatternSTIL/WGL或激励文件VCD/EVCD执行侧生成的Pattern交给仿真器如Tessent的仿真环境或ATE完成测试或诊断。所以PDL是夹在“测试意图”和“最终pattern”之间的那层描述。你写得越规范后面工具生成的pattern就越可靠调试芯片时序问题时也能更快定位。1.3 从热词看需求PDL和MBIST、SSN的关联从近期的关注度来看很多人搜“Tessent PDL”的时候往往是在做MBIST或者SSN相关的项目。这个关联性很强MBIST场景Tessent MBIST会生成Memory BIST Controller而这些控制器的行为初始化、启动BIST、等待完成、结果判断会有一套标准的PDL描述。当你需要定制测试流程比如在BIST前后插入特定的握手时序改的就是PDL。SSN场景SSNStreaming Scan Network是Tessent近年主推的测试压缩/访问架构它用流式协议替代传统的TAMTest Access Mechanism接口。SSN的核心优势之一就是协议灵活、引脚少但这也让时序描述的复杂度明显上升——你靠的就是PDL精确描述SSN通道上的命令和数据流。所以你会发现PDL不仅是“会写就行”它直接决定了你在MBIST、SSN这类复杂DFT架构下能不能把设计跑通、跑顺。2. PDL语法核心拆解搞懂这两块就能上手2.1 两大基础单元Procedure和MacroPDL语法体系里最主要的两块就是Procedure过程和Macro宏。先看Procedure。它是PDL里最基本的时序定义单元描述“一段具体的、包含多个周期的测试动作”。比如你可以定义一个“初始化过程”proc initialize {} { set_signal test_clk 0 set_signal test_rst 1 repeat 5 { pulse test_clk } }这段PDL的意思是把时钟信号初始化为低电平把复位信号设置为高电平然后连续给5个时钟脉冲。这是最典型的PDL用法——用“信号赋值 周期动作”的组合来描述一段可执行的操作序列。Macro就不一样了。它不是新定义一段时序而是把已有的Procedure和其他动作组合成一个更高层的操作单元。举个例子你可以把“初始化 加载多个扫描链”打包成一个macromacro load_unload { initialize set_signal scan_en 1 repeat 10 { pulse test_clk } }调用这个macro就相当于按顺序执行了里面的所有步骤。宏的好处显而易见当你在写复杂的MBIST流程或者SSN协议序列时不用每次把几十行底层动作重新写一遍直接调用封装好的macro就行。而且宏可以嵌套也能接收参数复用性非常好。2.2 时序描述方式Cycle-Based 与 Event-BasedPDL支持两种时序描述风格这是很多新手容易搞混的地方。Cycle-Based基于周期每个时钟周期都明确列出信号的期望值。比如“这个周期扫描使能1时钟上升沿数据移位”这种描述方式。优点是好懂、直观缺点是在复杂的长流程里行数会爆炸而且和具体时序周期的耦合太强。Event-Based基于事件不关心每个周期只描述关键事件发生的顺序和时刻。比如“在第5个时钟上升沿之后拉高capture时钟在下降沿时读取响应数据”。Event-Based描述更接近真实硬件行为也更灵活特别适合SSN这类协议复杂、依赖事件对齐的场景。下面这段是Event-Based风格的一个简单示意proc capture {} { set_time_unit ns set_signal capture_ck -event {rise 5} set_signal capture_ck -event {fall 10} }它描述的是在5ns时刻capture时钟上升沿10ns时刻下降沿。工具会基于这些事件自动推算周期和时序关系。从工程实践角度看我的建议是如果你的设计时序比较规整、周期固定优先用Cycle-Based容易维护如果协议复杂、需要精确对齐多个信号的变化时刻就用Event-Based。两者混合使用在Tessent里也是允许的关键是整个team要统一风格不然review代码的时候会崩溃。2.3 数据接口定义set_signal与端口映射PDL要操作的对象是设计里的信号。在写PDL之前你得先把这些信号“声明”出来告诉工具哪些是时钟、哪些是复位、哪些是数据端口。这部分主要靠set_signal命令。最基础的用法是声明端口类型set_signal test_clk -port test_clk -type pdl_clock set_signal test_rst -port test_rst -type pdl_reset这里把test_clk声明为PDL时钟信号test_rst声明为PDL复位信号。声明之后PDL里才能对这两个信号做周期动作。不止如此PDL还支持把design内部信号映射到操作端口。这个在MBIST场景特别常用——你可能需要从控制器内部拉出一个状态信号用来判断BIST是否执行完毕。做法类似set_signal bist_done -pin bist_controller/bist_done这样就可以在PDL里轮询这个内部信号的状态实现“等待BIST完成”这种逻辑。很多复杂流程的实现本质上就是靠这些内部信号的暴露和访问能力。2.4 层次化调用与TCL能力的融合PDL本身是建立在TCL语言之上的这意味着你在PDL里可以使用TCL的控制流、变量、函数、正则表达式等一整套能力。举个例子如果你有多个类似的通道要逐个初始化完全可以用TCL循环来实现for {set ch 0} {$ch 8} {incr ch} { set_signal ssn_ch${ch}_enable 1 repeat 2 { pulse test_clk } }这里用了TCL的for循环和变量拼接把8个通道的使能动作统一完成。底层TCL能力大大减轻了PDL的重复描述负担也让PDL具备了“可编程”的灵活性。实际写代码时我经常把复杂计算放在TCL层完成PDL只负责时序动作这样两者各司其职代码清晰度会高很多。3. 实操从零开始搭一个Tessent PDL流程3.1 环境准备与基本配置在动手之前得先把环境搞定。假设你已经装好了Tessent工具套件如果还没装找公司的CAD或者IT支持流程走一遍就行这里不展开讲工具获取渠道并且license和库文件都已配置OK。进入Tessent Shell之后第一步是加载设计。常见的做法是读取门级网表read_verilog ./netlist/top_gate.v read_cell_library ./lib/tsmc28hpc_stdcells.lib然后设置基本的设计约束比如时钟频率、模式信号等这些约束会直接影响后面PDL生成pattern的质量add_clock -port clk -period 10 add_scan_mode -name scan_mode -enable_scan_enable scan_enable从这里开始设计已经进入了Tessent Shell的管理范围接下来就可以写PDL、跑了。3.2 用PDL定义一条完整的测试流程假设我们要对一个简单的扫描设计做一次“load_unload capture”的流程测试。先定义好时钟和复位信号set_signal test_clk -port clk -type pdl_clock set_signal test_rst -port rst_n -type pdl_reset然后定义一个初始化和一个load流程proc initialize {} { set_signal test_rst 0 repeat 2 { pulse test_clk } set_signal test_rst 1 } proc load_unload {} { set_signal scan_enable 1 repeat 10 { pulse test_clk } set_signal scan_enable 0 }最后定义一个capture过程proc capture_cycle {} { set_signal capture_clock 1 pulse test_clk set_signal capture_clock 0 }执行的时候直接在Tessent Shell里调用这些过程即可。当然真实的工程里你不会自己手动敲这些Tessent在生成IP和controller时会自动生成一套标准PDL文件。你需要做的通常是理解它、调整它、在它基础上扩展。3.3 MBIST场景下的PDL应用实例MBIST是PDL最常见的应用场景之一。Tessent MBIST生成的控制器对外行为会有一套完整的PDL描述用来定义BIST的启动、等待、结果读取流程。默认PDL大致长这样proc bist_start {} { set_signal bist_enable 1 pulse test_clk } proc bist_wait_done {} { while {[get_value bist_done] ! 1} { pulse test_clk } } proc bist_read_result {} { set_signal result_valid 1 set result_data [get_value bist_result_data] puts BIST result: $result_data }这三个procedure分别对应BIST的启动、等待完成、读取结果。在很多实际项目里你会遇到控制器时序不完全匹配的情况。比如芯片的前端逻辑需要一个握手信号才能启动BIST那就在bist_start里额外加一步置位握手信号的PDL。再比如有些项目需要在一个BIST完成后立刻触发下一个地址段的BIST这种连续执行的逻辑也能用PDL循环来实现proc run_all_bist {} { for {set segment 0} {$segment 4} {incr segment} { set_signal segment_addr $segment bist_start bist_wait_done bist_read_result } }这就是PDL可编程带来的好处——测试流程的控制逻辑完全由你掌握不限制于工具生成的固定模板。3.4 SSN场景下的PDL扩展思路SSNStreaming Scan Network是Tessent应对大规模SoC测试访问的一种架构思路。它通过流式协议把测试数据和命令广播给各个测试通道相比传统TAM能大幅减少测试引脚和布线资源。面对SSNPDL的挑战在于描述流式协议时的时序精度。比如你要往SSN总线上发一个命令就得精确控制命令有效信号、数据线和时钟的对齐关系。下面是一段Event-Based风格的SSN命令发送示意proc ssn_send_command { cmd_data } { set_signal ssn_cmd_valid 1 set_signal ssn_cmd_data $cmd_data set_signal ssn_clk -event {rise 0} set_signal ssn_clk -event {fall 5} set_signal ssn_cmd_valid 0 }关键点在于SSN的时序要求命令数据和valid信号在同一时钟沿附近达到稳定并且不同通道之间可能有相位差。用Event-Based方式描述会比Cycle-Based更灵活也更容易应对后端时序收敛后的相位偏移。从我的实践经验看SSN项目里PDL的调试往往不是语法问题而是协议理解问题。你得对着SSN协议的时序图把每个PDL事件翻译成实际的引脚电平变化这非常考验耐心。4. PDL调试与常见问题排查实录4.1 从报错信息快速定位PDL问题PDL报错信息在某些版本里并不友好但报错类型基本集中在这几类信号未声明PDL里用了set_signal没声明过的信号。这类错误最好排查——报错会直接给出信号名回到文件顶部补一条set_signal声明即可。时序检查失败Timing Check Failure信号变化顺序和工具检查规则冲突。比如你在时钟上升沿之后才设置数据但工具要求数据必须在上升沿之前稳定。这类问题需要回头对着时序图确认每个事件的前后关系。宏嵌套层数过多或递归调用宏嵌套本身没问题但不要搞出无限递归。遇到stack overflow的报错检查宏的定义有没有形成环。对比一下我之前遇到的最常见问题和解决思路问题现象可能原因优先排查路径Pattern仿真时数据不匹配PDL里信号时序顺序有误用波形图对比PDL事件和期望波形BIST流程卡在等待状态握手信号或ready信号未拉高检查PDL里对应信号的赋值时机SSN通道数据错位命令数据与时钟沿对齐不精确用Event-Based重写命令发送段STIL输出时报协议错误PDL描述的时钟组和ATE约束不一致检查时钟定义与STIL protocol的匹配性4.2 用Waveform级调试定位时序问题PDL调试和普通编程调试有很大区别——它不只是逻辑问题更多是波形对不上。一个比较高效的排查办法是在Tessent环境里生成VCD/EVCD波形然后用波形查看器打开把PDL里期望的信号变化节奏和实际波形对齐看。具体操作路径是执行完PDL流程后用工具把仿真波形导出然后逐周期比对。这里有一个很实用的习惯别一上来就盯着上千个周期的波形看先把关键节点的信号比如时钟、复位、scan_enable、capture_clock、bist_done挑出来看这几个信号的变化是否符合预期。等关键节点对上了再去排查具体的数据路径。4.3 在Tessent Shell里快速验证PDL片段写PDL的过程不建议“一把梭”写完整个文件再跑。Tessent Shell是交互式环境完全可以一段一段地执行、验证。比如你刚写完一个process直接在Shell里调用它然后立刻检查波形或者打印信号值source my_pdl.tcl initialize # 或者只调里面的一步 set_signal test_rst 1 report_signal_value test_rst这样能非常直观地看到每一条PDL语句的实际效果。发现问题时改一行、跑一次比写完几十行再整体调要高效太多。4.4 踩坑经验PDL中容易忽略的3个细节第一个坑是复位信号的处理。PDL里你可能想当然地认为“复位释放之后设计就稳定了”但很多设计在复位释放后还需要几个周期的稳定时间。如果不加足够的延迟周期后面紧接着的capture动作就会捕获到不稳定的值。第二个坑是时钟域交叉的建模。当设计里有多个异步时钟域时PDL中给不同时钟域分配时钟沿的方式要非常小心。如果两个域的时钟沿在PDL里被设成完全对齐而实际芯片是异步的那么生成的pattern在ATE上可能产生冲突。解决办法是把时钟沿设置成有微小的偏移或者在不同阶段分别驱动时钟。第三个坑是宏的参数传递中引号与花括号。TCL的变量替换规则会在这里捣乱。一个典型错误是忘记使用花括号导致变量提前展开# 错误变量在定义时就展开而非调用时 macro bad_example { pulse test_clk $num_cycles }改成# 正确用花括号延迟展开 macro good_example { num_cycles } { repeat $num_cycles { pulse test_clk } }这种细节问题没有编译器的强约束全靠经验积累。5. 进阶话题PDL与Pattern生成、诊断的联动5.1 PDL在Pattern生成流程中的角色PDL写完、验证完之后最核心的产出就是能被下游工具消费的Pattern文件。在Tessent流程里PDL会被“编译”成语义等价的事件序列再映射到具体的pattern格式。常见的有STIL面向ATE的行业标准测试语言结构清晰适合直接烧录到测试机。WGL另一种ATE格式在某些旧测试机台上还在用。VCD/EVCD面向仿真的波形转储格式主要用于功能验证阶段的调试。你在Tessent里用write_patterns之类命令导出这些文件时命令内部会执行“PDL语义解析 → 事件序列抽取 → 目标格式映射”这条链路。链路里的任何一环出问题最后产出的文件都会有偏差。所以PDL是源头源头的时序描述错了后面转成什么格式都ode错。5.2 诊断场景下PDL的辅助作用IC诊断Diagnosis是PDL另一个有趣的应用领域。当芯片失效时诊断工具会拿到ATE上记录的失效pattern然后反推是哪个逻辑单元的哪个故障导致的。而PDL在这里的作用是还原测试时的激励时序。因为诊断工具需要知道你当时是怎么把测试向量灌进去的Capture的窗口到底在哪里扫描链的移位时序是否符合预期。如果你在PDL里做了定制化调整比如加了额外的等待周期诊断的时候就必须对这些调整进行等价转换否则失效分析会偏。所以在项目关键节点比如流片前PDL的状态一定要冻结并且要和最终产出的pattern文件严格对齐。我经历过一次版本没对齐导致的诊断误判那滋味确实不好受。5.3 与Tessent SSN的深度结合实例SSN作为新一代测试访问架构在大型SoC项目里越来越普及。PDL与SSN的结合关键在于要把SSN的命令时序准确映射到每一个测试通道。举一个实际项目的例子某SoC里有8条SSN通道每条通道对应一组memory BIST控制器。传统做法是每条通道单独写一组PDL流程但这样维护成本高也容易引入不一致性。更优雅的做法是把SSN命令封装成一个可参数化的macro所有通道共用macro ssn_channel_command { ch cmd_data } { set_signal ssn_ch${ch}_cmd_valid 1 set_signal ssn_ch${ch}_cmd_data $cmd_data set_signal ssn_ch${ch}_clk -event {rise 0} set_signal ssn_ch${ch}_clk -event {fall 5} set_signal ssn_ch${ch}_cmd_valid 0 }这样任何一条通道的命令发送动作都走到同一个宏里修改协议时只需要改一处。这种“以宏为中心的PDL设计”思路是应对复杂DFT结构的关键。6. 团队协作与PDL代码规范6.1 命名规范让你三个月后还能看懂自己的PDLPDL代码写起来快但维护起来最容易翻车。建议从项目第一天就定好命名规则。时钟类信号用clk/ck结尾复位类用rst/rst_n模式控制类用mode/en/sel数据类用data/load/result。宏的命名用动词开头比如run_、send_、load_、capture_一看就知道这个宏干了什么事。过程procedure同理。命名这件事看起来无关紧要但DFT项目动辄几十个流程文件、几百个宏没有规范的命名后面接手的兄弟真的会崩溃。6.2 版本控制和评审要点PDL文件应当纳入版本管理并且在每个版本节点与pattern文件、诊断结果进行一对一的关联。提一个复盘技巧在发布pattern之前建立一个“PDL → pattern → 仿真结果”三级对照表每次修改PDL后都同步更新这个表。这样一旦出现问题能迅速定位是PDL改动引起的还是后端时序变化引起的。同时PDL的代码评审不要只看语法一定要让有DFT经验的人对照时序图逐段review。你写了一个看起来很顺的procedure可能和硬件协议根本对不上。6.3 我踩过的一个印象深刻的坑最后分享一个个人经历。某次项目里我在MBIST流程里加了一个“在启动BIST前先做一次全局复位”的PDL操作本意是想确保所有控制器处于干净状态。结果pattern仿真时某个存储器的初始化时序完全乱了——原因是复位操作把MBIST控制器内部的状态也一并清零了而控制器需要在上电后经过特定的初始化序列才能开始正常工作。这个问题的教训是PDL里的时序修改不能只从“测试逻辑”角度出发还要理解内部控制器的状态机行为。在改任何“看似安全”的全局操作前至少要对照设计文档确认这个操作不会影响后续流程依赖的内部状态。做DFT有时候觉得像是在做“织毛衣”——每一根线都要对得上错一根后面全乱。而PDL就是那本记录怎么织的说明书。把PDL吃透你的Tessent流程才能真正玩得转。
