dave_59

You probably need to explain what the useful thing you want to do if you did know. There's probably a very different way to approach it. Also, are you aware of the difference between X.get_object_type() versus classX::get_type() if you have ClassX X; X = ClassX::type_id::create(...); if (ClassX::get_type() != X.get_object_type()) // then you know X has an object whose type is an extension of ClassX

I'll repeat what I posted earlier in other words: If you are starting a UVM verification environment from scratch, there is no reason to use anything outside the UVM standard that accomplishes what is inside the standard. Using the UVM_REG is a no-brainer decision.

my_comparator.set_report_severity_id_override(.cur_severity(UVM_WARNING),.id("Comparator Mismatch"),.new_severity(UVM_ERROR)); should have worked. What did you do?

You are much better off using the factory over parameterized classes so you can take advantage of dynamic polymorphism(i.e. virtual methods). See my DVCon paper on the subject. It is always easier to pass around unparameterized class handles that trying to deal with specialized parameterized class types.

You can, but not directly. When you register a parameterized class with the factory using the the `uvm_object_param_utils macro, it does not register a string name with the factory, only by type. Therefore you can only create or override these classes by type. I see two possible options: You create your own string mappings using an associate array. uvm_object_wrapper type_lookup_by_string[string];type_lookup_by_string = '{"myseq1_4":myseq#(1,4)::get_type(), "myseq2_8":myseq#(2,8)::get_type()};...factory.create_object_by_type(type_lookup_by_string["myseq2_8"],...); You register the class with the factory using the uvm_object_registry class and provide a string mapping there. See the probe class in my DVCon paper. class myseq #(int A, extends uvm_sequence;typedef uvm_object_registry #(myseq#(A,),$sformatf("myseq%0d_%0d",A,) type_id;...factory.create_object_by_name("myseq2_8",...);

Cygwin releases very frequently - the cygwin.dll has gone from 1.7.9 to 1.7.15 in the past two months. For this reason, Questa is not officially supported on this platform. BTW, this just happened to me a week ago on my own laptop and I just uninstalled/re-installed Questa and the problem went away.

There is no need for a vif container in UVM. You can use the uvm_config_db directly. uvm_config_db #(virtual myinterface)::set(null, "uvm_test_top", "my_vif", myifinstance); See http://verificationacademy.com/uvm-ovm/Config/VirtInterfaceConfigDb more complete examples.

The questa_uvm_pkg, which is released with Questa, can dump the UVM structure in XML. This package is used in addition to the uvm_pkg released by Accellera.

You will have to show the complete error message. It's possible the version of the tool you are using has a problem. It works for me in Questa.

Yes, if you are already using clocking blocks, then program blocks add no value. The UVM provides a much better end-of-test mechanism with objections. I suppose I never considered the case you mentioned as I usually only see one program block if any in someones testbench.

None of our examples at http://verificationacademy.com/uvm-ovm define the test classes in program blocks. In fact, we do not even recommend the use of program blocks. We recommend that all testbench classes be defined inside packages, and you use the factory to select which test to run using +UVM_TESTNAME. That way you never have to re-compile your simulation in order to select or add a new test.

The problem is that by default, task arguments are copied by value when you enter the task, and that argument is a local variable to the task. You should change your task argument to a ref. virtual task check_dut (ref logic aaa_logic_clk) repeat (10) @(posedge aaa_logic_clk) endtask Then the code inside the task will see value changes from the variable outside the task.The reason that your example 1) works is because the value of a virtual interface variable is a handle, which is already a reference to an interface instance. So copying the handle value in a local virtual interface variable still points to the same interface instance.

See http://go.mentor.com/uvm1-0-questa

That's fine as long as it documented. If you start doing this too often, consider using configuration settings or making a sibling class as this jumping around will become hard to follow through many layers of inheritance.

No, it's just that the classtype::method syntax is usually the only way to access the identifier of a static method.

You should have a very good and well documented reason for doing this. The syntax is class0::method()..

Maybe this will help: http://verificationacademy.com/forum/verification-methodology-discussion-forum/uvm-forum/22389-psequencer-msequencer

Yes, you can call the write method of an analysis port from a sequence that was declared in some other component class, but you can't declare the analysis port inside the sequence.

No, you cannot. All TLM ports must be connected before any sequences start. You can put a port in the sequencer that you can reference from the sequence. I don't remember, but the sequencer may already have analysis ports that you can connect up that write out what is being sent to the driver.

Sean, So far, no one has requested that the friend construct be added to SystemVerilog. SystemVerilog is derived from Java, which does not have the concept of friends. Do a search for "Friends in Java" and you will see the proper way to deal with this issue. Many times I see people forget that a member is always a friend to a class of the same or derived type. For example class Packet; protected int i; function integer compare (Packet other); compare = (this.i == other.i); endfunction endclassThe reference to other.i is allowed because other is the same class type.Another problem is the fact that the OVM/UVM was designed without the use packages in mind, mainly because of inconsistent SystemVerilog implementations at the time. Everything in is one giant monolithic package, so importing uvm_pkg exposed everything unprotected to the user.

Uwes, Again, your code will only register one string "my_test" for all specializations and will generate an error if there is more than one specialization. Dave

The typedef mentioned by mea1201 will register one string name for all specializations of my_test, and will be an error if there is more than one. You could do typedef uvm_component_registry#(my_test#(item_t, NUM_ANALYSIS_PORTS), $psprintf("my_test_%0d",NUM_ANALYSIS_PORTS) type_id;You need to realize that when you declare a parametrized class, it is only a generic template, not a real type. You need have a reference to a parametrized class for it to become real type, a specialization. The only strings that will be registered with the factory are the one that are associated with a specialization.

I think you are out of luck with the existing library, unless people name give instance names of all their fifos you can match.

Since tlm_fifo is not registered with factory, you can use uvm_root::find_all() to get a list of all components, and then iterate over the list using $cast() to select the types you are interested in.

Here is a link to Mentor's UVM Cookbook. You can read it online, or there are PDF book versions of it you can print.