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

看了不少回答,都在强调如何使用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,用仿真验证还是形式验证,只是具体的方法,归根结底还只能属于器物的范畴。

粤ICP备2022076896号 粤公网安备 44030702004875号
微信客服
添加微信咨询
在线客服