Hi,
I want to access top module signal (which is reset) inside sequence.Actually my intention is to provide on the fly (intermediate) reset from sequence but the thing is i applied initial reset (reset signal is inside top module itself)from top module & these functionality should not violate means for any sequence initial reset should be there & if i run reset_sequence then initial reset as well as intermediate reset both should applied.
I tried following things but no one works
inside virtual sequencer by using config db get the signal (FYI : which is set from top_module)& in my reset_sequence use p_sequencer.reset
Directly access signal using top_module.reset but this is also not working
Directly access signal using uvm_test_top.top_module.reset but this is also not working
Access reset signal through config_db get inside my reset_sequence & try to use it (Not working)
Instead of observing reset signal in sequence, you can observe reset in driver and discard received reset transaction as reset is already being driven.
You can get virtual interface in reset_sequence through uvm_config_db and observe the reset from the vif pointer.
For the first solution that you tried, did you make sure to set the reset signal using config db correctly and in a block that is executed before the reset get with config db?
I set reset signal(config_db::set)from top_module inside initial block & get (config_db::get)it in virtual sequencer inside build_phase
I think this is not a issue
initial begin
uvm_config_db#(logic)::set(null,“*”,“rst_n”,rst_n);
end
Inside virtual sequencer :
function void start_of_simulation_phase (uvm_phase phase)
if(!uvm_config_db#(logic)::get(this,“”,“rst_n”,rst_n))
begin
`uvm_fatal(“NO_VIF”,"virtual interface must be set for: ",get_name());
end
endfunction
test code
I don’t get it which code are you talking about ??? if you are talking about inside sequence than …
p_sequencer.rst_n = 'd0;
And you see any warnings in log related to that ?
No
In reply to parth099:
I have some problem with logic some time back, Can you try declaring reset as bit (driving 0 or 1 )/ int (driving some random value), and then see that the values getting reflected ?
You should NEVER access any signals inside of a sequence. You should ONLY access signals inside of a driver or monitor.
Generation of a sequence item should never depend on a signal state. A new sequence item could potentially depend on the response from a previous sequence item, but not on signals.
If you need to wait on an individual signal before driving a sequence item, this should be handled by the driver.
Hi Parth,
It is never a good idea to use signal as reference to generate sequence items.
But if still you want to access any signal inside sequence(not recommended) then there are two ways:
Have an instance of virtual interface inside your sequence; and pass the handle of physical interface using config_db (which you might have set in your top module) to your sequence and get it inside task “body”. And then you can use your reset signal through your interface.
if you don’t want to have and interface instantiation inside your sequence; then you can have same inside your sequencer where you need to pass the handle through config_db(similar to your driver and monitor). And inside your sequence you need to use this virtual interface using m_sequencer.<virtual_interface_name>. Which can be used for observing your reset signal.
Note: the procedure which you have mentioned of passing the signals as logic/int/bit inside config_db will not work; as it is passing this reset signals as a variable which is not passed by reference it is passed by value. Hence when try to get the value of this signal from config_db, will provide the value of the variable which it was having during the time of set call.