嵌入式入门生小陈简单直接分享几个实用技巧吧。
1. 从 Spec 到覆盖点：用荧光笔把 Spec 里所有带“如果”、“当...时”、“必须”、“应该”的句子标出来。这些几乎都是覆盖点的候选。
2. 编写测试序列：先搭一个基础的随机序列框架，然后像做菜一样“加料”。针对你想覆盖的某个点，在序列里插入一些定向的“动作”。比如，在普通的随机读写序列中，突然插入一个背靠背写操作去冲击 FIFO 满的情况。这种混合序列效率很高。
3. 分析报告：重点看“覆盖漏洞”（coverage holes）。现在的仿真工具都能列出未覆盖的仓（bin）。逐个分析这些仓为什么没覆盖到。是因为约束太强？还是序列根本没产生这种场景？然后对症下药。
4. 工具使用：学会用覆盖率排除（exclude）功能。有些代码或覆盖点确实是不需要覆盖的（比如 legacy code 或 error handling 的死代码），及时排除掉，让报告更干净，聚焦真正的问题。
总之，别让测试用例盲目跑。每个测试最好都有一个主要覆盖目标，在测试注释里写清楚。这样回归测试失败时，也容易定位问题。
我觉得核心是要理解设计的“意图”和可能的“漏洞”。看 Spec 不能只看字面意思，要想想设计者为什么这么定义，以及在实际硅片中可能出问题的地方（比如亚稳态、时序违例、资源冲突）。基于这些理解去定义覆盖点。
举个例子，一个仲裁器，Spec 说按优先级仲裁。那覆盖点就不能只是“所有请求源都被服务过”，还要交叉覆盖“多个高优先级请求同时到来时的处理顺序”、“低优先级请求被持续饿死的情况”（这可能需要超长序列来覆盖）。这些 Spec 可能没明说，但却是验证工程师的价值所在。
编写测试时，我会用 SystemVerilog 的约束控制（constraint control）和随机化方法（randomize() with {}）来动态调整权重。比如，当某个覆盖点一直没达到，我就在测试序列里动态地提高相关约束的权重。也可以写一些回调函数（callback），在特定事件发生后，修改随机对象的约束条件。
避免的坑：不要过度追求 100% 覆盖率，尤其是交叉覆盖，可能组合爆炸。要优先保证重要功能的覆盖。另外，确保覆盖点采样条件精确，避免在无效周期采样导致虚假的高覆盖率。
从项目管理的角度说，验证要系统化。我们团队会先做验证计划评审，把 DUT 的接口、功能、性能、异常情况都列出来，并给每个点分配一个覆盖点编号。这样，后期追踪覆盖率时，可以直接对应回需求，知道哪个功能没验到。
编写测试用例时，我们强调“场景化”。不是单纯发随机数据，而是构建真实的应用场景，比如一个完整的 PCIe 传输事务、一个图像处理流水线的完整帧处理。在这些场景里，关键参数（比如数据包大小、延迟、错误注入）用随机约束，但场景骨架是定向的。这样既能保证关键路径被验证，又能利用随机性发现意想不到的问题。
覆盖率分析报告，我们不光看代码覆盖率和功能覆盖率，还特别关注断言覆盖率。有时候功能覆盖到了，但断言没触发，说明场景可能没真正激活设计内部的某些检查点。工具上，Verdi 的覆盖率融合分析功能挺好用，可以把代码覆盖和功能覆盖关联起来看，快速定位为什么某个功能点没覆盖（是代码没执行到，还是执行了但条件不对）。
别把随机测试和覆盖率驱动对立起来。其实高效的 CDV 是两者结合。我的做法是：先基于 Spec 和架构文档，列出所有需要覆盖的功能场景（可以做成 Excel 或 Confluence 页面）。然后编写验证计划，把每个场景映射到具体的 covergroup 和 coverpoint。
在写测试用例时，我会先跑 broad 的随机测试，权重设得比较均匀，目的是探索空间。然后分析覆盖率报告，找出 holes。这时候，不是急着写定向测试，而是先调整随机约束的权重或增加新的约束，让随机测试能更“智能”地往那个方向靠。比如，如果发现深度为 0 的包没测到，就在随机包长约束里增加 weight=10 给 0 长度的约束。定向测试只用于那些随机确实很难触发的 corner case，比如需要非常精确的时序配合的场景。
一个小技巧：善用覆盖组的触发（trigger）和采样（sample）条件，确保数据在正确的时间点被采集，避免误覆盖或漏覆盖。
我刚开始做验证时也这样，觉得随机测试就是跑个几千次总能覆盖到。后来发现完全不是那么回事。我的经验是，先把 Spec 里所有功能点拆成一个个小目标，比如“FIFO 满时写操作的反应”、“中断优先级冲突处理”这种。然后针对每个小目标写专门的覆盖组（covergroup），定义好覆盖点（coverpoint）和交叉覆盖（cross）。这样跑仿真时，就能清楚地看到哪些点没覆盖到，而不是只看整体覆盖率数字。
定向测试序列我一般会在随机测试跑完一轮，覆盖率卡住的时候再写。比如发现某个状态机跳转路径没覆盖，就写个定向序列去触发它。工具上，VCS 或 Questa 的覆盖率报告里，我会重点看那些覆盖率为 0 的覆盖点和交叉项，这些就是下一步要攻克的难点。
