Jump to content

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
	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(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.




Link to post
Share on other sites


This topic is now archived and is closed to further replies.

  • Create New...