dave_59

Yes, m_root/parent/children are not instances of xxx_register, they are class variables that will contain handles that reference class instances of xxx_register. SystemVerilog does not have pointers like in C/C++. A pointer is an address that references a location in a uniform memory. A handle is an abstract concept that references a particular class instances. There is no way to see the value of a handle; you can only see what it references.

This is how you build a linked data structure. See http://www.slideshare.net/geeksrik/trees-data-structures-in-cjava. This seems to be redundant as uvm_component already these class members.

Yes, you could consider the initialization of all static variables as a separate "initial" procedural thread that executes before any other, but there is still no defined order of execution for the static initialization code within one design element. Not saying it couldn't be done; it just hasn't yet.

1) It's not legal because size is a method, not a random variable. The solve-before constraint only works with random variables. 2) It's not needed because the ordering is already implicit. See the LRM section in iterative constraints on arrays.

Do a search for "stop VHDL simulation modelsim" there is lots of information out there.

VHDL 2008 added a package STD.ENV that contains stop and finish functions just like Verilog. This package can be used even if the VHDL is not compiled with -2008. http://www.doulos.com/knowhow/vhdl_designers_guide/vhdl_2008/vhdl_200x_small/#env

You probably need to explain a little more what this flag is for. There may be other mechanisms in the UVM to do what you need. You should not be using the configuration data base as a synchronization mechanism.

Rather than setting and getting values from the configuration database, it is much more efficient to create a configuration object, use the configuration database to set and get a handle to the object once, and then modify the configuration object members as needed. See https://verificationacademy.com/cookbook/Config/Overview

The only requirement is that you do a set before a get if you want to get what you set. If you do both in the run_phase, then you need some other synchronization mechanism.

Ajeetha, You are unwittingly helping my case. Most users are completely unaware of the 1000s of lines of code these macros invoke. Yes, the performance has improved since the OVM code base, but that is only one of many issues we see users all the time with these macros 1. Auto configuration differences between uvm_components and other classes 2. restrictions on the available field data types 3. hard coded limits placed on all integral types, and packed representations of classes that must be changed for all integral fields. Bhunter, I don't see the efficiency of the UVM improving anytime soon. All I see the committee is adding new features, or replacing features with re-architected features. I don't see any work to make the existing features more efficient keeping the existing API.

Hi Cliff, I don't think they're easy to use when I see problems like this at least once a week. https://forum.verificationacademy.com/forum/verification-methodology-discussion-forum/uvm-forum/29427-uvmconfigdbset-method-does-not-work

Hi Cliff, As you may know from the DVcon2011 Best Paper, there are many people who do not recommend the use of the field automation macros at all. Dave http://www.businesswire.com/news/home/20110308006709/en/DVCon-2011-Announces-Paper-Reports-Significant-Attendance https://verificationacademy.com/cookbook/MacroCostBenefit

Look at using the inside operator to match a value in an array. That array can be a list of instructions. You can have different arrays that represent different lists of instructions, and then use the inside operator to find out which list a particular instruction matches. Again, try to describe what you want to do without using any SystemVerilog syntax. What defines an instruction? Don't use the word enum or typedef.

There are no dynamic types in SystemVerilog except for class variables. Perhaps you are going about this the wrong way. May you need to build lists, associate arrays, or queues instead of trying to use enums. Can you describe some of the operations you want to do with i?

Can you show ALL the declarations for your code. Just guessing, perhaps you meant int i[]; typedef enum{tx_0=3,tx_1=5,tx_2=7,tx_3=11 ) tx_t; function void my_func(bit [1:0]a) case(a) 0: i = new [tx_0]; // line 0 1: i = new [tx_1]; 2: i = new [tx_2]; 3: i = new [tx_3]; endcase endfunction Can you explain without using SV syntax what you want to do?

First, you should never get an internal error from any tool. Contact Mentor directly with more details about the platform/OS you are using and the command line used to invoke the tool. It also help to show as much as possible in the output before the error occurred. Second, You can not use `uvm_do_ with Modelsim because it calls abc_seq.randomize(). You need Questa to do that.

Robert, Although this style seems handy and works in some cases, there are a lot of issues around it that need to be resolved. What you are asking is for a static initialization to behave like an initial block, yet all static initializations are supposed to execute before any initial blocks. Regardless of any LRM issues, coding this way creates a problem for guaranteeing random stability for all classes constructed this way.

A fork/join_none is not allowed in this context because there is no thread calling the function from initial/always block.

http://tinyurl.com/uvm-list-of-bugs

As soon as you ask for a single testbench hierarchy, that implies testbench interaction like phasing and end-of-test. That cannot be done without converting the OVM components to UVM first. If you can keep the components in two separate testbench hierarchies and never have any code that imports both OVM and UVM in the same scope, that can be done. You will have to call ovm_pkg::run_test() and uvm_pkg::run_test() separately as well.

Your classes can be parameterized using the same parameters as your DUT. It would be great if both DUT and testbench can share a set parameters defined in the same package.

A local method is only available to methods of the same class. You cannot initialize a static member by calling a local method. Instead try local static singleton me = singleton::get(); P.S local constructors have always been in the IEEE 1800 standard and has been supported Questa.

It's not legal. Static initialization occurs before any initial or always processes start, there is no process to fork from. Also, there is no guaranteed ordering of static variable initialization. A better solution is to have a an access function get_dummy that retrieves the value of _dummy and initializes it if is not the default value. In your case the initialization is the default value, so it serves no purpose.

From my perspective, I consider the first release of the UVM 1.0p1 a beta release. I strongly suggest you move to 1.1 or later (1.1c was released a month ago).

No, use the run_phase in your receiving class. class receiving_class extends uvm_component; uvm_tlm_analysis_fifo #(T) a_fifo; uvm_tlm_analysis_fifo #(T) b_fifo; uvm_tlm_analysis_fifo #(T) c_fifo; uvm_blocking_put_port #(T) up_level_port; task run_phase(uvm_phase phase); T a,b,c; forever begin fork a_fifo.get(a); b_fifo.get(; c_fifo.get(c); join // figure out what you want to do with a, b, or c .... up_level_port.put(a_or_b_or_c); end endtask endclassThis is essentially what is inside the uvm_in_order_comparator.