walkeranderson Posted March 31, 2015 Report Share Posted March 31, 2015 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. Quote Link to comment Share on other sites More sharing options...
uwes Posted April 1, 2015 Report Share Posted April 1, 2015 hi, sounds like a bug. can you supply a testcase please? /uwe Quote Link to comment Share on other sites More sharing options...
walkeranderson Posted April 1, 2015 Author Report Share Posted April 1, 2015 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(); Quote Link to comment Share on other sites More sharing options...
jeff_fratus Posted May 24, 2016 Report Share Posted May 24, 2016 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@seqid3lock_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@seqid3num_last_reqs integral 32 'd1 num_last_rsps integral 32 'd1 -------------------------------------------------------------$finish at simulation time 3 Quote Link to comment Share on other sites More sharing options...
hevangel Posted June 17, 2016 Report Share Posted June 17, 2016 If you are using Cadence, try change "program test" to "module test" and see whether it solve your problem. I encountered SV threads scheduling issues when mixing class inside a program and sequence.get_next_item() in a module. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.