Jump to content


  • Content Count

  • Joined

  • Last visited

  1. The same can be achieved with the UVM phase_started function. virtual function void phase_started(uvm_phase phase); super.phase_started(phase); current_phase = phase; endfunction : phase_started
  2. Here's an example of what I tried explaining above: program test; import uvm_pkg::*; `include "uvm_macros.svh" class my_item extends uvm_sequence_item; rand integer data; `uvm_object_utils_begin(my_item) `uvm_field_int(data, UVM_ALL_ON + UVM_DEC) `uvm_object_utils_end endclass class my_seq extends uvm_sequence #(my_item); `uvm_object_utils(my_seq) function new(string name = ""); super.new(name); endfunction : new task body(); forever begin `uvm_do(req) end endtask : body endclass : my_seq class my_test extends uvm_test; `uvm_component_utils(my_test) uvm_sequencer #(my_item) seqr; function new(string name = "my_test", uvm_component parent); super.new(name, parent); endfunction : new function void build_phase(uvm_phase phase); seqr = new("seqr", this); uvm_resource_db #(uvm_object_wrapper)::set({get_full_name(), ".seqr.pre_main_phase"}, "default_sequence", my_seq::type_id::get(), this ); uvm_resource_db #(uvm_object_wrapper)::set({get_full_name(), ".seqr.main_phase"}, "default_sequence", my_seq::type_id::get(), this ); endfunction : build_phase task main_phase(uvm_phase phase); my_item item; phase.raise_objection(this); repeat (10) begin seqr.get_next_item(item); `uvm_info(get_name(), $psprintf("%0d", item.data), UVM_NONE); seqr.item_done(); end phase.drop_objection(this); endtask : main_phase endclass : my_test initial run_test("my_test"); endprogram : test If I don't specify a default sequence for the pre_main phase, everything works fine. If I do specify the default sequence for the pre_main phase, the simulation times out because the call to get_next_item never returns. Is this to be expected? I know there are other ways to have a sequence span several phases, I'm just trying to understand how this all works.
  3. I'm not sure what to make of the following situation: I've layered two sequences and set up the upper-layer sequence to start as a default sequence in several phases: post_reset_phase, pre_main_phase, main_phase. The bottom layer sequence is manually started by my test in pre_main_phase. As the title says, this came about as I was experimenting with UVM. Each sequence has its own sequencer. Effectively, the items from the upper-layer sequence are not intended to be used before the pre_main_phase; they are simply "available" before. As expected, the upper-layer sequence starts in all of the above phases. The bottom layer sequences starts correctly in pre_main_phase but gets stuck trying to retrieve items from the upper layer sequencer (the peek statement in get_next_item). I briefly tried tracing the execution of the UVM code and it appears that the request_id from the upper_layer sequence that got started in post_reset_phase is the one that gets marked as complete by the sequencer arbitration process during pre_main_phase. I'm assuming that the sequence request id for the pre_main_phase is the one that is expected and hence that is gating things, but admittedly I don't have the full picture in mind yet. Should the left-over sequence request ID from the post_reset_phase have been cleared when that phase ended? Or is this expected behaviour? Is the user responsible for ensuring that all sequences are properly terminated before the next phase begins? Of course, everything works fine if I do not start the upper-layer sequence before pre_main_phase.
  4. I'm not following; the length property is redundant so why does it need to be considered for the unpacking? If I take the length property out and hard-code in the constraint the size of the array, how is the problem going to be different? The array will still be packed the same way.
  5. Should that not be handled by the field automation macros?
  6. I found out what was wrong: our "company" base layer isn't implemented correctly and is overriding the new macro definition from UVM 1.1.
  7. Hi uwes, Thanks for the response but I am not calling the start_item() method, at least not directly. I am using the macros. I also just noticed that on a simple example, everything works fine. The problem only shows up, so far, in "full" test benches. I don't know if it's relevant but in those test benches, the sequences are started as default sequences.
  8. The following example of packing and unpacking does not work. Integral fields (length) get packed and unpacked properly but arrays do not get unpacked (unless I'm unpacking to an existing data structure that previously allocated space for the array). Is this a known issue? program test; import uvm_pkg::*; `include "uvm_macros.svh" class my_item extends uvm_sequence_item; rand int length; rand bit [7:0] payload[]; constraint data_length_cons { length inside { [1:10] }; } constraint data_payload_sizecons { payload.size() == length; } `uvm_object_utils_begin(my_item) `uvm_field_int(length, UVM_ALL_ON + UVM_DEC) `uvm_field_array_int(payload, UVM_ALL_ON) `uvm_object_utils_end endclass initial begin my_item a = new(); my_item b = new(); bit bitstream[]; int num_bits = 0; a.randomize(); `uvm_info("a", {"\n", a.sprint()}, UVM_NONE); num_bits = a.pack(bitstream); b.unpack(bitstream); `uvm_info("b", {"\n", b.sprint()}, UVM_NONE); end endprogram : test Typical output for the unpacked object will look like: UVM_INFO n.sv(32) @ 0: reporter [b] -------------------------------------------- Name Type Size Value -------------------------------------------- uvm_sequence_item my_item - @465 length integral 32 'd8 payload da(integral) 0 - --------------------------------------------
  9. I just tried to switch to UVM 1.1 and I am seeing new errors. I used to be able to start a sequence within a sequence by using the uvm_do_with macros in the body() method. I now get the following error: UVM_FATAL @ 0 [sEQNOTITM] attempting to start a sequence using start_item() from sequence Anyone have an idea of what may be causing this? Was my previous usage of the macros incorrect?
  10. The get_next_item() and item_done() methods of the sequencer are not documented and comments in the implementation state that they are not part of the standard. Is this because there are drawbacks to accessing sequencers directly from within a sequence instead of layering sequences through ports?
  • Create New...