激励生成策略：随机激励与定向激励、约束求解器调试、覆盖率驱动的激励调整

大家好，我是你们的IC验证讲师。今天咱们聊聊激励生成这个话题。说实话，这是验证工程师的看家本领，也是很多新人容易卡壳的地方。

你想想看，验证的本质是什么？说白了就是给DUT喂各种数据，看它能不能正确处理。但怎么喂、喂什么、喂多少，这里面的门道可不少。

随机激励 vs 定向激励：什么时候该用哪个？

我刚开始做验证那会儿，特别喜欢写定向测试。每个场景都手写，觉得这样可控。后来项目复杂度上来了，才发现这条路走不通。

定向激励，就是你知道DUT会怎么处理，专门构造特定场景去验证。比如验证一个FIFO，你写个序列：写10个数据，读5个，再写3个，再读8个。每一步都在你的掌控之中。

随机激励呢？让约束求解器去生成各种组合。还是那个FIFO，你只需要告诉它：写操作和读操作的比例大概1:1，深度不超过1024，然后让工具自己去跑。

我个人习惯是这样分的：

• 功能验证初期：用定向激励打基础。先把基本功能跑通，确保DUT能正常工作。
• 回归测试阶段：上随机激励。这时候需要大量覆盖各种边界情况。
• 覆盖率收敛阶段：定向+随机混合。针对未覆盖到的点，写定向用例去补。

我在项目中遇到过这样一个坑：有个同事全用随机激励，结果某个关键路径一直没被覆盖到。为什么？因为约束写得太松了，那个场景出现的概率极低。后来我们加了定向用例，问题才暴露出来。

约束求解器调试：别让它成为黑盒子

约束求解器这东西，用好了是神器，用不好就是玄学。很多同学遇到约束求解失败，第一反应是「改约束」，但往往越改越乱。

约束求解器的工作原理，其实就是一个数学求解过程。你给它一堆约束条件，它要找到一组满足所有条件的解。如果找不到，就会报错。

常见的约束求解问题有这几类：

问题类型	表现	解决方法
约束冲突	求解器报错，无法生成激励	检查约束之间是否有矛盾
求解效率低	仿真跑得很慢，卡在某个点	简化约束，减少求解空间
分布不均匀	某些值出现频率过高	使用dist或solve...before调整

我曾经遇到过一个特别头疼的问题：约束求解器跑了整整两个小时还没出结果。后来发现是一个循环约束导致的——A依赖B，B依赖C，C又依赖A。这种循环依赖会让求解器陷入死循环。

嗯，这里要注意一点：约束求解器的随机性不是真正的随机。它是伪随机，种子决定了整个序列。所以调试的时候，固定种子很重要。我一般会在仿真脚本里把种子打印出来，方便复现问题。

覆盖率驱动的激励调整

覆盖率驱动验证（CDV），说白了就是让覆盖率数据来指导你下一步该做什么。别闷着头跑仿真，跑完一看覆盖率才60%，那前面的时间都白费了。

覆盖率驱动的流程大概是这样的：

1. 定义覆盖率模型（功能覆盖点、交叉覆盖）
2. 运行随机仿真
3. 收集覆盖率数据
4. 分析未覆盖区域
5. 调整激励生成策略
6. 重复步骤2-5，直到收敛

我画了一张图，帮你理解这个闭环：

覆盖率分析的时候，我一般会关注这几个点：

• 功能覆盖点：每个覆盖点是否都hit到了？没hit到的原因是什么？
• 交叉覆盖：两个信号组合的场景是否覆盖全了？
• 覆盖率增长速度：如果跑了一百万个周期覆盖率还在涨，说明还有新场景没覆盖到。

调整激励的策略，我总结了几种常用方法：

1. 增加权重：对未覆盖的场景，在约束中增加权重，让它们更容易出现。
2. 定向注入：对于特别难覆盖的点，直接写定向序列去触发。
3. 改变随机种子：有时候换个种子，覆盖率分布就变了。
4. 分层激励：先跑随机，再根据覆盖率反馈调整下一轮的随机参数。

举个例子，假设你要验证一个AXI总线，某个地址区域的写操作一直没覆盖到。你可以这样做：

// 原始约束：地址完全随机
constraint addr_c {
  addr inside {[0:32'hFFFF_FFFF]};
}

// 调整后：增加目标区域的权重
constraint addr_c {
  addr dist {
    [0:32'hFFFF_FFFF] :/ 80,
    [32'h1000_0000:32'h1000_00FF] :/ 20
  };
}

这样目标区域的地址出现概率就从原来的几乎为零，提升到了20%。

好了，这一章的内容就到这里。激励生成是个实践性很强的工作，光看理论没用，得多动手。下次遇到约束求解失败或者覆盖率上不去的时候，记得回来翻翻这章的内容。

可可精品资料库