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 IQ
      • Verification IP
      • Static-Based Techniques
      • Simulation-Based Techniques
      • Planning, Measurement, and Analysis
      • Formal-Based Techniques
      • Debug
      • 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)

      • Introduction to UVM
      • UVM Basics
      • Advanced 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.

    • Featured & On-Demand

      • UCIe VIP - 12/7
      • RTL Profiling
      • RISC-V Design
      • Exploring Formal Coverage
      • Processor Customization
      • Interconnect Formal
      • Formal and the Next Normal
      • Formal Verification Made Easy
      • Data Independence and Non-Determinism
      • Exhaustive Scoreboarding
      • Visualizer Debug Environment
      • Webinar Calendar

    • On-Demand Library

      • SystemVerilog Assertions
      • Practical Flows for Continuous Integration
      • Continuous Integration
      • Questa Verification IQ
      • Avery & Siemens VIP
      • Protocol and Memory Interface Verification
      • HPC Protocols & Memories
      • Preparing for PCIe 6.0: Parts I & II
      • High Defect Coverage
      • SoC Design & Functional Safety Flow
      • Complex Safety Architectures
      • All On-Demand Recordings

    • Recording Archive

      • Lint vs Formal AutoCheck
      • FPGA Design Challenges
      • Design Solutions as a Sleep Aid
      • Fix FPGA Failures Faster
      • CDC and RDC Assist
      • The Dog ate my RTL
      • Questa Lint & CDC
      • Hierarchical CDC+RDC
      • Improving Initial RTL Quality
      • CDC Philosophy
      • Hardware Emulation Productivity
      • The Three Pillars of Intent-Focused Insight
      • All Webinar Topics

    • Conferences & WRG

      • 2022 Functional Verification Study
      • Improving Your SystemVerilog & UVM Skills
      • Automotive Functional Safety Forum
      • Aerospace & Defense Tech Day
      • Siemens EDA Functional Verification
      • Industry Data & Surveys
      • DVCon 2023
      • DVCon 2022
      • DVCon 2021
      • Osmosis 2022
      • All Conferences

    • Siemens EDA Learning Center

      • EDA Xcelerator Academy(Learning Services) Verification Training, Badging and Certification
      • View all Xcelerator Academy classes
  • 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 IQ
      • Verification Horizons Blog
      • Technical Resources

    • Verification Horizons Publication

      • Verification Horizons - July 2023
      • Verification Horizons - March 2023
      • Verification Horizons - December 2022
      • Issue Archive

    • About Us

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

    • Training

      • Learning @OneGlance (PDF)
      • SystemVerilog & UVM Classes
      • Siemens EDA Classes
Ask a Question
UVM
  • Home
  • Forums
  • UVM
  • Sequence to that respond to done signal

Sequence to that respond to done signal

UVM 7028
get_response 9 Response API 2 #sequence 43 sequence body() 7
bachan21
bachan21
Full Access
118 posts
August 04, 2021 at 3:52 am

I am writing the task body below

task body();
  req = packet::type_id::create("rqst");
 
  start_item(req);
    void`(randomize() with req.sel == 1;
                           req.en == 1;
                           req.addr == 20'h0100;);
  finish_item(req);
endtask : body

I am driving this signals to DUT. After the operation is completed, done bit will be set to 1.
On receiving done with I want to send address 20'h1100. So aim is to receive done as a response from DUT and send the packet to driver with another address. How can I code the sequence body for that.

Replies

Log In to Reply
chr_sue
chr_sue
Full Access
4032 posts
August 04, 2021 at 4:33 am

In reply to bachan21:

To be honest, I do not see any 'done' bit in your seq_item.
What do you mean with 'done' bit?
Or do you want to send consecutive seq_items? this automatically donw when adding a next start_item/finish_item.

bachan21
bachan21
Full Access
118 posts
August 04, 2021 at 6:25 am

In reply to chr_sue:

done is a part of sequence item class, which is an output from DUT.
done bit is raised to indicate current operation is done and next inputs can be passed.
Should I use multiple start and finish items?

chr_sue
chr_sue
Full Access
4032 posts
August 04, 2021 at 6:58 am

In reply to bachan21:

This is what the call of item_done() in the driver is doing. It is the indication to the sequencer to generate the next seq_item.
start_item/finish_item creates exactly 1 item. If you need more you have to implement multiple start_item/finish_item.
To make your code easy you could use a loop construct in the body method like this

task body();
 repeat (10) begin
  req = packet::type_id::create("req");
  start_item(req);
    void`(randomize() with sel == 1; en == 1; addr inside {20'h0000, 20'h0100};);
  finish_item(req);
endtask : body

This generates seq_item with addr in random order.

It looks like your seq_item has data members you do not need, like sel and en. You can set these variables directly in the driver.

bachan21
bachan21
Full Access
118 posts
August 04, 2021 at 11:22 pm

In reply to chr_sue:

I think, I didn't give much details on my DUT behavior. It takes up the address and performs write action on next 100 addresses near to it. So I had wait till this action is completed to drive next address. If I am using the body you provided it will overwrite the initial address and address calculation for further operation will be blocked. Is there any way to involve response port here?

Also I cant set sel and enable in driver as the driving is different for other tests.

chr_sue
chr_sue
Full Access
4032 posts
August 05, 2021 at 12:23 am

In reply to bachan21:

You are determining the timing behavior in your driver. The next seq_item will be retrieved after the item_done has been sent. This behavior does not override anything.
How do you differentiate your tests? Do you have really differnet protocols in your driver?
I do not believe it.

bachan21
bachan21
Full Access
118 posts
August 05, 2021 at 1:09 am

In reply to chr_sue:

No. I use same protocol. I was looking forward something like response port to achieve this behavior.

bachan21
bachan21
Full Access
118 posts
August 05, 2021 at 1:12 am

In reply to bachan21:

Quote:
repeat (10) begin
  req = packet::type_id::create("req");
  start_item(req);
    void`(randomize() with sel == 1; en == 1; addr inside {20'h0000, 20'h0100};);
  finish_item(req);

But I cant just put my body code like this. The addresses are deterministic in nature. So I have drive to those specific values in order. So should I use multiple start and finish item?

chr_sue
chr_sue
Full Access
4032 posts
August 05, 2021 at 1:22 am

In reply to bachan21:

Deterministic means you have to use fixed addresses in a well-defined order?

bachan21
bachan21
Full Access
118 posts
August 05, 2021 at 1:23 am

In reply to chr_sue:

Yes exactly

chr_sue
chr_sue
Full Access
4032 posts
August 05, 2021 at 1:34 am

In reply to bachan21:
int addr_q[$]; // declaration of a queu to store addresses

in the body method fill the queue with the proper addresses in the right order (using an assigment pattern or a loop.

task body();
   int tmp_addr;
   addr_q = '{addr1, addr2, ...};
 
    repeat (10) begin
      req = packet::type_id::create("req");
      tmp_addr = addr_q.pop_front();  // returns the first element of this queue
      start_item(req);
        void`(randomize() with sel == 1; en == 1; addr == tmp_addr;);
      finish_item(req);
   end
endtask
bachan21
bachan21
Full Access
118 posts
August 05, 2021 at 2:15 am

In reply to chr_sue:

Yes this can work. A little bit modification in driver will realize my logic.

chr_sue
chr_sue
Full Access
4032 posts
August 05, 2021 at 3:37 am

In reply to bachan21:

Please let us know if it is working.
If the next address depends on some data you receive from the DUT you need a response sent from the driver to the sequence.

bachan21
bachan21
Full Access
118 posts
August 22, 2021 at 11:32 pm

In reply to chr_sue:

In reply to chr_sue:

Hi,
This method is working. But I am facing an issue now.
I have created two sequences with 2 different queue values.

bit [19:0] q;

In first sequence (the name is a_seq), I have given following values
q = {20'h983, 20'h183};

In the second q(b_seq), I have given following values
q = {20'h903, 20'h103};

First sequence is working properly and done bit is produced for value 20'h983 and 20'h183
In case of second test only 20'h903 is being passed successfully. Test is hanging when 20'h103 is passsed.

But the crazy thing is when I have assigned 20'h983 and 20'h183 to q of a_seq. It's driven successfully. Given that the other contents of a_seq and b_seq are same,it doesn't make any sense. What can be the possible reason for hanging in this situation?

dddvlsique
dddvlsique
Full Access
15 posts
August 23, 2021 at 4:20 am

In reply to chr_sue:

Quote:
In reply to bachan21:
int addr_q[$]; // declaration of a queu to store addresses

in the body method fill the queue with the proper addresses in the right order (using an assigment pattern or a loop.

task body();
   int tmp_addr;
   addr_q = '{addr1, addr2, ...};
 
    repeat (10) begin
      req = packet::type_id::create("req");
      tmp_addr = addr_q.pop_front();  // returns the first element of this queue
      start_item(req);
        void`(randomize() with sel == 1; en == 1; addr == tmp_addr;);
      finish_item(req);
   end
endtask

@chr_sue ,If i have to drive addr2 based on response of addr1 from driver to sequence depends on "done" bit of sequence item class ,so following below code of driver and sequence is correct ?

driver code ::

task run_phase( uvm_phase phase );
  REQ req_item; //REQ is parameterized type for requests
  RSP rsp_item; //RSP is parameterized type for responses
 
  bit [15:0] rdata;
  bit resp;
 
  forever begin
    seq_item_port.get(req_item); // finish_item in sequence is unblocked
 
    //BFM handles all pin wiggling 
     drive(req_item);
 
    $cast(rsp_item, req_item.clone()); // Create a response transaction by cloning req_item
    rsp_item.set_id_info(req_item); // Set the rsp_item sequence id to match req_item
 
    rsp_item.done = resp;
    seq_item_port.put(rsp_item); // Handshake back to the sequence via its get_response() call
  end
endtask

sequence code :: 

task body();
   int tmp_addr;
   addr_q = '{addr1, addr2, ...};
 
      req = packet::type_id::create("req");
      tmp_addr = addr_q.pop_front();  // returns the first element of this queue
      start_item(req);
        void`(randomize() with sel == 1; en == 1; addr == tmp_addr;);
      finish_item(req);
     //first addr1 sequence is completed
 
     get_response(rsp);   //wait for response for first addr1
 
    if(rsp.done == 1)
    begin
    req = packet::type_id::create("req");
      tmp_addr = addr_q.pop_front();  // returns the second element of this queue 
      start_item(req);
        void`(randomize() with sel == 1; en == 1; addr == tmp_addr;);  
      finish_item(req);
    end
 
 
endtask
Siemens Digital Industries Software

Siemens Digital Industries Software

#TodayMeetsTomorrow

Portfolio

  • Cloud
  • Mendix
  • Electronic Design Automation
  • MindSphere
  • Design, Manufacturing and PLM Software
  • View all Portfolio

Explore

  • Community
  • Blog
  • Online Store

Siemens

  • About Us
  • Careers
  • Events
  • News and Press
  • Customer Stories
  • Partners
  • Trust Center

Contact

  • VA - Contact Us
  • PLM - Contact Us
  • EDA - Contact Us
  • Worldwide Offices
  • Support Center
  • Give us Feedback
© Siemens 2023
Terms of Use Privacy Statement Cookie Statement DMCA