
walkeranderson
Members-
Content Count
23 -
Joined
-
Last visited
-
Days Won
3
walkeranderson last won the day on October 5 2015
walkeranderson had the most liked content!
About walkeranderson
-
Rank
Member
Recent Profile Visitors
645 profile views
-
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
-
Adding a run-time phase example
walkeranderson replied to walkeranderson's topic in UVM (Pre-IEEE) Methodology and BCL Forum
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"; -
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
-
JeremyCali reacted to a post in a topic: uvm_object get_inst_id() not working
-
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
-
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
-
EkbergMit reacted to a post in a topic: uvm_object get_inst_id() not working
-
WelchKino reacted to a post in a topic: uvm_object get_inst_id() not working
-
Pipelined RAL access
walkeranderson replied to Kamlesh Shah's topic in UVM (Pre-IEEE) Methodology and BCL Forum
FWIW, Later yesterday I found this bug logged which seems to be the same thing. http://www.eda.org/svdb/view.php?id=4820 -
Pipelined RAL access
walkeranderson replied to Kamlesh Shah's topic in UVM (Pre-IEEE) Methodology and BCL Forum
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