Verification Academy

Search form

My Account Menu

  • Register
  • Log In
  • Topics
  • Courses
  • Forums
  • Patterns Library
  • Cookbooks
  • Events
  • More
  • All Topics
    The Verification Academy offers users multiple entry points to find the information they need. One of these entry points is through Topic collections. These topics are industry standards that all design and verification engineers should recognize. While we continue to add new topics, users are encourage to further refine collection information to meet their specific interests.
    • Languages & Standards

      • Portable Test and Stimulus
      • Functional Safety
      • Design & Verification Languages
    • Methodologies

      • UVM - Universal Verification Methodology
      • UVM Framework
      • UVM Connect
      • FPGA Verification
      • Coverage
    • Techniques & Tools

      • Verification IP
      • Simulation-Based Techniques
      • Planning, Measurement, and Analysis
      • Formal-Based Techniques
      • Debug
      • Clock-Domain Crossing
      • Acceleration
  • All Courses
    The Verification Academy is organized into a collection of free online courses, focusing on various key aspects of advanced functional verification. Each course consists of multiple sessions—allowing the participant to pick and choose specific topics of interest, as well as revisit any specific topics for future reference. After completing a specific course, the participant should be armed with enough knowledge to then understand the necessary steps required for maturing their own organization’s skills and infrastructure on the specific topic of interest. The Verification Academy will provide you with a unique opportunity to develop an understanding of how to mature your organization’s processes so that you can then reap the benefits that advanced functional verification offers.
    • Universal Verification Methodology (UVM)

      • Advanced UVM
      • Basic UVM
      • Introduction to UVM
      • UVM Connect
      • UVM Debug
      • UVMF - One Bite at a Time
    • Featured Courses

      • Introduction to ISO 26262
      • Introduction to DO-254
      • Clock-Domain Crossing Verification
      • Portable Stimulus Basics
      • Power Aware CDC Verification
      • Power Aware Verification
      • SystemVerilog OOP for UVM Verification
    • Additional Courses

      • Assertion-Based Verification
      • An Introduction to Unit Testing with SVUnit
      • Evolving FPGA Verification Capabilities
      • Metrics in SoC Verification
      • SystemVerilog Testbench Acceleration
      • Testbench Co-Emulation: SystemC & TLM-2.0
      • Verification Planning and Management
      • VHDL-2008 Why It Matters
    • Formal-Based Techniques

      • Formal Assertion-Based Verification
      • Formal-Based Technology: Automatic Formal Solutions
      • Formal Coverage
      • Getting Started with Formal-Based Technology
      • Handling Inconclusive Assertions in Formal Verification
      • Sequential Logic Equivalence Checking
    • Analog/Mixed Signal

      • AMS Design Configuration Schemes
      • Improve AMS Verification Performance
      • Improve AMS Verification Quality
  • All Forum Topics
    The Verification Community is eager to answer your UVM, SystemVerilog and Coverage related questions. We encourage you to take an active role in the Forums by answering and commenting to any questions that you are able to.
    • UVM Forum

      • Active Questions
      • Solutions
      • Replies
      • No Replies
      • Search
      • UVM Forum
    • SystemVerilog Forum

      • Active Questions
      • Solutions
      • Replies
      • No Replies
      • Search
      • SystemVerilog Forum
    • Coverage Forum

      • Active Questions
      • Solutions
      • Replies
      • No Replies
      • Search
      • Coverage Forum
    • Additional Forums

      • Announcements
      • Downloads
      • OVM Forum
  • Patterns Library
    The Verification Academy Patterns Library contains a collection of solutions to many of today's verification problems. The patterns contained in the library span across the entire domain of verification (i.e., from specification to methodology to implementation—and across multiple verification engines such as formal, simulation, and emulation).
    • Implementation Patterns

      • Environment Patterns
      • Stimulus Patterns
      • Analysis Patterns
      • All Implementation Patterns
    • Specification Patterns

      • Occurrence Property Patterns
      • Order Property Patterns
      • All Specification Patterns
    • Pattern Resources

      • Start Here - Patterns Library Overview
      • Whitepaper - Taking Reuse to the Next Level
      • Verification Horizons - The Verification Academy Patterns Library
      • Contribute a Pattern to the Library
  • All Cookbooks
    Find all the methodology you need in this comprehensive and vast collection. The UVM and Coverage Cookbooks contain dozens of informative, executable articles covering all aspects of UVM and Coverage.
    • UVM Cookbook

      • UVM Basics
      • Testbench Architecture
      • DUT-Testbench Connections
      • Configuring a Test Environment
      • Analysis Components & Techniques
      • End Of Test Mechanisms
      • Sequences
      • The UVM Messaging System
      • Other Stimulus Techniques
      • Register Abstraction Layer
      • Testbench Acceleration through Co-Emulation
      • Debug of SV and UVM
      • UVM Connect - SV-SystemC interoperability
      • UVM Versions and Compatibility
      • UVM Cookbook
    • Coding Guidelines & Deployment

      • Code Examples
      • UVM Verification Component
      • Package/Organization
      • Questa/Compiling UVM
      • SystemVerilog Guidelines
      • SystemVerilog Performance Guidelines
      • UVM Guidelines
      • UVM Performance Guidelines
    • Coverage Cookbook

      • Introduction
      • What is Coverage?
      • Kinds of Coverage
      • Specification to Testplan
      • Testplan to Functional Coverage
      • Bus Protocol Coverage
      • Block Level Coverage
      • Datapath Coverage
      • SoC Coverage Example
      • Requirements Writing Guidelines
      • Coverage Cookbook
  • All Events
    No one argues that the challenges of verification are growing exponentially. What is needed to meet these challenges are tools, methodologies and processes that can help you transform your verification environment. These recorded seminars from Verification Academy trainers and users provide examples for adoption of new technologies and how to evolve your verification process.
    • Upcoming & Featured Events

      • The Digital Twin: An Aerospace and Defense Revolution - March 9th
      • VIP solutions for Protocol and Memory Verification  - March 11th
      • Advance your Designs with Advances in CDC and RDC - March 23rd
      • Webinar Calendar
    • On Demand Seminars

      • The ABC of Formal Verification
      • I'm Excited About Formal...
      • 2020 Functional Verification Study
      • All On-Demand Seminars
    • Recording Archive

      • Improving Your SystemVerilog & UVM Skills
      • Should I Kill My Formal Run?
      • Visualizer Debug Environment
      • All Recordings
    • Conferences

      • DVCon 2021
      • DVCon 2020
      • DAC 2019
      • All Conferences
    • Mentor Learning Center

      • SystemVerilog Fundamentals
      • SystemVerilog UVM
      • View all Learning Paths
  • About Verification Academy
    The Verification Academy will provide you with a unique opportunity to develop an understanding of how to mature your organization's processes so that you can then reap the benefits that advanced functional verification offers.
    • Blog & News

      • Verification Horizons Blog
      • Academy News
      • Academy Newsletter
      • Technical Resources
    • Verification Horizons Publication

      • Verification Horizons - March 2021
      • Verification Horizons - November 2020
      • Verification Horizons - July 2020
      • Issue Archive
    • About Us

      • Verification Academy Overview
      • Subject Matter Experts
      • Contact Us
    • Training

      • Questa® & ModelSim®
      • Questa® inFact
      • Functional Verification Library
  • Home
  • Verification Horizons
  • November 2014
  • Controlling On-the-Fly-Resets in a UVM-Based AXI Testbench

Controlling On-the-Fly-Resets in a UVM-Based AXI Testbench

Verification Horizons - Tom Fitzpatrick, Editor

Controlling On-the-Fly-Resets in a UVM-Based AXI Testbench 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:

  1. Reset behavior has to be propagated to all testbench components.
  2. 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).
  3. All pending sequences already scheduled by the test should be removed from all sequencers and virtual sequencers.
  4. 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

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

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

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

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

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

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

  1. Universal Verification Methodology (UVM) 1.1 User's Guide
  2. SystemVerilog 3.1a Language Reference Manual.
  3. AMBA® AXI and ACE Protocol Specification AXI3™, AXI4™, and AXI4™-Lite ACE and ACE-Lite.
  4. On the Fly Reset by Mark Peryer, Verification Methodologist, DVT, Mentor Graphics.

Back to Top

Table of Contents

Verification Horizons Articles:

  • Whether for a Community Play or a Coverage Plan, Reuse Makes a Lot of Sense.

  • Integrate Ethernet QVIP in a Few Hours: an A-to-Z Guide

  • Fast Track to Productivity Using Questa® Verification IP

  • Cache Coherent Interface Verification IP

  • Hey You Design Engineer!

  • Please! Can Someone Make UVM Easier to Use?

  • Controlling On-the-Fly-Resets in a UVM-Based AXI Testbench

  • Increase Verification Productivity with Questa® UVM Debug

Siemens Digital Industries Software

Siemens Digital Industries Software

##TodayMeetsTomorrow

Solutions

  • Cloud
  • Mendix
  • Siemens EDA
  • MindSphere
  • Siemens PLM
  • View all portfolio

Explore

  • Digital Journeys
  • Community
  • Blog
  • Online Store

Siemens

  • About Us
  • Careers
  • Events
  • News and Press
  • Newsletter
  • Customer Stories

Contact Us

USA:

phone-office +1 800 547 3000

See our Worldwide Directory

  • Contact Us
  • Support Center
  • Give us Feedback
©2021 Siemens Digital Industries Software. All Rights Reserved.
Terms of Use Privacy Cookie Policy