验证的目标讲起来很清晰，就是在一定的时间尽可能多的测试硬件设计，发现设计缺陷并报告出来。同时，验证本身也是一项棘手的挑战。这一点可以从语言发展的属性和EDA工具在验证支持的快速发展上得到佐证。

我们从VHDL的语言发展线路来看，它的标准IEEE Std 1076-1987逐步经历了1076-1993，1076-2002再到1076-2008，这中间的年份从1987年逐步发展到2008年，可是我们真正在使用的设计标准是那一部分呢？目前我所在公司可能超过80%以上的设计都基于1076-1987，这是将近20年之前的标准啊，可是对于设计来讲已经足够用了，因为设计面临的问题不是语言自身的局限，而更多的是设计人员的经验和思想。此外，剩下的20%VHDL代码也仅仅是1076-1993。

同样的，我们看看Verilog语言的发展从IEEE Std 1364-1995到1364-2001再到1364-2005。目前我们所使用的Verilog代码也基本是在遵循1364-2001的标准，EDA工具商也主要在支持这一年份标准。

我们再来看看目前的主流验证语言SystemVerilog的发展情况，如果不将它在被列入IEEE标准之前在Accellera坐板凳的日子，它正式被认定位IEEE Std 1800-2005是从2005年才开始的！可我们看看它的发展速度在这10年以来已经经历了1800-2009和1800-2012，更重要的是，它的每一次更新都得到了工具商的及时支持。为什么呢？因为实际验证的需要，绝对的需要。这一点，我们也会在稍后的文章《SystemVerilog 2012的更新介绍》中带大家一起来回顾，帮助摘录出来重要的更新特性。

伴随着芯片自身的复杂度日渐提高，以及一直存在的项目进度压力，如何解决验证的完整性和高效性变成一个大家都关注的话题。概括来讲，验证目前面临的两个挑战是：

1. 如何穷尽所有可能的情况给设计产生激励。

2. 如何在各种可能的激励情况下判断出不符合硬件描述的行为并报告出来。

这两个挑战都很大！

我们先看看挑战1，如何穷尽所有可能的情况。在这里我们单拿手机屏幕显示来举例吧，假如手机屏幕分辨率是1920x1080，像素点的色彩值是2³²，同时由于每个像素点之间的状态是独立的没有联系，那么屏幕可能分布的状态应该是:

        2³²x(1920x1080) = 8,906,044,184,985,600

如果再考虑到像素点色彩值的变化，那么在连续两个时钟下，像素点可能发生的状态跳转空间是：

        2³²x(1920x1080) x  2³²x(1920x1080) = 7.9x10³¹

这仅仅是屏幕色彩的一个基本功能，而可以预见到的状态空间数目就足以让人抓狂了吧。

所以，面对这样的挑战，我们需要作出一些平衡，这种平衡来自于状态空间本身的庞大和项目实施中的进度压力，而为此如何有效划分出有效的测试空间，以及如何给出随机约束激励，是验证人员需要具备的职业素质。

接下来我们看看挑战2，如何在各种激励下判断出硬件设计的缺陷。首先我们把常见的硬件设计划分为下面几类，同时再看看针对不同设计种类应该侧重的激励输入类型和结果判断的方法。

通过上面的列表我们可以发现，针对不同类型的设计，我们需要产生的激励类型和结果比对方法也是不一样的。针对不同类型的设计、不同复杂程度、不同集成度的设计，我们会考虑采用不同的验证方法。

从验证工具的分类来看，我们可以将其分为仿真验证和形式验证，从复杂度出发来看，我们可以随之考虑根据设计透明度来划分为黑盒验证、白盒验证以及灰盒验证。关于验证的方式以及合适的运用场景，我们也会在后面的文章《验证的策略》里面展开详细讨论。

下一次内容，我们将会和大家讨论《验证能力的五个维度》。

您可以在手机移动端同步关注订阅号“路科验证”。

如需转载请联系路科验证，并注明出处“路科验证”。