Wenhui's Rotten Pen
验证工程师与芯片验证（四）

验证工程师与芯片验证（四）

本文

芯片验证系列文章主要分为三部分：验证工程师与芯片验证、SV学习笔记、UVM学习笔记。此为 验证工程师与芯片验证 部分第四篇，主要介绍验证周期、验证管理三要素、验证的收敛、问题的追踪、团队的建设、验证的专业化。

版本 说明
0.1 初版发布

参考

名称 作者 来源
《芯片验证漫游指南》 刘斌 书籍
《全面的功能验证：完整的工业流程》 Bruce Wile , John C. Goss , Wolfgang 书籍

专业术语与缩略语

缩写 全称 说明
GLS Gate level simulation 门级仿真
TO Tape-out 流片
CDC Cross clock domain chec 跨时钟域检查
PA Power-Aware-Testing 能效测试
SDF Standrad Dealy Format 标准延时格式文件（常说的反标文件）
ECO Engineering Change Order Flow ECO是指在流程中某个阶段发现错误，在不需要重复全流程的情况下，通过对当前流程阶段的设计直接进行变更，以减小全流程重复带来的项目时间的延长。由于门级网表到最后的版图期间仍可能发现设计错误，因此通常需要通过对门级网表直接进行设计变更。

验证的周期

验证菜鸟的成长

  1. 确定验证的模块，与设计人员交流，熟悉模块，进行模块验证，所有的精力专注在这个模块。
  2. 考虑验证时间，尽可能又快又多的发现bug，在项目节点前完成验证。
  3. 在模块验证完后不知做什么，被动安排工作。
  4. 不清楚每个节点应该做什么、上一个节点和下一个节点的联系、不同节点对整个项目周期的意义，这些需要有一个宏观的认识。
  5. 随着经验增长，被赋予更多的责任，从模块到子系统，再到系统。
  6. 接到富有挑战性的任务会感受到压力，但是学到的东西也更多。
  7. 每一个验证人员能够充分了解各个验证环节，那么就可以更好的贯彻验证任务，保持信息通畅，整体的风险就会降低。

验证与设计的节点

  • RTL0： 芯片框架 和 模块功能 定义完成，进行任务分配和制定验证策略。
  • RTL1： 模块和子系统 的功能信号定义完成，开始搭建验证环境。
  • RTL2： 完成所有模块的设计，模块功能全部完成验证，完成部分系统验证。
  • RTL3： 完成芯片 系统 的连线集成和验证，完成系统验证，覆盖所有的功能点。
  • GLS： 完成 门级网表 的验证。
  • TO： 回顾验证的各项检查清单，最终 *流片*。

RTL0

任务 内容
团队验证环境准备 项目的工作目录、采取的验证进度跟踪方法
验证人力和进度安排 模块、子系统、系统需要的人力和进度安排
验证工具和方法选择 仿真工具和形式化验证工具的版本、验证方法学
验证文档 记录验证策略、验证平台环境、方法学

RTL1

任务 内容
搭建模块验证环境 按照设计接口搭建验证环境
生成寄存器模型 由设计XML文件生成UVM寄存器模型
验证文档 模块验证环境、寄存器模型 、环境编译
验证计划回顾 模块级验证计划的回顾

RTL2

任务 内容
语义检查（linting） 检查常见的设计规范问题
跨时钟域检查（CDC） 模块、子系统级的CDC检查
创建测试用例 将测试用例同功能验证点完成匹配
仿真验证、形式化验证 选择合适的方法学完成模块全部和子系统80%以上的验证
回归测试 创建和更新模块级/子系统级的回归测试表
bug修复和跟踪 记录发现的bug，完成修复后的回归测试

RTL3

任务 内容
跨时钟域检查（CDC） 完成系统级的CDC检查
能效仿真（PA） 完成系统级的PA仿真
仿真验证和形式化验证 完成系统级的验证
创建测试用例 创建系统级测试用例
回顾测试用例 系统级测试用例和功能点回顾
bug修复和跟踪 修复系统级测试的bug，并跟踪和回归测试
回归测试 集中提交所有模块的测试用例，评估整体进度
代码/功能覆盖率收集 合并模块/芯片覆盖率，创建新的用例完备覆盖率

GLS

任务 内容
门级验证环境准备 需要从RTL芯片验证环境做更新，使用门级仿真
网表仿真验证 从RTL级选择测试用例，在网表环境测试逻辑一致性
网表+SDF仿真验证 伴随门级延迟仿真，完成时序验证
bug修复和验证 伴随设计ECO流程，完成RTL和门级验证

TO

任务 内容
验证功能点回顾 确保所有待验的功能点全部被测试用例覆盖
测试用例回顾 检查最终回归测试表结果，检查用例是否全部通过
覆盖率回顾 检查最终合并的覆盖率，功能覆盖率100%，代码覆盖率在90%以上
门级仿真用例回顾 所有的时序违例均被修正和过滤，功能全部通过

验证管理三要素

时间管理

  • 早行动 ：
    1. 各个模块和系统验证人员早参与到项目的前期定义环节，可以尽早知道设计的改动，从而考虑如何对原有的环境做出更新。同时，在选用IP和定义新模块的过程中，验证人员也可以更早的考虑选用什么验证IP、验证方法以及相应的工具。
    2. 有经验的验证团队，在项目开始之前就考虑更新的验证环境、流程、工具选择、方法学、技能训练、自主工具脚本开发等。
    3. 将验证环境搭建工作和测试用例创建工作分开，也就是少数人搭建维护验证环境，剩下的绝大部分人专心创建测试用例，通过这种让验证人员更专注的进行功能验证的模式来提高产出率。
  • 少依赖 ：
    1. 一旦有了充分的意识，懂得验证过程并非是在设计完备后开始，那么验证人员就应该想出各种办法来减轻或者消除对于设计进度的依赖性。
    2. 尤其对于验证经理而言，让团队因为依赖一些未完成的事情而白白浪费时间，这对于项目进行来讲是大忌。
    3. 同时，验证团队往往需要在多个项目中一边开展新项目一边维护老项目，这更需要做好人力协调安排，避免出现项目之间人力冲突的情况。
  • 大局观 ：
    1. 验证人员不但要专注于自己的“一亩三分地”，还要清楚共同的关键节点，以及各个模块之间的依赖性，
    2. 面临选择验证方法和工具时，需要考虑的不单单是该方法或该工具可以提高多少仿真速度或覆盖率，同时也要考虑人员的技能培训投入、学习曲线、新工具整合、新环境维护等与项目进度密切相关的因素。

人力安排

  • 团队建设 ：
    1. 由于验证技术的趋势变化加快，新的方法、工具层出不穷，验证团队成员组成往往需要不同的技术背景。
    2. 招聘或培养人员时，要考虑所要具备的基本技能，和在某些技术领域拥有着丰富经验。比如软件编程、验证环境建设、形式化验证、硬件加速等。
    3. 一个经验丰富的验证团队，成员之间的技能一般会有重叠和差异部分。这种方式可以保证在人员任务分派时会有多种选择，同时团队共同工作时可以实现技能互补。
    4. 不同经验层次的梯队可以保持技术的传承，梯队培养，同时在任务分派的时候，也可以考虑将新的任务交给老员工，将老的任务交给新员工，满足老员工新技能培养、接受新的挑战，也使得新员工快速使用项目环境。
  • 技术和管理 ：
    1. 技术功底深厚的人少有管理同样出色的，而善于在不同部门、技术组之间沟通的人善于协调、计划和监督却又无法很好的兼顾技术层面。
    2. 往往技术优秀的人才会被委以团队和项目管理的职责，但是这种选择不一定是最合适的。
    3. 伴随着验证项目的要求越来越复杂，芯片公司也越来越需要有经验的项目管理者，因为这样一位管理者会对整个项目起到组织和推动的作用。
    4. 好的验证组织既需要有技术良好的梯队，也应该具备贯彻执行验证计划的执行力，一个验证团队需要不同技术专长的验证人员，也需要可以统管全局的验证经理。

任务拆分和重组

项目启动初期，由于系统结构和设计功能描述尚未确定，相邻模块间的接口上不稳定，这时候在这些不确定中找到确定因素，来安排验证进度、估算所需的验证资源，对于验证经理的经验有很高的要求。

  • 任务拆分指的是可以将一件用时较长或较复杂的任务拆分为相对独立的小任务。拆分任务的好处：
    1. 更容易清楚要做的任务和技术难易度、时间长短。
    2. 帮助分辨不同小的任务间的依赖性。
    3. 发现哪些部分是核心，哪些部分存在风险。
    4. 在有多人参与情况下，可以合理的分配任务，并发执行。
    5. 细化的任务有助于进度的跟踪和工作的量化。
  • 任务重组指的是验证经理在统筹各个模块、不同验证节点之间的任务时，可以合理的对不同任务进行合并、转接、排序等，它的目的是更有效利用整体的验证资源。常见的任务重组场景包括：
    1. 发现各个验证模块中共同的可利用资源，指派专人维护（验证IP、回归工具、环境、脚本、仿真工具）。
    2. 模块A和模块B都需要创建一个类似的环境或组件时，考虑两个组件间共同规划同一个环境或参数化组件，以便减少整体工作量，提高模块复用性。
    3. 在发现不同模块之间有依赖性的时候，就需要安排优先级，消除依赖路径，尽可能使全员都行动起来。

验证的收敛

写在前面

随机验证的方式使得回归测试更加有意义。一般来讲，我们基于两种目的来提交回归测试表：

  • 由于随机环境每次产生激励序列不同，这样每次回归测试均会对覆盖率收集做出贡献。
  • 当设计bug修复后，回归测试保证bug的修复且不会引入新的bug。

回归测试具体指的是每次直接将所有测试用例提交到服务器运行，并且检查测试结果，对于模块级的回归测试，这种方法在时间和计算资源上也许是可行的，但对于系统级回归测试，这种方式每次要消耗的时间和资源需要重新考虑，一般考虑的因素是： 回归流程 、 回归质量 、 *回归效率*。

回归流程

  • 流程阶段：

    1. RTL1：模块级基本功能验证、模块级高级功能验证。
    2. RTL2：模块级回归测试和收集覆盖率、系统级基本连接验证、系统级模块交互功能验证。
    3. RTL3：系统级回归测试和收集覆盖率、模块级和系统级副覆盖率合并。

  • 流程细节：

    1. 模块设计阶段，除了准备验证环境，在验证的基本功能完成之时就应该创建一些 基本的测试用例 ，并逐渐形成回归列表，在RTL2时要全部测试通过。
    2. 保证基本功能回归列表时，一些 高级功能或附加功能 ，以及 corner场景 尽可能的在RTL2前完成验证。但是这些功能可能有部分需要在RTL2和RTL3之间完成验证，所以按照优先级划分功能回归列表也需要作为模块验证完成的检查项。
    3. 由于RTL2节点可以保证基本功能的正常工作，这份回归测试表单也使得RTL3开始时进行的 系统集成 工作得到保障。
    4. RTL2和RTL3之间，需要完成模块级的高级功能验证，之后 反复 进行回归测试，通过大规模的随机测试来验证设计的 稳定性 ，并且完成覆盖率的收集。
    5. 模块级验证必须在RTL3之前完成，而 系统级验证 必须在门级仿真之前完成，并且尽可能减小落后于节点的差距。

  • 备注： 这里提到的 基本功能回归表 ，能够初步保证设计代码的正确性，在代码提交前设计师先通过代码编译检查和基本功能回归测试，通过后再提交到 git库 ，交验证人员进行更多的高级功能回归测试，可以减少因提交代码质量导致时间的浪费，也可以将其集成到git提交管理。

回归质量

  • 芯片设计在每次完成后，我们可以通过回归测试工具将设计、验证环境的编译、仿真、结果检查集成为一体，也可以通过一些简单的命令由设计者先查看 基本功能 是否正常工作。
  • 只有保证基本功能回归列表测试通过，代码 版本管理 工具才可以允许提交，同时通知验证人员更新设计代码，随后展开高级功能的回归测试。
  • 如果验证人员发现了bug，设计人员在bug修复后，先通过 基本功能测试 ，再递交给验证人员检查之前的bug场景，确定修复后再进行高级功能或更高层次的验证工作。
  • 总结：
    • 前期设计不稳定时，主要定期提交基本功能测试来快速检查功能是否通过。
    • 设计比较稳定后，规划用时较短、测试场景简单的用例，检查核心功能是否正确。
    • 设计后期，应该一方面实现复杂场景测试，一方面大量提交回归测试表类完善功能覆盖率。

回归效率

  • 影响回归效率的几个方面：

    1. 模块级验证阶段 ，随机测试方式倾向于反复提交测试表来产生各种可能场景，而到了后期覆盖率难以得到更多提升，那么如何 精细控制随机约束 使得每次回归测试总有新增覆盖率的收获就显得额外关键。
    2. 在设计bug修复后，如何 快速检查设计基本功能 ，保证设计版本提交的质量，这对提高回归测试效率也很关键，一个低质量的设计代码会降低回归测试的收益。
    3. 系统级验证阶段 ，由于测试用例时间明显加长，每次回归整个测试表需要消耗很长时间，越到后期反复回归的 收益就越低 ，但同时验证管理又需要这样的数据，这种矛盾也需要化解。

  • 提升回归效率：

    1. 切分测试场景 ，将较长的测试用例切分为多个序列，这样做的好处是避免过于冗长复杂的测试用例，划分多个用例可以方便并行提交，用计算资源来节省时间。
    2. 对于较难切分场景的测试用例，比如系统级仿真时需要先完成上电、复位、时钟使能等一系列初始化操作之后才能进行有效测试场景，可以考虑 快速跳转到特定状态 来实现缩短测试时间。
    3. 针对第二条所描述的特定状态，也就是需要长时间的运行来到达某一测试状态，建议分为两个阶段，第一阶段来检查跳转该状态的条件以及跳转功能是否正常，第二阶段在第一阶段测试通过的前提下，可以 直接初始化到测试状态 ，例如强行置位寄存器、状态信号等方式，使得设计快速到达测试状态，缩短测试时间。
    4. 尽可能给予充分的计算资源，目前用于仿真的普遍方式是，中心化 服务器集群 来提供计算和数据存储资源，通过资源分配管理办法来实现充足的 并行运算 资源，缩短回归测试的运行时间。
    5. 后期回归测试，使用定向用例或精确控制随机约束，提高覆盖率收集的效率。

问题的追踪

问题类型

  • 系统功能定义问题。
  • 硬件设计问题。
  • 芯片验证环境问题。
  • 综合时序问题。
  • 硅前工具问题。
  • 引用库和IP问题。

追踪工具

  • 关于bug追踪需要的功能： 分类、派发、查找、追溯、报告 等。
  • 标准化的问题追踪工具可以加速芯片开发的进度：
    • 商业工具：Team Foundation Server(Microsoft), JIRA, Rational cLEARqUEST(IBM)
    • 开源工具：Bugzilla(Mozilla), Redmine, Trace

工具功能

  • 记录 ：记录问题标题、内容、出错场景、背景描述、发布版本、测试用例、复现命令以及其他相关文件。
  • 分类 ：归属哪个项目、哪一层次、哪个模块、哪一类型以及问题的严重性。
  • 派发 ：问题提交即代表追踪的开始，管理者或提交人员可以指定谁来修复。
  • 查找 ：查找功能可以方便bug追踪的查看，也可以在新bug发生时查找是否之前出现过此bug或有其他同事已经提交相同bug。
  • 追溯 ：追溯是跟踪bug的状态迁移，从提交、派发、解决、完成等一系列状态的迁移。
  • 报告 ：将整个数据库中的bug统计，从不同的维度形成报告，方便管理者查看。

追踪流程

  • 步骤1：发现一个新的问题，填写相应内容并在追踪工具中提交。
  • 步骤2：提交者将问题派发给所有者，如果所有者发现该问题不属于自己负责，派发给真正的所有者。
  • 步骤3：如果问题所有者分析后确定问题属于自己，则进入开始状态，修复问题。
  • 步骤4：如果问题所有者分析后发现并非属于自己，则将状态重新修改为新的问题。
  • 步骤5：如果该问题之前已经被提交，则将状态修改为重复状态，同时需要备注已经提交相同问题的ID号，用来追溯。
  • 步骤6：如果该问题不严重影响项目进度且不是致命问题时，可能选择延后，
  • 步骤7：如果该问题在新的版本中已修复，可以将该问题改为解决状态。
  • 步骤8：如果问题所有者将问题进行了修复，则将问题修改为解决状态。
  • 步骤9：问题所有者修复问题过程，发现该问题之前已经被提交，仍可以改为重复状态。
  • 步骤10：问题所有者修复问题过程，仍可以改为延后状态。
  • 步骤11：问题修复后，问题所有者可以将该问题派发给验证人员。
  • 步骤12：问题得到修复和验证后，问题再次派发给当初的提交者或管理员，由他们将状态修改为关闭状态。
  • 步骤13：问题可能会被重启，由问题所有者分析是否需要再次修复。
  • 步骤14：问题重启后，若确定需要再次修复，则进入开始状态。
  • 步骤15：问题重启后，若确定已经修复，则可转入解决状态。
  • 步骤16：之前延迟的问题此时具备解决条件时，可选择重启。

团队的建设

7个好习惯之从全局入手

  • 同一个问题，专家的考虑角度总会比新手 更高、更广、更丰富 ，解决问题的方案也会有高低的区别，所以无论处于哪个专业水平，总会有 更高更全面的视角 等待挖掘。
  • 对于一个团队而言，在项目启动的时候，如果团队负责人能够对项目的 周期、难点、人力估计、环境建设 做出响应，与团队 分享 他的视野，保证团队 清楚 接下来大家如何作战、 清楚 每个阶段的作战目标，对于整个项目的推进很有意义。
  • 团队中每一个成员在思考问题时都保持一种 全局观 ，往往对于项目的中长期运行，可以 更少资源、更高效率 的去实现目标，另外对 个人成长 也很有意义。

7个好习惯之追求百分百

  • 如果一个问题从硅前 隐藏 到门级仿真，那么 代价 是数倍的，如果 隐藏 到硅后测试， 代价 是数十倍的，这就需要每个人的 严谨工作态度，百分百的工作努力 。
  • 如果遇见了问题就要及时解决它，以往的经验来看，凡是没有验证过的场景就一定存在bug，在发现问题或预测到问题的存在时，就 尽早的去解决 它，否则隐藏的风险会在后期不对放大， 如果你认为没问题，那么问题很快就会来找你 。
  • 如果发现一个会影响大家的问题， 主动去修复 它，避免问题的延续导致影响更多的人，以及更长的影响时间。
  • 维护好自己的 TODO list ，确保有序高效的完成它们，切记不能遗忘否则可能会带来灾难，并且当自己不确定时及时请高层次的人员或负责人来帮助自己确认。

7个好习惯之保持面向对象的开发习惯

  • 对于设计人员， 面向对象 的开发方式不一定要熟悉，但对于验证人员，它的重要性尤为显著。
  • 无论使用SV、SC、C++还是Python，如果需要开发一个 长期维护 的环境或工具，请先考虑 面向对象 的方式。

7个好习惯之合理复用

  • 复用 是高效验证的核心理念，无论是方法学的推陈出新还是验证环境的搭建维护，都需要考虑复用。
  • 复用 所涉及的范围很广，除了设计模块复用、验证环境复用、测试用例复用之外，也包括项目环境复用、 脚本 复用等。
  • 验证目前占到整个芯片开发60%以上的工作量， 提高复用性 可以 加快验证速度和减少维护成本 。
  • 为了提高复用性，在构建验证环境时，尽可能考虑 验证环境参数化、脚本自动化、提交文档 等方式，使得验证环境的维护和使用。

7个好习惯之保持创新

  • 从新手逐渐变为“老司机”之后，往往会有一段 倦怠期或自满期 ，因为验证人员觉得：他对所属的模块已经足够掌握，验证环境也熟悉，似乎没有那么多再需要深挖的地方了。
  • 这个时候，可以 争取新的模块和任务 ，往往“老司机”和新任务的搭配，能够 发现更多的问题和改善措施 。
  • 我们相信验证总会有需要不断完善的地方，在新的空余你的思想还会保持一段活跃的时间，从而提出一些新的改善方法。
  • 如何让大脑 保持不断创新 ？除了不断学习。不断交流外，那就是永远 追求验证效率 的提高。实际工作中的创新，一旦被证明它对整个团队的价值，那么不单单是它的作用会逐渐放大，而且你也可以感染和吸引更多的人，一同加入到你们的创新队伍中去。

7个好习惯之高效的沟通

  • 首先，多人团队可以进一步 拆分 为5人以内的小组， 平行 执行任务，保持各组之间的 独立 。
  • 其次，在可行的情况下优先考虑 面对面谈话 ，次者打电话，再次者写邮件，我们相信口头表达是最高效的方式。
  • 再者，尽量 少开会、开短会 ，只邀请必要的人参加，节省他人时间，也节省自己的时间（最害怕白天开会，晚上加班coding）。
  • 最后，如果有条件，可以将团队在一些 关键项目节点 前，聚集在一起办公进行 团队作战 ，减少沟通成本。

7个好习惯之突破责任边界

  • 在设计的 边界划分 上，我们可以通过定义模块层次和结构来实现，而在验证工作中，我们无法很 清晰的划分出边界 ，因为模块间有互动功能。
  • 一般情况下，我们会遵循 主从端、上下行数据传输和功能实现工作量大小 的方式来确定， 互动功能 由哪一方来验证。
  • 尽管我们希望以一种合理的方式来划分验证边界，但仍然难免有一些边界不清晰的功能交互部分。
  • 如果有关联的模块A、B双方可以 突破责任边界 ， 积极承担 各自的部分，或者从项目整体出发，去定义验证的完整方案，在考虑工作的承担问题，毫无疑问这对于整体验证质量是有益的。
  • 主动突破责任边界 ，会对自己的成长很有帮助，学到更多东西。

验证的专业化

对于验证的偏见

  • A公司目前的 设计复杂度低 ，而且有面向市场的进度压力，所以他们更愿意将设计做完后经过 简单的测试 直接将 原型验证通过FPGA来实现和测试 ，至于 RTL验证 的投入则少的可怜。

  • B公司的 验证平台 已经很多年 没有更新 ，尽管 设计越来越复杂 ，但是因为一直缺少经验丰富的验证师来更换升级公司的验证平台，所以在项目开始，尽管能听到越来越多对于验证平台老旧不方便的抱怨，项目管理者还是以 缺少合适的人力 为理由，让大家 通过加班来弥补验证平台的效率缺失 。

  • C公司 没有专门的验证团队 ，而验证的工作几乎是公司内部的 设计人员之间相互合作验收 的，在 缺少验证标准、计划、环境和文档 的情况下， 设计师同时也兼任了验证师的角色 。如果询问设计师，实施验证是否困难？他们会回答，这不就是添加激励，看看行为是否异常吗？在他们眼里， 设计工作才是应该受到公司最多关注的 。

  • D公司验证团队整体实力与设计团队有不小差距，通过分析我们可以发现，该公司的 验证团队 是由公司 不合格或暂时没经验的设计师和新进公司的新手 拼凑组成的。公司的管理层认为，验证的好处不单单是可以发现一些漏洞，还可以让那些 不合格或暂时没经验的设计师先到验证环境去熟悉 ，至少不会因为一些简单的错误给设计种下一些严重的漏洞。看起来D公司的验证团队接收到的，是一种 隐形的“二等公民” 。不过通过验证工作，debug过程可以熟悉设计，进而在对设计有一定理解之后，逐渐承担设计任务，也是很多公司目前采用的培养方式。

  • E公司的设计团队和验证团队比较健全，然而他们之间的 沟通经常不顺 。当验证人员在项目前期发现bug时，还可以和设计人员探讨修复bug的问题，而到了 项目的后期 ，如果再发现什么严重的漏洞，设计人员就显得不那么愉快了。因为 漏洞越到了后期才被发现，修复漏洞的难度和代价越大 ，同时由于项目进度的压力，有时候设计人员不得不 加班加点 去完成，这就是为什么不愉快的原因。

验证的专业化认识

  • A公司虽然看起来在用FPGA可以快速得到测试结果，但是更多地是将设计作为 黑盒验证 ，缺少内部信号的检查调试，同时 缺少随机激励的场景 来达到 验证的完备性 ，缺少 边缘场景错误场景 保证设计的稳定性。

  • B公司为什么缺少合适的人？深层次的原因恐怕与公司 对验证不重视 有很大关系。如果一开始从验证人员招聘和对验证贡献的充分肯定上入手，那么 验证人员的培养不会滞后于设计人员太多 。

  • C公司除了对与设计师的验证能力充分“信任”之外，也没有觉得验证是一项 单独需要培养的技能 ，或者说 缺乏对一个专业验证团队的认识 。事实上，验证确实不是一项技能，而是需要很多知识综合起来的技能。

  • D公司看起来倒是通过这种小聪明，使得烫手的员工没有做出什么可能让公司无法挽回的损失。但除了 让员工被感到不信任 之外，公司又如何能够保证他们的验证工作做的足够好？要知道验证和设计一样重要， 设计种下了漏洞，验证没有发现，同样是致命的 。

  • E公司的设计人员越到后期越不情愿听到自己的设计被发现漏洞，而且和验证人员沟通起来也颇为困难。除了对于设计和验证的关系需要理清之外，该公司还需要 多鼓励验证团队 ，让他们在 关键时刻顶住压力 ，该报告的设计漏洞需要义无反顾的提交，并且到 后期每报出一个漏洞都应该值得庆幸，因为幸好它没在流片后回来才被发现 。

验证面临的现状

  • 芯片业对验证的偏见不单单来源于公司和业界的成见，就连 教育行业 也是如此。高校的教育与芯片行业的脱节十分严重，基本很少看到有高校 开设关于芯片验证的课程 ，哪怕是导论。
  • 国内芯片验证领域 可参考的书目 也不多，而国外优秀的图书又没有得到及时的翻译和引进。
  • 对于从事验证的工程师，业界优秀的图书本身也与实际工作联系不够紧密，而大多数人 缺少时间和资源 来查阅每年最新的验证领域的相关论文。
  • 国内缺少验证行业广泛交流大会，使得验证工程师在经验积累和技术交流上，缺少途径。
  • 就公司而言，对于验证工程师的培养以及职业发展路径上，应该给出明确的信息，从公司层面给出对验证工程师的认可，让验证工程师对于自己的职业发展感受到动力。

验证的标准化

  • 如果想让验证技术呈现出更清晰的理念，首先要将 验证的流程标准化和量化 ，就像软件测试的环节一样。无论对于团队还是个人，只有趋于标准化、量化的验证才能更稳固地推进项目，从而做到心里清楚，手中不慌。
  • 验证团队除了需要优秀的验证工程师，也需要经验丰富的验证经理，这一要求的着眼点不只在于日常管理，也包括针对 芯片整体验证去规划验证框架、环境、流程、制定验证计划、评估人力、时间节点 等。
  • 验证经理会对所在的项目、之前的项目和未来的项目之间验证环境的复用和优化两方面考虑，要求模块、子系统和系统级验证环境可以保持 垂直复用 和 水平迁移 的要求。同时验证经理也需要考虑采样哪一种验证方法、选派合适的人进行验证等。

验证经验的积累和突破

  • 经验分享 是需要长期贯彻的事情，包括公司的内部分享和公司的外部分享两方面。验证的事务做久了容易让人产生倦怠，原因主要在于验证工程师对于验证环境逐渐掌握，趋向于按照现有的环境框架去思考问题，也容易对现有环境的效率感到满足，很难做到主动突破现有框架、做出改善甚至验证环境换代的举措。
  • 公司内部的交流值得推荐，除了 沟通成本小 ，不同验证团队、不同事业部或者分公司之间都可以就验证技术展开交流。
  • 请 EDA技术支持工程师 ，为大家培训，或咨询。
  • 通过总结自己的验证经验，完成体系的验证思想，发表到行业技术大会以及其他技术交流会议，同其他公司分享，也查看和听取其他公司的技术分享和探讨。

文章原创，可能存在部分错误，欢迎指正，联系邮箱 cao_arvin@163.com。

文章目录