case与验证环境的划分界限?
时间:10-02
整理:3721RD
点击:
各位大神好,首先声明小弟不是搞专职验证的,不对之处海涵。
本人在进入新公司后遇到了点文化差异,有关case与验证环境的划分界限在哪?
旧公司:验证环境只包括电路的搭建等静态的东西,此部分代码做成common的文件。
其他所有与当前特定验证点相关的东西,包括激励的产生、发送,结果的采集、检查相关的代码全都作为case的内容,放到独立的文件中。
新公司:“case”,仅指对transaction类中各种变量赋值的代码。其他所有的代码(驱动、检查相关的)都放在验证环境里。
对新公司的做法,我有点疑惑。我想,只有电路中截取的一块小电路才是只有单一的功能,仅仅给予不同的信号值作为激励就可以验了。
稍微大点的功能模块都是有好多动作模式,进而对于不同的动作模式相关的case,有不同的结果检验方式(只有在验单一的动作模式,比如正常状态下的简单收发,才可以用一套单一的结果检验方法)。那么,用新公司的这种在case中修改不同的变量值,来指导整个验证环境动作的方法,就会导致:
(1) 要么在验证DUT另一个截然不同的动作模式时,需要手修改验证环境内的代码;
(2) 要么在case中要多准备好多作为选择信号的变量,同时在验证环境中也要多写好多根据前述的选择信号进行选择不同的代码块的代码,显得冗长庞大。
各位大神们的验证环境与case的划分是怎样的?
本人在进入新公司后遇到了点文化差异,有关case与验证环境的划分界限在哪?
旧公司:验证环境只包括电路的搭建等静态的东西,此部分代码做成common的文件。
其他所有与当前特定验证点相关的东西,包括激励的产生、发送,结果的采集、检查相关的代码全都作为case的内容,放到独立的文件中。
新公司:“case”,仅指对transaction类中各种变量赋值的代码。其他所有的代码(驱动、检查相关的)都放在验证环境里。
对新公司的做法,我有点疑惑。我想,只有电路中截取的一块小电路才是只有单一的功能,仅仅给予不同的信号值作为激励就可以验了。
稍微大点的功能模块都是有好多动作模式,进而对于不同的动作模式相关的case,有不同的结果检验方式(只有在验单一的动作模式,比如正常状态下的简单收发,才可以用一套单一的结果检验方法)。那么,用新公司的这种在case中修改不同的变量值,来指导整个验证环境动作的方法,就会导致:
(1) 要么在验证DUT另一个截然不同的动作模式时,需要手修改验证环境内的代码;
(2) 要么在case中要多准备好多作为选择信号的变量,同时在验证环境中也要多写好多根据前述的选择信号进行选择不同的代码块的代码,显得冗长庞大。
各位大神们的验证环境与case的划分是怎样的?
大神在哪里?
环境是一个整体c类,基本上不动。测试用例可以例化环境实例,在测试用例中变化。