dudi

Factory override of instances such as transactions (not an issue in type overrides) can cause a severe performance degradation so be careful. The DPI regular expression is very expensive... I would recommend you to think of a different approach, such as using the config_db to set an object wrapper of the new transaction and get it from the sequence only once. Or you can set various parameters using the config_db into the sequence from the test, that control your constraints.

That will do the trick. You can also move the event to the interface, and trigger it in an always@(posedge clk) block. Then wait for vif.event_name.triggered . This way you won't need to fork it in the run_phase

Define a SVA sequence in the clocking block: clocking cb @(posedge clk); ... sequence at_posedge; 1; endsequence endclocking Then in the driver use the following code before driving the transaction: wait (vif.cb.at_posedge.triggered);

No one has any idea?

Why do you need to use config_db for this? Since its a random delay, you can either use std:randomize to locally randomize it in the run task, or even better - you can add the delay to be part of the transaction. Then you can easily control the delay with constraint given to your transactions/sequences

Hi all I'm trying create a simple mechanism for checking the functionality of a DUT with CRC, that maybe can also be used to other scenarios that require forcing a signal. What do you think is the best approach in order to create a reusable environment? I'm thinking of 2 ways to achieve this: 1) using the "uvm_hdl_force" function - forcing the signal through VPI. The benefits are it is very simple, and and it can be reusable if you use the config_db to pass the sting type hdl path. 2) using a virtual interface - This approach requires more code, but you can have better performances in runtimes (vpi requires special compilation flags) Do you have other suggestions? Which do you think is better? Thanks a lot! Dudi

Since the actual type of the sequencer is my_seqr (derived from uvm_sequencer), and m_sequencer is a handle of type uvm_sequencer, you can use the dynamic cast ($cast) to produce a handle of the derived class type from the handle of the parent class type. Maybe I'm not explaining it well, or maybe we don't not fully understand each other... Perhaps someone else can provide a better explanation. Good luck!

This is a very basic principle in OOP, called polymorphism. Perhaps you should search for a brief tutorial of SystemVerilog

Use the `uvm_declare_p_sequencer macro in your sequence. It will generate a handle to your sequencer with the type you want. If you also need to have access to the sequencer in your sequence items, simple provide this handle (p_sequencer) to them from the sequence that generates them.

Another option is that in some tools you can use PLI to add functionality to $error calls. This way you can force every $error to perform a uvm_error as well.

Report catcher can only be used on UVM messages. The SVA checker is producing a $error message and can't be modified by the catcher.

You can also use std:randomize to randomize primitive types

config_db works in objects: my_type foo; ... uvm_config_db#(my_type)::get([B][COLOR="Red"]null[/COLOR][/B], get_full_name(), "foo", foo); Just make sure the object's get_full_name() return the correct path (for sequence items, it is already implemented for you, so you can use it strait away)

Awesome, thanks again Uwe!

Thanks for the response Bart. Printing the factory (with all_types = 0) will indeed print all the factory overrides, but that's not what I'm looking for. I don't want to print all the overrides, only the ones that was never used (and I want to see it as a UVM_WARNING) I guess I'll have to implement something like this myself.