dave_59

We strongly recommend that you do not override uvm_report_server for two key reasons: Only one entity can effectively override uvm_report_server to achieve the formatting they want. If you try to combine code from multiple entities (from within or outside your organization) that try to override uvm_report_server, things will fail miserably. Many vendors tightly integrate the uvm_report_server with their tools. Messages get recorded so that they can be displayed with the waveforms and hyper-linked to their location in your source code. Overriding may break that integration. A better options would be to post-process the log files to get the format you want. Otherwise I have no idea why the performance has degraded other than because of something in your code.

The mantis was never field. I entered 0005047 uvm_component:::do_flush is not documented RefGuide - 2014-10-21 23:12

You need to contact Mentor support. Other people have gotten this to work.

I think the Makefile.questa in the top-level examples directory is not correct. See this

Roman, I suspect the problem is the version of C compiler you are using to compile the DPI code. I don't know if the UVM committee has documented their C compile requirements. I recommend you use the gcc version that is available with the version of Questa you are using. Disclaimer: Unless you have a specific need to use UVM 1.2 (i.e. to provide feedback), we suggest that you stay with UVM 1.1d and continue to use the pre-compiled libraries that come with Questa. UVM 1.2 is still in transition as it being transferred to the IEEE.

The import statement only makes symbols visible inside the scope of the import. Your import statement is inside a generate block and does not make symbols visible after the generate. If you need to select this package globally, it might be better to have two different versions of the same package compiled into separate libraries. Then just select the library you want at compilation time. If the package only contains parameter values, then you might consider using a structure or class type as a container for your parameters instead of a package.

Everything is passed by value in a fifo. It just so happens that the value of a class variable is a handle that references a class object. Unless you construct or clone a new object each time you write to the fifo, you are writing a handle to the same object over and over again. Dave

I would rather you not use anything other than run_phase() and instead use standard OOP practice of overriding the run_phase.

You should only be using the run phase in your driver. But regardless of which solution you choose, the test developer needs to be informed of the requirements you want to place on your testbench architecture. There is no getting around that. There are linting tools that can check for the proper calls to super.method() and you could also put in run time checks to make sure no other sequences have been started before your required sequence has finished.

Have a test base class for the test developer to extend. The first line of their test's run_phase should call super.run_phase() which is in your base class. That should start the initialization sequence.

Other than catchers, I do not recommend any user modifications to the reporting system. Even though the UVM allows it, you will get into trouble if everyone starts doing this and then you try to integrate different groups of VIP each with their own modifications. With catchers, you can modify and add to the message that will be emitted - there is no need for $display. And you can still use uvm_report_ messages as long as you can ensure there is no recursion in your catchers.

Where did you see this? The SystemC -> AVM -> OVM -> UVM methodologies have gone to great efforts to get everyone using a common messaging system. It's not just the Verbosity - it's all the the filters, catchers, and callback mechanisms around the messaging system that are subverted when you use $display. Many tool vendors have instrumented the UVM reporting mechanism to interact with their debugging environments, and using simple $displays will also subvert those efforts. Dave

The 1800-2009 LRM added an explicit example to clarify that parameterizing the base class form was legal. See http://www.eda.org/svdb/view.php?id=2142 Although multiple inheritance is not the same as multiple interfaces, you could still use it to simplify the code that needs to be written here.

One recommendation is not to use defaults unless they are meaningful. Then you will be forced to provide matching overrides. virtual class my_abstract#(type T, string Tname); pure virtual task transact(input my_trans#(T, Tname) trans); endclass : my_abstract

A `define macro is part of the compilation unit and does not belong to any package or other scope. Compiler directives like `define and `ifdef are compiled away as the first step in compilation process before any SystemVerilog syntax is parsed. I would use an actual Verilog parameter inside a package rather than a const variable because parameters can be used in more places than variables; like range declarations. I have a DVCon paper that has a section on explaining the difference between parameters and const variables.

That still is a bit vague. If all you want is for your C++ code to invoke your simulator command line, that will depend on the OS and the tool you want executed.

You never call a class in C++ or SystemVerilog. You construct class objects and then call class methods in the context of an object. I'm sure you want more interaction between the C++ code and UVM than just selecting which test gets run. You'll need to explain further.

Questa, like most simulation tools, has a built-in package that will interpret uvm_report_warning as $warning, uvm_report_error as $error, etc. If you do not use that built-in package, then all UVM reports are just simple $display statements. The severity of a failing assertion by default is error, but you can change that by putting a different severity task like $warning in the fail action block. The final TESTSTATUS of a simulation is determined by the most severe message issued during that simulation.

You'll need to look at the Questa User Manual to learn how to set a breakpoint. There are also commands you can use to find out where the simulator was executing at the time of the limit was reached. You might also try increasing the limit to 1000000.

You can usually get more verbose help about an error message from Questa by typing verror NNNN In this case type verror 3601.

In many programing languages, a handle is a term used for an opaque pointer. It is opaque in the sense that you cannot see or manipulate the value of a handle, you can only see what it references. Conversely, a pointer can be manipulated to point to other object by incrementing or decrementing it. You can also convert it to an integer representing a memory address.

Why is it you don't want the elements of array a to be randomized? If it is because you want the array values to be 0, then just add that constraint - foreach(a) a == 0;

Typically, you already have a agent configuration object that will have virtual interface handle in it, You can add methods to that configuration object to do perform the waits. See https://verificationacademy.com/cookbook/stimulus/signal_wait

Recoding dynamically sized arrays and queues requires the the vsim -classdebug switch. Use of the `uvm_field macros are not required. Check the reference manual for other options related to the "add wave" command regarding dynamic memories. For more help, please contact Mentor Support.

Regardless of the direct answer to your question, I suggest that you not use an immediate assertion to check the result of randomize() and instead use a simple if/else statement. This is because assertions are included the coverage statistics for the design, and this check does not belong with the design, it is part of the testbench. If you do plan to turn off assertions, I suggest that you apply it to a specific DUT scope instead of globally to the entire simulation. You can also use the new $assertcontrol system task to only target concurrent assertions. Using both these suggestions will ensure that you do not lose the randomize functionality no matter what your tool decides to do.