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

      • VA Live - Multiple Dates & Locations
      • 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 - March 2023
      • Verification Horizons - December 2022
      • Verification Horizons - July 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
OVM
  • Home
  • Forums
  • OVM
  • Virtual interface resolution cannot find a matching instance of interface

Virtual interface resolution cannot find a matching instance of interface

OVM 2521
larrylikesyou
larrylikesyou
Forum Access
4 posts
May 12, 2008 at 10:10 am

Hi All,

While loading my design I get this error (I'm running Questa 6.3f):

# Loading work.mem(fast)
# ** Fatal: (vsim-8451) env//driver.sv(71): Virtual interface resolution cannot find a matching instance of interface 'mem_if'.

I'm using the method proposed in the Doulos examples to assign an interface to an virtual interface in a wrapper through set_config_object. I checked it 20 times and can't see what's wrong. What does the error exactly mean?

thanks a lot,

Pieter

Replies

Log In to Reply
larrylikesyou
larrylikesyou
Forum Access
4 posts
May 13, 2008 at 12:20 am

Hi all,

I found the cause (below, from Supportnet Mentor) and the solution, adding the the same parameters to the virtual interface as to the instance and setting the flag: -permit_unmatched_virtual_intf.

kind regards,

Pieter

When a virtual interface is declared, it references an interface as its type. There must be a matching instance of the actual interface for the type to be fully defined. Prior to 6.3d, Questa would substitute a trivial type for the virtual interface type, if the true matching interface could not be found. After analyzing some user designs, it was found that automatically doing this substitution, while preventing an error, could lead to other fatal problems. Therefore, in 6.3d, this is now an error at elaboration time.

IEEE 1800-2005 Section 24.9 says: “A virtual interface is a variable that represents an interface instance.” This means that Questa must be able to resolve a virtual interface declaration with an instance of a matching actual interface in the design. It is possible to get this error if a virtual interface is declared but never used; such is in the above example if the class method ‘do_something’ was never called. This can occur if a virtual interface is declared in a base class that is re-used among multiple designs, but only some of the designs actually utilize the virtual interface.
For these cases, an option was added to vsim to avoid this error: –permit_unmatched_virtual_intf. It is important to note the LRM restriction: “A virtual interface must be initialized before it can be used; it has the value null before it is initialized. Attempting to use an uninitialized virtual interface shall result in a fatal run-time error.” Therefore, the above example will load successfully if –permit_umatched_virtual_intf is used, however a fatal run-time error would still occur if method ‘do_something’ was ever called.

dlong
dlong
Full Access
202 posts
May 13, 2008 at 2:09 am

Hi Pieter,

Thanks for sharing that. I hadn't come across that particular issue with unconnected virtual interfaces before - the usual run-time error is an illegal dereference when the virtual interface is accessed!

The other question to ask is why do you have an unconnected virtual interface at all? The two most common mistakes I have seen are:

1. Specifying a wrong path with set_config_object

2. Forgetting to call `ovm_field_object for the virtual interface wrapper in the driver (so it doesn't automatically pick up the configuration at the end of the build phase).

Regards,
Dave

larrylikesyou
larrylikesyou
Forum Access
4 posts
May 13, 2008 at 2:54 am

Hi,

If I'm not mistaken, I don't have an unconnected interface. During loading, Questa searches an instantiation of the interface that matches the virtual interface. As I had
mem_if #(data_t, address_t) m_mem_ifand the virtual interface
virtual mem_if m_mem_if (without parameters) Questa couldn't find an instance that matched the virtual interface. So I added the parameters to the virtual interface.

While trying to match the virtual interface (with parameters) during loading of the design, Questa couldn't handle it (it said: can't match interface none). So I had to turn that check off. Everything runs fine now.

kind regards,

Pieter

dlong
dlong
Full Access
202 posts
May 13, 2008 at 4:23 am

Hi Pieter,

Sorry, I hadn't spotted that you were using parameterised virtual interfaces.

I did write some code using parameterised virtual interfaces that worked OK with Questa 6.2 but got broken in Questa 6.3. The -permit_unmatched_virtual_intf does indeed allow the assignment to the virtual interface (provided the parameters match) but I faced another problem. To be really useful, the classes that contained the virtual interface had to be parameterised too. This required coding along the lines of:

class if_wrapper #(int ADDR_WIDTH=8, int DATA_WIDTH=8) extends ovm_object;

typedef virtual my_if#(ADDR_WIDTH,DATA_WIDTH) my_if_t;

virtual my_if_t v_if;

function new (string name, virtual my_if_t if_);
  super.new(name);
  v_if = if_;
endfunction
...
endclass

This would build OK but give a run-time error when the interface was accessed since the virtual interface specialisation due to the typedef in the class was taken to be a different type from the actual interface specialisation.

I abandoned this approach since it was not supported by other simulators either.

Regards,
Dave

jgg
jgg
Forum Access
25 posts
May 13, 2008 at 2:13 pm

dlong wrote:
This would build OK but give a run-time error when the interface was accessed since the virtual interface specialisation due to the typedef in the class was taken to be a different type from the actual interface specialisation.

I'm surprised I haven't hit the above bug (I hope you filed a bug report :)), but I've been using parameterized interfaces quite a bit and the working approach I use is to make the class parametric on the interface type:

class if_wrapper #(type my_if_t  = int) extends ovm_object;
   my_if_t v_if;
   [..]
endclass;

Foo_intf #(.BAR(10),.GAR(11)) intf;

if_wrapper #(virtual Foo #(.BAR(10),.GAR(11))) wrap = new("intf",intf);
This seems to be a very good practice in general since there is no OOP properties for interfaces. This lets all the drivers/monitors use any interface that is member name compatible and thus provides something kind of like polymorphism for interfaces.

In one case I have a family of about a dozen name compatible interfaces with slightly different properties (like bit widths/etc) that can be used interchangeably with a generic family of driver/monitors.

I've also had a few cases where a generic component might take two interfaces in but, in a specific test one is not used and is just assigned to null. This is where the limitation that was originally quoted becomes annoying, and seemingly unnecessary.

dlong
dlong
Full Access
202 posts
May 14, 2008 at 2:13 am

Hi jgg,

Thanks for sharing your approach - it does seem to work OK for my examples too with Questa 6.3f :)

The crucial step seems to be in making the wrapper parameter a virtual interface and then using that "as is" within the wrapper (rather than passing simple parameter types and using them to define a virtual interface within the wrapper). e.g.

class if_wrapper #(type my_chip_if = int) extends ovm_object;
   //parameter my_chip_if must be passed as virtual
 
   my_chip_if if1;  //simple variable declaration not virtual intf

   function new(string name,my_chip_if if_);  //if_ not declared as virtual intf
      super.new(name);
      if1 = if_;      
   endfunction : new
   
endclass : if_wrapper

In top module:

chip_if#(8,8) dut_if();
  chip dut ( .dut_if );

  //parameter must be passed as virtual intf
  if_wrapper #(virtual chip_if#(8,8)) if_wr = new("if_wr",dut_if);

Unfortunately, the SystemVerilog preprocessor (svpp) in IUS (6.20-s005) doesn't seem to be able to cope with a virtual interface parameter so this approach can only be used at present with Questa :(

Regards,
Dave

jgg
jgg
Forum Access
25 posts
May 14, 2008 at 2:29 pm

dlong wrote:
The crucial step seems to be in making the wrapper parameter a virtual interface and then using that "as is" within the wrapper (rather than passing simple parameter types and using them to define a virtual interface within the wrapper). e.g.

Yes, without the virtual keyword an interface name is not a type. It is in the same category of not-type, not-variable 'something else' that modules, modports, clocking blocks and interfaces fall in.

That is one of my big hates toward SV, there are too many *different* things. IMHO, modules, interfaces, clocking block/etc/etc all should have been rationalized into an object model, instead of keeping them as a separate 'magic' concept. Modern high level language design has been moving in a direction that magic concepts are bad for a long time.

As we've seen in several threads lately, trying to mix the structure world of interfaces and modules with the dynamic class world is a huge PITA in anything but the most simple of cases.

dlong wrote:
Unfortunately, the SystemVerilog preprocessor (svpp) in IUS (6.20-s005) doesn't seem to be able to cope with a virtual interface parameter so this approach can only be used at present with Questa :(

This reminds me a lot of the early C++ days where compiler writers tried hard to not make a full meta-programming environment in the compiler and it never worked right. It took a long time before C++ compilers were actually expanding and evaluating template code with the full generality of the language. As you observed even things that should work in Questa do not. I've found numerous cases where something that should be statically evaluated based the template parameter does not work, ie something like:

bit [$size(ifi.foo)-1:0] bar;

Bails even though it is statically defined.

At least for C++ the preprocessor approach to templates ended up being doomed as it was never able to fully cope with the generality. The pre-processor would have been as complex as the compiler front end.

dave_59
dave_59
Forum Moderator
10898 posts
May 14, 2008 at 10:55 pm

jgg wrote:

That is one of my big hates toward SV, there are too many *different* things. IMHO, modules, interfaces, clocking block/etc/etc all should have been rationalized into an object model, instead of keeping them as a separate 'magic' concept. Modern high level language design has been moving in a direction that magic concepts are bad for a long time.

This is one of the major reasons I've been on my crusade to get people to stop using virtual interfaces and use abstract classes instead. It's also the reason we don't use program and clocking blocks. There are too many features in the SV language that have been brought in from other languages that might have made sense in their native environment, but no longer have enough value to justify the added complexity they introduce.

Dave Rich

— Dave Rich, Verification Architect, Siemens EDA

dlong
dlong
Full Access
202 posts
May 15, 2008 at 2:45 am

Hi Dave,

dave_59 wrote:
my crusade to get people to stop using virtual interfaces and use abstract classes instead.

Would you care to give us a few clues about how you would use abstract classes to connect drivers and monitors in an OVM environment to the module ports in the rest of the testbench? All of the examples I recall in AVM and OVM use virtual interfaces.

Thanks.
Regards
Dave

jgg
jgg
Forum Access
25 posts
May 15, 2008 at 1:57 pm

dlong wrote:

Would you care to give us a few clues about how you would use abstract classes to connect drivers and monitors in an OVM environment to the module ports in the rest of the testbench? All of the examples I recall in AVM and OVM use virtual interfaces.

Indeed, I know of no way to connect class members to ports, which is part of my complaint about 'magic'. A signal/variable in a class is not the same thing as one in a module :( I've seen a technique where you place both the driver class and the UUT in a new module and then reference the driver class with a path name - but that is still challenging as there is alot more typing and boilerplate involved when compared with a virtual interface.

FWIW, I do use clocking blocks with my interfaces, but it is a PITA. Clocking blocks and interfaces don't work well unless you dedicate the interface to be used only for test benches, and then you need a 'driving' and 'sampling' test bench interface with a corresponding reversal of clock block direction to avoid multiple driver issues - and of course these interface is not compatible with a synthesis interface (though, I think that is solvable by nesting interfaces, but proper *inheritance* would have been so much nicer).

It isn't so much the complexity of the feature that bothers me, but the fact that many of the new features have an incredibly narrow 'possible use'. Outside that you trip into weird things that make no sense as limitations. That is not a hallmark of a well designed general purpose language.

Program blocks are the same, it is a good idea to have a reactive region, but the concept should have been introduced as a decorator for thread spawning: 'reactive always [..]' 'reactive fork [..] join'

dave_59
dave_59
Forum Moderator
10898 posts
May 16, 2008 at 3:10 pm

dlong wrote:

Would you care to give us a few clues about how you would use abstract classes to connect drivers and monitors in an OVM environment to the module ports in the rest of the testbench? All of the examples I recall in AVM and OVM use virtual interfaces.

OK, here you go. This example demonstrates the following principals
  1. An abstract class is essentially an API defined using pure virtual methods that represents a contract between the user and implementor.
  2. The implementor extends the abstract class into a concrete class by providing the implementations for the methods that directly access the module/interface port/signals.
  3. The concrete class in defined inside a module/interface. Each instance of that module/interface in turn creates a unique class extension.
  4. Each extension is registered with the object factory. The driver either "knows" which factory object it needs, or the instance override can set which driver needs which instance.
I tried using set/get config objects instead of using the factory, but the factory was a little less code.

Dave

— Dave Rich, Verification Architect, Siemens EDA

dlong
dlong
Full Access
202 posts
May 17, 2008 at 8:14 am

Hi Dave,

Thanks for that - it's an interesting approach. I also like the fact that you can give an interface a TLM API without needing import/export functions through a modport.

On the negative side, there does seem to be a danger that functionality that belongs in the class-based environment could "slip" into the interface instead, limiting reuse. The other issue is that since modules and interfaces do not support inheritance, creating a set of SV interfaces with additional "interface methods" (in the Java/C++ sense) could be a lot of work - you would need to create a new abstract class and create each interface from scratch.

Regards,
Dave

dave_59
dave_59
Forum Moderator
10898 posts
May 17, 2008 at 8:56 am

dlong wrote:
Hi Dave,

Thanks for that - it's an interesting approach. I also like the fact that you can give an interface a TLM API without needing import/export functions through a modport.

Even better, your driver can be designed to work without any SV interfaces at all, making it easier to cross SV/SC/C++ borders.
dlong wrote:

On the negative side, there does seem to be a danger that functionality that belongs in the class-based environment could "slip" into the interface instead, limiting reuse. The other issue is that since modules and interfaces do not support inheritance, creating a set of SV interfaces with additional "interface methods" (in the Java/C++ sense) could be a lot of work - you would need to create a new abstract class and create each interface from scratch.

There's no need to define the class inside the interface. It just can't be in a package where hierarchical references are not allowed. See the paper at the beginning of this thread and the example at the end of that thread.

Dave

— Dave Rich, Verification Architect, Siemens EDA

Hellen Gong
Hellen Gong
Forum Access
2 posts
November 05, 2008 at 6:08 am

but I've been using parameterized interfaces quite a bit and the working approach I use is to make the class parametric on the interface type:

[code]
class if_wrapper #(type my_if_t = int) extends ovm_object;
my_if_t v_if;
[..]
endclass;

Foo_intf #(.BAR(10),.GAR(11)) intf;

if_wrapper #(virtual Foo #(.BAR(10),.GAR(11))) wrap = new("intf",intf);


Hi
[=Times New Roman][=3]I use parameterized interface, and make the class parametric on the interface type as your approach. But the ModelSim [=3]Additionally, If the ports and exports are declared by avm_*_port and avm_*_export, and connected them by connect function, of course, the ports and exports have been instanced, in run-time, ModelSim [FONT=/>

Hellen Gong
Hellen Gong
Forum Access
2 posts
November 05, 2008 at 6:19 am

... but I've been using parameterized interfaces quite a bit and the working approach I use is to make the class parametric on the interface type:

[code]
class if_wrapper #(type my_if_t = int) extends ovm_object;
my_if_t v_if;
[..]
endclass;

Foo_intf #(.BAR(10),.GAR(11)) intf;

if_wrapper #(virtual Foo #(.BAR(10),.GAR(11))) wrap = new("intf",intf);



Hi
I use parameterized interface, and make the class parametric on the interface type as your approach. But the ModelSim <?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" />6.3f gives run_time errors: Null instance dereference, the ports and exports are declared by tlm_*_if, and they are connected by assignment.
Additionally, If the ports and exports are declared by avm_*_port and avm_*_export, and connected them by connect function, of course, the ports and exports have been instanced, in run-time, ModelSim 6.3f said the port to export and the export to fifo export did not connected.
I can not figure out why it happens.
Thanks a lot!
Best Regards!
Hellen Gong

dave_59
dave_59
Forum Moderator
10898 posts
November 05, 2008 at 10:51 pm

Hi Hellen Gong,

It sounds like you have been using AVM 2.0 style port connections which are not compatible with AVM 3.0 port connections. (By the way, the AVM 3.0 port connections are the only kind of connections that are supported in the OVM)

You did not give enough information about the errors you are getting for me to help you. Try attaching a small code sample we can compile.

Dave Rich

— Dave Rich, Verification Architect, Siemens EDA

Michael D Scott
Michael D Scott
Full Access
43 posts
March 07, 2012 at 12:19 pm

In reply to dave_59:

I will admit to not reading the whole thread- but I got errors out of Questa for unconnected virtual interfaces that exist on agents I am not even instiating in my test. I have a compile scripts which compiles all my files, regardlessof the test. The block tests use a small subset of these agents.

I was then using custom compile scripts which only compiled files that were needed. This was a pain and unmanageable.

I addded the permit_unmatched_virtual_inf option; and now I can use my one comple script for my blocks tests in addition to my system test. Thanks.

Definitely seems like this should be the default-- especially for uninstantiated objects.

dave_59
dave_59
Forum Moderator
10898 posts
March 07, 2012 at 1:45 pm

In reply to wpiman:

wpiman,

You might want to think about putting the code for your agents in separate packages. See http://verificationacademy.com/uvm-ovm/Package/Organization. You can compile all your packages all the time, but only the packages that get imported will be analyzed for this consistency.

The problem with virtual interfaces is that references via virtual interfaces treat the interface as if it were a class type. The compiler needs the type information in order to generate code around those references, and it doesn't know without very expensive analysis that the code is unreachable. The switch says "I know what I'm doing" and you are one your own for any weird behaviors that come out of it.

— Dave Rich, Verification Architect, Siemens EDA

baridude
baridude
Forum Access
13 posts
March 19, 2012 at 8:55 am

In reply to dave_59:

Hey Dave, I was searching the forum for something else and hit upon this old post which touches on a topic about which I've been curious. Over the years I've heard mostly vague references to people recommending against using program and clocking blocks. I recently did a web search but could not find a single source article with pros and cons listed. I was hoping there would be a Cliff or Stu paper, but could not find one. Do you know if such a paper exists? or has there been a thread on this topic in one of the verification forums?

Thanks,
ericm

dave_59
dave_59
Forum Moderator
10898 posts
March 19, 2012 at 9:58 am

In reply to baridude:

Eric,

I have this article on program blocks. Coincendently, there was this recent post as well on the VerificationGuild.

If you notice, all the OVM/UVM examples simply ignore them, which I take to mean the committee didn't feel they were necessary either.

As for clocking blocks, there is one useful application for making it easier for the testebench to procedurally assign wires. I wrote about this in a recent DVCon paper.

— Dave Rich, Verification Architect, Siemens EDA

Sumeet Jain
Sumeet Jain
Full Access
4 posts
November 20, 2016 at 7:02 pm

Hello,
I am a new member facing the same virtual interface problem.
I was looking at the solution to this but i don't actually get it when you say turn the -permit_unmatched_virtual_inf flag true.

How do I turn this flag true?

Note: I don't have a parameterized virtual interface
: I don't usually use tcl command. Let me know if typing some command help me solve this run time error
EX- class generator
....
..
Virtual intf i;
..

endclass

Thanks

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