【随笔】芯片验证杂谈

好的验证应该是啥样(思想层面)
选用哪些技术来支撑(技能层面)
如何让员工具备技能(实施层面)
如何度量以驱使落地(管理层面)

这个议题主要讨论是 devops 流程的事。先要解决思想层面，统一大家的认识，建设合理的流程，让每个人都知道该怎么做，什么做是对的，什么样是好的。我把验证分为 3 个阶段，分别阐述我认为合理的做法：

1. 方案制定阶段

• 1.1. 验证也需要正向设计，而不是调出来的。

• 1.2. 活动：
  阅读需求，阅读研制规范/方案，与开发同事串讲，一切活动都围绕着对需求和方案的理解。期间，为了辅助对 DUT 的理解和对平台和用例架构的设想，你可以快速搭建一个平台，做一些简单的冒烟测试，尝试一些方案 idea。不只是停留在纸上推演。

• 1.3. 输出：

  • 1.3.1.《验证需求》分解，包括需求功能点的分解，电路功能点（时序空间）的分解。说白了就是覆盖率（非用例）的文字版本，当前我们都是用 excel 管理，此处推荐一个正式的专业工具 vManager来管理，放到一个地方随时可以供大家复盘也是很有必要的，但是一定不能一竿子插到底，一开始就要关联用例，关联 coverage。在平台和用例不稳定的情况下，我现在都还不知道用例有几个，叫什么名字，更别说维护这些对应关系，如果强行维护，后续就要不停迭代修改，这是个很大的痛点，落不了地的主因之一。但是覆盖率（即功能点）是要清楚的，当需求或者研规变了，也要及时把新的覆盖点分解，体现到 vManager 上来，总不能记载脑海里，需要有地方承载，而且这个维护是没有代价的。

  • 1.3.2.《验证方案》文档，重要的是要定好平台和用例的策略，对 dut 抽象的业务模型，抽象的数据流图，抽象的配置流程（用例），清晰的通过准则。平台部分要思考如何定义 dirver，如何随机到时序空间；需要定义多少 coverage，在哪里采样，如何分 bin，如何 cross。除了平台和 refm，对用例，也存在一个架构设计的问题，如何用例分层，如何定义 item，如何定义随机粒度，如何约束随机；

• 1.4. 意义：
  这个过程一定要有，它是充分的理解 DUT 的关键，是构思验证产品的过程，是决定后续效率的重要阶段。没有这个过程，边开发边想，前期成果很好，一个月就验证了 50%功能点，但都是通过直接用例堆上去的，后面就越来越力不从心，工作量巨大，收敛慢，泄露多。因为我们从来不是在可见的功能点上泄露 bug，都是在不可见的时序类空间出 bug，后面的覆盖率和收敛时间才决定验证的成败。这个阶段做得不好，后面就避免不了以不停打补丁的方式推进。

• 1.5. 时间：
  1-2 个月。

• 1.6. 一个观点：平台，用例，coverage，这三个玩意儿是正交的。虽然他们要附着在一起，但是逻辑上是独立正交的。平台负责对 dut 建模，负责比较，它不管你用什么用例来激励，它不管如何随机的；用例（seqense）是负责高效的覆盖全验证空间，UVM 世界里它一定是随机+约束；coverage 只是度量用例的有效性，空间的完备性，它是可以独立与用例演进的。用例和覆盖率的关系，就是因为用例有了随机性才有覆盖率，没有随机性其实覆盖率意义不大。用例要追求最大可能的随机，覆盖率要追求最大程度的完备。即 UVM 世界，说用例完备不完备其实是不合适的，应该说覆盖率完备不完备。UVM 世界里，只强调随机而不用覆盖率度量，就是耍流氓。

• 1.7. 退出准则：正式的评审，几大经理，开发干系人，验证 SE。

• 1.8. Vmanger：承载 topdown 的正向需求分解，文字描述。这个阶段没必要明确。

2. 平台和用例开发阶段

• 2.1. 活动：将方案代码实现。你可能会发现方案的瑕疵，做些微调，这都是可以的。
• 2.2. 提效：寄存器模型，sim 自动化平台，vip，这些都是有助于提效的。后续也需要积累更多的公共验证组件。比如覆盖率，对仲裁的，对 fifo 的，对 AIX 的等都可以模式化。
• 2.3. 参考模型痛点：参考模型要不要和 DUT 做到一比一。做到最好（tradeoff 实现代价），做不到也没关系，很多情况是没有必要做到 1 比 1。
  • 2.3.1.划辅助线：dut 的行为没有办法仅仅从输入预测输出，可以通过后门方式检测内部信号，就像几何题划辅助线一样；但是辅助线自身的正确性必须要验证。比如由于内部有仲裁的原因，我无法预测输出，我把仲裁结果拿出来作为 refm 的输入。我就必须把仲裁器做单独的验证（可以是单元验证；也可以是对仲裁做了 coverage 度量，比如检测了输入，cov 了输出等等）；后续需要积累案例。
• 2.4. 随机用例痛点：是不是所有用例都要随机，什么功能点都要靠随机？不是的！
  • 2.4.1.比如一些异常功能，部分调测功能，随机代价太大。而这类用例，一般电路功能都是非常聚焦的，从电路功能上就非常清楚，它就跟其他电路无关，就可以用直接用例来覆盖。后续需要积累案例。
  • 2.4.2.可以打开电路来看：如果你发现有些随机代价特别的大，但是电路功能可以非常明确的证明随机没有必要。后续需要积累案例。
• 2.5. 通过准则痛点：是不是所有情况下都要 bit2bit 正确？不是！
  • 2.5.1.特定的功能点是可以模糊比较的，可以是 bit 数，可以是包数，可以是统计占比，可以是延时区间。后续需要积累案例。
• 2.6. 案例：psync 时序空间大，功能空间小。主要功能是定时器发中断，有多个参考源，性能 1 是精度要求，2 是容错要求。没有必要 c2c 比较，异步太难预测。模糊比较统计其所有条件下精度范围，所有场景能容错的范围，建模非常简单。即建模层面，要站在高处看通过准则，要理解需求，每个需求的本质，哪些是一定要准确比较的，哪些是可以模糊比较的。不能把具体电路实现方案带来的空间作为自己的验证空间。比如 psync 的鉴相，方案可以是高频去采样，也可以是低频时钟延时出多个相位去鉴相。我管他什么电路，达成精度需求即可。当然好的验证，还可以把电路的后端可实现性作为自己的通过准则(不强求)。用例加 cov 层面，要看到所有空间是否被覆盖了，就需要深入电路，通过 cov 收集内部时序。深入了解关键电路。比如鉴相的各种相位是否都模拟到了，抖动都模拟完备了。
• 2.7. 阶段的结束标准：这个阶段不是要把所有的用例和覆盖率都开发完了，但是全随机用例已经开发完了，主要用例开发完了，并且调试通过，它就可以随机覆盖到功能的 90%。覆盖率也把第一个阶段识别出来的 coverage 90%开发完成了，不需要收集完成，至少编译通过了。
• 2.8. VManger：此阶段是一个 bottom up 的过程，将第一阶段的 coverage 代码化。这个阶段就把vManger 分解进一步完善了，需要建立起来连接关系。但是不要求覆盖率收集，不需要上系统实时展示覆盖率。验证需求的分解条目是在系统上的，就类似于之前的需求跟踪表。经过前两个阶段，经过开发和验证的充分讨论，双方的理解都一致了，研规基本上就定型了，需求跟踪表可以稳定了。后续只会随着认知的深入再小修小补。
• 2.9. 时间：1-2 个月

3. 验证执行阶段：随机+覆盖率收集+补充阶段

• 3.1. 执行和优化随机用例：这个主要就是机器工作，不需要太多人的工作量；通过检测覆盖率的收敛空洞驱动下，我们会完善随机用例，完善约束。比如你发现覆盖率覆盖不到，你需要修改约束，发现覆盖率增长太慢，你可能通过遍历其中某个变量，把全随机变成多条约束随机，以提高覆盖的效率。增加随机用例，通常情况下，流程相关的随机很难做到，代价太大，比如一个业务的配置流程，先配谁后配谁。但是有了母随机用例，在这基础上增加这类随机就是小 case了，等等。
• 3.2. 覆盖率的收集：覆盖率可以不断的增补，这个阶段你对 dut 越来越了解，你会发现之前还有很多验证空间被忽略了，就需要补充和完善覆盖率。你对 dut 的理解都应该体现到覆盖率上。通常对于功能点的覆盖率是很容易做完善，开发也能很好的把关。但是对于时序空间，不仅仅是bfm 级别的时序空间，还包括内部的时序空间，这里是需要花费大力去增补，也是 bug 泄露的主要来源。覆盖率的收集，很重要一个作用就是触发开发验证，不断的看清楚功能和时序空间，不断发现自己的漏洞。
• 3.3. 覆盖率的完善：所以这个阶段，我认为开发和验证的精力大部分是对于覆盖率的挖掘，功能点、接口时序、配置流程、内部时序空间、关键电路，说白了就是找可能出错的点，然后用覆盖率去度量，说白了就是用覆盖率把电路打亮，把各种业务场景打亮。主要工作是开发覆盖率，而不是不停的开发用例。现在实际工作中，为什么我们在后期要不停开发用例，就是因为没有做到随机，还是用的低效的方法。当然，不是说随机就搞定一切了，必定还是有一些空间，用随机用例很难或者很低效覆盖，也是需要用直接用例来弥补。直接用例自身也是一个覆盖率。即不是非此即彼，而是谁主谁辅的问题。
• 3.4.vManger：此阶段验证工作度量，要在系统上实时展示，vManger 就很好用了，它可以帮我们收集，看到实时状态，看到收敛曲线。覆盖率 100%是必须的一定要达成的，达成了也不能证明
  质量很高。不仅仅要看覆盖率的收敛，还要覆盖点的增长，覆盖点的增长才是置信度的增加。
• 3.5. 时间：3 个月

总结起来 vManger 三个阶段作用不一样，我们对它的要求也要不一样
1，方案制定阶段 -> 需求分解， vManger 帮助展现 top down 的思考过程，确保空间分解全。主要是文字形式体现。
2，平台和用例开发阶段 -> 验证实现， vManger 帮助我们在 buttom up 的代码实现过程，不要有遗漏。主要是平台和用例代码的开发。
3，验证执行阶段 -> 成果度量， vManger 方便我们寻找验证空洞，帮助发现和管理风险。主要体现在覆盖率的增长或收敛曲线的变化。