DUT处理延迟对Monitor采数和验证环境结束机制的影响分析

最新推荐文章于 2023-05-08 14:00:47 发布

cc_hook

最新推荐文章于 2023-05-08 14:00:47 发布

阅读量704

点赞数 1

分类专栏： UVM 文章标签：经验分享

本文链接：https://blog.csdn.net/cc_hook/article/details/127289117

版权

UVM 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

1. 问题背景

一句话描述： 验证环境中，当激励完成发送时，由于DUT存在处理延迟，monitor在延迟一段时间后才能采集到DUT完整的输出，如何设计验证环境的结束机制？

此处的验证环境结束机制，可以认为是main_phase的结束控制，但并不单纯指UVM中phase的raise_objection和drop_objection机制，还包括由哪个组件完成raise和drop，组件之间如何进行结束握手，如何保证monitor能够采集到DUT完整的输出。

在uvm的框架结构里，sequence，sequencer，driver，monitor，scoreboard的逻辑关系如下。

sequence激励启动sequencer，通过driver发送到DUT中；monitor采集DUT的输出数据或状态，主动或被动地发送到scoreboard；scoreboard将RM和monitor地数据做比对，判断DUT的行为是否符合预期。
上述UVM组件在最后一个激励发送结束后，在时间轴上的大致顺序如下。

一般来说，验证环境的raise_objection和drop_objection会由sequence发起，避免在多个组件中raise和drop，以免带来控制上的混乱。而如果只在sequence激励发送结束后，通过raise和drop结束仿真，由于DUT存在处理延迟，monitor不能保证接收到完整的DUT输出。即上图中环境结束点应该在t5，而不应该在t2结束。

2. 影响因素和应对思路

2.1 DUT处理延迟

原则： sequence参与环境结束投票，根据DUT的处理延迟，触发环境结束。
在DUT接收到激励后，其处理延迟和业务特点强相关，可以按如下类别进行分析。

2.1.1 固定延迟

对于固定延迟类模块，在接收到最后的激励后，延迟固定个数cycle后，处理完成，monitor可以接收到完整数据。此种场景下可以仅由sequence控制raise_objection和drop_objection，driver在发送完最后的激励后，延迟N个cycle后再调用seq_item_port.item_done()即可。

如果scoreboard和RM是On-line形式，也无需要控制raise_objection和drop_objection。如果是Off-line形式，因为monitor已经完整地采集DUT地输出，也可以进行完整的比对。
如果模块的处理延迟是根据模式控制，或者根据测试用例不同，也可以使用该思路。不同模式或用例的延迟范围，可以随sequence激励一同送给driver。
处理延迟建议使用时钟cycle为单位，而不是具体的绝对时间，如2us,1ms。如果延迟确实是绝对的时间值，则此部分的延迟也可以放到sequence完成，收到driver的item_done之后，延迟固定延迟时间。
该类型的结束机制也可以使用scoreboard参与raise_objection和drop_objection，见后续分析。

2.1.2 不定延迟

如果所验证模块的处理延迟是不固定的，如CPU流水线收到的指令，跳转指令，算术指令和store/load指令，则pipeline执行结束的时钟数就不再是固定值。此类模块一般都具有“累积效应”，即当前激励的执行和历史激励相关。
验证环境在发送完最后一个激励，需要确认DUT的处理已经完成，才可以结束当前仿真。此时可以考虑使用DUT的工作状态指示。

假设DUT模块存在着工作状态上报，可以通过总线回读获取或者通过interface连接DUT内部信号获取。

如果还是通过driver获取DUT状态指示，仍可以仅由sequence发起raise_objection和drop_objection。driver获取DUT的工作状态指示，当确认DUT处于idle时，发起seq_item_port.item_done()，结束激励发送，进而结束验证环境。
如果通过monitor或者其他组件获取该状态，该组件需要参与raise_objection和drop_objection。但该组件的main_phase需要小心处理。由于激励可以是间歇性发送，DUT的状态也可以是间歇性busy和idle。因此该组件只有在最后一个激励发送完成后，获取到DUT状态为idle，才可以结束验证环境了。此种办法还需要增加额外的握手，使得该组件“知道”当前处于尾部激励处理过程。

如果不能使用DUT的状态指示，可以考虑在Scoreboard中使用RM驱动的结束机制，见后续因素分析。

2.2 Scoreboard和On-line RM

原则： Scoreboard参与环境结束投票，On-line RM的队列数据决定比对完成，进而触发环境结束。
除了sequence外，scoreboard也发起raise_objection和drop_objection。使用On-line RM，可以认为scoreboard在尾部激励发送完成时，就已经获得golden的数据队列。在main_phase中，RM的数据和monitor的数据一一比对完成，才会发起drop_objection，否则等待monitor接收到足够多且正确的数据。

在这种方式下，driver侧可以无需考虑DUT的处理延迟特点，激励发送完成，即可以发起seq_item_port.item_done()。

2.3 Scoreboard和Off-line RM

如果RM是Off-line的方式，即在验证结束后根据monitor结果才进行数据的比对。此时，scoreboard没有RM数据队列，也不能完全决定DUT是否处理完成，环境是否可以结束。Scoreboard也常常不再是一个环境的组件，而由仿真控制脚本代替。
如果此时DUT是一种不定处理延迟，而且又没有状态指示，建议将Off-line RM先于验证环境运行，将RM数据存储到文件中，再由验证环境读取，达到On-line Rm的效果。同时该模式需要RM的激励输入也要先于验证环境运行前产生。