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 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 - November 2020
      • Verification Horizons - July 2020
      • Verification Horizons - March 2020
      • Issue Archive
    • About Us

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

      • Questa® & ModelSim®
      • Questa® inFact
      • Functional Verification Library
Ask a Question
SystemVerilog
  • Home
  • Forums
  • SystemVerilog
  • Distributing task calls between SV implementations in "generate" blocks

Distributing task calls between SV implementations in "generate" blocks

SystemVerilog 4983
task 13 distributor 1 generate 9 SystemVerilog 40
simonsabato
simonsabato
Forum Access
3 posts
February 21, 2019 at 5:43 pm

In our "ram" library element, we compile in accessor tasks during simulation. Currently, we globally define LIB_VENDOR or LIB_BEHAVIORAL to control implementation. So we have code like:

module ram; 
  `ifdef LIB_VENDOR
     vendor_ram uINST ();
     task RamWrite (input a, output b);
     begin uINST.VendorRamWrite(a, b); end
     endtask
  `else
     behavioral_ram uINST ();
     task RamWrite (input a, output b);
     begin uINST.BehavioralRamWrite(a, b); end
     endtask
  `endif
endmodule

We use the RamWrite task to normalize the task names, arguments, etc, between the various implementations (or to print an error if the implementation doesn't support a backdoor task).

Now we'd like to migrate to having the implementation controlled by parameter (for example, we may want to sometimes use "RTL RAM" for small memories). I was thinking that the following should work:

module ram #(parameter Vendor = 0) ();
  generate
    if (Vendor) begin : impl_vendor
      vendor_ram uINST ();
    end
    else begin : impl_rtl
      behavioral_ram uINST ();
    end
 
    task RamWrite (input a, output b);
      begin
        if (Vendor) impl_vendor.uINST.VendorRamWrite(a, b);
        else impl_rtl.uINST.BehavioralRamWrite(a, b);
      end
    endtask // RamWrite
 
  endgenerate
endmodule
 
module vendor_ram;
  task VendorRamWrite (input a, output b);
    begin $display("vendor ram write"); end
  endtask // VendorRamWrite
endmodule
 
module behavioral_ram;
  task BehavioralRamWrite (input a, output b);
    begin $display("behav ram write"); end
  endtask // BehavioralRamWrite
endmodule

... But this doesn't work. It seems that SV, for the instances, only "goes into" one of two paths, but within the ram.RamWrite task, it wants both to be there. This doesn't seem *necessary* ... I believe I understand the classic issues of calling a task within an array of instances, etc, but in this case I thought it should work. Does this seem like a vendor-specific tool issue, and if not, what's the "recommended" way to do this kind of thing? Note this is design-side SV code, so it would be nice to keep the verif-side complexities (UVM, classes, etc) out of it ... if possible.

Replies

Log In to Reply

Solution

Solution

dave_59
dave_59
Forum Moderator
8586 posts
February 21, 2019 at 11:35 pm

In reply to simonsabato:

SystemVerilog requires all hierarchical references to be bound at elaboration. There would have to be optimization rules to skip the binding. This might be doable at some point in the future with a generate-if construct, but more difficult with a procedural-if construct.

A suggestion for you is creating two ram module wrappers, one wrapping each implementation, and using a Verilog config construct to select the ram on a per instance basis. See See section 33 of 1800-2017 LRM and this paper: https://lcdm-eng.com/papers/snug01_verilog2000.pdf

— Dave Rich, Verification Architect, Siemens EDA

simonsabato
simonsabato
Forum Access
3 posts
February 22, 2019 at 7:00 pm

In reply to dave_59:

Thanks Dave, that was helpful. The contrast of "generate-if" vs "procedural-if" is what I was missing.

As an aside, while waiting for the response I was playing around and found that (at least on one tool) the following works:

module ram #(parameter Vendor = 0) ();
  generate
    if (Vendor) begin : impl
      vendor_ram uINST ();
    end
    else begin : impl
      behavioral_ram uINST ();
    end
    task RamWrite (input a, output b);
      begin
        if (Vendor) impl.uINST.RamWrite(a, b);
        else impl.uINST.RamWrite(a, b);
      end
    endtask // RamWrite
  endgenerate
endmodule
 
module vendor_ram;
  task RamWrite (input a, output b);
    begin $display("vendor ram write"); end
  endtask // VendorRamWrite
endmodule
 
module behavioral_ram;
  task RamWrite (input a, output b);
    begin $display("behav ram write"); end
  endtask // BehavioralRamWrite
endmodule

Basically, name the two generate blocks the same, name the tasks the same, and ensure tasks have the same arguments. This probably doesn't solve my original problem because I need to be able to call different subtasks.

I'm asking this followup because I'm not sure if this is expected to work (cross-vendor etc). It feels a bit like I'm "fooling" the tool. I did run it and verified that it calls the right sub-module's task when I change the top level parameter.

If this *is* legal, I could imagine building an additional layer of "distributor" tasks (within vendor_ram and behavioral_ram) which have the same name/arguments (RamWrite), which then call the local versions (VendorRamWrite & BehavioralRamWrite). If that is somehow valid it's another way to get this to work.

I'll still look into the config files. AFAIK those are the only way to swap in a *really* different implementation (behavioral, gate level, etc) so it's a powerful technique. It's not ideal for the problem I was trying to solve as I'm trying to make a very reusable library and I don't want the "integration" person to be in the loop for these RAM mappings. If the config file can be setup hierarchically that could work...

dave_59
dave_59
Forum Moderator
8586 posts
February 22, 2019 at 10:42 pm

In reply to simonsabato:
Yes, what you wrote is legal. I think Example 4 in LRM section 27.5 is very similar to what you are doing.

And yes, you can build up config declarations hierarchically.

— Dave Rich, Verification Architect, Siemens EDA

simonsabato
simonsabato
Forum Access
3 posts
February 27, 2019 at 11:47 am

In reply to dave_59:

Dave,

THANKS!

That was exactly the shove that I needed. The following code shows a working solution to the original question. It *does* use a layer of "distributor" tasks. But since the "distribution layer" is within the wrapper, it *doesn't* require modifying the vendor_ram / behavioral_ram implementations, which is key (they may be 3rd party, encrypted etc).

Specifically the two things I was missing:
- LRM 27.5 discussion on how multiple generate blocks can use the same name if only one will be included
- Putting tasks within the conditional generate blocks (next to the RAM instances) allows for a unique task for each possible implementation, all having the same name/args, such that the top level RamWrite task can just call impl.RamWrite unconditionally.

module ram #(parameter Vendor = 0) ();
  generate
    if (Vendor) begin : impl
      vendor_ram uINST ();
      task RamWrite (input a, output b);
        uINST.VendorRamWrite(a, b);
      endtask // RamWrite
    end
    else begin : impl
      behavioral_ram uINST ();
      task RamWrite (input a, output b);
        uINST.BehavioralRamWrite(a, b, 0, 1);
      endtask // RamWrite
    end
    task RamWrite (input a, output b);
      impl.RamWrite(a, b);
    endtask // RamWrite
  endgenerate
endmodule
 
module vendor_ram;
  task VendorRamWrite (input a, output b);
    $display("vendor ram write");
  endtask // VendorRamWrite
endmodule
 
module behavioral_ram;
  task BehavioralRamWrite (input a, output b, input x, input y);
    $display("behav ram write");
  endtask // BehavioralRamWrite
endmodule
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