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 und

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";

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

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 comple

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 tw

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_blo

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.