by Sundar Raman Arunachalam, Senior Software Engineer, VeriKwest Systems
INTRODUCTION
Despite being a common requirement, handling hardware resets in a verification environment has always been beset by a host of challenges, including:
- Reset behavior has to be propagated to all testbench components.
- All UVM components such as driver monitor and scoreboard should be capable of reacting to the reset (i.e., they should be made reset aware).
- All pending sequences already scheduled by the test should be removed from all sequencers and virtual sequencers.
- Once the system comes out of reset the traffic should be re-generated to the DUT.
Special reset handling capabilities are especially important for the driver, which needs to stop executing the current sequences and bring the testbench to a known state immediately. This problem gets further exacerbated in AXI environments for two reasons. (i) The AXI interface has multiple channels, each of which work independently, and (ii) the AXI protocol supports out-of-order responses and multiple outstanding transactions. Therefore at any point in time, the driver could be juggling several transactions. When a reset occurs, the driver has to stop activities on "all" AXI channels. The driver needs to ensure a proper handshake with the sequencer to enable continuation of the sequences following the reset action.
The stimulus control thread also needs to be handled properly so as to determine what needs to happen after a reset is encountered (typically the entire traffic needs to be re-generated). Here traffic includes the sequences required to initialize the DUT before the actual test activity is carried on. In UVM, the concept of phase jumps can provide a solution to this problem. However phase jump is undergoing changes in the UVM technical committee. While several solutions have been proposed for handling reset problems in the past, an AXI-like environment can be tricky and often require additional insights. This article describes techniques for modeling UVM testbench components in an AXI-based environment. It also covers handling the stimulus generation unit (uvm_test) required to re-generate the DUT traffic without using phase jumps. Note that this technique can be applicable to other UVM-based testbench environments.
AXI PROTOCOL ARCHITECTURE
AXI protocol (defined by ARM®) is burst-based and defines five independent transaction channels: read address, read data, write address, write data and write response. An address channel carries control information that describes the nature of the data to be transferred. The write data channel is used to transfer data from the master to the slave. In a write transaction, the slave uses the write response channel to signal the completion of the transfer to the master. The read data channel is used to transfer data from the slave to the master.
Interleaving of data transfers between write and read transactions are also allowed by the protocol in order to increase the throughput of the system.
AXI supports multiple outstanding transactions, which means that more than one transaction can be spawned off by the master without getting responses to the previous transactions. It also supports out-of-order completion of transactions, so the master can get response for any transaction regardless of the order in which the transactions were sent. However there are some ordering restrictions that apply based on the ID of the transaction sent.
 |
|
Figure 1 – Channel architecture for reads and Figure 2 – Channel architecture for writes
|
EXISTING APPROACHES FOR RESET HANDLING
Using UVM phasing, the run phase of the uvm_test can be implemented with separate phases like reset_phase, config_phase, main_phase, etc. The main_phase of the test will be responsible for generating the actual traffic that is intended by the test. The reset_phase and config_phase may contain sequences specific to the DUT requirements of configuring and initializing it before actual traffic can be applied.
When a reset event is encountered, the test can implement a phase jump to go back to the reset_phase so that the configuration and initialization sequences are executed again. This ensures that the complete traffic is re-generated and sent back to the DUT.
The phase jump does not provide a complete solution to handling resets. If the UVM driver is in the middle of driving some transactions special efforts might be needed to completing the handshake with the sequencer. A driversequencer handshake is complete only when the driver sends an item_done() and put_response() back to the sequencer for all transactions that have been received by driver with the 'seq_item_port.get_next_item(req)' API. The put_response(rsp) call is required since some sequences may be waiting on a "get_response(rsp)".
This handshaking mechanism can become more complex in AXI environments where the driver can be simultaneously processing multiple transactions in different channels. Implementing the driver using a state machine approach can provide a solution to this problem. But the traditional state machine design of an AXI master can make the code quite complex.
This article addresses the problems of on-the-fly reset handling without the use of phase jumping. Our UVM components (including the tests) use only the run phase to generate traffic to the DUT. The sections that follow discuss techniques for modeling various components of the AXIbased UVM testbench with reset awareness.
MODELING UVM DRIVER
Since AXI supports multiple outstanding transactions, the driver can implement global queues for storing the read and write transactions. The driver can send an item_done() immediately to the sequencer so that it can fetch the next transactions using the get_next_item call. The transactions remain in the queues until a data/response has been received from the slave. Once a response is received from the slave, the driver can complete the sequencer handshake by sending a put_response(rsp).
class axi_driver extends uvm_driver #(axi_trans);
axi_trans read_queue[$];
axi_trans write_queue[$];
...........
task run_phase(uvm_phase phase);
forever
begin
reset_interface_signals();
get_and_drive();
end
endtask : run_phase |
Figure 3 – Design of reset-aware AXI driver
The get_and_drive task spawns three parallel processes as shown below:
 |
|
Figure 4 – get_and_drive task of driver
|
The transmission control process takes care of fetching the transactions from the seq_item_port of the driver and storing them in the global read and write queues mentioned above. Checks can be added in this task to make sure that the master does not exceed the maximum outstanding transactions configured for this agent.
The drive_axi_channels task is responsible for fetching the transactions from the driver queues and driving them on the various channels of the AXI interface.
 |
|
Figure 5 – drive_axi_channels task
|
The driver uses fork join constructs to spawn off separate threads that drive each of the channels. Each channel task can be a separate block that will keep executing forever. These tasks basically look into the global read and write queues for transactions and drive them into the interface. The reset monitoring task is responsible for detecting the reset signal from the interface and disabling all other activities that are going inside the driver.
// Reset Monitoring Process
begin
// wait till the system encounters a reset.
@(negedge axi_vif.aresetn);
put_reset_response();
// disable execution of other processes.
disable transmission_control;
disable drive_block;
end |
| Figure 6 – reset monitoring task |
When an asynchronous reset event is sampled by the driver, the reset monitoring process is unblocked, executing a task that completes the handshake with the sequencer. Optionally, a field can be set in the response transaction to indicate that it has completed abruptly due to the reset event. Once the handshake is completed, all the transaction stored inside the driver queues can be deleted. Finally the reset monitoring process disables the drive and the transmission control threads which cause the processes and their child processes to end immediately. The driver then goes back to the initial state where it is waiting for the system to come out of the reset.
task put_reset_response();
for(int i=0; i<read_queue.size(); i++)
begin
axi_trans tr = read_queue[i];
seq_item_port.put_response(tr);
end
for(int i=0; i<write_queue.size(); i++)
begin
axi_trans tr = write_queue[i];
seq_item_port.put_response(tr);
end
// Remove the transaction from the queues.
read_queue.delete();
write_queue.delete();
endtask : put_reset_response |
| Figure 7 – put reset response task |
MODELING UVM MONITOR
The monitor component in the UVM testbench should be responsible for propagating the occurrence of the reset event to the rest of the testbench components such as the scoreboards/checkers and the test. The monitor can be implemented similar to the driver described above with queues for collecting read and write transactions. When reset is encountered, all transactions in the queues are removed and thus not sent to the analysis port for scoreboard/checker analysis. The monitor triggers a global uvm event named "EVENT_RESET" as shown below:
 |
|
Figure 8 – Reset-aware UVM monitor
|
The monitor spawns off two processes, one for sampling the signals on the interface and sending them on the analysis port. Secondly it spawns off a reset monitoring process which samples the reset signal on the interface and triggers a global UVM event.
Once the reset signal has been sampled, the monitor removes all the in-progress transactions within its queues and disables the sampling process until the system comes out of reset.
fork
begin : sample_signals
// sample interface signals
end
begin
// Reset monitoring thread.
// wait till the occurrence of reset.
@(negedge axi_vif.aresetn);
// Trigger the reset event.
is_reset.trigger();
disable sample_signals;
end<
join |
| Figure 9 – Design of a reset-aware AXI monitor |
SCOREBOARD/CHECKERS MODELING
Any higher level components such as scoreboards, protocol checkers and coverage collectors can wait for the reset event triggered from the monitor and then perform the required action. When a reset event occurs, the scoreboard may be in an unstable state with partial information about several of the transactions. However because of the global reset event, it can now be reinitialized to a known stable state.
task run_phase(uvm_phase phase);
.......
event_pool = event_pool.get_global_pool();
// Get the Reset Event created by monitor.
is_reset = event_pool.get("EVENT_RESET");
.......
is_reset.wait_for_trigger(); // blocking call
// perform required tasks/actions
endtask : run_phase |
| Figure 10 – Modeling checkers/scoreboard |
MODELING UVM TEST
There is debate in the verification community regarding the requirements for reset handling in uvm_tests. While some methods continue the execution of the tests post-reset, we believe that the traffic needs to be re-generated from the start. The configuration and initialization of the DUT needs to be done by proper sequences before the regular sequences can start.
A normal uvm_test flow looks like:
 |
|
Figure 11 – Normal UVM test flow
|
The code for the normal flow of uvm tests is posted below:
task run_phase(uvm_phase phase);
vseq = sample_vseq::type_id::create('vseq');
vseq.starting_phase = phase;
phase.raise_objection(.obj(this));
vseq.randomize();
vseq.start(m_vsqr);
phase.drop_objection(.obj(this));
phase.phase_done.set_drain_time(..);
endtask : run_phase |
| Figure 12 – Code for normal UVM test flow |
Figure 13 describes the flow of a reset-aware UVM test.
 |
|
Figure 13 – Reset-aware UVM test
|
In a reset-aware test, the test spawns two parallel processes. One is the normal test flow and the other is a reset monitoring process. When a reset event is detected the entire UVM test flow starts from the beginning. In addition, there might be some sequences/transactions on the virtual sequencer or agent sequencer queues that have not been scheduled on the driver. Those pending sequences need to be removed since we want to abort all operations and start executing the test from the beginning. This can be done by calling stop_sequences() method on the sequencer handles. This is done in the reset monitoring thread of the test.
The run phase of the uvm_test is shown below:
task run_phase(uvm_phase phase)
..
boolean_t exit_condition;
// Get the Reset Event created by monitor.
is_reset = event_pool.get("EVENT_RESET");
exit_condition = NO;
while(exit_condition == NO)
begin
exit_condition = YES;
fork
begin
// Do the normal uvm test flow.
end
begin
// wait till the occurrence of reset signal.
is_reset.wait_for_trigger();
exit_condition = NO;
// Remove all pending sequences on the
// sequencers
m_vsqr.stop_sequences();
// Do the above for the sub sequencer
//handles as well.
m_vsqr.mst_sqr_0.stop_sequeunces();
end
join_any
end // while loop
endtask : run_phase |
| Figure 14 – Reset-aware UVM test |
CONCLUSION
Handling resets on the fly in UVM environments can be accomplished if the testbench components are built with reset awareness as described in the article. We have highlighted the techniques required to design reset-aware drivers, monitors, scoreboards and tests. These techniques can be applied to any other protocol environments and also for OVM testbenches.
REFERENCES
- Universal Verification Methodology (UVM) 1.1 User's Guide
- SystemVerilog 3.1a Language Reference Manual.
- AMBA® AXI and ACE Protocol Specification AXI3™, AXI4™, and AXI4™-Lite ACE and ACE-Lite.
- On the Fly Reset by Mark Peryer, Verification Methodologist, DVT, Mentor Graphics.
Back to Top