Jump to content
Sign in to follow this  
bhunter1972

Bug in uvm_sequencer_base::grant_queued_locks();

Recommended Posts

I discovered this issue when multiple sequences attempted to perform a lock() at the same time (not at all uncommon at the beginning of time when all sequences are launched). In 1.1d, the grant_queued_locks() function has a loop with the following comment:

    // Grant the lock request and remove it from the queue.
    // This is a loop to handle multiple back-to-back locks.
    // Since each entry is deleted, i remains constant

This loop is missing in 1.2. In fact, the whole function looks to have been re-written entirely. To start, I noted that if I simply replaced the 1.2 code with the 1.1d code, the test passes.

 

In 1.2, the second begin block in grant_queued_locks() starts out like this:

  // now move all is_blocked() into lock_list
  begin
	uvm_sequence_request leading_lock_reqs[$],blocked_seqs[$],not_blocked_seqs[$];  
	int q1[$];
	int b=arb_sequence_q.size(); // index for first non-LOCK request
	q1 = arb_sequence_q.find_first_index(item) with (item.request!=SEQ_TYPE_LOCK);
	if(q1.size())
		b=q1[0];  
	if(b!=0) begin // at least one lock
		leading_lock_reqs = arb_sequence_q[0:b-1]; // set of locks; arb_sequence[b] is the first req!=SEQ_TYPE_LOCK	

Note the variable 'b'. It starts out as being the size of a queue, but then changes to an index in the arb_sequence_q variable. If that index happens to be 0, then the 'at least one lock' if statement won't be true. This is a real issue.

 

I'm going to try to find a patch that fixes it, but unless somebody here has an objection, I'll be submitting it to the Mantis page shortly.

 

 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×