dave_59

With TLM. you use analysis ports that implement a write method. There is a get_ap and put_ap that comes with the tlm_fifo that you can connect to.

I highly recommend not using the `uvm_field macros and writing the utility methods yourself. There is tremendous overhead in the automation of these functions. See http://verificationacademy.com/uvm-ovm/MacroCostBenefit for examples and a link to the DVCon2011 best-paper award.

Why didn't you use uvm_config_db#(test_config)::set(this,"*.my_env","cfg",my_test_config);

Pratta, the rest of your post seems to answer your own question. An abstract class is declared in a packages outside of a parameterized interface. It is free from any dependencies on parameters used by the interface. More likely, some subset of parameters used by the interface may be needed by the abstract class and will be more manageable to deal with at the system level. I don't understand the need to extend the concrete class. It is just there to provide access to the signals and methods in the interface or module. Since you can't extend the interface/module, why would you need to extend the class? FYI, the concrete class does not need to be inside your interface. It could be defined in another module/interface, or in an interface that is bound into your interface.

Don't understand the title of your post in relation to the question being asked. For classes not derived from uvm_component, you must explicitly get the value from the config db. if (!uvm_config_db#(int)(context,"",N)) `uvm_error("code","message); You context could be m_sequencer or it could be null if this is a global setting.

First, the syntax issues. You have to realize that SystemVerilog has packed and unpacked kinds of array dimensions. When you declare bit [31:0] foo [4]; This in an unpacked array[4] of a packed array [31:0]. Because of some parsing issues, there are places where you must use a typedef so that dimension kinds can be distinguished. You could have used a single typedef. typedef [31:0] DW_ARRAY[4]; As far as setting individual elements, we recommend using a single configuration object for each component instead of multiple configuration settings. You can then use uvm_config_db#(my_config_object) to access its handle, and you have access to each individual element.

The UVM BCL shipped with Questa is the same one released on the Accellera website. Using this vendor supplied kit saves you a number of compilation steps, especially compiling the required DPI libraries as well as automatically supplying the necessary command line switches to access the macros and libraries. Questa 10.1 now includes an extra UVM debug package the is layered on top of the UVM BCL, without modifying the library as we did previously with the OVM package. The debug package includes hooks for logging messages and transactions in the waveform database. There will be a paper at DVCon 2012 describing this package. Depending on the timing of releases, the vendor supplied kit might be behind the latest Accellera release. That should become less of an issue as the UVM matures.

For C++, you need to do extern "C" get_value( int idx, int64_t* data);If you you are using Questa, you should generate this header file from your SV code directly using the switch -dpiheader file.h. That way you can be sure at compile time that your arguments across the DPI match up.One other tip about using DPI exports, make sure you use only SV tasks when your call might consume time, otherwise use stick with SV functions. There is some extra work to deal with process control if your process gets terminated.

I think you are confusing the set_config/get_config methods from ovm_component with the class uvm_config_db. You can use uvm_config_db anywhere, even outside any class. The key thing is understanding how the first two arguments are used to build a string name. As the end of the article points out, you can use any arbitrary string for the scope name, it doesn't have to be related to any UVM naming scheme. But it is a very good idea to use whatever naming scheme the UVM uses.

uvm_sequence_item is extended from uvm_object. Unlike the OVM's get_config_* methods, the uvm_config_db#(type)::get() take context and scope arguments. class my_bus_seq extends uvm_sequence #( my_bus_sequence_item ); string scope_name = ""; task body(); my_bus_config m_config; if( scope_name == "" ) begin scope_name = get_full_name(); // this is { sequencer.get_full_name() , get_name() } end if( !uvm_config_db #( my_bus_config )::get( null , scope_name , "my_bus_config" , m_config ) ) begin `uvm_error(...) end endtask endclass See http://verificationacademy.com/uvm-ovm/Config/ConfiguringSequences

It is defined inside the file uvm_factory.svh as a static global variable in the uvm_pkg const uvm_factory factory = uvm_factory::get(); It is instantiated by the first call to uvm_factory::get();

The reason the constraint 'no_branch' does not work is because that constraint belongs to an insn_sequence object, and you are calling randomize() on an insn object. You would need to put the no_branch constraint inside the insn class. Even better is to extend the insn class into another class with a no_branch constraint. Then either create that class directly, or use factory overrides for the construction of the insn class. That way you can represent a hierarchy of instruction sequences based on extensions to the insn base class. BTW, the `uvm_sequence_utils macros was deprecated in UVM 1.1. Just use `uvm_object_utils to register a sequence with the factory.

Is this only your design or any example provided with the release that has this problem? One thing to try is delete your work library and recreate it with "vlib work". You should always do this when switching between major revisions of the simulator. The vlog command line does not need -sv if all SystemVerilog files have the extension *.sv Try the vsim command line "vsim Top" without the -novopt. If you have further issues, you need to contact Mentor support. You will also need to provide your OS/platform.

If by procedural constraints you mean the ones added by calling randomize() with {extra_constraints}, they work in tandem, or added, with the constraints declared in the class. Although it is quick and easy to add constraints this way, in my opinion it is better to extend the class to be randomized with constraints you want to add or override with another class. If you need to override the constraints added procedurally using the with clause, you will have to extend the procedure with another class anyways.

Yes, you can read the command line using the UVM command line interface. Also some simulators, like Questa provide a -g CLI option to change global parameters at run time.

1. IMHO, uvm_void is of no use. It destroys the type safety of class by create a universal base class type - similar to void* in C++. 2. The idea of a transaction is that it is transient, it exists only for a short time. Whereas the reporting functions and their associated settings in the report_handler exist for the entire simulation. When you issue a report in a class that is not extended from uvm_report_object, it will use the global reporter. You can identify messages from your transactions by using the string ID field of the message. Usually transactions are sequence_items and some people use the report handler of the sequencer they are running on by using m_sequencer.uvm_report_****(). Another option is to create a static log member in your report handler and initialize it on construction of the first transaction. my_transaction extends uvm_transaction; static uvm_reporter log; function new(string name =""); super.new(name); if (log==null) log = new("my_transaction"); endfunction

Yes, a parameterized class is not a real type, it is a template. You may want to read my DVCon paper on parametrized classes.

When you have a parameterized class, you always need to specify the parameters you want if not using the defaults. It would help if you didn't specify defaults when declaring AgentA, then you would be required to override the parameters. class AgentB #(type seq_item_type, driver_type, monitor_type) extends AgentA #(seq_item_type, driver_type, monitor_type);Then when calling the static function get_type(), you need to specify the matching parameters set_type_override_by_type(AgentA#(SI,DT,MT)::get_type (), AgentB#(SI,DT,MT)::get_type())Note: since you are doing this from inside MyEnv which is a uvm_component, you do not use 'factory.'. Then the override is implicitly from the current place in the UVM hierarchy.

None of this sounds right to me. Why can't you have two sequencers and a single sequence sent items to different sequencers?

What I would do is create the configuration object in your SV testbench and a handle to your object down to your Env. Then have the Env set it so the Testbench can use it. The timing of this is critical though, you'll need to explain more about why and when you you need the info.

I'll give you another tip, don't mention what tool you are using until it is absolutely necessary - it will decrease the amount of expert advice you might get. Are these classed being compiled in the order you presented? Where and exactly what is the error message?

Could please explain what "doesn't work" means? Are you getting a compiler error or not the result you expect? You always have access to base class members from an extended class, unless they are declared "local".

Hi Erling, This is a reported bug in Questa. It has to do with the interaction of a variety of things and you can contact Mentor for more details. The quick workaround is prefix the call with 'this.' or add the virtual keyword in all derived methods.

You should use 3). Then the weight of 63, 127, 255, and 511 will be (4 + (1/512))/17= 0.2354. The weight of 'others' will be (1/512)/17 = 1/8704 = 0.0001

The Verification Academy's UVM Cookbook contains an on-line version of guides and examples that is continuously updated. There are also PDF books that you can download and print for yourself.