dave_59

Erling, I like your solution. What you have just described is essentially making MyDrv an abstract class without explicitly using the keyword "virtual" in front of the class declaration. In both cases you have to extend MyDrv to get a working driver implementation. Adding "virtual" to the class means that the compiler could check that it was never constructed directly, but then you would not be able to register it with the UVM factory. The other thing it does is keep all the signal and timing related references inside the interface or module where the class is declared. This eliminates all the indirect references that normally would be through a virtual interface reference. Dave

Because it is a more elegant solution. This is a standard OO programming patern and it means you don't have to have an RTL interface around if you don't need it.

Although you didn't mention it, I assume that your problem is because both driver and monitor class are referencing the same virtual interface. Unless the compiler has some very sophisticated dead code analysis, it not going to know that that your driver is not going to be used - especially if the driver is registered with the factory. I'll use this as another plug to get people to think about using abstract classes instead of virtual interfaces to connect to the DUT. See the following papers http://www.dvcon.org/2010/proceedings/papers/06_1.pdf http://www.dvcon.org/2011/proceedings/papers/01_4.pdf http://ovmworld.org/forums/showthread.php?100-OVM-wrapper-for-Verilog-Bfms&p=350#post350 Dave Rich

clone() means construct followed by a call to copy(). clone() is virtual so that you can construct the same object type as the one you started with. clone() calls copy() to perform a deep copy of the object type you just created. The copy() method by itself just copies class member values from one object to another. Normally, the copy() method only copies the class members for the current class type, then it calls super.copy() to copy the class members of the base class.

der57. I agree with you 100% See http://go.mentor.com/a-time-for-change .

The text you quoted in 13.3.2 seems to be leftover from Verilog-2001, which introduced automatic tasks, but not automatic variables in general. That section should be deleted and what is stated in section 6.21 Scope and lifetime should apply instead: In your example, the task foo is the enclosing scope that includes a fork-join block. The compiler will extend the life of taskArg to inclide the like of the nested fork/join block. It can do that because it can statically (i.e. at compile time) determine the dependencies. It can't do that across a task call. Dave http://www.eda.org/svdb/view.php?id=3548

First, you should be using the pre-compiled UVM package released with Questa 10.0a. See http://go.mentor.com/uvm1-0-questa Yes, there was a compiler performance bug with the UVM 1.0 in Questa 10.0a and 6.6d. It has been fixed in Questa 10.0b (soon to be released), Questa 6.6e (already released), as well as the next release of the UVM.

Erling, The UVM EA kit was an early adopter release -- a work in progress, not for production use. The body() method in ovm_random_sequence correctly turned turned the pick_sequence constraint off in ovm_sequence_base. Then, uvm_sequence_base added the c_randomized constraint, but uvm_random_sequence forgot to turn it off as well. This section of the UVM (the sequence built-in's) had no examples/tests to catch this error, and is now deprecated, so I guess you are left with one of my suggested workarounds, or modify the source yourself.

Erling, See the LRM section 18.11 In-line random variable control. When you call randomize(i), all rand variables in MySeq (including the is_randomized bit in uvm_sequence_base) become state variables except for i. All constraints remain enforced, so the c_randomized constraint is not able to set the is_randomized bit to 1. Not knowing what you are really trying to do, there are a number of things you could do: is_randomized = 1; before calling randomize(i) c_randomized.constraint_mode(0); before calling randomize(i) call randomize(i,is_randomized) call std::randomize(i) with {your_constraints};

Another option, depending on how much you need to selectively control the report options, is to use the report handlers from higher level components in the lower levels: class my_agent extends uvm_agent; function void build_phase(uvm_phase phase); my_driver_h = my_driver::type_id::create(...); my_driver_h.set_report_handler(get_report_handler); ... endfunctionIf you do this, you will no longer be able to selectively modify the reporting options for all messages in your driver. You still have the ability to controll messages by IDs.The other option is to create separate logging objects that are disconnected from the hierarchy: class my_driver extends umv_driver; uvm_report_object log = new("some_shorter_name"); function void some_function(); `uvm_info_context("myid","my message here", UVM_LOW, log); end

There is a Questa 6.6e release that might fix your problem. Questa 10.0a is the latest release and was the first release to incorporate the released UVM-1.0p1 directly. You should look at this article and try to run the example with the pre-compiled UVM package Otherwise contact Mentor support directly.

This is not a language question. See +uvm_set_action in the reference manual +uvm_set_action=uvm_test_top.*,_ALL_,UVM_WARNING,UVM_NO_ACTION There is no way to get a list of message types that have been masked other than querying the severity-id pairs individually. I would not recommend this approach as you would now be using the report handler as a configuration mechanism. Instead, use the configuration mechanism to drive the report settings.

Because the UVM was deigned by committee and committees love to have more than one way of doing anything (Sorry, could not resist) I think the idea was that at some later point, the UVM might include more than just a UVM package. Technically, the UVM macros are not part of the UVM package, but are needed to compile the package anyways. Dave

An easier mechanism is using the string ID field, the first argument to any message, with set_report_id_action() to ignore messages with particular IDs.

RC, you are using a beta release that is not supported. Please download the latest version: 10.0a.

If you are using a release prior to 10.0a, then you must follow the directions Building the UVM DPI Shared Object Yourself setting $UVM_HOME to the location where you downloaded the Accelera kit. Questa 10.0a was the first release that included the Accellera kit. Dave

Mike, This is exactly what we recommended in the OVM. Use only config objects, not ints or strings. Use uvm_object as the base for your config class; components have much more overhead associated with them. You should not call xx.build() directly because the scheduler inside the UVM kernel will do that for you at the appropriate time. Dave Rich

The makefiles will be updated in the next release of the UVM. Please see http://go.mentor.com/uvm1-0-questa.

The `uvm_field_**** macros are the field automation macros, where **** are a certain subset of data types. They are supposed to save you some amount of code writing by performing certain operations for you, get_config being one of them, along with printing, copying, pack, and unpack. I normally do not recommend using them because I like seeing the code, and there can be a lot of overhead in the code the macro invokes. See Parameterized Classes, Static Members and the Factory Macros. By the way, the paper I reference just won "Best Paper" as this year's DVCon. Dave

The UVM_READONLY setting only applies to operations performed by the field automation macros. Anything you do manually is not affected by the field macro settings. BTW, since this is inside an uvm_component, get_config_int would have been implicitly called if you had not used UVM_READONLY. Dave

4th option, just seq.start(seqr); in your test.

Please see http://go.mentor.com/uvm1-0-questa for instructions for running Questa 10.0a with the UVM.