关于sequence位置的问题

e_epsh

在验证时，verfication环境通过interface与rtl进行交互，在这个交互中，我们做的事情其实主要是配置rtl的寄存器，rtl根据这些寄存器配置实现ref_mdl中期待的行为，输出相应的data在scob中进行比较。
配置这些寄存器，做在了sequnce上。每一个register是一个sequence，case中发出一个sequence_list到drv上，完成寄存器配置。那么问题是，一般来说寄存器配置是在哪一个phase中完成呢？
1.在post_configure_phase中发送这些sequence。但是环境中还有另外一个数据通路的drv是在main_phase中工作，这样会导致无法使用virtual_sequencer。virtual_sequencer只能发送virtual_sequence到某一个phase，如main_phase（还是说我理解错了，virutal_sequencer发送的virtual_sequence 能够在发送之后的所有phase被drv get到，在post_configure_phase中发送sequence可在main_phase中get到这个sequence）
2.直接在main_phase中做一个virtual_sequncer，在这个phase中进行cfg_sequence和data_sequnce的交互发送。这样实现是很简单的，如果这样实现，那main_phase之前的cfg_phase的存在是为了什么， 只是为了兼容以前的验证方法吗？

another问题：
uvm是如何去check某些实时变化的RO寄存器？这些寄存器在rtl running的过程中会不断的变化

e_epsh

顶自己一下
是问题太没意义了吗？ ？？？？！！！

gaurson

1、对于phase是有严格顺序的，顺序在前的phase触发的事件，顺序在后的phase无法get到，除非采取一种强硬的措施，这个研究不足，只是有这样的机制，但正常来说，是和我前面说的一样。

yamahill

回复 1# e_epsh


    1. 我觉得这种需要数据交互的sequence需要放到一个phase中去实现，不然你无法进行交互。
2. UVM之所以分这么多的phase，就是为了方便你安排不同的sequence，你完全可以不用。例如你这种需要交互的sequence，就不必拘泥于他的功能，硬要安排到不同的phase中。

UVM也具有后门的功能，可以观察RTL一侧信号的值。但是这个不是非常推荐使用。 你完全可以在某个时间去检查一下这个RO寄存器，是否跟你的期望值一样。

本人拙见。

飞扬紫百合

（1）在run的相应phase操作需要设定相应的sequence，这个是没问题的；
或者直接用你自己的task，控制好执行顺序一样ok；
（2）寄存器可以用模型完成，或者自己写自己的checker模块

e_epsh

回复 4# yamahill

UVM的后门功能是指
uvm其实也只是通过hierarchy将信号线引出来吗

e_epsh

回复 5# 飞扬紫百合


    uvm的寄存器模型是通过hierarchy引出ro register的值还是需要将寄存器在总线上读出来？

e_epsh

感谢楼上各位
看来需要做各种sequence的同步交互之类的动作都是在同一个phase中完成比较好，这样做可以做的明确简单，也只需要一个virtual seqence 在环境中，其余组件都是可以随便的重载

AnswerLJ

run_phase中的各个task其实都是可有可无的，UVM中提供的 各个phase 中没有 raise/drop，激励发完则立刻终结，main_phase其实是作为一个扩展task提供给user来自行定义raise/drop做定制化控制的；
所谓的各个pre_main phase，不管被定义为何种行为，有一点是共同的，他们对仿真的结果无直接意义，不参与checker的 校验过程；而由用户自行定义的激励通常是需要产生相应的输出进行check的；而main_phase之后的 各个phase也是如此；至于为什么提供这么多个细化的区分，你可以理解为为了验证环境重用的考量；

寄存器模型的backdoor方式的读写不需要消耗仿真时间，要追根溯源要找一个 VCS版本查阅ral_usrguide，UVM的寄存器模型是从那来的，你可以通过这个文档深刻认识寄存器模型

yvhksovo

楼主同学；config_phase作寄存器的下发/main_phase 下发业务数据本身是没有任何问题的；12个run-time phase顺序执行；和一个run_phase 并行执行；uvm这样作，就是为了让我们实现更精细化的控制，不要将寄存器的配置和业务数据的发送混在一个phase中执行；当然有的业务类型要求在业务发送过程中进行软件的干预，另当别论；
具体到你的问题；
virtual_sequncer负责协调我们的sequence和driver之间的transactiton发送；具体的说就是 在sequence中有一个成员变量seq_item_port;在sequncer中有成员变量seq_iterm_export;这两个通道在agent的connect_phase 中进行了链接；并不需要我们手动去作，uvm内部源码已经实现；然后driver通过get_next_item函数不断的获取sequence里面的内容进行发送；我的理解是当你的driver的get_next_item实现在哪个phase的时候，你就在哪个phase去产生你的激励；