从现在各个项目遗漏的bug 来看，目前的问题主要集中在以下个方面
（1）UT/BT 的testfeature 没有考虑场景验证，模块验证负责人不知道自己的模块在客户是实际上配置是什么，怎么使用的。完全是从规格角度进行分解，我之前就反复跟大家强调过，验证要从规格设计（白盒）和使用场景（黑盒）两个角度了解角度进行分解。既要像设计者一样进行考虑，怎么做更好，又要像客户那要考虑，如果遇到问题，仅仅从客户能看到的寄存器配置和端口怎么快速debug 到问题，目前设计是否够友好。
（2）testfeature 分解只有配置，没有输出，没有说明要check什么。这次培训 培训内容就是“testfeature 分解和superbench 3.0使用简介"。我们写的testfeature 往往真得还有很多问题，但是我也理解，有时候要写好一个testfeature 真的需要花很多时间，有时间有限，折中处理一下也是可以，关键是有些testfeature 写得实在是太简单了，有些写的像设计规格。有时候感觉还不清楚testfeature 和 设计规格区别。这个不仅仅只是形式问题，现在很多bug 都和这个相关，比如有些testfeature 我们激励给了，但是没有检查到想检查的地方，bug 在出现了，但是没有checker，就这样在眼皮底下漏过去了。尤其是如果验证没有全局的RM 和scoreboard 比较，也没有全局的assertion，testcase 比较都是在用例特定 时刻去读取待检查对象和golden值进行比较。那就有两个问题，1）我们怎么知道在比较时刻之前或者之后有没有出现其他没有满足设计需求的时序（就是不该出现的时序）。 2）我们是怎么知道这个testcase 选取的比较对象就是全的，比如端口有5组output，人为选择其中某些进行比较，剩下没有比较的output 是什么情况。 但是如果用scoreboard 和 assertion 比较 就不是人为在testcase选择对象或者时刻，他们是自动monitor 进行比较的。只要出现都会进行checker。完全没有用scoreboard 和 assertion 验证 ， 有漏checker 的风险。
（3）对输入把控不严格，我们不能随便接受一个需求，一定要搞清楚原由，是什么原因修改，需求来源哪里，需求是否合理，文档有没有更新描述，而不是别人告诉我们这次修改很简单，随便一个会议就接收了，告诉我们就这么验证哪里哪里就行了。
（4）对于功耗和性能验证不够敏感，这个目前还是我们验证薄弱环境。我们不能只扔一个波形出去，让设计去判断性能是否满足，功耗是否满足。性能我们需要完全能判断，功耗我们也要跑ptpx 做好基本的判断。验证环境支持ptpx，后续我们都配置用起来。如果需要增加时间就要考虑时间增加。项目会正向先排计划，然后考虑和项目规划时间的偏差。
验证这个岗位入门是比设计需求低一些，但是要做好，绝对比设计要求高。这就是下限可以很低，上限可以很高。关键是我们怎么去做。既要像设计一样考虑问题，又要像客户一样考虑问题，就这点就不简单做到。我们是验证的负责人，我们不能听别人告诉我们怎么去验证，要怎么验证要我们自己判断，然后评审确定，其他人尤其是是设计告诉就这么验证一下就行了， 只能做参考，最终怎么验证要自己判断。设计岗位从他们角度天然就是只会从时间和PPA 考虑问题，他们天然对质量缺乏敬畏之心。
我们写用例也要尽量像客户能操作那样去考虑（除了一些特殊情况外，比如仿真加速，异常配置，构造错误，并行触发等等情况），少使用一些固定延迟，等待内部信号判断。force 内部信号等等操作。所有做的这些操作基础出发点就是客户能否做得到（客户使用我们芯片能force 内部信号吗），实际情况有没有可能出现。 我们做一些仿真加速，异常配置，并行触发，后门操作时，也要有一个用例保证是真实情况配置。
评论 (0)