dave_59

You must import a package or explicitly reference a symbol in a package if you want to use it. Importing a symbol just means you don't have to prefix the symbol with the package name (i.e. pkg_name::symbol_name) The biggest problems we see with packages related to random stability are caused by static variable initializations that call class constructors. You either have a class variable in your package that is statically initialized, or there is a static member of a class that is statically initialized. The ordering of these initializations is not deterministic. (http://www.parashift.com/c++-faq/static-init-order.html). What makes it even worse is the unanswered question: "if I compile my a package and nobody references it, does it exist?" meaning do the static variables exist and call functions/constructors as part of their initialization. Tools have different ways of handling this.

Within a non-static class method, randomize() and this.randomize() are the same method call. You can think of any method call as having an implicit this argument. method_call() is really method_call(.this(this)) and obj.method_call() is really method_call(.this(obj)). The scope of the randomize() object is the this argument inside the randomize method and that is the object whose constraints are to be met. std::randomize is just a function in a package, it is not a method. The only constraints it observes are the one specified by an optional with clause or if the variable being randomized is itself a class object with constraints. You are not restricted to randomizing variables in the current scope, and they don't even have to be class members. It just randomizes what ever variables you put into its argument list. So std::randomize(count) randomizes an int with not constraints since count is not a class variable. std::randomize(this) would be the same as this.randomize() or just randomize(). The scope containing the call to obj.randomize() statement has significance when you have variables with the same name in both the calling and the object being randomizes scope used in a with clause constraint. The with clause assumes the constraint refers to the object being randomized first. If it can't find it in that object, it then searches for that variable in the scope where the call to randomize took place.

Please copy the file to the correct location if you install 10.0c and use UVM. With later releases the file should be in the correct place. The missing files are: <install>/<uvm_dir>/win32/uvm_dpi.dll The <uvm_dir> names are: uvm-1.0p1, uvm-1.1 and uvm_reg-1.1. The files are located at: <install>/win32/<uvm_dir>/uvm_dpi.dll Please copy the files to the correct location: <install>/<uvm_dir>/win32/

There is an installation problem with Questa 10.0c only on Windows. Please read this note. Also note that this version of Questa is 2 years old and relative for UVM contains a very old version of it.

There's a difference between a data type and a variable or expression of a certain data type. It's only the type (i.e. typedef) that is not allowed to be dynamic. You can use it on a dynamically sized variable, and in this case, a member of a class.

Sure, Instead of using this for the context of the uvm_config_db#()::set(this,...), you can use null, uvm_root::get(), or use find() to get a higher level context. As long as the get() call is in a later phase than the set() call, this should work.

You're much better off post-processing this in a PERL/AWK/SED script.

Just because a phase is there doesn't mean you have to use it. Some of these phases were added just for "symmetry" but have no real value to most users. Mentor's suggests that you stick with a single run_phase and use combinations of sequences to encapsulate the different facets of your test.

See https://forum.verificationacademy.com/forum/verification-methodology-discussion-forum/ovm-forum/28735-connect-driver-ported-interface-modport

You never store a class object in a class variable. It's always the class handle to the class object that is stored in the class variable. Both examples store class handles in an array of class variables. The first example stores a class handle in an intermediate class variable (obj1) before making an second assignment of the intermediate variable to an element of the array (obj). Each time through the loop creates a new object whose handle is stored in each element of the array. The second example stores a class handle in an intermediate class variable (obj1) only once. Then each time through the loop you assign a new object handle to an element of the array (obj) and then overwrite the handle with the handle stored in obj1. So at the end of the loop, you have 5 elements of the array obj referencing a single object. I think what you want is this: ex_obj obj[5]; foreach (obj) begin obj = new(); end

I'll bet you are trying to make a procedural assignment to a wire. That is illegal. See my DVCon paper "The Missing Link: The Testbench to DUT Connection" about handling bidirectional signals in a testbench.

Here are some UVM examples. https://verificationacademy.com/cookbook/Factory The factory pattern is a common Object-Oriented coding pattern. Do a search for it.

FYI, The SystemVerilog LRM is now available at no charge thanks to Accellera. http://go.mentor.com/get-1800

FYI, The SystemVerilog LRM is now available at no charge thanks to Accellera. http://go.mentor.com/get-1800

No, only with the time consuming phases. My point was that knowing what phase you are in could be used for something other than objections, not that I was promoting its use.

Cliff, The older syntax is already deprecated - it's only there for backward compatibility with OVM. You will create confusion if people assume that connect and connect_phase are just syntactic synonyms for each other and people start extending their classes with connect() from classes already using connect_phase()or vice versa - these methods will not be called in the right order. I can see some purpose in using the phase argument when calling common routines for reporting or debugging to know which phase you were called from.

The factory pattern does not allow for extra or different types of constructor arguments . The UVM provides two factories: one for classed extended from uvm_object with one constructor argument, and another factory for classes extended from uvm_component with two constructor arguments. The reason for this is because the create() method is delegating the construction of a class object through a number of intermediate classes and methods and it has to pass the arguments though these methods using a predetermined set of arguments. You could build your own private factory for classes with different kinds of arguments, but you would need to replicate it for every different kind of constructor prototype. But even without using the factory pattern, it's still not good practice to add extra arguments to a class's constructor. You can wind up with whats called a bloated constructor. For every argument you add, the class that constructs your class has to deal with the added argument, usually through another argument to its constructor. The upper level classes wind up with huge lists of arguments. The UVM way to handle this is to use the configuration database. That way you can localize the dependencies on the on the data a class object needs without involving the intermediate classes in the hierarchy.

Normally what you do is define a virtual method in the base class to access the additional fields in the extended class - you never access class members directly. These are the do_copy, do_compare, and do_print, etc. virtual methods in the UVM. You better explain what you are eventually trying to do because if every class extension has exactly one extra member, there is really no need to extend the class, just put the test variable in the base class. Or why not use a simple array?

Hi Cliff, Didn't you write a paper on this? If you use stop_request() and/or global_stop_request(), then you will need to use the plusarg +UVM_USE_OVM_RUN_SEMANTIC, otherwise your testbench will end prematurely without awaiting your stop_request().

First, there is no need to declare tr as a ref argument. tr is already a class variable that references a class object. Use 'input A tr' or simply 'A tr' instead. What you put as the actual argument to a ref, output, or inout argument must all be "writable". 'this' is not a variable and cannot be written to. The keyword 'this' is a special reference to the object used to invoke the method that 'this' is used from within. See this link about when you should use ref arguments: https://forum.verificationacademy.com/forum/verification-methodology-discussion-forum/systemverilog-and-other-languages-forum/29572-passing-arguments-reference#comment-29573

It is on the same page where you go to download Questa.

Can you show the complete definition of foo? Where is the 'function' keyword. Is it a static method? You can only use 'this' inside a non-static method of a class. If it is not static, can you show the actual error message you are seeing?

What I was suggesting is that you change the declaration of data_from_file to be a static variable, just simply move its declaration outside the class.

Have you tried using $fread in a simple Verilog module to see if there are any OS related issues? Or its possible that $fread requires the receiving variable to be statically allocated.

See http://go.mentor.com/ready-for-systemverilog-2012 for an easy way to do this in SystemVerilog 2012. Otherwise there's a link to a solution using the existing syntax.