Search the Community

In my testbench I have two background sequences (call them S1 and S2) perform register access and a test that has multiple threads ( call them T1 to T7) also performing register access on the same shared bus. T1 through T7 need to lock the sequencer in order to perform multi-cycle transactions on the CPU bus. The scenario is S1 issues a write, resulting in arb_sequence_q.size == 1 and arb_sequence_q[0].request == SEQ_TYPE_REQ in the same simulation tick, T1 through T7 issue lock requests. arb_sequence_q.size() == 8 and arb_sequence_q[0] is still the S1 request S2 issues a read, resulting in arb_sequence_q.size() == 9, arb_sequence_q[8].request == SEQ_TYPE_REQ The CPU driver calls get() and the request at the head of arb_sequence_q (the write from S1) gets popped, resulting in arb_sequence_q.size() == 8 and arb_sequence_q[0:6].request = SEQ_TYPE_LOCK and arb_sequence_q[7].request == SEQ_TYPE_REQ (this is the request from S2). finish_item is called for the S1 request, resulting in grant_queued_locks getting called, pushing all LOCK requests onto the lock_list and leaving only S2 on the arb_sequence_q. arb_sequence_q.size() == 1, arb_sequence_q[0].request = SEQ_TYPE_REQ (this is the S2 request) lock_list.size() == 7 arb_completed.num() == 0 T1 calls write, enqueuing a SEQ_TYPE_REQ on the arb_sequence_q. The arb_sequence_q.size() == 2, arb_sequence_q[0] is S2's request and arb_sequence_q[1] is T1's request. [edit] Here's where the problem hits. Because the lock_list size() > 1, when the consumer (driver) calls get(), the sequencer will cycle through all its requests in its arb_sequence_q until it finds one that is ~is_blocked(). Unfortunately, that function cycles through all sequences in the lock_list regardless of whether the first item in the lock list corresponds to the request being processed. So since we have 7 locks in there, one for each thread, when the driver tries to get a new sequence, T1 will always be blocked by T2:T7. Similarly any request from T1:T7 will get locked out by the others. We've now deadlocked. I believe there is an issue here with the is_blocked() function which should have some form of priority encoding.

//This is not a question, but me storing some debug notes online, lest I run into this problem again. //good for debugging this issue, print_topology in particular. Put them in your test. `uvm_info("TEST",$psprintf(" TOPOLOGY..............................."),UVM_HIGH); uvm_top.print_topology(); `uvm_info("TEST",$psprintf(" CONFIG_DB_DUMP..............................."),UVM_HIGH); uvm_config_db::dump(); //When a sequence doesn't run, double-check the following. //in the test (or wherever) where we assign the sequence to run on a sequencer uvm_config_db#(uvm_object_wrapper)::set(this, "*.dpx_xyz_agent_m.dpx_xyz_seq.main_phase", "default_sequence", dpx_xyz_simple1_seq::type_id::get()); //compare the name of the sequencer with the name that is given to the factory for the sequencer, when it is created //where we create the sequencer (in the agent), what name did we supply to it with the factory? m_seq = dpx_xyz_sequencer::type_id::create("dpx_xyz_seq", this); //make sure they match. This problem has bitten me a few times.

Dear all, I'd like to access a register via multiple physical interfaces (bfm). Is it possible to set 2 different sequencers to the registers with same address? I have read this is a known issue from this forum. Could anybody give me a good example? I'm looking for a solution that there is no problem in prediction as well as write/read of UVM_REG. Thanks & Regards,

In the body of a virtual sequence I have a sequence running inside fork join, which is then killed by disabling the thread, like so: virtual task body(); .... fork:seq_thread `uvm_do_on(my_seq, my_seqr) join @(negedge reset_b ); disable seq_thread; ... ... endtask; On doing this, we get the following error from the sequencer: [sEQREQZMB] The task responsible for requesting a wait_for_grant on sequencer 'uvm_test_top.env.my_seqr' for sequence 'uvm_test_top.env.soc_v_sequencer.my_vseq.my_seq' has been killed, to avoid a deadlock the sequence will be removed from the arbitration queues. What can I do in my virtual sequence to cleanly kill 'my_seq' when reset_b is asserted ?

Hi, I am implementing multiple reset inside UVC componenets (sequencer, driver, monitor and etc). When reset is asserted between get_next_item() and item_done(), the following error is issued. UVM_ERROR (SEQREQZMB) The task responsible for requesting a wait_for_grant on sequencer '....' for sequence '...' has been killed, to avoid a deadlock the sequence will be removed from the arbitration queues. I guess this error is caused that queue for sequence item already gets a item to transfer into driver. How can I fix this problem? How can I remove current item from the arbitration queue? My UVC is using run_phase(). I don't use main_phase(). So, I would like to control it using run_phse(). Thanks & Regards,

Hello Everyone, I am trying to control a sub virtual sequencer's non-virtual sub sequencers using a top level virtual sequencer. It looks like this diagram. <start of diagram> .------------------------------------------------------. | my_test | .--------------------------------------------------. | | | sequences | | | '--------------------------------------------------' | | .--------------------------------------------------. | | | my_env | | | '--------------------------------------------------' | '/----------------------------------------------------\' / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ .----------------------------------------------------------------------------------------------------. | my_env | | .------------------------. | | | my_virtual_sequencer | | | '------------------------' | | .-----------------------------------. .----------------------------. .---------------------------. | | | sub_virtual_agent | | sub_agent_a | | sub_agent_b | | | | .-------------------------------. | | .------------------------. | | .-----------------------. | | | | | sub_virtual_sequencer | | | | sub_sequencer_a | | | | sub_sequencer_b | | | | | '-------------------------------' | | '------------------------' | | '-----------------------' | | | | .-------------------------. | | .------------------------. | | .-----------------------. | | | | | sub_agent_3 | | | | driver_a | | | | driver_b | | | | | .-------------------------. | | | '------------------------' | | '-----------------------' | | | | | sub_agent_2 | | | | .------------------------. | | .-----------------------. | | | | .---------------------------. | | | | | monitor_a | | | | monitor_b | | | | | | sub_agent_1 | | | | | '------------------------' | | '-----------------------' | | | | | .-----------------------. | | | | '----------------------------' '---------------------------' | | | | | sub_sequencer_1 | | | | | | | | | '-----------------------' | | | | | | | | .-----------------------. | | | | | | | | | driver_1 | | | | | | | | | '-----------------------' | | | | | | | | .-----------------------. | | | | | | | | | monitor_1 | | |-' | | | | | '-----------------------' |-' | | | | '---------------------------' | | | '-----------------------------------' | '----------------------------------------------------------------------------------------------------' <end of diagram> I am trying to apply section 4.8 Virtual Sequences of uvm users guide. But I think I am missing on something. I have a top level virtual sequence that has the top level virtual sequencer as its p_sequencer. I have this in the macro: `uvm_declare_p_sequencer(my_virtual_sequencer) And then I have this in the task body() to access the sub sequencer of the sub virtual sequencer: `uvm_do_on(sub_sequence_1, p_sequencer.i_sub_virtual_sequencer.i_sub_sequencer_1); sub_sequence_1 is a physical sequence. Is this correct under the UVM standard? If not, how do I properly control i_sub_sequencer_1? This is how I access it in the test build_phase: uvm_config_db #(uvm_object_wrapper)::set(this, "i_my_env,i_my_virtual_sequencer.main_phase","default_sequence",my_virtual_sequence::type_id::get()); Any help/inputs to this is much appreciated. Thanks, Martin

In the Layered Sequencers, As shown in the figure below, I want to use multiple lower layer sequencers(1,2,3) in parallel. Is it possible? If possible, Can you tell me how do I implement? Sequencer(Upper) +-----> Sequencer(Lower1) ----> Driver +-----> Sequencer(Lower2) ----> Driver +-----> Sequencer(Lower3) ----> Driver