VCD 转 WGL，真正难的不是“改格式”，而是“怎么采样”

本文属于《芯片测试自动化与验证基础设施实践》专栏。
聚焦芯片测试自动化、测试向量生成、WGL 处理、可综合 Testbench 与验证基础设施工程化。

前面几篇文章，我已经把这条主线逐步展开过了：

• 从功能测试指令出发，可以通过模板化方法生成 JTAG 向量
• 多份 WGL 合并后，可以进一步组织成可综合 Testbench
• 真正有价值的，不是某一个孤立文件，而是一条能复用、能扩展的测试基础设施链路

但如果把视角再往前推一步，就会遇到一个更具体、也更容易被低估的问题：

VCD 到 WGL，到底是不是一个“格式转换”问题？

很多人第一反应会是：

• VCD 是波形文件
• WGL 是测试向量文件
• 那中间写个脚本改一下格式，不就行了吗？

表面看，这样理解似乎没问题。

但真做过这类工具的人很快就会发现：

真正难的，往往不是把一种文本改写成另一种文本，而是决定：到底在什么时刻，把哪些信号值，当成“有效向量”采出来。

也就是说，难点不在“输出长什么样”，而在“输入应该怎样被理解”。

这篇文章，我就专门把这个问题拆开讲清楚。

一、为什么很多人会误判 VCD -> WGL 的难度

VCD 文件本质上记录的是信号值变化历史。

只要信号发生变化，VCD 就会把那个变化记下来。

所以从数据形态看，VCD 更接近：

• 一串按时间排序的事件流
• 每个时间点上，某些信号发生了变化
• 这些变化未必构成一个完整“采样点”

而 WGL 更接近什么？

更接近：

• 在特定时刻采到的一组输入/输出状态
• 这些状态被组织成一拍一拍可执行的测试向量
• 最终会被 ATE 或其他测试执行平台消费

这两者最大的差别，不在文件后缀，而在数据语义层次不同。

一个是：

事件变化流

一个是：

采样后的离散向量序列

所以，VCD -> WGL的核心不是：

怎么把事件文本改写成另一种文本。

而是：

怎么从事件流中，恢复出真正应该被保留下来的“采样结果”。

这就是为什么很多一开始看起来简单的小脚本，最后都会越写越复杂。

二、先改格式，为什么通常会做错

如果把这个问题简单理解为“逐时间展开、逐行写出”，很容易掉进几个典型坑里。

1. 把所有 value change 都当成有效测试点

这会直接导致向量数量膨胀。

原因很简单：

VCD 会记录所有变化，包含：

• 正常功能翻转
• 时钟跳变
• 中间组合传播
• 瞬态毛刺
• 一些在测试平台上根本不该被当成独立向量的过渡值

如果这些都原样写进 WGL，那么生成出来的 pattern 往往既冗长，又不稳定。

2. 没有明确 working clock

如果没有定义“哪个时钟决定采样节拍”，那你根本无法知道：

• 什么时候该取一拍
• 什么时候只是中间传播
• 哪些变化该进入最终向量

没有采样时钟，所谓“向量生成”很可能就退化成“波形抄写”。

3. 把输入变化和输出观测混在一起处理

很多信号在 VCD 里只是“发生了变化”，但在测试语义上，它们并不处于同一层次。

例如：

• 某些输入信号是在采样点前完成激励设置
• 某些输出信号是在采样点上或采样点后才具有比较意义

如果不区分这两类信号，WGL 就很容易出现“值写上去了，但语义不对”的情况。

4. 忽略 x / z / 未定义态的处理

ATE 或 pattern 执行环境并不总是接受“你看到什么就照抄什么”这种处理方式。

对于：

• x
• z
• 未驱动状态
• 双向口切换过程中的过渡值

到底是保留、屏蔽、转成 don’t care，还是转成有效位控制，往往都需要明确策略。

所以从工程角度说，VCD -> WGL从来不是一个纯粹的格式问题，而是一个采样策略问题。

三、真正应该先回答的问题：什么叫“一拍有效向量”？

要把 VCD 转成 WGL，最先要定义的，其实不是输出格式，而是下面这几个问题：

1. 以谁为采样基准？

也就是 working clock 是谁。

2. 在哪个边沿采？

上升沿、下降沿，还是某个偏移点？

3. 哪些信号属于输入激励？

这些信号在采样时刻之前应该已经稳定。

4. 哪些信号属于输出观测？

这些信号在采样时刻才具有比较意义。

5. 哪些变化只是中间传播，不应进入最终向量？

如果这一步没定义清楚，后面写出来的 WGL 即使格式正确，也很可能语义错误。

这也是为什么一个真正能用的转换器，往往都会被拆成几个独立模块，而不是一段从头扫到尾的大脚本。

四、一个更合理的 VCD -> WGL 处理链路

结合实际工程经验，一个更合理的处理流程通常会长这样：

这个链路里，真正决定结果质量的，不是最后那一步输出 WGL，而是中间这三步：

• 识别 working clock
• 确定采样点
• 处理无效与过渡语义

也就是说，采样模型比输出模板更重要。

五、为什么 working clock 是整个转换器的“第一开关”

在很多设计里，VCD 里会同时出现很多时钟或伪时钟信号：

• 系统主时钟
• JTAG TCK
• 分频时钟
• 门控时钟
• 内部衍生时钟
• 异步控制脉冲

如果不先确定 working clock，转换器就会立刻失去统一节拍。

1. working clock 决定“什么时候采”

没有采样节拍，就没有离散向量。

2. working clock 决定“哪些变化属于同一拍”

同一个采样点前后的过渡变化，是否应该并入这一拍，取决于你怎么定义时钟边沿与观察窗口。

3. working clock 决定“输出长度”

采样过密，WGL 膨胀；
采样过疏，关键信息丢失。

所以 working clock 的确定，不是实现细节，而是整个转换策略的根。

在我看到的一些脚本实现里，往往也都会把时钟处理单独抽出来，而不是和普通向量解析混在一起。这样做其实是非常合理的，因为：

时钟定义的是向量的节拍，不只是一个普通信号。

六、为什么 pad 映射决定了“你到底在采什么”

即使已经有了 working clock，如果没有 pad 映射，还是不够。

因为 VCD 里看到的是仿真层级下的信号名，最终 WGL 里关心的是：

• 哪些是测试相关 pad
• 哪些只是内部辅助信号
• 哪些信号是输入
• 哪些信号是输出
• 哪些可能是双向口

这就是为什么很多工具都会额外读一个pad_info.v或类似描述文件。

它的本质作用不是“补充一点名字信息”，而是：

把仿真信号空间，投影到测试向量空间。

如果没有这一层，转换器就很容易出现两类问题：

1. 采了很多不该进 pattern 的内部信号

结果是生成文件巨大，而且没有测试意义。

2. 漏掉真正需要进入 pattern 的关键 pad

结果是看起来文件生成成功，但拿去执行就发现向量不完整。

所以从工程结构看，pad mapping 其实和 clock definition 一样，属于上游“语义建模”层，而不是下游“文本输出”层。

七、采样点一旦确定，接下来才轮到“取值”

很多人写这类工具时，最喜欢一开始就写“怎么把 0/1/x/z 输出成字符”。

但其实在那之前，更重要的是：

在某一个采样点上，哪些值才应该被认为是这一拍的有效状态。

一个更合理的处理思路通常是：

1. 以采样边沿为中心，收集该拍前已经稳定的输入值

也就是说，输入更像“已设置好的激励条件”。

2. 在采样边沿或指定观察窗口内，读取输出值

输出更像“在这一拍上需要比较的结果”。

3. 过滤掉仅仅是传播过程中的短暂中间态

例如某些逻辑在拍间发生的瞬时跳变，如果不具备测试意义，就不应该写进最终向量。

这一步本质上是在做一件很重要的事：

把“仿真变化历史”压缩成“测试平台可执行的拍级语义”。

这一步做得对不对，直接决定 WGL 的可用性。

八、glitch 为什么会把一个看起来“能跑”的脚本拖垮

VCD 最大的一个特点，就是它对变化非常诚实。

这本来是优点，但在做测试向量生成时，也可能变成负担。

因为测试平台要的，通常不是“所有真实发生过的过渡”，而是“对测试有意义的离散状态”。

如果不处理 glitch，通常会出现几种情况：

1. pattern 数量异常增多

本来一拍应该只有一个有效向量，结果因为中间抖动多写出很多条。

2. 输出比较点错位

某个输出在最终稳定前短暂经过若干中间值，如果直接抄到 WGL，就可能造成预期比较提前或错误。

3. 输入与输出关系被污染

原本属于同一拍的激励和响应，被中间变化拆散了。

所以 glitch 过滤不是“锦上添花”，而是只要你想把 VCD 真正用于 pattern 生成，就几乎绕不开的一步。

当然，具体要不要做强过滤、弱过滤，或者只在采样边沿取最近稳定值，要看你的目标平台和具体设计。

但无论采用哪种策略，前提都一样：

你必须先承认：VCD 的原始事件流，并不天然等于测试向量。

九、为什么 x / z / 双向口处理会比想象中麻烦

VCD -> WGL在工程上另一个经常被低估的问题，是状态语义转换。

在 VCD 里，常见状态包括：

• 0
• 1
• x
• z

问题在于，WGL 或测试平台并不一定按同样的方式理解它们。

1.x不总是可以直接保留

有时候它代表未知；
有时候它代表 don’t care；
有时候它其实意味着当前不应比较。

这三种语义，在测试执行中完全不是一回事。

2.z常常涉及驱动方向问题

尤其是双向管脚，在仿真里看到z，可能是：

• 当前未驱动
• 当前处于输入状态
• 当前处于方向切换过程

如果不结合 pad 类型和当前场景来理解，单纯抄值往往会出错。

3. 双向口往往要求“值 + 有效位”一起组织

这也是为什么更完整的测试向量系统里，经常不只保存逻辑值，还会保存：

• 哪些位有效
• 当前方向是什么
• 当前比较是否生效

这类问题再一次说明：

VCD -> WGL 的核心，不是写字符串，而是把仿真语义翻译成测试语义。

十、一个真正能演进的转换器，应该怎样分模块

如果目标不是写一段一次性的脚本，而是做成可维护、可扩展的工具，我更建议把它拆成下面几层：

1. 输入层

负责读：

• VCD
• pad 信息文件
• 可选配置项

2. VCD 解析层

负责恢复：

• 时间推进
• 信号定义
• value change 事件

3. pad 建模层

负责明确：

• 哪些 pad 进入 pattern
• 输入/输出/双向口分类
• 目标输出顺序

4. 时钟与采样层

负责：

• working clock 识别
• 采样边沿定义
• 采样点生成

5. 向量规整层

负责：

• 采样值抽取
• glitch 策略
• x/z处理
• 有效位组织

6. WGL 输出层

负责：

• header
• pad 列表
• vector section
• 文本格式化

这样分层的好处是：

• 每一层职责清楚
• 后续更容易替换策略
• 更容易从 Python 脚本演进成 C++ 工具
• 更容易接到后续的 WGL 合并和 testbench 生成链路

十一、为什么我一直强调：先定义采样语义，再谈输出格式

因为从长期维护角度看，真正稳定的从来不是某一种文本格式，而是：

你如何定义“一拍测试向量”的生成规则。

格式可以变：

• 今天输出 WGL
• 明天输出内部中间格式
• 后天接入别的 pattern 组织方式

但只要你的采样语义是稳定的，整个工具链就有可复用基础。

反过来，如果一开始只关注“文本怎么写”，那就很容易出现这种情况：

• 代码写得很快
• 文件也能生成
• 但每换一个设计、一个时钟结构、一个双向口场景，就要重写一遍

这类工具最怕的，不是报错，而是：

看起来成功生成了，实际上语义已经偏了。

这往往比直接失败更危险。

十二、从 VCD 到 WGL，本质上是在做一次“语义压缩”

如果用一句更抽象的话来概括，我会这样定义：

VCD -> WGL 的本质，是把连续事件流压缩成离散测试向量。

这个压缩过程里，真正决定质量的不是打印函数，而是：

• 你认为什么是一个采样点
• 你认为什么是有效值
• 你如何处理中间过渡态
• 你如何把仿真层级映射到测试 pad 层级

所以这件事绝不是“改格式”那么简单。

它更像是：

• 上游理解仿真语义
• 中间构造测试语义
• 下游再把它组织成测试平台能执行的格式

这也是为什么一旦把这个问题做深，它很自然就会连接到更大的链路上：

• ATE pattern 组织
• 多 WGL 合并
• 可综合 Testbench 生成
• 验证加速执行框架

也就是说，VCD -> WGL看起来只是中间一环，但它本质上是整个测试基础设施链路中的一个关键翻译层。

十三、结语：把 VCD 转成 WGL，真正考验的是你怎么定义“测试”

很多工程问题，表面看像格式问题，做深了才发现其实是语义问题。

VCD -> WGL就是一个很典型的例子。

如果只是想“生成个文件”，也许一段脚本就够了。

但如果你希望这个文件：

• 真正可执行
• 真正可比较
• 真正能接入 ATE 或后续验证链路
• 真正能适配不同设计和时钟场景

那你迟早都要回到最核心的问题上：

我到底怎样定义一个有效测试向量？

而这个问题的答案，首先体现在：

working clock 怎么定，采样点怎么取，pad 怎么映射，过渡态怎么处理。

所以，VCD 转 WGL，真正难的不是“改格式”，而是“怎么采样”。

这也是为什么我认为，这类工具真正的价值，不在于会不会写某种输出模板，而在于：

能不能把仿真变化历史，可靠地翻译成测试平台真正需要的离散执行语义。

下一篇预告

下一篇我准备继续往下写：

《为什么 VCD->WGL 脚本最后都要重构成 C++ 工具》

重点会展开：

• 为什么很多早期脚本都能快速起步
• 为什么一旦进入真实工程场景，就会逐渐失控
• 一个更合理的 C++ 工具架构应该怎样拆
• 为什么“可维护性”本身就是测试基础设施能力的一部分