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

      • CDC+RDC Analysis - 4/20
      • Low Power Verification - 4/29
      • User2User - 5/26
      • Webinar Calendar
    • On-Demand Webinars

      • Basic Abstraction Techniques
      • Safety Analysis Techniques
      • QVIP Workflow and Debug for PCIe
      • Writing a Proxy-driven Testbench
      • Achieving High Defect Coverage
      • Visualizer Features
      • Questa Static and Formal Apps
      • All On-Demand Webinars
    • Recording Archive

      • Siemens EDA 2021 Functional Verification Webinar Series
      • Improving Your SystemVerilog & UVM Skills
      • Should I Kill My Formal Run?
      • Visualizer Debug Environment
      • Industry Data & Surveys
      • 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 Basic
      • Questa Advanced
      • Mastering Questa
  • Home
  • Verification Horizons
  • June 2012
  • On the Fly Reset

On the Fly Reset

Verification Horizons - Tom Fitzpatrick, Editor

On the Fly Reset by Mark Peryer, Verification Methodologist, DVT, Mentor Graphic

INTRODUCTION

A common verification requirement is to reset a design part of the way through a simulation to check that it will come out of reset correctly and that any non-volatile settings survive the process. Almost all testbenches are designed to go through some form of reset and initialization process at their beginning, but applying reset at a mid-point in the simulation can be problematic. The Accellera UVM phasing sub-committee has been trying to resolve how to handle resets for a long time and has yet to reach a conclusion.

In a UVM testbench, stimulus is generated by sequences which create and shape sequence items which are sent to a driver for conversion into pin level activity compliant with a specific protocol. Sequences pass sequence items to drivers via a hand-shake and arbitration mechanism implemented in the sequencer. This mechanism is based on the assumption that each protocol transaction will complete. If a reset occurs, then a sequence will need to be terminated early. Killing a sequence abruptly potentially results in the driver trying to return a handshake or a response to a sequence that has been deleted from the sequencer, causing a fatal error in the simulation. One way to avoid this problem, is to implement the driver so that when it detects a reset it terminates the in-progress sequence items with a reset status so that the stimulus control process can handle the reset appropriately.

HOW TO HANDLE A RESET

A reset can be considered as a highly disruptive event that occurs unexpectedly. Typically, a hardware reset will cause a DUT to immediately stop what it is doing and re-apply default values to its register contents. On exit from reset the DUT will most likely need to be re-initialized or re-configured before it can start normal operations. There are two ways in which a reset can be generated in a UVM testbench; the first is when the UVM stimulus thread is in control of the reset and the second is when the static side of the testbench generates a reset asynchronously to the flow of the UVM stimulus process.

Generally speaking, if the reset is generated under the control of the UVM testbench, the stimulus control process can make sure that all of the stimulus generation machinery is in a quiescent state before asserting the reset signal. The control process would de-assert reset and then go through the required initialization process before resuming the rest of the test. In many circumstances this may be good enough, but there may be situations where an external asynchronous reset is necessary to check DUT behavior, or resets may be generated by the UVM testbench at random intervals.

An asynchronous reset places two requirements on the UVM testbench code – it must first detect that a reset has occurred and then it must react to the reset. In other words, a testbench needs to be coded so that components such as drivers, monitors and scoreboards are reset aware and the stimulus generation process needs to be able to react to the occurrence of a reset.

The stimulus generation process in a UVM testbench may well use a hierarchy of sequences and there could be multiple sequences sending sequence items to a driver at any point in time. At the top level of the sequence hierarchy there will be a master execution thread that is coordinating the execution of all the different sequence threads, usually in the test or in a virtual sequence. A hardware reset will be detected by the driver since it is driving and monitoring the pin level interface. At the start of a reset, the driver needs to halt its operations and then signal back to all the sequences that are sending sequence items that a reset is in progress. In turn the sequences need to terminate, returning a reset status. If the sequences are hierarchical, then they need to terminate with a reset status recursively until the main control loop is encountered. The control loop then needs to change the stimulus generation flow so that a new re-initialization process is started before re-applying traffic stimulus.

Figure 1 - Comparison of sequence execution flow for normal completion and a reset

Figure 1 - Comparison of sequence execution flow for normal completion and a reset

If a driver is not active, it will detect a reset but it will not be able to return the reset status. If all the drivers, sequences and sequence items in the testbench are reset aware, then it is very likely that at least one of them will return a reset status that will allow the stimulus process to go into a reset handling thread. However, if this is not the case and the reset status is important, then the main stimulus generation loop should monitor the state of the reset signal in parallel with its normal activities and initiate a change in stimulus if a reset occurs.

IMPLEMENTING RESET HANDLING

The key to being able to handle an asynchronous reset in UVM testbenches is to be able to flag detection of a reset condition back to the process that controls the test and the stimulus generation. The most convenient way to do this is to add a status field to sequence items and sequences to communicate that a reset has been detected. This status field can then be tested as part of the stimulus generation process to determine what to do. The UVM base classes do not contain a suitable field, so this is something that the user has to add. The recommended approach is to add a variable called status of type uvm_tlm_ response_status_e to sequence items and sequences. When a sequence item or a sequence completes successfully, the status field would be set to UVM_TLM_OK_RESPONSE. When a reset occurs then status value of UVM_TLM_INCOMPLETE_RESPONSE should be set.

Figure 2 - Sequence Item with status field

class adpcm_seq_item extends uvm_sequence_item;
 
rand logic[31:0] data;
rand int delay;
 
// Response - used to signal whether
transfer was aborted due to reset
uvm_tlm_response_status_e status;
 
`uvm_object_utils(adpcm_seq_item)
 
// etc
 
endclass: adpcm_seq_item

In the body method of a reset aware sequence, the status field of each sequence item should be checked after driver has completed its execution – usually on return from the finish_item() or the get_response() call. If the status returned is normal, then the sequence continues as usual. If the status field indicates that a reset has occurred then the sequence should stop what it is doing and return, having first set its status field to indicate that a reset has been encountered. The next level in the stimulus generation hierarchy must also test the status of the returning sequence and determine what to do with a reset status. For instance, instead of starting the next planned traffic sequence, it may start an initialization sequence which will start as soon as the hardware reset sequence has completed.

Figure 3 - Reset aware sequence

class adpcm_tx_seq extends uvm_sequence
#(adpcm_seq_item);
 
`uvm_object_utils(adpcm_tx_seq)
 
// ADPCM sequence_item
adpcm_seq_item req;
 
// Status – used to signal reset status
back to originating thread:
uvm_tlm_response_status_e status;
 
function new(string name = "adpcm_tx_seq");
 super.new(name);
endfunction
 
task body;
 req = adpcm_seq_item::type_id::create("req");
 
 for(int i = 0; i < 10; i++) begin
  start_item(req);
  if(!req.randomize()) begin
   `uvm_error("body", "req randomization failure")
  end
  finish_item(req);
  status = req.status;
  if(status == UVM_TLM_INCOMPLETE_RESPONSE)
  begin
   `uvm_warning("body", "Interface reset occurred");
   return;
  end
 end
endtask: body
 
endclass: adpcm_tx_seq

Both drivers and monitors need to be able to detect a reset condition and they need to be able to cope with the consequences. For a driver this means that a protocol pin level transfer has to be abandoned part way through, and that the status field of the current sequence item has to be updated to indicate that a reset has been encountered. The driver also needs to clear down any other sequence items that might be in the seq_item_port FIFO, marking them with a reset status. With more advanced protocols with out of order responses, there may be several outstanding sequence items queued up within the driver, and all of these will have to be terminated with a reset status. These requirements usually mean that the main driver loop has to be implemented with a state machine so that it can treat the reset condition as a temporary state.

Figure 4 – Test level control thread which restarts the sequence if it returns with a reset status

task run_phase(uvm_phase phase);
 adpcm_init_seq init_seq = adpcm_init_seq::type_id::create("init_seq");
 adpcm_cfg_seq config_seq = adpcm_cfg_seq::type_id::create("config_seq");
 adpcm_tx_seq traffic_seq = adpcm_tx_seq::type_id::create("traffic_seq");
 state_e state = INIT;
 uvm_tlm_response_status_e status = UVM_TLM_GENERIC_ERROR_RESPONSE;
 
 init_seq.status = UVM_TLM_GENERIC_ERROR_RESPONSE;
 config_seq.status = UVM_TLM_GENERIC_ERROR_RESPONSE;
 traffic_seq.status = UVM_TLM_GENERIC_ERROR_RESPONSE;
 
 phase.raise_objection(this, "starting adpcm test");
 forever begin
  case(state)
   INIT: begin
         init_seq.start(m_sequencer);
         if(init_seq.status == UVM_TLM_OK_RESPONSE) state = CONFIG;
        end
   CONFIG: begin
         config_seq.start(m_sequencer);
         if(config_seq.status == UVM_TLM_OK_RESPONSE) state = TRAFFIC;
         else state = INIT;
        end
   TRAFFIC: begin
         traffic_seq.start(m_sequencer);
         if(traffic_seq.status == UVM_TLM_OK_RESPONSE) break;
         else state = INIT;
        end
  endcase
 end
 phase.drop_objection(this, "finished test_seq");
endtask: run_phase

The purpose of a monitor is to track pin level activity against the protocol and to generate transactions which record completed transfers. One important monitor design decision is whether to send out a transaction when a reset is detected, even though a protocol transfer has not completed. Arguably, if the monitor has to handle a reset, then reset is part of the protocol and it should generate and broadcast a transaction with reset status at the end of the reset. Whether the reset transaction should contain information on the transaction that was in progress when the reset occurred is determined by the protocol and how much information the monitor had extracted from the pin level activity before the reset. Like the driver, the monitor will most likely have to be implemented using a state machine in order to handle resets.

Figure 5 - Reset aware driver implemented using FSM

class adpcm_driver extends uvm_driver #(adpcm_seq_item);
 
`uvm_component_utils(adpcm_driver)
 
virtual adpcm_if ADPCM;
typedef enum {IDLE, DELAY, FRAME} state_e;
 
function new(string name = "adpcm_driver", uvm_component parent = null);
 super.new(name, parent);
endfunction
 
task run_phase(uvm_phase phase);
 int idx;
 adpcm_seq_item req;
 state_e state;
 
 forever begin
  ADPCM.frame <= 0; // Default conditions:
  ADPCM.data <= 0;
  @(posedge ADPCM.resetn); // Wait for reset to end
  forever
   begin
    @(posedge ADPCM.clk or negedge ADPCM.resetn);
    if(ADPCM.resetn == 0) begin // Reset detected:
     ADPCM.frame <= 0;
     ADPCM.data <= 0;
     state = IDLE;
     if(req != null) begin
      req.status = UVM_TLM_INCOMPLETE_RESPONSE;
      seq_item_port.item_done();
     end
     while(seq_item_port.has_do_available()) begin
      seq_item_port.get_next_item(req);
      req.status = UVM_TLM_INCOMPLETE_RESPONSE;
      seq_item_port.item_done();
     end
     break;
    end
    else begin
     case(state)
      IDLE: begin // Waiting for something to do
          if(seq_item_port.has_do_available()) begin
           seq_item_port.get_next_item(req);
           req.delay--;
           state = DELAY;
           ADPCM.frame <= 0;
          end
         end
      DELAY: begin // Wait for the specified no of clocks
          if(req.delay > 0) begin
           req.delay--;
          end
          else begin
           state = FRAME;
           idx = 0;
          end
         end
      FRAME: begin // Send the ADPCM frame
          if(idx < 7) begin
           ADPCM.frame <= 1;
           ADPCM.data <= req.data[3:0]; // Send nibbles
           req.data = req.data >> 4;
           idx++;
          end
          else begin
           ADPCM.data <= req.data[3:0];
           req.status = UVM_TLM_OK_RESPONSE;
           seq_item_port.item_done();
           req = null;
           state = IDLE;
          end
         end
     endcase
    end
   end
  end
endtask: run_phase
endclass: adpcm_driver
 
Figure 6 - Reset aware monitor
class adpcm_monitor extends uvm_component;
 
`uvm_component_utils(adpcm_monitor)
 
typedef enum {WAIT_FOR_FRAME, IN_FRAME} monitor_state_e;
 
uvm_analysis_port #(adpcm_seq_item) ap;
 
virtual adpcm_if ADPCM;
 
function new(string name = "adpcm_monitor", uvm_component parent = null);
 super.new(name, parent);
endfunction
 
function void build_phase(uvm_phase phase);
 ap = new("ap", this);
endfunction: build_phase
 
task run_phase(uvm_phase phase);
 adpcm_seq_item txn;
 adpcm_seq_item analysis_txn;
 int nibble_count;
 monitor_state_e state;
 
forever begin
 @(posedge ADPCM.resetn); // Wait for reset to end
 if(txn != null) begin
  txn.status = UVM_TLM_INCOMPLETE_RESPONSE;
  ap.write(txn);
 end
 txn = adpcm_seq_item::type_id::create("txn");
 forever begin
  @(posedge ADPCM.clk or negedge ADPCM.resetn);
  if(ADPCM.resetn == 0) begin // Reset detected
   state = WAIT_FOR_FRAME;
   break;
  end
  else begin
   case(state)
    WAIT_FOR_FRAME: begin
           if(ADPCM.frame) begin
            txn.data = 0; // Initialise the data
            txn.data[3:0] = ADPCM.data;
            state = IN_FRAME;
            nibble_count = 1;
           end
           end
    IN_FRAME: begin
 
         if(ADPCM.frame) begin
          if(nibble_count > 7) begin
          `uvm_error("run_phase", "Too many nibbles in ADPCM frame")
               end
               case(nibble_count)
                1: txn.data[7:4] = ADPCM.data;
                2: txn.data[11:8] = ADPCM.data;
                3: txn.data[15:12] = ADPCM.data;
                4: txn.data[19:16] = ADPCM.data;
                5: txn.data[23:20] = ADPCM.data;
                6: txn.data[27:24] = ADPCM.data;
                7: txn.data[31:28] = ADPCM.data;
               endcase
               nibble_count++;
              end
              else begin
               state = WAIT_FOR_FRAME;
               txn.status = UVM_TLM_OK_RESPONSE;
               assert($cast(analysis_txn, txn.clone()));
               ap.write(analysis_txn);
               txn.data = 0;
              end
             end
    endcase
   end
  end
 end
 
endtask: run_phase
 
endclass: adpcm_monitor

Analysis components such as scoreboards and functional coverage monitors also need to be designed to handle resets. What a scoreboard should do in the case of a reset is determined by the behavior of the DUT. For instance, if the DUT flushes all of its data buffers on a reset, then the scoreboard will need to do the same, or it may mark outstanding transactions as flushed to check that the DUT has flushed its data. If recovery from an on the fly reset is important for certain conditions, then functional coverage monitors can be made reset aware by checking the state
of the design when it entered reset.

Event Initiated by Recommended Approach
Interrupt DUT Implement a context switch in the stimulus generation, no disruption to protocol transfers. See: http://verificationacademy.com/uvm-ovm/Stimulus/Interrupts
Error DUT Should be signalled as an error status, stimulus should have error handling embedded
Power Down Testbench Originated by the stimulus process, an orderly transition with protocol level transactions completing normally before entering power-down state.
Power Loss DUT (Hardware) Sudden loss of power is like an interrupt and should cause a context switch to enter a power-down state.

HANDLING OTHER HARDWARE EVENTS

An asynchronous reset is probably the most disruptive type of hardware event that can happen to a DUT. Other types of hardware events can be handled in other ways or by adapting the techniques outlined, the exact requirements are dependent on device behavior and the nature of the event. The most common forms of disruptive hardware events are summarized in the table above.

CONCLUSION

On the fly resets can be made manageable within a UVM testbench by building reset awareness into the agent, the sequence item and sequences. If the driver detects a reset condition, then it can bring the current transaction to an early close and return reset status through the sequence hierarchy to ensure a managed change in the stimulus generation path. This approach works well in the situation when all the testbench components have been implemented in this way, but if there are components that ignore reset, then they will need to be handled separately, allowing currently running sequences to come to halt of their own accord and dealing with the consequences.
As the reset aware technique does not rely on multiple run-time phases, it can also be used with OVM testbenches.

FURTHER EXAMPLES

The code examples shown in this article have been taken from a relatively simple unidirectional agent, other types of agent with bidirectional and pipelined protocols require a similar implementation approach. For more details and code examples please refer to the UVM cookbook available on the Verification Academy.

Back to Top

Table of Contents

Verification Horizons Articles:

  • "Murphy" on Verification: If It Isn't Covered, It Doesn't Work

  • Mentor Has Accellera's Latest Standard Covered

  • Is Intelligent Testbench Automation For You?

  • Automated Generation of Functional Coverage Metrics for Input Stimulus

  • Targeting Internal-State Scenarios in an Uncertain World

  • Virtualization Delivers Total Verification of SoC Hardware, Software, and Interfaces

  • On the Fly Reset

  • Relieving the Parameterized Coverage Headache

  • Four Best Practices for Prototyping MATLAB and Simulink Algorithms on FPGAs

  • Better Living Through Better Class-Based SystemVerilog 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