This paper is submitted for 53rd Design
Automation Conference , please find the slides for the same.
1. Report catcher file.
class error_report_catcher_c extends uvm_report_catcher;
//new constructor
virtual function action_e catch();
if(get_severity() == UVM_ERROR && get_id() ==
"MON_CHK_NOT_VALID") begin
set_severity(UVM_INFO);
return CAUGHT;
end
else begin
return THROW;
end
endfunction
endclass : error_report_catcher_c
2.Testcase
class invalid_test extends base_test_c;
//
report catcher to suppress errors
error_report_catcher_c error ;
///
\fn new_constructor
///
\fn build_phase
virtual
function void build_phase(uvm_phase phase);
super.build_phase(phase);
error = new();
uvm_report_cb::add(null,error) ;
uvm_config_db#(int)::set(this,“uvc.tx_agent","is_active",UVM_ACTIVE);
// User configurations
env_cfg.print();
uvm_config_db#(env_config_c)::set(this, "*" ,
“env_cfg", env_cfg);
// Calling the error sequence
uvm_config_db#(uvm_object_wrapper)::set(this,
“uvc.tx_agent.tx_sequencer.main_phase","default_sequence",valid_invalid_seq_c::type_id::get());
endfunction : build_phase
endclass : invalid_test
Typically an
ASIC or a SOC will have multiple resets and which adds other dimension to reset
verification wherein verification engineer need to ensure that the modules in
the chip react only to the desired resets and ignore others. On-the-fly reset
must be taken into account by all the modules of testbench and housekeeping
must be made accordingly.
Figure I is
a representation of stimulus life-span and flow in a reset aware test-bench.
Apart from reset agent, the Verification environment has two other agents which
can be reset individually by applying agent1 reset or agent2 reset
respectively, or simultaneously by applying a global reset. Reset agent from
Figure I will be continuously monitoring the reset interface and triggers the
reset event on successful capture of any of the above mentioned resets. All
other components in the test bench will waiting for a respective reset even
trigger.
Here
is how the 4 major components Drive, Monitor, Scoreboard and Sequences must
behave on capturing the reset event:
Driver:
1) Must not
drive data under reset and wait until reset is removed. (t4 from figure 1)
2) Must
stop driving the bus and send item_done on reset application. (t4 from figure
1)
3) Must
complete the transaction if there was no reset while the transaction is in
progress.(t5 and t6 from figure 1)
Monitor:
1) Must be
monitoring the bus and trigger report error for conditions on bus which are not
expected under reset. (t4 from figure 1)
2) Must
treat the bus data as invalid if a reset is applied in between a transaction.
(t4 from figure 1)
Scoreboard:
1) On
application of the reset all the FIFO’s must be flushed. (t4 from figure 1)
Sequences:
1)
Immediately after reset the configuration sequence must be driven before
driving any other sequence. (t6 from figure 1)
Reset is an
important state of an IP and the test-bench needs to be designed to accommodate
and handle this state. Here are simple steps with code samples to make your
test-bench reset-aware:
Triggering
interrupts from sequences:
As a part
of stimulus
Triggering
a global reset event:
global_reset_ev
= cfg.event_pool.get(“global_reset”);
global_reset_ev.trigger();
In case of
Agent1 reset:
Triggering
an Agent1 reset event:
agent1_reset_ev
= cfg.event_pool.get(“agent1_reset”);
agent1_reset_ev.trigger();
Triggering
an Agent2 reset event:
agent2_reset_ev
= cfg.event_pool.get(“agent2_reset”);
agent2_reset_ev.trigger();
In reset
aware components: Components shall wait for respective interrupts and
implement their reset behavior upon successful reception of interrupts.
forever
begin : Reset_service
fork
: capture_reset
begin
agentX_reset_ev.wait_ptrigger;
end
begin
global_reset_ev.wait_ptrigger;
end
join
reset_procedure();
end
The
on-the-fly reset can be made more elegant by usage of customized uvm_phases,
this approach is out of this paper scope.
Happy Reading ...!
