回归验证

 

       在芯片开发过程当中，一旦RTL代码做了修改，就有可能引入新的问题，所以这个时候就需要把已经完成了的验证用例重新跑一下，以确保RTL代码的修改没有对已经验证过的功能造成影响。我们把这一个过程叫做回归验证（也有人叫代码回归，或者只叫回归, regress）。 

       一般地，RTL代码的修改主要是因为验证人员发现了RTL代码当中存在的BUG。这时需要重点回归发现问题的那条用例，以保证BUG确实被设计人员修复了。但是开发人员在修复BUG的时候有可能理解的不够透彻，只修改了BUG的外在表现，而没有修复BUG的内在原因；也有可能是设计人员修复了一个BUG，却引入了另外一个BUG，使原本验证通过的用例不能通过。所以在回归的时候需要进行分析，针对此BUG是否需要增加新的用例，是否对原来已经验证过的用例有影响。

        另外当RTL代码当中增加或者删除了一些功能的时候，也需要进行了回归。新代码加入的时候，除了新加入的代码当中有可能含有BUG之外，还有可能对原有的代码带来影响。当然删除代码的时候也有可能造成影响。因此，每当RTL代码发生变化，我们就必须重新测试现有的功能，以便确定修改是否达到了预期的目的，检查修改是否损害了原有的正常功能。同时，还需要补充新的测试用例来测试新的或被修改了的功能。

      那么是不是说，每发现一个BUG，或者RTL代码稍有修改，我们都要把原来已经测试通过的用例重新跑一遍呢？我觉得没有必要。因为我们验证一个芯片或者单个模块，有可能开发成百上千条用例。随着验证工作的进展，测试通过的用例会越来越多，如果在后期，每回归一次，可能就要跑成百上千条用例。而这一项工作需要很长的时间和资源，会对项目的整体进度造成影响。尤其是项目如果采用迭代开发的方法，设计人员逐次提交包含功能1，功能2，功能3…的RTL代码。验证人员也是相应地完成功能1、2、3…的验证，不可能说在进行功能2的验证时，把功能1的验证用例回归一下；进行功能3的验证时，把功能1，2的用例再回归一下。当然如果可以这样做，最好了。但是我们往往没有这么多的人员、时间和资源。

      一般地，我们在所有的功能都验证完成了之后，会把所有的验证用例进行回归一次。就这一次回归，也是需要很多时间和资源的。为了提高效率，需要开发一个回归脚本来完成这项工作。脚本需要具有自动完成验证用例的提交，自动统计回归结果等功能。