Jump to content

drianf0

Members
  • Content Count

    9
  • Joined

  • Last visited

Everything posted by drianf0

  1. Hello, The question is SystemVerilog specific, not related to UVM. I was wondering if it is possible to initialize an interface inside an internal module A and further pass it to an another module B, which is at the same level of hierarchy as the module A. interface Inter (input logic clk); logic a; endinterface module A(Inter inter); logic clk; Inter inter(clk); endmodule module B(Inter inter); always_ff @(posedge inter.clk) ..... endmodule module top; A a( .* ); B b( .* ); endmodule Let's assume module A is a master of some Stream interface (like AXI4-Stream), B is the slave. The signal clk could be a regular variable inside the Inter, however, clk must be connected to the interface, so it seems logical to me, that it's on the port list, so developer will not forget to provide it. Therefore (port assignment of inter), the inter has to be initialized inside the module A, not in top as it would be done in case of regular interface usage. The code is for synthesis and my compiler doesn't support virtual interfaces. Does it exist any elegant solution for the described issue ? Thanks, Adrian
  2. Hello, I have a library with the sequence which exploits `uvm_info to print messages. It uses UVM_MEDIUM verbosity and AXI4STREAM_SLAVE id. I would like to disable those messages, however I can't change code of the library. For this reason, I have tried to call m_sequencer.set_report_severity_id_verbosity(UVM_INFO, "AXI4STREAM_SLAVE", UVM_HIGH). Please notice, the function is called for sequencer on which the sequence is spawned. The report configuration of the sequencer: # report handler state dump # # # +-----------------+ # | Verbosities | # +-----------------+ # # max verbosity level = 200 # *** verbosities by id # # *** verbosities by id and severity # UVM_INFO:AXI4STREAM_SLAVE --> UVM_HIGH # # +-------------+ # | actions | # +-------------+ # # *** actions by severity # UVM_INFO = DISPLAY # UVM_WARNING = DISPLAY # UVM_ERROR = DISPLAY COUNT # UVM_FATAL = DISPLAY EXIT # # *** actions by id # # *** actions by id and severity # # +-------------+ # | files | # +-------------+ # # default file handle = 0 # # *** files by severity # UVM_INFO = 0 # UVM_WARNING = 0 # UVM_ERROR = 0 # UVM_FATAL = 0 # # *** files by id # # *** files by id and severity # report server state The problem is that the message is still displayed. I debugged the issue and noticed that the problem is in uvm_sequence_item.svh (I use UVM-1.1d). In the uvm_report_enabled function, there is a part: if (m_client.get_report_verbosity_level(severity, id) < verbosity || m_client.get_report_action(severity,id) == uvm_action'(UVM_NO_ACTION)) return 0; else return 1; As one can see, even if the message will be rejected by get_report_verbosity_level, it will get the default action from get_report_action and be printed at the end. According to my understanding, it's not a behaviour described in the documentation (uvm_report_object): The decision whether the message is printed is based on the assigned action, not verbosity. Moreover, I don't see sense of verbosity usage in this case. I would be grateful, if somebody could clarify my concerns. Of course, another workaround is to call: m_sequencer.set_report_severity_id_action(UVM_INFO, "AXI4STREAM_SLAVE", UVM_NO_ACTION) however, I don't understand, why I couldn't get the same behaviour modifying verbosity.
  3. Hello, I don't know, what is an official way to report a bug. I was not able to add one on the webpage: http://www.eda.org/svdb/view_all_bug_page.php because of lack of an access (I haven't sported any registration form). Anyway, I think that the description of the `uvm_do macro is misleading. It states: "This macro takes as an argument a uvm_sequence_item variable or object. The argument is created using `uvm_create if necessary, then randomized". Actually `uvm_create is called every time, no matter whether SEQ_OR_ITEM is null or not. My preliminary impression was that passing a non-'null' argument, i.e. already preconfigured item, the macro will skip creation, proceeding with randomization and so on... Regards, Adrian
  4. Hello, I would like to ask whether the reference design exits which would introduce an error injection and would present a methodology how to handle it. I am acquainted with the basic examples like the UBUS, APB and UVM_ref_flow_1.1 (Cadence's contribution). However, all of them, I understand for simplicity, work on transaction level, where a driver sends a content of a sequence_item in the proper way. In my case, I would like to add the error injection on low level. For example, in case of a SERDES, it could be a simple introduction of disparity errors, wrong codding, ect. Is any design pattern defined to add such a functionality in the UVM ? I have tried to obtain it with inheritance. However --- I had to override a driver, monitor, sequences, ect... Basically, a reasonable part of the whole testbench. Moreover, developing the new functionality(error injection) I had to quite often modify base classes, which shouldn't happen in well designed class scheme. I would be grateful for any remarks/thoughts/examples. Regards, Adrian
  5. Hello, Is it safe ? I mean, I use the same trick. However, I am wondering, whether it is fine, that somewhere else in the top module I have: initial run_test("My_Test") Does it not introduce a race hazard of initial processes ? Of course, one could put start of the test as a condition in the last iteration of the generate loop, but in my opinion is not a clean solution...
  6. Hello, Is it safe ? I mean, I use the same trick. However, I am wondering, whether it is fine, that somewhere else in top I have: initial
  7. Dear Erling, Thanks a lot for your reply. The issue has been reported to Mentor Graphics. They confirmed it is a bug ( Defect DVT-31448 ). Your idea of possible workaround of course works. Adrian
  8. Hello, I would like to write a generic virtual sequence, which will spawn another sequences. Since I would like to to keep it generic, the type of spawned sequences should be defined by the overriding facility of the factory. My problem is that the code: class vir_seq extends uvm_sequencer#(); ... virtual task pre_body(); uvm_sequence_base seq; seq = uvm_sequence_base::type_id::create("my_name"); endtask; ... instead of creating the overriding type (let's say my_seq), creates vir_seq. One comment: I use the uvm_sequence_base instead of the uvm_sequence#(T) because I don't want to have the parametrized vir_seq (from my experience parameters always imply troubles at the end...). Is any other, more clean way, to avoid parameters ? I know, the that the uvm_sequence_base inherits type_id from uvm_sequence_item (so by default, without overriding, an item should be created). However, fact that I get every time vir_seq confuses me. To understand better the issue and isolate the problem, I end up with the following simple example: import uvm_pkg::*; `include <uvm_macros.svh> module top; test a(); endmodule // top class seq extends uvm_sequence#(); `m_uvm_object_registry_internal(seq, seq) // <- MACRO 1 // `uvm_object_utils (seq) function new(); super.new(); $display(uvm_sequence_base::type_id::type_name ); // <- DISPLAY 2 endfunction // new endclass // seq program automatic test; task start(); seq s; $display(uvm_sequence_base::type_id::type_name ); // <- DISPLAY 1 s = new(); endtask // start initial start(); endprogram // test Display 1, as expected, returns always 'uvm_sequence_item'. Output of Display 2 depends whether the Macro 1 (which is a part of `uvm_object_utils) is commented or not, returning respectively 'uvm_sequence_item' or 'seq' I would be grateful for an explanation why the above simulation doesn't follow my expectations. Thank you in advance. Regards, Adrian
  9. Hello, The uvm_queue and uvm_pool don't have implemented do_compare function. Could somebody please explain me why ? Maybe that feature could be added in future releases. I think that even `uvm_field_queue_object macro would solve the issue... I understand that one can derive from those classes and implement the do_compare by himself. However, I think it would be more convenient to have it already implemented by the standard. Thanks in advance.
×
×
  • Create New...