验证编程范式这么远又那么近


新人刚进入公司,若之前未做过相关工作且无导师梳理编程范式,同时没从编程模板、Java、C++相关编程范式书籍中接触过,对编程范式这个词可能了解不多。
直观来讲,新人进入公司后,接触更多的是已搭建好的验证环境以及前辈们写的测试用例。从项目节奏要求来看,更希望新人能基于现有环境和测试用例赶上工期。但这一过程中,难免会为了赶工期而不重视早期验证环境搭建的合理性,后期写测试用例时也可能出现冗余甚至垃圾代码。
从UVM方法论来看,有足够源码证据表明其参考了软件面向对象编程的思想与模板,比如类的注册、类的覆盖,同时它也有因验证环境需求而发展出的自身特点,比如不同的phase机制、组件之间的连接等。
坦白来说,我们并没有过多引入软件面向对象编程中的思想或更多模板,这主要源于验证环境自身的特点,无论是模块验证还是系统验证,其实现过程不会像大型软件项目那样反复堆叠。比如在工作环境中,一些公司不会将模块验证环境垂直复用到系统验证环境,也未必在现有系统验证环境基础上做改动,以满足下一个项目的需求。对于多数验证工程师而言,他们在这方面的经历并不充分。
也正是因为验证环境的框架就项目而言,不会像软件项目那么大,并非说验证范式或编程范式不重要,而是验证环境在日常实操中的代码比例,以及项目前期搭建所花费的时间比例都没有那么高,所以我们或多或少会疏忽验证环境对个人及整个团队工作效率的提升作用。
从这个角度来看,尽管UVM验证方法论涉及的软件编程模板思想没有那么多,但我们仍希望验证工程师能重视这一点。在与不少在职工程师沟通时,我们也听到了他们的一些烦恼,比如公司现有环境过于散乱,项目进程中搭建的验证环境存在结构不清晰、临时拼凑的历史背景。后续随着人员交替,这类臃肿的环境以及臃肿的测试用例带来的效率浪费会越来越明显。
所以我们希望不管是模块验证还是系统验证,都能提升编程范式的重视程度。往小了说,这其实就是一种编码风格(coding style);往大了说,希望公司在新人培养方面,以及团队或公司的CAD部门、验证平台部门或方法学部门,能将这些编程范式梳理出来。
但至于编程范式的复杂度、颗粒度、自动化程度,以及如何与工程师日常工作结合,让他们理解编程范式的必要性,而非机械应用或遵循,这一点我们下次再谈。
#IC验证 #芯片验证 #集成电路 #半导体 #芯片 #IC #验证环境#UVM
直观来讲,新人进入公司后,接触更多的是已搭建好的验证环境以及前辈们写的测试用例。从项目节奏要求来看,更希望新人能基于现有环境和测试用例赶上工期。但这一过程中,难免会为了赶工期而不重视早期验证环境搭建的合理性,后期写测试用例时也可能出现冗余甚至垃圾代码。
从UVM方法论来看,有足够源码证据表明其参考了软件面向对象编程的思想与模板,比如类的注册、类的覆盖,同时它也有因验证环境需求而发展出的自身特点,比如不同的phase机制、组件之间的连接等。
坦白来说,我们并没有过多引入软件面向对象编程中的思想或更多模板,这主要源于验证环境自身的特点,无论是模块验证还是系统验证,其实现过程不会像大型软件项目那样反复堆叠。比如在工作环境中,一些公司不会将模块验证环境垂直复用到系统验证环境,也未必在现有系统验证环境基础上做改动,以满足下一个项目的需求。对于多数验证工程师而言,他们在这方面的经历并不充分。
也正是因为验证环境的框架就项目而言,不会像软件项目那么大,并非说验证范式或编程范式不重要,而是验证环境在日常实操中的代码比例,以及项目前期搭建所花费的时间比例都没有那么高,所以我们或多或少会疏忽验证环境对个人及整个团队工作效率的提升作用。
从这个角度来看,尽管UVM验证方法论涉及的软件编程模板思想没有那么多,但我们仍希望验证工程师能重视这一点。在与不少在职工程师沟通时,我们也听到了他们的一些烦恼,比如公司现有环境过于散乱,项目进程中搭建的验证环境存在结构不清晰、临时拼凑的历史背景。后续随着人员交替,这类臃肿的环境以及臃肿的测试用例带来的效率浪费会越来越明显。
所以我们希望不管是模块验证还是系统验证,都能提升编程范式的重视程度。往小了说,这其实就是一种编码风格(coding style);往大了说,希望公司在新人培养方面,以及团队或公司的CAD部门、验证平台部门或方法学部门,能将这些编程范式梳理出来。
但至于编程范式的复杂度、颗粒度、自动化程度,以及如何与工程师日常工作结合,让他们理解编程范式的必要性,而非机械应用或遵循,这一点我们下次再谈。
#IC验证 #芯片验证 #集成电路 #半导体 #芯片 #IC #验证环境#UVM
夜雨聆风
