Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by dudi

  1. 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.
  2. 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
  3. 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);
  4. 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
  5. 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
  6. 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!
  7. This is a very basic principle in OOP, called polymorphism. Perhaps you should search for a brief tutorial of SystemVerilog
  8. 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.
  9. 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.
  10. 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.
  11. 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)
  12. 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.
  13. Hi Uwes, thanks for the response! I think the spell checker only works for the resource_db and not for the config_db (correct me if I'm wrong). And I mostly use config_db... check_config_usage() covers this though - I call it on the check_phase of the test like this: virtual function void check_phase(uvm_phase phase); super.check_phase(phase); uvm_root root=uvm_root::get(); root.check_config_usage(1); endfunction I'll probably implement my own function though, because it uses $display.I still need something for the factory overrides ( set_type_override / set_inst_override). Do you know anything for this? Another thing I saw is that check_config_usage() is not called automatically - this is a documentation bug I think because I doubt it should be called automatically
  14. Hi Is there a way to produce a uvm_warning for unused config_db "sets" and factory overrides? By "unused" I mean a set to the config_db that received a corresponding "get", and a factory override that was never required. Since the factory and the config_db is string based, a small typo is hard to debug. Is there an automatic way to produce the warning? I know I can turn on the "trace" function by adding +UVM_RESOURCE_DB_TRACE to the command line (BTW - there is a bug in UVM, it ignores +UVM_CONFIG_DB_TRACE and only uses the resource_db options class) but it still requires me to parse the log. An automatic warning can be very helpful. Thanks for your help!
  15. Thanks for the replies! jeff.schroeder Using a class wrapper doesn't help, since the class it self is parameterized. Instanciating it in a monitor for example (and then using the config_db to get it) still requires passing the parameters. mea1201 I'm currently using something similar to what you suggest: `define my_monitor my_monitor#(DATA_WIDTH) Can't say I'm satisfied though, but it is a bit more elegant
  16. oops, my bad. The typedefs are indeed scoped, but I still need to parameterized all of the classes that require an instance of the virtual interface, except this time I'll need to give it a 'type' parameter of that virtual interface. I guess like previously mentioned, there is no elegant solution here...
  17. Perhaps I'm missing something, but I can't see how using typedef helps in case of multiple instances with different parameters. Wouldn't it cause en error declaring the same typedef twice with different values? interface bus_if #( BUS_WIDTH= `MAX_ADDR_SIZE ) ( input logic clock ); logic [BUS_WIDTH:0] addr; typedef virtual bus_if #(.BUS_WIDTH(BUS_WIDTH)) vif_t; endinterface // bus_if module tb bus_if #(16) if1(clk); bus_if #(32) if2(clk); ... endmodule
  18. Hello everyone, first post here I have a problem when using parameterized interfaces. My current solution is not very pretty, so I will appreciate your suggestions. I have a parameterized interface (and ofcourse a corresponding parameterized virtual interface). The problem is that in every place I create an instance of the vif, I must supply the parameters which forces me to make those classes (driver, monitor etc...) parameterized as well. I pretty much end with almost all classes being parameterized (since the agent must supply the parameters to the instances of the driver and so on). This is ofcourse not very elegant. Do you know of a good way to overcome this limitation? I can't use `define to pass the parameters since the idea is to later create multiple instances of the same agent with different parameters. Thanks for your help!
  • Create New...