904
看了不少回答，都在强调如何使用uvm的。UVM/SV属于工具范畴，工具用的熟不熟练，当然非常重要，但是脱离了芯片本身讨论工具未免有些本末倒置。
举个例子，验cpu core中fpu（也就是浮点运算）的同学可能一年到头都用不到几次uvm，以此类推，环境写的好不好，优化的程度高不高，重要吗？重要。但是作为验证工程师，最重要的在于验证行为本身。
什么是验证行为？说白了就是找bug。无论用什么方法，总之，在极其有限的时间内，找出尽可能多的RTL bug，这个bug可以是功能上的，也可以是性能上的，也可能是时序上的（如果跑gatesim的情况下）。但是，至今为止，没有哪家公司敢说他们家的芯片是没有bug的，可能产品迭代了几代以后，依旧可以找到第一代产品的bug。所以，只要场景足够丰富，bug永远找不完。
所以，怎么办呢？那就是对功能测试点做优先级划分，比如软件可回避的场景，优先级可以安排的最低，实在来不及在tapeout前甚至可以不做。比如，dma做数据搬运时，对某个client发出了无效地址，系统该如何处理？如果软件可以确保这类访问不会被发出，那么这部分的check可以放到最后。
我们以cpu指令验证为例，所有的单指令都验完以后，指令交叉的场景可以多到怀疑人生，难道每一种排列组合都cover吗？如果采取大规模的随机用例组合，那么random case的数量同样十分惊人，并且在漫无目的的全随机中，会存在大量重复的组合，这无疑浪费了宝贵的仿真时间。这个时候可以采取二分法，将单指令验证归为一类，然后直接运行高度复杂的组合场景（比如多指令乱序发射+乱序指令+多核数据共享），如果证明无误，那么在这个复杂度以内的所有组合其实也被间接地证明了其正确性，初中物理中将这类做法归类于极端法。
同样的道理，在验证slave数据通路的时候，如果上层直接将每次访问的时间间隔（也就是delay）直接设置成系统允许的最小时间（通常是0），采取冲击型的访问方式，如果这种极端情况下，通路依旧可以正常工作，那么理论上正常delay间隔的所有访问的正确性也就得到了保证。
上述说的这些内容，都是在讲验证行为本身，并不涉及工具的使用。今天我们都在讲第一性原理，通俗地讲，就是对现象进行层层还原，找到一个基本点，也就是所谓的底层逻辑（当然，也可以是物理规律），然后不断地进行 正-反-合的演绎，构建出一个庞大的符号系统。在芯片验证中，这个基本点就是芯片系统本身，以确保系统功能完备性和准确性为目的，展开的一系列证明活动，就是验证行为本身。
所以，整个认识活动的优先级应该是，芯片系统（block/ip spec） > 验证思想 （功能点以及优先级的拆分，包括验证计划） > 验证方法。
所谓形而上者，谓之道；形而下者谓之器。使用uvm/sv还是c，用仿真验证还是形式验证，只是具体的方法，归根结底还只能属于器物的范畴。
