做 PAM-4 高速链路测试的工程师应该都有过类似的经历白天在测试台前反复改参数、按采集按钮晚上导数据、做眼图截图、拼报告。正式认证测试还没排上队预一致性已经把人力吃掉了一大半。我后来认真做了一套面向 PAM-4 预一致性测试的自动化软件核心就是两件事让仪器自动跑完重复测量让测量结果自动变成能复现、能追溯的报告。这篇文章就把整套方案的思考过程和落地细节拆开讲。为什么值得做因为 PAM-4 信号本身比传统 NRZ 信号更“难测”。四个电平叠加出三个眼图信号裕量小符号速率又高任何链路损伤都会被放大。手动操作示波器和误码仪抓波形、调触发、跑算法、记条件最后整理报告单个 case 跑下来几个小时很正常。但如果把测试流程脚本化、自动化同样的 case 可能只需要几分钟还能顺手把之前一直没做好的记录和报告补全。适合看这篇文章的人我默认是三类正在做 100G/lane 及以上产品预研的硬件工程师刚接触 PAM-4 测试、想摆脱“手动点到底”的实验室测试工程师以及准备自己搭一套测试工具的开发者。下面我会从为什么自动化、架构怎么拆、PAM-4 到底测什么、报告怎么设计到完整落地步骤一层层展开。1. 手动走查一遍 PAM-4 预测试就知道自动化省在哪1.1 手动测试的耗时真相很多人觉得预一致性测试就是“把仪表连上按几个按钮看眼图合不合格”。实际上一次完整的 PAM-4 发射机预测试通常包含幅度、眼高眼宽、抖动分解、电平线性度、预加重参数扫描以及类似 TDECQ 这类经过参考通道和参考均衡器计算出来的综合指标。手动跑的时候问题很快就暴露出来了。PAM-4 有上、中、下三个眼不能只看一个眼图需要足够的采样点数否则抖动和眼高数据本身就不稳定TDECQ 这类指标要求采集多组波形、做信号处理后取统计结果抓一次常常不够。等这些做完还要切换通道、切换速率、切换预加重寄存器配置。一个 4 通道模块每个通道跑几十种组合手按示波器按键的次数加起来非常可观。我见过最典型的场景是一个工程师从下午两点开始测到晚上八点才把发射机预测试的一轮数据抓完晚上十点还在整理截图、填 Excel。整个过程里真正有含金量的是判断哪些指标边缘、哪些配置能继续优化但时间全被重复劳动吃掉了。1.2 自动化不是替你“判断”而是替你“跑流程”这里必须把自动化的边界说清楚。自动化的价值不是把工程师从测试台前赶走而是把“重复、繁琐、容易漏记”的部分接管掉让工程师把精力放在对结果的分析上。我把自动化软件的目标定成三点可复现拿到一份报告能看出测试条件、仪器配置、被测对象版本换一个人用同一套系统能跑出可以对比的结果。可扩展测试标准更新、仪器型号更换不需要把所有脚本推倒重来。可追溯测了哪些波形、用了哪版参考通道文件、出了哪些数据全部有记录。所以自动化测试工具本质上是给测试台加了一套“可重复执行的流程引擎”而不是简单替你点几下按钮。2. 把测试平台拆成四层后面所有扩展都不慌我见过不少人的第一版自动化脚本是把仪器厂商的示例代码改一改一个 Python 文件从头写到尾连接仪器、设置参数、采集波形、算指标、画图全揉在一起。单个 case 能跑通但第二个 case、第三台仪器加进来就乱套。后来我把整套软件拆成了四层设备抽象层、用例执行层、数据记录层、报告输出层。前两层在这节先讲数据层和报告层后面单独展开因为它们各自的坑也不少。2.1 设备抽象层让仪表变成可替换的“插头”PAM-4 预一致性测试台上通常有实时示波器、误码仪BERT或者高速信号发生器还可能有一台可编程电源给被测模块供电。每台仪器都有自己的程控命令集直接调用厂商 API 的后果就是代码和具体型号绑死。我在设备抽象层做的事情很简单给每类设备定义一个统一接口底层实现去适配不同厂商的差异。比如示波器统一接口是set_acquisition()、get_waveform()、measure_eye()BERT 则是set_pattern()、set_voltage_swing()、start()、stop()。底层驱动优先使用 VISA 标准也就是通过 pyvisa 配合 NI-VISA 或各家的 IO Libraries 连接仪器。原因有两个一是 VISA 在 LAN、GPIB、USB 上都通实验桌上非常方便二是大部分高端测试仪器都提供 SCPI 命令跨品牌一致性远好过私有 API。这一层多花两天开发时间后期换仪器时能省下大量返工。实验室里同时有泰克、是德、力科示波器是常态没有这层封装每次换设备都是“重写一半代码”。2.2 执行层把测试用例变成数据而不是代码第二层是关键也是我踩坑最多的部分。一开始我把每个测试项都写成 Python 函数参数变了就改函数参数场景多了以后函数签名越来越长最后连调用关系都理不清楚。正确思路是把测试用例变成一段可配置的数据。我用的是一份 JSON 或 YAML 描述文件里面写清楚这个用例的速率、Pattern、通道号、仪表配置、测量项、判断阈值。执行引擎读取这份数据再调用设备抽象层去跑测量。举个例子一份简化后的用例配置长这样{ case_name: tx_tdecq_lane0, data_rate_gbaud: 53.125, pattern: PRBS13Q, lane: 0, swing_mv: 800, pre_emphasis_taps: [0.2, 0.6, 1.0], measurements: [eye_height, eye_width, tdECQ], thresholds: { eye_height_mv: 23, tdECQ_db: 3.4 } }为什么要这么做因为预一致性测试的条件经常变化标准修订会改阈值产品调试过程会调整预加重参数。如果这些都在代码里换条件就要改代码、走回归配置和数据分离之后现场工程师改一版配置文件就能跑新的条件组合开发人员只需要维护执行引擎本身。这一层还要负责流程编排设置示波器、等待波形稳定、抓波、算指标、判断上下限、记录数据。用例本身就是一张流程表执行引擎把它翻译成一条条仪器操作。2.3 数据层波形、测量值、环境记录分开存第三层是最容易被忽视的。很多人把所有结果塞进一个 Excel 或一张 PDF看起来“出报告了”但真要重新分析、再次处理波形、对比两组配置时就发现原始数据已经丢了。我的经验是数据分三类存储每类用同一个 run-id 关联起来原始波形二进制或 HDF5 格式包含采集时间、示波器量程、采样率、通道信息。HDF5 的优势是自描述打开文件就能知道里面存了什么不依赖外部的 Excel 说明。结构化测量结果JSON 或 CSV记录每个测量项的值、上下限、判定结果。环境与状态记录DUT 固件版本、仪表固件版本、连接拓扑、VNA 测得的通道 S 参数文件路径、温度、供电电压、软件版本。这么做最大的好处是报告可以被“反算”。出现过一次测试结果有争议后来我们就是用保存的原始波形和配置重新跑了一遍算法确认是参考通道文件用错了而不是产品真的有问题。没有原始数据这种复现根本做不到。3. PAM-4 测试项到底在测什么软件必须理解的物理层自动化软件如果只是控制仪表那和一套遥控器没区别。真正有价值的部分是知道 PAM-4 信号哪些指标值得测、哪些指标容易受测量细节影响然后把它们变成可执行的测量流程。3.1 PAM-4 核心测量项眼高、抖动、TDECQ 这些指标为什么重要PAM-4 用四个电平表示 00、01、11、10每个符号携带两个比特。四个电平叠加起来垂直方向上有三个眼而且三个眼的信号裕量不一样通常中间眼和最下边眼会更紧张。这决定了软件测量时必须分别处理三个眼不能像 NRZ 那样只看一个眼。我把常用测量项整理成一张表方便对照测量项它说明什么物理问题自动化侧注意点眼高 / 眼宽电压和时域裕量直接关系接收端能否正确采样三个眼分别测量同时取最差眼抖动TJ / RJ / DJ时序裕量和随机噪声成分需要足够长的波形样本统计才有意义电平分离/线性度四个电平是否均匀、是否存在压缩或非线性测量在不同幅值条件下做和预加重参数相关联TDECQ经过参考通道和均衡器后信号相比理想发射机的劣化程度依赖参考通道文件和均衡器配置必须全套记录预加重/去加重响应高频分量补偿是否到位软件需要控制信号源发射特定码型并扫描抽头系数其中 TDECQ 是 PAM-4 发射机测试里最核心、也最容易被误会的指标。它不是在测试台直接测一个波形数值而是把捕获的波形经过一个定义好的参考通道再用一个参考均衡器做处理最后和理想波形比较算出劣化量。这个过程包含大量 DSP 步骤对软件实现来说难点不在“采集”而在“后续处理链路是否复现了标准定义的条件”。3.2 参考通道与均衡预一致性最容易“错位”的地方自动化工具做得越多越觉得参考通道这一步是质量分水岭。很多测试结果不一致不是仪器不准而是参考通道没选对或者均衡器参数没用对。参考通道一般是一组 S 参数文件也可能是一个定义的频域响应模型。不同规范版本的参考通道不同不能混用。软件里必须把参考通道文件路径、S 参数拟合方式、带宽延拓方法这些细节记入测试报告。否则这个测试结果在正式认证时很可能不认。参考均衡器同样要留意。标准里定义的参考接收机通常是一组前馈均衡器FFE抽头算法需要根据波形自适应计算抽头系数。软件实现时要明确使用什么长度的 FFE、算法如何去收敛。不同实现跑同一个波形TDECQ 结果可能有零点几分贝的偏差这已经足以影响“过还是不过”的判断。所以我在架构里把信号处理单独做成一个模块输入是波形和参考通道文件输出是测量指标。这样至少能做到同一份原始波形处理模块的任何改动都能通过重跑历史数据来验证而不是“新版软件测出的结果和旧版不一样”。3.3 以“条件”而不是“操作”为中心采集手动测试时工程师脑子里想的是“按一下采集看看波形”。自动化软件如果也这么设计就只是把按键换成了脚本。真正好用的一套系统应该以“测量条件”为中心。比如我们要评价一个发射机在不同预加重配置下的表现手动做法是改寄存器、抓波形、记眼图循环十几次。自动化的做法是把这些条件定义成一组扫描参数预加重抽头从低到高变化、电压摆幅从 400mV 到 900mV 变化、通道分别带上不同长度的参考通道软件自动跑完全部组合并把每组的通过/失败、余量、最差眼的结果汇总出来。这种“条件扫描”能力才是自动化比人手动强的地方。手动测试通常只敢测两三组配置因为每一组都耗时自动测试可以扫几十组还能在扫描过程中实时判断“哪一组余量最大”帮工程师快速找到最优配置而不是仅仅“测一下合格不合格”。4. 报告引擎内容比你想的要求多得多报告的自动化听起来最简单实际做起来最烦。很多人以为报告就是“把眼图截图贴进 PDF”真正做过合规申请或者和客户过评审才发现报告的信息结构、版本、可追溯性才是核心。4.1 报告的信息层级结论先行、数据兜底我把生成报告设计成按层级输出而不是一个大文件从头写到尾第一层是汇总页DUT 型号、测试标准、数据速率、总体结论、每个测试项的通过/失败状态。给人快速判断用。第二层是测量总结表每个通道、每个测试条件下的关键数值以及和限值的对比余量。给人看问题用。第三层是支撑细节眼图波形、测量点示意、参考通道文件信息、处理参数。给人复核用。第四层是附录仪表清单、仪表固件版本、校准日期、连接拓扑、环境条件。给人信任用。这份报告的首页必须一秒钟就能看懂“这批样品过没过”。细节越多前提条件越复杂反而越不适合放在前面。4.2 图形、数值和元数据如何对齐报告里最常出现的坑是图是图、数值是数值说不清这张眼图对应哪一组配置。原因往往是生成图片文件名太随意比如eye.png存了一堆后面的覆盖前面的。我的做法是图片命名带完整上下文并写入报告主页。比如scan_lane3_swing800_tapA_0.2_tapC_1.0_tDECQ_3.1dB.png文件名本身就把关键条件表达清楚了。同时每个图形文件旁边列一个元数据 JSON单独记录生成这个图时用的波形文件、处理脚本版本、时间戳。生成报告时我常用 HTML 为主格式、PDF 做归档格式。HTML 的好处是可以在实验室任何一台机器上用浏览器打开不用装 PDF 阅读器交互式的眼图坐标轴还能鼠标缩放。PDF 则用于发给客户或留档因为版式固定。两者都生成机器可读的 JSON 数据也单独输出一份方便后续导入数据库做批量趋势分析。4.3 报告版本与档案化能追溯才能定性报告本身也是一份“代码产物”前面那份是软件代码的产物报告则是数据和配置的产物。既然测试软件在演进报告格式在演进DUT 固件也在变就必须给报告打版本。我的实践中每条报告的页脚会输出测试软件版本号、配置文件的 SHA256 哈希、参考通道文件路径和哈希、示波器固件版本、BERT 固件版本。这些信息看起来很占版面但遇到“客户说你这轮测试和上轮结果不一样”时它就是救命线索。另外一个很实用的管理方式是整个测试项目放进 Git 仓库波形和报告这种大文件用 Git LFS 托管。这样每次测试跑完提交一次记录后续可以 diff 出“这次配置和上次到底差在哪里”而不是靠人工回忆。5. 一套完整流程怎么落地从硬件到检查页面理论讲了这么多最后落到可执行的层面。下面是我在实际搭建自动化 PAM-4 预一致性测试系统时走的完整落地路径每一步都踩过坑直接列出来给你参考。5.1 环境准备驱动、地址和命令自检第一步不是写脚本而是把仪器连接和管理梳理清楚。给示波器、BERT、可编程电源分别配置固定 IP并在实验台记录一张 IP 分配表。这个问题很基础但经常出问题——DHCP 重新分配 IP 后脚本里写的地址全失效。安装统一的 VISA 运行时比如 NI-VISA 或者仪器厂商提供的 IO Libraries然后用 pyvisa 做资源管理和命令收发。开机后用一条*IDN?命令确认每台仪器都能正常通信并把返回的厂商、型号、序列号、固件版本存入日志。这一步建议做成系统启动自检清单比如python check_instruments.py --config lab_devices.yaml脚本会逐台探测仪器输出每个设备的连接状态和身份信息。只有全部通过才允许开始正式测量避免中途才发现误码仪没连上白跑一晚上。5.2 一个可落地的波形自动化获取与指标计算样例我在这里给一个精简但可运行的 Python 骨架用来演示设备抽象 波形采集 指标计算 数据存储的链路。真实工程代码会比这个复杂但核心结构就是这样。import pyvisa import numpy as np import json class ScopeController: def __init__(self, resource_addr): rm pyvisa.ResourceManager() self.instr rm.open_resource(resource_addr) self.instr.timeout 20000 # 20s timeout self.instr.clear() print(self.instr.query(*IDN?)) def capture_waveform(self, channel1): self.instr.write(f:WAVeform:SOURce CHAN{channel}) self.instr.write(:WAVeform:POINts 1000000) self.instr.write(:WAVeform:FORMat BYTE) data self.instr.query_binary_values(:WAVeform:DATA?, datatypeb) # 实际工程还需要读取 x-increment、y-origin 等 Scaling 参数 waveform np.array(data, dtypenp.float64) return waveform def get_time_scale(self): x_inc float(self.instr.query(:WAVeform:XINCrement?)) return x_inc def compute_eye_height(waveform): # 这里只是演示接口实际 PAM-4 眼高计算需要分段统计三个眼区域 hist, edges np.histogram(waveform, bins256) # 简化处理返回分布峰之间的最小差 peaks np.argsort(hist)[-4:] levels np.sort(edges[peaks]) eye_heights np.diff(levels) return float(np.min(eye_heights)) def run_case(scope_addr, channel, run_id): scope ScopeController(scope_addr) waveform scope.capture_waveform(channel) eye_height compute_eye_height(waveform) result { run_id: run_id, channel: channel, eye_height: eye_height, unit: mV } with open(fresults/{run_id}.json, w) as f: json.dump(result, f, indent2) print(saved, run_id) if __name__ __main__: run_case(TCPIP0::192.168.1.20::inst0::INSTR, channel1, run_idrun_001)这段代码想表达三个习惯统一封装设备对象、测量结果结构化输出、run-id 作为所有文件的核心关联键。真实项目里compute_eye_height会被替换成完整的眼图处理和 TDECQ 计算模块但外部调用逻辑可以保持不变。5.3 调试经验先跑单条链路再上批量自动化系统最容易出现的局面是第一版流程能跑第二版数据一多就各种偶发失败。我总结了几条非常实在的调试经验。第一绝不要直接写一个“全部通道、全部速率、全部配置”的大循环开始跑。先把单条链路、单种配置、单次跑通确认报告里每个指标都合理再扩大范围。批量跑出现问题时才能定位是配置问题还是某台仪器偶发故障。第二每个步骤都要留日志。至少记录每个步骤的开始时间、结束时间、耗时、涉及的仪器、返回状态。跨天跑批时凌晨某个时刻示波器网络超时是常有的事。有日志才能知道卡在哪一步也才能写“步骤级重试”逻辑让流程自动恢复而不是整批作废。第三做完一轮测试后把测试报告和状态文件一起提交进 Git。这样你可以随时反问“昨天那批报告是哪个配置跑出来的”而不是翻聊天记录找谁改过配置文件。最后讲一个压箱底的小技巧把报告生成设计成“先出 HTML、再存 PDF”并且 HTML 里嵌入一个“运行参数摘要”的折叠块末尾附带配置文件的哈希。这样哪怕是团队里没有代码基础的人拿到报告也能快速确认这份报告的来源和条件。我在实际项目中吃过不少亏后来发现很多时候问题不是测试没做对而是报告里少写了一个关键条件导致整个测试结果在评审时被怀疑。自动化测试本身解决的是效率问题但配套的报告和追溯体系解决的才是信任问题。