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

      • Low Power Verification - 4/29
      • Fault Campaign for Mixed-Signal - 5/4
      • User2User - 5/26
      • Webinar Calendar
    • On-Demand Webinars

      • CDC+RDC Analysis
      • Basic Abstraction Techniques
      • Safety Analysis Techniques
      • QVIP Workflow and Debug for PCIe
      • Writing a Proxy-driven Testbench
      • Achieving High Defect Coverage
      • Visualizer Features
      • 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
Ask a Question
UVM
  • Home
  • Forums
  • UVM
  • How to pause a sequence based on event

How to pause a sequence based on event

UVM 5685
#sequence 22 Cookbook: Sequences... 5 sequencer arbitration 2 sequence arbitration 2 #systemverilog #UVM 17
peterjin
peterjin
Full Access
36 posts
March 06, 2020 at 5:31 pm

Hi,

I have a question about how to pause a uvm_sequence based on events.

My test setup is like this:
1) I am trying to simulate a QoS-based flow control traffic
2) I have one driver and 4 sequences, all the four sequences are being arbitrated on the same sequencer. Each sequence represents a QoS class.
3) During the simulation, all four sequences will be driving data via the same driver. In the meantime, the environment will generate a pause-event to pause a certain sequence (let's say sequence 0).

What I want to achieve:
1) When the environment generates the pause-event to pause sequence0, only sequence0 should be paused, while seq1,2,3 should continue to drive data to the DUT
2) After some time, when the environment generates the clear_pause-event to unpause sequence0, sequence0 should resume driving data

I wonder is there any existing UVM mechanism to let me do this? Or I have to extend the sequencer and write my own arbitration policy?

Thanks in advance for your help!

Hao

Replies

Log In to Reply
cuonghle
cuonghle
Full Access
308 posts
March 06, 2020 at 6:27 pm

In reply to peterjin:

Because there are multiple sequences share the same sequencer, then you need to pause sending the stumilus in your particular sequence. The simplest way:
- Declare the pause event flag in sequence-config, set the config to your sequences
- Get the config and check the condition of pause event in order to generate stimulus in your sequences
- Control the pause event flag in your environment when you want to pause/unpause.

Chris Le

chr_sue
chr_sue
Full Access
3326 posts
March 06, 2020 at 11:16 pm

In reply to peterjin:

What you are trying to do is useless. The sequencer does not actively send a seq_item to the driver. This happens only when you are using the uvm_push_sequencer.
In your case the driver is retrieving a seq_item from the sequencer. The sequencer is only providing the seq_item. The consequence is all timing related activity has to be in the driver. Stopp your driver and it will not retrieve a new seq_item. Very simple to implement.

warnerrs
warnerrs
Full Access
121 posts
March 08, 2020 at 6:57 pm

Hi Hao,

In reply to peterjin:

Quote:
Hi,
I have a question about how to pause a uvm_sequence based on events.
My test setup is like this:
1) I am trying to simulate a QoS-based flow control traffic

This immediately gets me thinking about using the priority feature of the sequencer.

Quote:
2) I have one driver and 4 sequences, all the four sequences are being arbitrated on the same sequencer. Each sequence represents a QoS class.
3) During the simulation, all four sequences will be driving data via the same driver

When not throttled, do they all have equal priority?

Quote:
In the meantime, the environment will generate a pause-event to pause a certain sequence (let's say sequence 0).

What I want to achieve:
1) When the environment generates the pause-event to pause sequence0, only sequence0 should be paused, while seq1,2,3 should continue to drive data to the DUT


This would correspond to lowering the priority of a sequencer.

Quote:
2) After some time, when the environment generates the clear_pause-event to unpause sequence0, sequence0 should resume driving data
This would correspond to restoring the priority.


It sounds like you could use set_arbitration() to put the sequencer in either UVM_SEQ_ARB_STRICT_FIFO or UVM_SEQ_ARB_STRICT_RANDOM mode, and then alter the priority of sequences as needed. If your environment has a handle to all of the sequences which need to have their QoS modified, it would simply call set_priority() on the sequence you want to pause or unpause.

The change in priority will apply to the next item the sequence tries to send. If there is already a pending item already started on the sequencer, it's priority won't be changed.

-Ryan

cuonghle
cuonghle
Full Access
308 posts
March 08, 2020 at 8:02 pm

In reply to warnerrs:

Setting the sequencer priority only changes the order of traffic to driver, it does not make a sequence stop sending stimulus (pause), Then, I think the simplest way is controlling the generation in sequence if you want to pause/unpause traffic for a particular sequence.

Chris Le

chr_sue
chr_sue
Full Access
3326 posts
March 09, 2020 at 12:13 am

In reply to cuonghle:

Quote:
In reply to warnerrs:

Setting the sequencer priority only changes the order of traffic to driver, it does not make a sequence stop sending stimulus (pause), Then, I think the simplest way is controlling the generation in sequence if you want to pause/unpause traffic for a particular sequence.

Note, the traffic between sequencer and driver is determined by the driver NOT the sequencer.
The sequencer doe NOT send any transactionn to the driver. The driver is polling a seq_item. It is just easy to implement your behavior in the driver.

warnerrs
warnerrs
Full Access
121 posts
March 09, 2020 at 1:28 am

In reply to cuonghle:

Quote:
Setting the sequencer priority only changes the order of traffic to driver, it does not make a sequence stop sending stimulus (pause), Then, I think the simplest way is controlling the generation in sequence if you want to pause/unpause traffic for a particular sequence.

I forgot about the case where only the paused sequence is trying to send items. Still, QoS is a form of arbitration, so putting it in the sequencer is a natural fit. If this scenario requires that the paused sequence stay paused, even when there are no other sequences trying to send items, then the UVM_SEQ_ARB_STRICT_* modes won't work.

User defined arbitration ( UVM_SEQ_ARB_USER ) could be added to the sequencer to handle this without requiring adding anything into the sequences. The advantage of that is, you can write sequences that aren't even aware the QoS mechanism exists. Any sequence ran on that sequencer would be affected. You still need to have some env component altering the priority ( pause state ) of the sequences.

If you go with cuonghle's sequence based approach, you might implement is_relevant() and wait_for_relevant(). That way you don't have to put pausing code explicitly in the sequence body(). Implement them in a base sequence shared by all QoS sequences.

In reply to chr_sue:

Quote:
Note, the traffic between sequencer and driver is determined by the driver NOT the sequencer.
The sequencer doe NOT send any transactionn to the driver. The driver is polling a seq_item. It is just easy to implement your behavior in the driver.

I don't follow how the driver can implement a QoS arbitration scheme. The driver can stop getting the next item, but if there are multiple sequences trying to send items at different QoS level, such a mechanism will block items from all sequences.

-Ryan

cuonghle
cuonghle
Full Access
308 posts
March 09, 2020 at 1:48 am

In reply to chr_sue:

Quote:
In reply to cuonghle:

Quote:
In reply to warnerrs:

Setting the sequencer priority only changes the order of traffic to driver, it does not make a sequence stop sending stimulus (pause), Then, I think the simplest way is controlling the generation in sequence if you want to pause/unpause traffic for a particular sequence.

Note, the traffic between sequencer and driver is determined by the driver NOT the sequencer.
The sequencer doe NOT send any transactionn to the driver. The driver is polling a seq_item. It is just easy to implement your behavior in the driver.

What you said is confusing.
The topic owner has 4 sequences, they start same sequencer and there is one driver to drive the transaction to DUT. Now, he wants to pause (stop sending traffic) from a particular sequence, but other sequences are still working.
Why you want to implement this behavior in the driver? And how?
In order to pause, the easy way is pausing the source of the traffic which is in sequence.

Chris Le

chr_sue
chr_sue
Full Access
3326 posts
March 09, 2020 at 3:23 am

In reply to cuonghle:

You can do this by adding a specific ID to the seq_items. In the driver you are checking this item and do not process this simply discardingg it.

peterjin
peterjin
Full Access
36 posts
March 09, 2020 at 2:23 pm

In reply to cuonghle:

In reply to warnerrs:

Hi Ryan, Chris:

Thanks for your reply.

Quote:
I forgot about the case where only the paused sequence is trying to send items. Still, QoS is a form of arbitration, so putting it in the sequencer is a natural fit. If this scenario requires that the paused sequence stay paused, even when there are no other sequences trying to send items, then the UVM_SEQ_ARB_STRICT_* modes won't work.

Yes, the paused sequence will stay paused as long as DUT (slave-side) is asserting pause to the driver.

What I have implemented is whenever the paused sequence detects the pause signal (I did a signal probe from my sequence, though I know this is not a proper way), it will skip the current packet generation and advance 1ps (to prevent dead loop). This is what my sequence looks like

task body;
int seq_qos; //indicate which qos this sequence represents
...
while (generated_pkt < pkt_to_send)begin
...
  if(dut.pause[seq_qos]==1) begin//pasue is bitmap based pause
    #1ps; 
    contiune
  end
  else begin
    start_item(req);
    finish_item(req);
    generated_pkt++; //only increase when a packet was truly generated
  end
end

However, from what I observed from the waveform, when DUT paused qos0, even though I did see sequence 1-3 is able to generate packets for qos1-3, but it was driving at a much slower speed. (I am expecting sequence 1-3 to generate at full speed, but the actual speed is 10x slower)

In that case, I think I should write my own arbitration_policy for my sequencer. But I wonder why detecting and adding the 1ps delay (my DUT clock cycle is 1ns) in seq0 will significantly slow down the traffic generation for other sequences?

Thanks for all your help,

Hao

Solution

Solution

cuonghle
cuonghle
Full Access
308 posts
March 10, 2020 at 12:22 am

Quote:
But I wonder why detecting and adding the 1ps delay (my DUT clock cycle is 1ns) in seq0 will significantly slow down the traffic generation for other sequences?

Thanks for all your help,

Hao

The idea to add 1ps delay was to avoid the simulation hang due to zero time consumption of the while-loop when pause, and it was not a good idea, it makes the simulator's scheduling overloaded and slow down your simulation. You can improve it by changing:

task body;
int seq_qos; //indicate which qos this sequence represents
...
while (generated_pkt < pkt_to_send)begin
...
  wait(dut.pause[seq_qos] == 1'b0); // or using === operator if checking X
  start_item(req);
  finish_item(req);
  generated_pkt++;
end

In case of pause, the code is blocked at "wait" statement until unpause (dut.pause[seq_qos] = 0).

Chris Le

peterjin
peterjin
Full Access
36 posts
March 11, 2020 at 5:31 pm

In reply to cuonghle:

Hi Chris,

Thanks for your answer, my problem solved with your solution

Thanks

Hao

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