返回列表 发帖

[讨论] 验证人员应该以何种角度阅读spec

[讨论] 验证人员应该以何种角度阅读spec

在开发流程中,设计和验证人员关注的点肯定是不一样的,尤其在spec的理解上,验证人员往往需要有自己独立的理解。在拿到spec时,作为验证人员,应该如何提炼其中的功能从而转化为对应的inference model以实现和详细设计的交叉验证。大家有什么经验能讨论一下下

我觉得验证人员看spec中的功能点的时候,需要关注输入,输出以及从输入到输出所需要的时间。
首先,“从输入到输出所需要的时间”,也就是RTL内部的延迟,我觉得这是设计reference model的最大的难点。因为你即使问写spec的人,他也很有可能不知道。这个时候我们会去问设计人员或者看RTL代码,但是这样我们就很有可能被设计人员的思路影响,搭出来的ref model就有可能和RTL一起错了,这样你的验证环境有可能永远也查不到那个BUG。
然后就是从输入到输出,这就好比一个真值表,我们需要做的就是按照随机策略设计并约束激励。但是随着逻辑的复杂度的增加,这个真值表会越来越大,大到我们很难写全。这个时候我们可以像设计一个很大的模块一样,把这个大的真值表分成若干小的真值表。说起来简单,但是这里的工作量是随着逻辑复杂度指数上升的。如果要做所谓的交叉验证的话,不如再找一个设计人员,也设计这样一个模块,然后他们比一比结果,再磨合一下延迟,根本不需要验证人员。
最后再说下题外话,我在大学做设计的时候,是先设计reference model(用C++写好,用软件跑一下看看效果),然后再根据这个reference model去设计模块,最后设计完模块上FPGA跑一跑就结束了。这里如果加上验证一步骤的话,就可以直接拿这个reference model去验证了。所以我觉得应该是先有reference model, 再有需要被验证的RTL,这才是最合理的流程。但是我在实际工作的时候,是先有RTL再有ref model, 楼主所在公司应该也是这样,不然也不会问这个问题。我们分析一下,ref model虽然是根据spec写的,但是却要获取RTL的内部延迟,然后我们再用这个部分逻辑来源于RTL的ref model 去验证RTL。这里面稍有不慎,就会放过BUG, 因为一般情况下我们的scoreboard里面的auto_check是直接拿ref model的输出用的,不会去验它内部的逻辑的。

TOP

1.题主对于reference model的过度关注,侧面反映了题主更多还是站在设计者的角度来做验证,一开始我也执迷于reference model,自动对比给初做验证的人很大的快感。2.楼上说的输入到输出的时间的验证,我认为reference model更侧重于数据流的对比,时序上面的checker可以使用assertion。
个人认为设计人员和验证人员看spec的角度是不同的:
1.设计人员通常是站在功能实现的角度,而验证人员应该更多站在使用者的角度,也就是说如何使用做出来的芯片
2.如何使用芯片,决定了你的激励,你的激励决定了芯片所面临的状况,芯片在所有可能的状况下都能保持正确,那这个芯片的quality就得到了保证,所以如何设计你的激励是验证的核心。

TOP

回复 3# zxm92


    我工作时间也不长,我现在对reference model也特别迷茫,感觉上如果写了这个就把一部分逻辑交给ref model判断去了,如果这部分逻辑和DUT错成一样可能会造成很糟糕的情况。
   reference model更侧重于数据流的对比这个我很赞同,因为我验证过UART模块,像这类验证功能点的时候结果的时候主要关注寄存器里面的值,ref model搭起来得心应手。而且后来通过阅读UVM_COOKBOOK发现,像这类数据流的对比连ref model都可以不要。只要在slave agent里设计好transaction,然后和master agent的transaction传递给scoreboard直接比对就够了。
   用assertion去验证timing的做法我也尝试过,但是后来我放弃了。因为写assertion我需要知道2个事件发生间的时间。因为逻辑很复杂的时候,DUT有很多内部信号,对于某个功能点的验证来说,整个信号的传递可以看做“输入->内部信号a->内部信号b->...输出”。输入和输出我们可以通过sepc看出来,但是输入到输出花的时间即使我们问写spec的人,他很可能也不知道。这里我开始选择写assertion, 因为我不能信任内部信号,我只能直接去找从输入到输出的时间,结果我问设计人员的时候,发现他也是按照这些内部信号去推出来的,所以我只能选择仿波形去确认。但是这么大的量,不能全靠看波形啊,所以我按照自己的理解设计了输出波形,把这个波形去和dut实际的输出波形去作比较,只要uvm报错了,就去找系统工程师和设计人员确认。这个时候发现即使是SV的assertion,根本满足不了我的要求,只能自己用SV甚至C++去搭自动check的逻辑。
  验证中激励很重要我也赞同,但是我不觉得它是核心。对于UVM验证方法学来说,我觉得核心应该是如何去判断激励输入以后的结果是不是对的以及覆盖率的设计。覆盖率设计就像一个大纲,激励只不过按照那个大纲一步一步写(这里分成2个人去做效果应该更好),而且SV真的很合适干这事。

TOP

返回列表

站长推荐 关闭


欢迎访问 TI SLL(信号链)专区

欢迎访问 TI SLL(信号链)专区


查看