下图显示了功能验证流程： 这个验证过程可以被分解成三个主要阶段： 制定验证策略和验证计划； 创建验证平台， 运行和调试； 覆盖率分析和回归测试；
１ 制定验证策略和验证计划阶段
制定验证策略和验证计划阶段主要处理以下三个问题：
（１） 主要功能点和测试用例
当前， 复杂设计的测试空间是非常大的。 一个典型的百万门的设计可能有百万乃至上亿个需要测试的功能点， 将测试空间缩小到一个可以管理的范围， 或者说是一个有实际意义的集合并且没有损害其期望的功能， 这是第一步。 针对这些功能点， 我们将根据具体情况拟定验证策略和测试用例， 最后具体化到一个详细的、 可执行的验证计划中， 作为整个验证工作的指导；
（２） 验证平台的抽象层次
验证平台的抽象层次将决定它主要的处理对象： 比特、 包或者更高层次的数据类型；高层次的抽象建模可以让验证平台中低层次的功能自动化；
例如， 一个以太网的验证平台运行在比特的抽象层次中， 则要求验证工程师手工创建一个一个的数据包， 从而组成一个测试用例。 然而， 若相同的验证平台在更高的层次上建模， 例如包这个层次， 它就能够自动的生成和注入数据包， 而不需要验证人员去手工的创建每一个数据包。 这个方法将极大地减少创建测试用例的时间， 从而获取更高的测试覆盖率。 这将大大解放验证工程师， 使之可以专注在一些很难查找的边界情况 （ conner-case）上面。 提高验证平台的抽象层次， 也使得创建测试用例和检查结果更加容易；
（３） 激励生成和结果检查原则
这些原则定义了输入到验证平台的激励是如何提供的， 结果是如何检查的， 并判断测试是通过还是失败
２ 验证平台搭建阶段
这是第二个阶段， 也就是验证平台的搭建， 书写测试用例和调试阶段。 在这个阶段，书写验证平台代码和测试用例。 验证平台持续被扩展， 因为测试用例不断被添加进来。 其中， 验证平台的搭建要以可重用为基本原则， 而且能够方便设计工程师和验证工程师添加测试用例；
３ 回归测试和覆盖率收敛阶段
一旦几乎全部测试用例被成功运行， 验证就进入了回归测试 （ regression test） 和覆盖率收敛阶段。 回归测试要求能够周期的批处理运行， 二是激励必须能够容易得到重现， 成功或者失败能够自动检查。 覆盖率显示出该设计被测试的程度， 是验证收敛的重要标准；
一般会出现下面几种情况：
（1）code coverage 高 functional coverage 高 理想情况
（2）code coverage 高 functional coverage 低 需要进行更多的仿真或者修改testbench
（3）code coverage 低 functional coverage 高 可能错过了某些覆盖点
（4）code coverage 低 functional coverage 低 需要进行更多的仿真或者修改testbench
验证技术和验证方法学
本节将介绍三种常用验证手段： 白盒、 黑盒和灰盒验证； 三种主要的验证技术： 形式验证、 仿真验证和硬件加速验证； 三种重要的验证方法学： 随机激励生成、 断言验证和覆盖率驱动验证；
黑盒、 白盒与灰盒验证
功能验证的最终目标是验证一个设计是否能够像预期的那样工作。 然而， 并非在设计中的任何一个设计缺陷都能通过激励在其输出边界上被检测到， 为此可能会被遗漏。 这样的错误可能包括下列几种情况：
１） 从来没有被激发过的错误；
２） 被激发的错误没有被传递出来；
３） 多个潜在的错误掩盖了其他错误；
１ 黑盒验证
黑盒验证 指的是只通过其边界信号来验证一个模块或者设计的功能。 黑盒验证的一般的架构如图所示， 通过这种方法， 激励可以被应用到设计和参考模型中； 在某个抽象层次 （例如事务级、 指令级、 时钟周期级等）， 通过被测设计和参考模型的输出被校对。黑盒验证存在下列主要的缺点：
１） 很难验证和设计相关的特点
２） 很难调试
３） 要求一个精确的参考模型
同一个设计规范， 不可能所有的实现都做得等价。 每一个实现都包含了很多和设计相关的细节， 以达到性能或者效率上的差异， 这是每个设计之间最大的区别 （ 例如fifo的读写阈值设定或者总线仲裁器的算法） 。 这都是通过黑盒验证方法很 难 验 证 的 具 体实现。
另外一个难题是， 是否使用黑盒验证取决于被测的复杂度。 黑盒验证需要通过多个时钟周期才能查看到传递到外部引脚上的内部错误。 为此， 要求更长的仿真时间来传递这个错误； 即使这个错误在输出到外部检测到， 也很难追溯这个问题的根源。
采用黑盒验证还有一个难题， 在某种程度上要求有一个参考模型能够足够精确得可以检测所有的内部错误。 对于这样一个模型， 未必存在或者很难做得像设计那样， 为此不可能完全依靠这种验证方法；
２ 白盒验证
白盒验证 和灰盒验证 提供了另外一个途径来解决黑盒验证的局限性。 在白盒验证中， 可以不需要参考模型， 因为可以通过在设计内部或者外部输出信号放置监控器和断言来保证设计操作的正确性。
３ 灰盒验证
灰盒验证是一个综合了白盒和灰盒的一个手段， 也就是在设计内部添加监控器和断言来减少对参考模型的精确要求， 在错误发现的时候也减少调试的压力；
验证存在的挑战
功能验证是芯片设计流程中的一个挑战。 随着设计规模的变大和复杂性的提高， 上市时间的缩短， 这都意味着验证工程师要在更短的时间内验证一个更大， 更复杂的设计。 一个有效的验证方案必须解决以下挑战， 来达到验证收敛；
（１） 完备性
验证完备性的挑战， 就是如何最大限度地验证被测设计的行为。 难点在于如何获取所有必须被验证的场景。 这是手工操作的过程， 可能存在错误而且冗长。 在这个领域， 最重要的进步是采用覆盖率驱动的验证方法学。 覆盖率驱动验证方法学要求制定一个可以数量化衡量完备性， 可追踪， 有组织的验证计划。 这对于验证计划的严格要求可以暴露出可能被遗漏的相关场景。
（２） 可重用性
验证可重用性的挑战是如何优化验证环境的架构， 使之可以在不同的场合重用 （下一个版本的项目或者同一个版本的不同层次或者一个类似的项目）。 重用可以通过以下几种方式来实现： 模块化验证组件、 采用标准的接口、 将激励产生机制和验证架构分离等； 一个项目中， 深层次的重用就是如何实现一个验证平台可以供多个测试用例使用。 当然， 验证平台的重用的程度取决于验证工程师投入多少人力和时间去规划和优化， 其中也要折中考虑到项目的进程和投入回报。
（３） 可靠性
验证可靠性的挑战在于如何减少在完成一个验证项目中的手工操作。 很明显， 手工操作可能存在错误、 冗长和耗时很大。 相反， 自动化系统可以在更短的时间内完成更多的工作。 然而， 自动化系统必须通过手动搭建。 为此， 在可靠性上的改进必须细心分析在搭建自动化系统上的投入和该系统的可靠性。 约束随机验证是一个很好的方法， 通过搭建一个自动化的系统来产生激励和自动比较， 进而提高验证的可靠性。
（４） 效率
效率就是如何在给定的时间内使对验证工作投入的产出最大化 （例如， 调试失败场景的个数、 验证环境模块的实现等）。 提高验证效率已成为功能验证中的最重要的挑战。 在设计流程中， 重用等技术已经给予了设计工程师更高的效率。 验证效率的提高已远落后于设计方面， 这使得功能验证成为了完成一个项目中的瓶颈。 高效的功能验证要求消除在设计和验证之间的这个鸿沟。 提高验证效率可以通过提高验证平台的抽象层次和采用重用的。
（５） 性能
验证程序性能上的挑战就是如何最大化验证程序的效率。 消耗在一个验证项目上的时间主要是由验证工程师投入的人工来决定的， 为此， 在设计和搭建验证环境中验证程序性能是第二个要考虑的因素。 在运行回归测试的时候， 迭代周期主要为验证平台运作的有效性来决定， 验证程序的性能成为这个阶段的主要因素。 对专业工具和语言的掌握是实现一个验证环境和改善验证性能的必要条件。
验证方法学
验证一个设计需要回答两个问题： “ does it work？” （ ＤＵＴ 能够正常工作么？） （在验证计划中可以分解成： 测试什么功能点？ 怎么测？ 最后功能对不对？） 和 “ are we done？” （我们做完了么？）。 第一个问题属于最基本的验证概念， 也就是说设计能否符合设计者的意图；第二个问题就是问我们的验证是否充分和完备， 验证是否达到收敛。 我们可以通过这两个问题来揭示整个设计和验证的流程:
