Jump to content

Two grabbing sequences both win arbitration at the same time


Recommended Posts

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.

 

 

 

Link to comment
Share on other sites

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();

Link to comment
Share on other sites

  • 1 year later...
Here's a simple case which shows 1.2 behavior:
  first,  a sequence gets a lock, then 2 more (unrelated) sequences request locks (1st sqr.print).
  then, the first sequence gives up it's lock, and both the other 2 sequences are granted locks (2nd sqr.print).
 
It appears uvm_sequencer_base.grant_queued_locks will push sequences on the lock_list without checking
if those sequences are blocked by sequences it previously pushed on the lock_list during the same call.  
(applies to grab or lock).
 
test code:
class Seq extends uvm_sequence;
  function new(string name=""); super.new(name); endfunction
endclass
 
program test;
  uvm_sequencer sqr = new("sqr", null);
  Seq seq1 = new("seq1"), seq2=new("seq2"), seq3=new("seq3");
  initial begin
    sqr.lock(seq1);
    fork
      sqr.lock(seq2);
      sqr.lock(seq3);
      #2 sqr.unlock(seq1);
    join_none
    #1 sqr.print;
    #2 sqr.print;
  end
endprogram
 
test code output:

----------------------------------------------------------------------
Name Type Size Value
----------------------------------------------------------------------
sqr uvm_sequencer - @335
rsp_export uvm_analysis_export - @344
seq_item_export uvm_seq_item_pull_imp - @462
arbitration_queue array 2 -
[0] string 20 SEQ_TYPE_LOCK@seqid2
[1] string 20 SEQ_TYPE_LOCK@seqid3
lock_queue array 1 -
[0] string 11 seq1@seqid1
num_last_reqs integral 32 'd1
num_last_rsps integral 32 'd1
----------------------------------------------------------------------
-------------------------------------------------------------
Name Type Size Value
-------------------------------------------------------------
sqr uvm_sequencer - @335
rsp_export uvm_analysis_export - @344
seq_item_export uvm_seq_item_pull_imp - @462
arbitration_queue array 0 -
lock_queue array 2 -
[0] string 11 seq2@seqid2
[1] string 11 seq3@seqid3
num_last_reqs integral 32 'd1
num_last_rsps integral 32 'd1
-------------------------------------------------------------
$finish at simulation time 3

Link to comment
Share on other sites

  • 4 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...