对于任何一家IC公司，验证是确保IC品质的必要环节。在2005年加入瑞萨电子随后的5年内，IC验证的工作量占比我们团队每年业务内容的80%以上。我带领团队执行过4bit、8bit、16bit 的微处理器功能验证，累计验证的产品近40个型号，对IC验证算是有些认识，所以今天聊聊IC验证的事儿。
1、IC验证，验什么
IC新产品的功能规格和性能指标，通常是基于既存产品的规格以及未来可能的应用而设计的。但是，作为IC原厂的验证，应该是脱离具体应用的 “单体验证”。对于用户可编程的IC产品，“单体验证” 是指以IC内部寄存器的每个功能 bit 为基本验证单元，逐位验证各项功能的基础验证。
本土的IC公司，不少是从IC应用方案商转型而来的。因此其IC验证内容，仅少部分执行的是单体验证，更多是沿用方案开发商的思维、验证内容是基于应用方案的 “组合验证”。如此验证的后果是：即使寄存器的某个功能 bit 动作异常，“组合验证” 却未必能够发现。因为组合验证考察的是多个功能单元联合动作的结果，可能会出现 “负负得正” 的虚假正确结果，这种案例我自己在验证初期也曾遇到过。
不少的IC验证工程师，是从开发IC应用方案的职位转型过来的，不具备IC原厂的验证实操经历，对于 “IC验证需要验什么” 这个问题的认知其实是比较模糊的。加入瑞萨之初，我对IC验证的认知同样如此。后续通过日方工程师2年时间的常驻指导和自己深入学习日本人的过往验证报告，逐步领悟了IC验证的正确方针。
举例说明：快充IC的验证
在验证快充芯片的功能时，很多公司通常是要验证充放电功能的。但是，快充芯片自身其实是不具备充电和放电功能的，需要结合外部功率MOS和电感电容才能实现。充放电本质上是快充应用方案的功能，而非快充IC自身的功能。对于方案的充放电功能，映射到芯片自身的功能，主要是快充芯片的多功能PWM。如果PWM的单体功能验证结果符合设计规格，那么快充芯片的PWM功能就是正确的，就能实现正确的充放电功能。如果出现不能正确地充放电操作，那也是应用方案的问题，而非IC自身的问题。这个是IC原厂验证IC的基本思路。
2、IC验证，谁来验
前面提到了单体验证和组合验证。那么每个类型的验证，通常该由哪个部门、或者说那个岗位的工程师来执行呢？
● 单体验证：验证部门的职责。
--> 目标是确认IC自身的每个功能是否都能正确动作。
● 组合验证：应用部门的职责。
--> 目标是根据预想应用的需求，确认IC某几个单元的联动是否符合目标规格。
如果以应用方案商的思维执行IC验证，那么后果必然是单体验证不充分。那么在后续的客户应用开发实践中，会出现各种IC原厂验证未曾发现的问题。
改善方法：
验证部门应以单体验证作为重点、兼顾少量的多功能组合验证。如果确需大量的组合验证，应该由应用部门来实施，或者应用部门制定详细的组合验证规格并提交给IC验证部门来实施。两个部门各有侧重才能兼顾单体验证和组合验证，实现全面、细致的IC验证。
3、IC验证，输出什么成果
验证团队的验证工作，通常会涵盖两个职能：
● IC设计启动前的POC验证：
利用FPGA搭建验证板，确认某个功能是否可以在IC设计中实现。这类验证的输出成果是向设计部门提供可行性报告：目标功能是否可以集成到IC内部来实现。
● IC生产样片后的功能验证：
利用样片搭建验证板，确认IC所有功能和性能是否满足设计规格。这类验证的输出包括2个方面：首先是向设计部门提交验证报告，指出每个功能是OK还是NG，以及性能参数是否满足目标规格。另外一个输出是：对于发现的IC瑕疵 （达不到Bug级别的功能限制），总结成 “注意事项” 通知应用部门、并追加到应用文档中，提醒IC使用者在应用开发中注意、规避这个问题。
4、IC验证，如何呈现结果
验证结果是OK还是NG，是基于一定的验证条件和验证方法、对测得的波形或数据进行判定得出的结论。因此，每个验证子项的验证报告内容，都必须涵盖条件、方法、过程（实测数据/波形）、判断结论四个部分。
作为每个验证项的成果物，必须有相应的验证代码和验证报告同步保存。因为验证条件、验证方法的正确性都是通过代码实现的。并且，同步保存和各个验证项一一对应的验证代码，对于 “复核时快速复现当初的验证结果” 是非常必要的。
很多IC验证者为了加快验证进度，经常在同一个验证程序文件中、修改不同的代码行来实施各个不同验证子项的验证，如此操作的后果是：在最终保存的验证工作成果中，经常会发生以下问题：
1）验证代码和验证项内容不一致。
=>多个验证项是在同一代码文件中修改不同地方来验证的，造成复核时不易快速复现报告中的NG结果，因为保存的验证代码可能和发生NG的代码并不一致。
2）验证代码行的注释内容和本行代码的实际功能不一致。
=>同一源文件在验证中反复修改，经常忽略了注释内容的相应修改，造成代码功能和注释内容不一致，易读性差，不易复用。
改善方法：
=> 每个验证子项使用单独的验证代码源文件。修改代码行的功能时，必须修改代码行的相应注释内容。
5、IC验证，如何提升效率和品质
提升效率和品质，除了工程师自身技术力的提升，需要强化既存验证资源的可复用性。
1）改善成熟的IC验证，生成一套完整包含 “验证规格+验证代码+验证报告” 的验证模板，可复用性强、新人易上手；
2）同一模块在某个IC产品上完成验证后，后续基于该IC而设计的衍生产品，不必再重复验证这个模块的全部项目，仅验证重点内容甚至不验证；
3）每个验证项尽可能独立化、简单化，减少每个验证项和其他功能单元的关联；
4）使用正确的验证条件和方法，尽可能利用测试波形（可留存）作为判断依据，而不是直观的指示（如闪灯）；
感想：
高效率和高品质的验证，需要制定详细的 “验证规格”：明确验什么、怎么验、判断验证结果OK的标准是什么，这是验证团队不断提升效率和品质的重要资源，也是IC原厂的重要财富；工作风格严谨、细致的验证工程师，则是正确、高效地执行验证规格、找出IC中潜藏Bug 的人力保障。二者对于IC原厂保证IC品质都是必不可少的，其中人力是更活跃、对最终验证工作的品质更具影响力的要素。即使使用相同的验证规格，严谨、细致的资深验证工程师能从验证过程的波形细节中发现更多的问题。
