walkeranderson

What is the recommended way to control the timescale of the UVM timeout as set with set_timeout()? Controlling the timescale in the calling code doesn't seem to work. For example, `timescale 1ns/1ps ... uvm_top.set_timeout(2000000ns, 1); results in the timeout set to 2000ns. UVM seems to be using a timescale of 1ps.

What happens when a driver calls seq_item_port.put_response() with a response associated a request sequence item where the sequence that sent the request sequence item has terminated (and taken its response queue with it)? I'm not talking about a programming error condition where the sequence shouldn't have terminated. I'm talking about a real use case where the sequence did not want to wait for the response. And there would be other sequences working with this driver that did want to wait for and get their responses. It seems to be "handled" by the UVM code. Presumably the code under the hood for put_response sees that the response queue (or sequence) is no longer running and just does nothing. I'm wondering if this is intentional in the UVM implementation, and an expected usage model, or I'm just getting lucky and the current implementation happens to work for me. Thanks. Walker

Figured this out myself. In case anyone is interested, here's what I did. My goal was to add a run-time phase that I could use for configuring default sequences on sequencers. /////////////////////////////////////////////////////// Here's the definition of the new phase class uvm_foo_phase extends uvm_task_phase; virtual task exec_task(uvm_component comp, uvm_phase phase); my_uvm_sequencer seqr; if ($cast(seqr, comp)) seqr.foo_phase(phase); endtask local static uvm_foo_phase m_inst; static const string type_name = "uvm_foo_phase"; // Function: get // Returns the singleton phase handle static function uvm_foo_phase get(); if(m_inst == null) m_inst = new; return m_inst; endfunction protected function new(string name="foo"); super.new(name); endfunction virtual function string get_type_name(); return type_name; endfunction endclass /////////////////////////////////////////////////////// Here's what I added to the build phase of my test component to add it to the run time schedule. uvm_phase sched = uvm_domain::get_uvm_schedule(); sched.add(uvm_foo_phase::get(), .after_phase(sched.find_by_name("pre_configure")), .before_phase(sched.find_by_name("configure"))); /////////////////////////////////////////////////////// Here's what I added to my my_uvm_sequencer class virtual function void foo_phase(uvm_phase phase); start_phase_sequence(phase); endfunction

I'm sure it's simple (if you know what you're doing) but could someone please point me to, or include in a response, a simple and complete example of defining a user-defined phase to be inserted into the schedule between the pre_configure and configure phases? Thanks.

In the run_phase() of a component, I'd like to raise an objection to the main phase so I added the following: uvm_main_phase::get().raise_objection(this); and I get this error when it runs: UVM_ERROR @ 0 ns: reporter [uVM/PH/NULL_OBJECTION] 'uvm_test_top.foo' attempted to raise an objection on 'main', however 'main' is not a task-based phase node! (This is a UVM_PHASE_IMP, you have to query the schedule to find the UVM_PHASE_NODE) Why? What do I not understand or how should this be done? It looks to me like uvm_main_phase is derived from uvm_task_phase so wouldn't that make it a "task-based phase node"? Thanks. Walker

Actually that bug report is for uvm_mem. The bug I described is with uvm_mem_mam. FWIW, changing all of the "int unsigned" size or n_bytes arguments to "longint unsigned" works just fine it seems.

Is there some good reason that the n_bytes argument to uvm_mem_mam request_region() and reserve_region() are unsigned ints and not unsigned longints? It seems inconsistent with the address "offset" arguments/attributes which *are* longints (or bit [63:0]) and obviously it prevents allocation of regions larger than 2**32-1. Perhaps this could/should be fixed in a future release? Or is there some subtlety I'm missing. Thanks. Walker

No time to do a full-fledged test case but I think it could be described simply enough. 1) Sequence A locks a sequencer 2) Sequence B tries to lock the sequencer but the call to lock() doesn't return (presumably because sequence A has the sequencer locked) 3) Sequence C tries to lock the sequencer but the call to lock() doesn't return (presumably because sequence A has the sequencer locked) 4) Sequence A unlocks the sequencer 5) The call to lock() from sequences B and C both return 6) Sequences B and C both call start_item() 7) Sequences B and C hang because start_item() never completes for them As I instrumented the UVM code to debug, there is code to clearly have a notion of a lock list suggesting that the idea of more than one sequence getting the lock is somehow supported but I don't understand that usage model. It seems like a sequence can get the lock but still be "blocked". I ended up working around it by having the grabbing sequences do the following. Not sure if this is what one is expected to do or if this is a robust solution so comments would be welcome. lock(); while (is_blocked()) begin unlock(); lock(); end start_item(foo); finish_item(foo); unlock();

Right. I have no problem with the check/warning. But the code that's causing it is in the UVM library and all that I did to expose it was create a nested register block. What's the recommended workaround? I downgraded the warning but perhaps there is something more elegant. Thanks.

I'm working on upgrading to UVM 1.2 (from 1.1d). I am seeing a case where multiple sequences have called a sequencer's grab(), they are both blocked waiting on a grab() done by an earlier sequence, and when that earlier sequence calls ungrab(), both of the waiting sequences unblock and their grab() calls complete. I thought this shouldn't happen. My understanding was that the grab ensured that only one grabbing sequence would win that arbitration until it ungrabbed. Instrumenting the UVM code, I can see the grant_queued_locks() function calling m_set_arbitration_completed() for two sequences in a foreach loop. Am I misunderstanding grab/ungrab or doing something wrong? Thanks.

Creating a UVM register block that is a sub-block of another UVM register block, when I call the configure function of the sub-block, I get this warning. UVM_WARNING @ 0 ns: reporter [uVM/RSRC/NOREGEX] a resource with meta characters in the field name has been created "regs.foo_regs" because of this implementation of configure from the UVM 1.2 source code function void uvm_reg_block::configure(uvm_reg_block parent=null, string hdl_path=""); this.parent = parent; if (parent != null) this.parent.add_block(this); add_hdl_path(hdl_path); uvm_resource_db#(uvm_reg_block)::set("uvm_reg::*", get_full_name(), this); endfunction Because the full name for the sub-block includes the name of the parent block with a "." between it. Am I missing something or doing something wrong? Seems like this will always happen with nested register blocks.

FWIW, Later yesterday I found this bug logged which seems to be the same thing. http://www.eda.org/svdb/view.php?id=4820

I just hit this same problem and tracked it down to the same underlying problem in the UVM code. This change, to both the do_bus_read() and do_bus_write() tasks in uvm_reg_map.svh, seemed to fix it for me. Changed: rw.parent.get_base_response(bus_rsp); to: rw.parent.get_base_response(bus_rsp, bus_req.get_transaction_id()); Any comments on whether this is a bug or not. It is not changed/fixed in the UVM 1.2 release.

Does anyone have an answer to this question about use of the backdoor. I encountered a related problem to this map override issue described in this post. http://forums.accellera.org/topic/2104-question-about-backdoor-map/ I can't see any way around it and any way to not get the warning from the register model that I described for any back door write. Thanks. Walker

Agree with post #7. Also, if you look carefully at the example I posted, the count seemed to be incrementing quite nicely but it didn't seem to be getting used to initializing the ID of each object.