为什么 VCD-＞WGL 脚本最后都要重构成 C++ 工具？

本文属于《芯片测试自动化与验证基础设施实践》专栏。在前一篇里我重点讨论了一个问题VCD 转 WGL真正难的不是“改格式”而是“怎么采样”。但当这个问题继续往工程里走很快又会遇到另一个现实问题为什么很多一开始“能用”的 VCD-WGL Python 脚本最后都走向了重构甚至会被改写成 C 工具这篇就专门聊这个问题。一、很多 VCD-WGL 工具一开始都不是“工具”而是“救火脚本”真实项目里VCD-WGL 这类东西很少是一开始就按正式产品来做的。更常见的情况是验证侧先能导出 VCD测试侧又需要 WGL 或类似 pattern 文件中间缺一个转换环节于是有人先写个脚本把链路接起来这个阶段的目标通常非常明确先跑通。所以脚本的典型特征往往是先假设输入格式比较固定先假设 working clock 只有一个先假设 pad 信息来自单一文件先假设项目里只处理少数几种信号情况先把输出文件拼出来再说这类实现本身没有问题。因为在系统早期脚本的最大价值就是低成本试错。如果没有这些“先跑通”的脚本很多后续方法论根本没有机会落地。所以我并不认为脚本不好。真正的问题是很多人把“原型脚本”误当成了“长期工具”。而这往往就是后面越来越难维护的起点。二、脚本为什么一开始很顺手要理解为什么后面会重构先得承认Python 脚本在早期确实特别适合这类工作。原因很现实。1. 文本处理快VCD、WGL、pad_info、log、comment这些本质上都是文本或半结构化文本。Python 在这类场景下非常高效正则方便字符串拼接快文件读写直观调试门槛低2. 试验成本低比如你临时想验证是否能从 pad_info.v 提取 pad 列表是否能找到 working clock是否能在上升沿采样向量是否能先生成一个简化版 WGL这些事用脚本很容易快速试出来。3. 规则变化时改动也快项目早期最常见的不是“算法优化”而是“规则还没定”。今天想按上升沿采样明天可能改成下降沿。今天 working clock 先手工指定明天又想自动识别。今天输出 header 这么写明天测试平台又要求另一种片段格式。这种时候脚本式实现的灵活性非常有优势。所以很多 VCD-WGL 系统第一版用 Python 起步是非常合理的。三、真正的转折点不是“脚本跑不动”而是“脚本开始失控”很多人会把“要不要重构”理解成性能问题是不是 Python 太慢是不是文件太大是不是 C 更快这些当然是因素但通常不是最先触发重构的原因。更常见的真实原因其实是脚本还没完全慢到不能用但已经复杂到没人敢改了。这才是最危险的状态。换句话说推动重构的往往不是“执行速度”而是规则越来越多分支越来越多输入格式越来越不统一临时补丁越来越多只有原作者自己知道哪里能动、哪里不能动到这个阶段脚本的主要矛盾就变了。前期的主要矛盾是能不能把功能做出来。后期的主要矛盾变成谁还能保证改了之后不会把别的 case 搞坏。这时候重构几乎就是必然的。四、VCD-WGL 这类脚本最容易失控的几个地方这类脚本为什么特别容易越写越乱因为它天然横跨了几个不同层次输入解析时钟识别采样规则pad 映射向量抽取格式输出表面上看只是“读文件、写文件”但本质上它同时包含语义处理 时序处理 格式化输出而脚本一旦把这三层混在一起就很难长期维护。1. 时钟逻辑和格式输出搅在一起例如一边判断当前 timestamp 是否到达采样点一边更新 pad 值缓存一边又顺手把 WGL 文本写出这样做短期很方便长期就很危险。因为采样语义一改输出行为也跟着变输出格式一改又容易反向影响采样代码本来是两个问题最后变成了一个大泥球。2. pad 映射规则写死在各处比如某些 pad 只在一个函数里特殊处理某些信号名映射关系散落在多个 if 分支里input/output/inout 的规则没有单独抽象开始还记得时间一长就没人说得清到底哪些规则是通用的哪些只是某个项目特例。3. 全局变量越来越多很多脚本初版为了快都会用大量全局变量。例如pad listpad direction flagwaveform nametime scaleworking clockcomment list这种写法早期没问题但一旦流程变长就会出现谁在什么时候改了这个变量这个变量当前是否已经初始化多个函数是不是共享了同一个临时状态到最后代码虽然还能跑但行为很难预测。4. 输入假设越来越脆弱最开始脚本往往默认VCD 格式固定pad_info.v 风格固定端口声明方式固定时钟命名规则固定但只要项目一扩展很快就会遇到多行端口声明不同模块风格的 pad 文件VCD 中信号别名变化总线和标量混用压缩文件输入多时钟混合这时候原本的“简单假设”就开始连锁失效。五、为什么这时候很多团队会转向 C重构当然不一定非要用 C。从理论上说也可以继续用 Python 做模块化重构。但在很多 EDA、验证、测试基础设施团队里最后转向 C 是非常常见的。原因通常有 4 个。1. 更适合做长期维护的模块边界C 不会自动让系统更优雅但它会逼着你更早去面对这些问题数据结构到底是什么模块边界怎么划生命周期怎么管理哪些对象应该只读哪些状态可以更新这对工程化是好事。因为 VCD-WGL 这种系统一旦过了原型阶段就不再只是“写几个函数”而是需要有明确的模块分工。2. 更容易接入现有 EDA 基础设施很多测试、验证、EDA 内部平台本来就大量使用 C/C。如果一个工具最终要接入内部库统一构建系统回归框架性能分析环境老的工具链组件那 C 的接入成本常常更低。3. 对大文件和高吞吐更友好VCD 文件一旦变大处理成本会迅速上升。尤其在以下场景长时间波形大量信号多 pattern 数据抽取频繁字符串处理这时候如果工具要长期用于批处理或集成到流水线里C 在内存控制流式处理自定义数据结构吞吐优化方面通常会更有操作空间。4. 有利于把“脚本”升级为“工具”这其实是最重要的一点。所谓工具化不只是换个语言而是开始具备这些特征明确的命令行接口可测试的模块稳定的输入输出约束错误处理和日志可扩展的配置项可回归验证的行为边界当目标从“我自己能跑”变成“别人也能稳定用”工具化就会变得比“语言偏好”更重要。而 C 常常就是很多团队做这一步时的自然选择。六、真正要重构的不是语言而是结构我想强调一点从 Python 重构成 C真正要重构的不是语法而是结构。如果只是把原脚本逐行翻译成 C那大概率只是把原来的混乱搬到另一种语言里。真正有价值的重构应该先回答1. 系统到底分几层一个更合理的 VCD-WGL 工具至少应该拆成下面几层CLI / ConfigVCD ReaderPad ParserClock AnalyzerPad MapperSamplerVector BuilderWGL Writer这几个模块解决的是不同问题CLI / Config输入参数、模式开关、配置管理VCD Reader读取 value change 事件Pad Parser解析 pad_info.vClock Analyzer确定 working clock、边沿、时间单位Pad Mapper建立 VCD 信号与目标 pad 的映射Sampler按采样策略抽取向量Vector Builder组织内部向量表示WGL Writer输出最终格式这样做的好处是以后你改采样规则不必同时改输出格式以后你改 pad 解析也不会波及 WGL writer。这才叫结构化。2. 内部统一数据结构是什么如果没有统一数据结构代码就会一直在“字符串世界”里打转。但真正稳的设计应该尽量先进入结构化表示再决定怎么输出。例如structPadInfo{std::string name;enumclassDirection{Input,Output,Inout}dir;};structSamplePoint{uint64_ttime_ps;std::vectorcharvalues;// 0, 1, x, z};structVectorSet{std::vectorPadInfopads;std::vectorSamplePointsamples;};一旦有了这种中间结构调试 easier比较 easier单元测试 easier输出到 WGL 之外的其他格式也更容易也就是说工具真正的核心资产不是最后那个 writer而是这套中间表示。3. 哪些规则应该配置化很多脚本的问题不在于写得乱而在于把“项目特例”写成了“系统真理”。比如working clock 名称pad 过滤规则是否忽略某些信号采样边沿选择x/z 输出策略header 模板这些东西如果全写死后续每换一个项目都得改代码。更合理的办法是把容易变化的部分尽量参数化、配置化。这样工具才有可能真正复用。七、一个更像“正式工具”的 C 版本应该长什么样如果让我从零重构一个最小版 C demo我会优先做这几件事。第 1 步先做最小可运行链路目标不是一开始就覆盖所有复杂情况而是先证明主流程稳定读 VCD读 pad_info.v找 working clock在指定边沿采样生成简化版 WGL 输出这个阶段最重要的是把主干跑通而且结构别乱。第 2 步补错误处理和日志很多脚本的通病是跑成功的时候看起来没问题一旦输入不符合预期就直接崩或者生成了错误文件自己还不知道正式工具至少要能明确区分文件打不开pad 解析失败clock 未找到采样点为空输出写入失败并且错误信息要能让别人看懂。第 3 步做回归样例VCD-WGL 这类工具最怕“改一点坏一片”。所以只要工具准备长期维护就一定要有一组回归样例小 VCD对应 pad_info.vgolden WGL 或关键片段不同 clock case不同 x/z case有了这些后续每次改采样逻辑、改映射规则才有东西兜底。第 4 步再逐步加复杂能力比如gzip VCD总线支持多时钟策略glitch filtervalid bit 生成comment blockpattern 分段多文件批处理这是一个典型的“先主干、后特性”的过程。真正成熟的工具不是第一天就功能最多而是每加一个能力都不会把前面的结构搞坏。八、为什么这件事对你的技术形象也很重要如果只从“能不能转出来”看写个脚本也许就够了。但如果从对外展示、技术沉淀、专家形象建设来看“我能写一个脚本”和“我能把一条工具链工程化”是完全不同的叙事。前者更像会处理一个具体问题后者更像理解问题本质知道系统应该怎么分层知道原型怎么演进成基础设施知道哪些是可变规则哪些是稳定抽象这也是为什么我一直认为VCD - WGL这个点不应该只写成一个“转换小技巧”而应该写成一条更完整的工程演进链路。这样别人记住的就不是“你写过一个脚本。”而是“你做过芯片测试自动化工具链的工程化设计。”这两个含金量完全不一样。九、VCD-WGL 工具化之后下一步还能走向哪里一旦把这条链路从脚本重构成工具后面其实就很自然能往外扩。比如1. 往上接测试语义层也就是不只是“读 VCD”而是逐步往“测试任务描述”“寄存器访问语义”“JTAG 模板化生成”方向靠。2. 往下接验证执行层也就是把 WGL 继续组织成多 pattern 统一管理可综合 testbench加速仿真执行框架3. 往中间做统一中间表示如果工具内部已经有比较干净的向量结构那么将来输出WGLSTIL自定义 pattern 格式调试日志格式都会容易很多。这也是为什么我说真正的价值不在某个 writer而在系统内部抽象。十、结语真正该重构的是“原型思维”为什么很多 VCD-WGL 脚本最后都要重构成 C 工具表面答案当然可以说为了性能为了维护为了扩展为了接入现有平台这些都对。但更本质的答案其实是因为问题已经变了。一开始的问题是怎么把 VCD 先转成 WGL。后来的问题变成怎么让这条转换链长期稳定、可维护、可复用、可集成。当问题从“单次完成任务”变成“长期支撑流程”原来的脚本式思维就一定会碰到边界。所以真正要重构的不只是语言不只是文件读写逻辑甚至不只是某几个函数。真正要重构的是从“救火原型”走向“基础设施工具”的思维方式。而这恰恰也是很多芯片测试自动化系统真正开始变成熟的标志。下一篇预告下一篇我准备继续把VCD - WGL放回更大的链路里看题目大概率会是《VCD-WGL 不是终点它怎样接到 ATE、WGL 合并和可综合 Testbench》如果这一篇解决的是为什么脚本会走向工具化那下一篇就会继续讨论这个工具化之后的中间层到底在整条芯片测试自动化链路里处于什么位置。