One of the biggest challenges in dynamic functional verification is testing Reset – resetting the DUT during simulation and check DUT operation afterwards. The main challenges are propagating the reset information in the testbench, and adjusting the components behavior.
For performance and accuracy, it is best to have one agent controlling and monitoring the reset, rather than each and every agent monitoring the reset signal/s. There can be an agent dedicated to reset, and this could be handled by another component such as a bus agent. I will use the term Reset Agent to refer the agent that handles reset, regardless if this is all it is doing, or if it is a general purpose agent.
Propagating reset indication
The Reset Agent can propagate the reset start/end information explicitly using events, or implicitly using UVM e Testflow. Using events, the Reset Agent emits reset events, and other components should know the name and location of the events, and use them as sampling events or sync to them in TCM actions.
The following code shows few examples of how components can use the synchronizer reset event:
unit synchronizer {
reset_ip : in simple_port of bit is instance;
event reset_ended is rise(reset_ip$) @sim;
};
unit bus_monitor {
!smp : synchronizer;
event reset_ended is @smp.reset_ended;
on reset_ended {
start watch_signals();
};
};
extend MAIN bus_sequence {
body() @driver.clock is only {
// test scenario to start only after reset ended
wait @driver.reset_ended;
// start test scenario…
};
};
Using Testflow the synchronization is implicit. Each component defines its phases activities and it is given that no component will execute its post reset activities before the Reset Agent had finished its reset activities. The components do not need to have a pointer to the Reset Agent, just to know its domain name.
In this example, the BUS_TF domain defines a dependency on the RESET phase of the RESET_AGENT_TF domain. As a result, the bus MAIN_TEST sequence, defining the test scenario, and the checker TCM, started at INIT_LINK phase, will start running only after reset had ended.
extend MAIN MAIN_TEST bus_sequence {
body() @driver.clock is only {
// do test scenario...
};
};
extend bus_checker {
tf_init_link() @tf_phase_clock is also {
start data_checker();
tf_get_domain_mgr().register_thread_by_name(me, "collect_frames",
POST_TEST, FALSE);
};
};
extend env {
connect_pointers() is also {
// BUS_TF domain should not proceed beyond INIT_LINK, before
// RESET_AGENT_TF starts INIT_LINK (the phase after RESET)
tf_add_dependency(BUS_TF, INIT_LINK, RESET_AGENT_TF, INIT_LINK);
};
};
Adjusting Temporals upon reset
In the above examples we saw how TCMs can start at reset, or wait for it. Much of the testbench functionality is implemented with temporal expressions – events and expects. Using temporal options, you can define conditions on which a temporal expression evaluation should start, stop (and will restart when the start indication occurs) or abort (will not restart). This way, you can synchronize temporal expression with reset.
// data_phase is expected within few cycles after addr_phase;
// not to evaluate during reset (between reset_start and reset_end)
expect legal_trans is
@addr_phase => {[3..7]; @data_phase}
using exclusive_start @reset_ended, abort @reset_started;
And of course – these options can be added to existing temporals. So, if until today you were not aware of this capability – you can now extend your temporal expressions, and fine tune them.
event data_burst using also stop @power_down, start @power_up;
When using UVM e Testflow, you can condition temporal expressions not only by events, but also to phases -
extend checker {
post_generate() is also {
// this event is meaningful only during the phases
// INIT_LINK..MAIN_TEST
tf_get_domain_mgr().register_event(me, "legal_trans",
INIT_LINK, MAIN_TEST);
// this check is valid only during the reset phases
tf_get_domain_mgr().register_expect(me,
"dut_initializtion",
HARD_RESET, RESET);
};
};
With the keep enhancing Specman temporal language and UVM e Testflow, even one of the biggest verification challenges – reset during simulation – becomes controllable.
Specman Team