新手芯片验证工程师如何快速提高自己的水平?

做芯片验证，首先要有明确清晰的认知：什么是验证行为？

说白了就是找bug。无论用什么方法，总之，在极其有限的时间内，找出尽可能多的RTL bug，这个bug可以是功能上的，也可以是性能上的，也可能是时序上的（如果跑gatesim的情况下）。

但是，至今为止，没有哪家公司敢说他们家的芯片是没有bug的，可能产品迭代了几代以后，依旧可以找到第一代产品的bug。所以，只要场景足够丰富，bug永远找不完。

所以，怎么办呢？那就是对功能测试点做优先级划分。

比如软件可回避的场景，优先级可以安排的最低，实在来不及在tapeout前甚至可以不做。

比如，dma做数据搬运时，对某个client发出了无效地址，系统该如何处理？如果软件可以确保这类访问不会被发出，那么这部分的check可以放到最后。

我们以cpu指令验证为例，所有的单指令都验完以后，指令交叉的场景可以多到怀疑人生，难道每一种排列组合都cover吗？

如果采取大规模的随机用例组合，那么random case的数量同样十分惊人，并且在漫无目的的全随机中，会存在大量重复的组合，这无疑浪费了宝贵的仿真时间。

这个时候可以采取二分法，将单指令验证归为一类，然后直接运行高度复杂的组合场景（比如多指令乱序发射+乱序指令+多核数据共享），如果证明无误，那么在这个复杂度以内的所有组合其实也被间接地证明了其正确性，初中物理中将这类做法归类于极端法。

同样的道理，在验证slave数据通路的时候，如果上层直接将每次访问的时间间隔（也就是delay）直接设置成系统允许的最小时间（通常是0），采取冲击型的访问方式，如果这种极端情况下，通路依旧可以正常工作，那么理论上正常delay间隔的所有访问的正确性也就得到了保证。

上述说的这些内容，都是在讲验证行为本身，并不涉及工具的使用。

今天我们都在讲第一性原理，通俗地讲，就是对现象进行层层还原，找到一个基本点，也就是所谓的底层逻辑（当然，也可以是物理规律），然后不断地进行 正-反-合的演绎，构建出一个庞大的符号系统。

在芯片验证中，这个基本点就是芯片系统本身，以确保系统功能完备性和准确性为目的，展开的一系列证明活动，就是验证行为本身。

所谓形而上者，谓之道；形而下者谓之器。使用uvm/sv还是c，用仿真验证还是形式验证，只是具体的方法，归根结底还只能属于器物的范畴。

所以，整个认识活动的优先级应该是，芯片系统（block/ip spec） >验证思想 （功能点以及优先级的拆分，包括验证计划） >验证方法。

【免责声明】：本站部分文章为转载或网友发布，目的在于传递和分享信息，并不代表本网赞同其观点和对其真实性负责；文章版权归原作者及原出处所有，如涉及作品内容、版权和其它问题，我们将根据著作权人的要求，第一时间更正或删除。