dave_59

The reference module should be part of the scoreboard or between the monitor and scoreboard. You might want to check out the Verification Academy section on scoreboards for some examples. http://www.verificationacademy.com/uvm-ovm/Tour/Analysis

Zeno, For 1) you will need to contact Synopsys or Mentor to get the recently released VMM 1.2.2 version that is SystemVerilog compliant to run on all simulators. For 2), your test most likely has a static class variable that initializes with a call to its constructor . Get rid of that static initialization and call new() in an initial block instead. Dave

There is no such restriction in the LRM.

I would add that parameterized classes cannot be handled using the string based factory access IF you use the macros. See http://go.mentor.com/mcem for an example that show how to register a parameterized class with a string.

You cannot use this as a context inside a sequence; you must rely on the full sequence name. uvm_config_db#(reg_model)::get(null, get_full_name(), "register_model", model);

If you have a cyclic randc variable (btw you forgot to declare a as rand), only type 2 will work. As far as distributions are concerned, it should not matter. Solutions are produced based on probabilities without considering previous results. Type 2 is also good if you have non-rand state variables that are used in your constraints. If you mean type 2 is harder to do factory overrides dynamically, yes that is true.

See http://go.mentor.com/uvm1-0-questa. If that doesn't help and you're trying to run an existing example, you'll need to contact Mentor support with more details about the specific OS and gcc versions you are using.

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

That's not what the code does (from AVM->OVM->UVM). It counts messages of all report IDs. Does there really need to be a way to control counting of messages separate from stopping on reaching max_quit_count?

The action UVM_COUNT is not really whether to count, but whether to stop on count reaching max_quit_count.

The next scheduled release of UVM is slated to occur sometime before DVCon’12. If enough bugs accumulate, they may issue an interim release, but right now the committee is not at that point yet.

Perhaps this is a different UVM bug. See http://www.eda.org/svdb/view.php?id=3666

The key problem with new() is that you cannot override it, you can only extend it. The extension functionality must always be appended to the base class functionality because super.new() is implicitly or explicitly the first statement of any extended new function. build has none of those requirements; you can put a call to super.build anywhere in the extended build as well as not all. BTW, UVM now uses build_phase() instead of build.

Yes, the create() method just delegates construction by the factory, and eventually calls new() based on what factory overrides are in effect. Calling new() is the only way to construct a class object(component).

Uwe, Random stability issues are a natural part of any testbench environment that one has to deal with, just like race conditions, and process synchronization. Any language has to balance “stability” with “randomness”, i.e. you don’t want every object generating the same series of random numbers. It's difficult for a compiler to know a priori which is needed. A similar problem exists when performing a deep-copy: the user needs provide knowledge about whether references are to remain references, or need to be cloned. There is a simple, brute force way of dealing with this in the UVM when you don’t want a method to disturb the random generation. A push/pop of the internal random state inside every method call using the get_randstate/set_randstate functions can preserve stability. Doing that inside every method would be a lot of overkill, so it would best to understand what conditions disturb the random state and only apply it where needed. Dave Rich

Random stability in SV is easy to maintain if you are aware of the issue, know what causes instabilities, and have a test plan for detecting it. That needs to become a higher priority for the UVM than adding new features.

I think you may have introduced an infinite loop because the report server will try to construct an object as well. Try single-stepping to confirm. See if using a simple $display works better. This will produce an enormous amount of output.

OVM 2.1.2 is now available for download This release contains 13 bug fixes. Refer to the release-notes.txt file for complete details. You can download the release from the Verification Academy.

Erling, If you do a wildcard import of a package, that package has to exist, and the static initializations inside that package must be executed. I believe that should be a portable solution. The question that usually comes up is what happens if I have a package with static init's and there is no mention of the package anywhere. Let's say there are two packages (A and with static init's in a single file. I compile that file, but only import package A. There is no reference to package B anywhere else in the design. Will the init's in package B get executed? That answer is tool flow dependent. With Questa, and other tools that support a separate compilation flow, the answer is the same as what happens with modules: a module will be loaded into a design if there is a reference to it and the module that references it contained in the design. As part of the elaboration step, you need to tell the tool the top-level modules and packages that should be loaded into the design, and it will recursively descend through the design to find the other packages and modules that need to be load in as well. Dave

The is really a SystemVerilog question, not a base class library question. Next time please use the appropriate forum. A task or function call does not create a new process; it is executed by the same process that calls it. Some people think that the task calls below are creating new processes: fork task_call1; task_call2; join But the way to read this is that each statement inside fork creates a new process. In this example, a process is created for each statement, and then each process executes a task call.

The specialization of any parametrized class, whether it is a typedef or the declaration of a class variable, creates the space for all static variables once the type exists. There is no need to construct an object of that class type; all the static variables of all class types are initialized at time 0 before any always or initial blocks execute. See section 8.24 of the 1800-2009 LRM

Didn't I just answer this question for you here: http://www.uvmworld.org/forums/showthread.php?239-when-is-the-const-uvm_root-uvm_top-uvm_root-get%28%29-executed&p=859&viewfull=1#post859

I mean any reference to a package by name implies that the package exists. The LRM says "The compilation of a package shall precede the compilation of scopes in which the package is imported." When you do a wildcard import, you have to look inside the package to build a list of candidates to imports, or identify collisions with wildcard imports from other packages. To do that, the package must exist. But what does existence mean to a simulation run? Certainly you have to compile it, but not everything you have ever compiled is included in a simulation run.

As a static variable initialization, it is executed at time 0 before any initial or always block gets executed. Note that the ordering of static variable initializations is never guaranteed, so you should never reference another static variable in any other static variable initialization.

See http://go.mentor.com/programblocks