ssokorac Posted January 26, 2015 Report Share Posted January 26, 2015 According to the description of grant_queued_locks function in UVM 1.1d, it should grant any non-blocked locks that are at the top of the arbitration queue. However, what it appears to be doing is granting the first non-blocked lock in the queue, wherever it is. The function simply traverses the arbitration queue from the top and once it finds a non-blocked lock, it removes it to the queue and adds it to the lock list. As far as I can see, that's not the desired behaviour -- locks should be arbitrated in-order with other requests, and should not have a higher priority than others. I have a scenario where I have 3 sequences arbitrating for one sequencer. Two of them are making <lock><txn><txn><unlock> requests, while the third is just issuing normal transactions. That third sequence is starved, as one of the other two always has a pending lock that wins over it. Looking at the UVM 1.2 code, I can see that this function has been re-written and will properly jump out if the first request in the queue is not a lock. Is this a (known) bug in UVM 1.1? I can't find any mention of it in Mantis... Quote Link to comment Share on other sites More sharing options...
uwes Posted January 27, 2015 Report Share Posted January 27, 2015 hi, i think this has been fixed as part of another mantis (http://eda.org/svdb/view.php?id=4885) /uwe Quote Link to comment Share on other sites More sharing options...
ssokorac Posted January 27, 2015 Author Report Share Posted January 27, 2015 It looks like it was "accidentally" fixed by the rewrite of the function as a part of that fix, I guess? Do you know what's the policy on outstanding 1.1d bugs -- will there be a 1.1e with bug fixes, or are we left on our own to fix bugs in 1.1 if we don't want to switch to 1.2 at this point? Quote Link to comment Share on other sites More sharing options...
uwes Posted January 27, 2015 Report Share Posted January 27, 2015 hi, >It looks like it was "accidentally" fixed by the rewrite of the function as a part of that fix, I guess? when i rewrote the function due to the issue raised in the mantis i saw a couple of "suspect" code sections. i havent made a mantis for each suspect area. there is no intent to make a uvm11e. uvm is open source and all bugfixes are avail in the sourceforge repository. if you do require a fix for a particular bug feel free to merge in the one fix you you require.... Quote Link to comment Share on other sites More sharing options...
ssokorac Posted January 27, 2015 Author Report Share Posted January 27, 2015 Yeah, I did put in a fix for it, but I was wondering if going forward I will be able to abandon the "custom" version in favour of an official release, or if I'll need to maintain the patched version. It sounds like the latter is the case. Thanks for your help! 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.