设计复杂度的增加、IP重用等当前复杂SoC/ASIC设计的特性要求对设计的功能进行更加充分的验证。基于PSL的功能覆盖率分析与传统的代码覆盖率分析共同构成了一个完整的衡量电路验证质量的尺度，这一全新设计方法学的使用将有效提高验证的质量和效率。
随着集成电路的广泛应用，对功能正确性及速度、功耗、可靠性等都有严格要求。其中，功能正确性是最基本的要求。2003 年度的国际半导体技术发展报告（International Technology Roadmap for Semiconductor, ITRS2003）指出，验证已经成为集成电路设计流程中开销最大的工作。在目前的工程项目中，验证工程师的数目超过了设计工程师，对于复杂的设计更是达到了2:1 或者3:1 的比率。造成这种局面的原因有二 ：一方面，设计的规模正如摩尔定律所指出的呈指数增长。如果用设计中的状态数目来衡量功能复杂度的话，则设计的功能复杂度随着设计规模又呈指数增长。如此惊人的速度，对验证技术的处理能力提出了极大挑战。另一方面，历史上对设计流程中的其它环节（如逻辑综合、布局布线、测试产生等问题）关注颇多，而对验证重视不够，造成验证成为目前的瓶颈。如果没有重大突破的话，验证将成为未来集成电路设计工业流程中的重大障碍。

功能覆盖率
随着集成电路设计规模越来越大，使得穷尽模拟所有的输入组合的方式在计算上逐渐不可行。如何利用合理的时间和计算资源达到最理想的模拟效果，这是一个具有实际意义的问题。同时随着随机激励生成技术的发展，约束（constrains）和偏置（biasing）技术大大提高了随机向量的质量，与传统的随机验证相比，约束化的随机指令生成可以在更短时间内执行更大量的相关测试，并且达到高覆盖率。随机激励生成实现了自动化，但是基本上没有考虑检测设计错误的能力，因此如何确定约束化的随机验证效果也是一个不容忽视的问题。解决这两个问题通常的做法就是运用覆盖评估技术。在模拟验证中，覆盖评估能够量化地度量模拟激励集的完备性。同时，对于当前的激励集来说，覆盖评估技术能够诊断出哪部分设计尚未充分验证，有助于后续的激励生成。
覆盖评估技术起源于软件测试。其中的覆盖评估主要以代码为对象，如：语句、分支、表达式、路径等等。由于用硬件描述语言所写的设计也是一种软件，所以代码覆盖评估很容易从软件测试领域移植到设计验证中来。这种评估技术简单易行，但是其评估能力较弱。由此出发，结合硬件设计的特点，派生了其它的覆盖评估技术，例如电路结构覆盖、有限状态机覆盖等等。
现有的商用HDL代码覆盖率工具通过在HDL代码中插入特殊的PLI(Programming Language Interface)任务在动态仿真过程中捕获代码覆盖率。图1中显示了商用代码覆盖率工具的使用方法。由于仿真过程中调用大量PLI任务造成仿真速度的降低，因此随着设计规模的增大，代码覆盖率分析的效率也越来越低。
功能覆盖率主要是面对设计的功能而不是HDL(Hardware Description Language)代码，所以使用断言语句验证功能覆盖率可以更有效地描述所需捕获的边脚逻辑以及所有感兴趣的数据及控制信号的组合。这里描述的功能覆盖率可以被认为是断言规范的一种延伸，从某种意义上用户不再需要为了测试功能覆盖率而再一次描述那些复杂的表达式。那些用于描述设计功能、变量以及其他行为的断言语句都可以用来作为功能覆盖率的建立基础。通过观察每一条断言语句如何被执行，用户可以了解验证是否达到了所需要的覆盖率。
代码覆盖率与功能覆盖率的关键不同点在于：在验证过程中，代码覆盖率检测激励所执行测试代码的验证效率；而功能覆盖率用于检测激励所执行代码功能的效率。传统上，设计功能的验证是基于动态的仿真，通过观察仿真结果发现、定位设计的缺陷。随着ASIC和SoC设计复杂性的增加，如何有效地构建设计的测试激励，缩短验证周期，这些为功能验证带来了巨大的挑战。因此高效率的测试激励自动生成技术也是当前设计验证的热点技术之一。测试激励自动生成的核心是带约束的随机测试激励自动生成。由于随机测试激励技术的产生，简单的100％的代码覆盖率已无法保证设计被100％的验证。而功能测试覆盖率可以更有效地告诉哪些功能已经经过测试，根据这些信息我们可以动态调整产生随机测试激励的约束条件，从而明显地提高测试效率。但是，功能覆盖率还不能完全替代代码覆盖率的所有工作，代码覆盖率在保证代码书写质量上仍有着重要的地位，只有当代码覆盖率和功能覆盖率都达到100％时，我们才可以认为我们的设计得到了比较好的验证（即使代码覆盖率和功能覆盖率都达到100％，也不代表设计已被100％完全验证）。功能覆盖率与代码覆盖率结合在一起，可以为设计和验证提供一个完整的质量验证标尺。

断言验证
断言验证就是在模拟中引入形式特征检查的验证方法。用这种方法，设计师编码时插入对特征