The sequencer lock method is called from a sequence and its effect is that the calling sequence will be granted exclusive access to the driver when it gets its next slot via the sequencer arbitration mechanism → Is it not something that happens usually even if we dont use lock ? Also can someone explain what it means to say exclusive access to the driver ? When a sequence gains access to the driver after going through arbitration, should it not be getting exclusive access to the driver anyways?
When a sequence gains access to the driver after going through arbitration, should it not be getting exclusive access to the driver anyways?
That is not correct. It’s the sequence_item that gets a slot, between start_item and finish_item. Another sequence can be in the arbitration queue with its sequence_item.
You are correct in stating that a sequence_item always has exclusive access to the driver. A sequencer can only send one sequence_item to the driver at a time. But you are confusing sequence and sequence*_item* when it comes to sequence to sequencer protocal.
Once lock is granted, no other sequences will be able to access the driver until the sequence issues an unlock() call which will then release the lock.
You can have many sequences running in parallel requesting that sequence_items be sent through the sequencer. Through the sequencer arbitration mechanism, only one sequence will be granted access to send their sequence_item to the driver. During that time, that sequence and its sequence_item have exclusive access to the connected driver.
It’s at the point when that sequence_item is done and it’s time to choose the next sequence_item when lock() and grab() become relevant.
Assume we have s0 currently sending transaction to driver. And we have 3 sequences- s1,s2,s3, trying to run on sequencer in parallel. And s1 out of these 3 uses lock method.
Now after s0 is done, s1 will get the sequencer and start sending transactions?
The lock method assures that the next sequence which will access to driver is s1. Is that right?
Than what is grab() here?
The grab method is similar to the lock method, except that it takes immediate effect and will grab the next sequencer arbitration slot, overriding any sequence priorities in place. T
So that means if s1 is using grab, s2 using lock, than s1 will get access to driver?
Scenario 1: In a TB say, sequence’s S0’s sequence item is accessing the drive and we have three sequences S1, S2 and S3 ( none of them are using lock or grab ) and they are in corresponding sequencer waiting ( say some other sequence’s S0’s sequence item is accessing the drive ) in the order ( S1 ->S2-> S3 ) with arbitration being FIFO
So the order in which the sequences’ S* sequence item will access the driver is S1->S2->S3.
Scenario 2: In a TB say, sequence’s S0’s sequence item is accessing the drive and we have three sequences S1, S2 and S3 ( out of these say S2 uses lock()and unlock() calls ) and they are in corresponding sequencer in the order ( S1 ->S2-> S3 ) with arbitration being FIFO
Based on the statement in the cookbook which says: The sequencer lock method is called from a sequence and its effect is that the calling sequence will be granted
exclusive access to the driver when it gets its next slot via the sequencer arbitration mechanism.
my understanding is that even in the scenario 2, the sequences S* sequence item will access the driver is S1->S2->S3.
So, Can you help me understand the significance of lock() in scenario 2 ? The order of completion seems to be the same in both the cases.
I can see the difference if we had used grab() , ungrab() in scenarion 2 instead of lock and unlock, the order of access to the driver would be S2, S1 and S3.
It might help to show some code for the scenarios you have trouble comprehending. I’m assuming each sequence will be sending in several sequence items. Also assume that S1,S2,S3 are identical instances of the following running in parallel
task my_sequence::body();
repeat (20) begin
req = my_sequence_item::type_id::create(...);
start_item(req);
finish_item(req);
end
lock()
repeat (20) begin
req = my_sequence_item::type_id::create(...);
start_item(req);
finish_item(req);
end
unlcok();
endtask
The first 60 sequences will be FIFO arbitrated with 20 sequence items from each sequence. (S1.1 ->S2.1-> S3.1 → S1.2 ->S2.2-> S3.2 ->…-> S3.20) All three sequences will issue a lock after finishing from their 20th sequence_item. When S1’s 21st sequence_item get granted, the lock becomes effective and the next 20 sequence items will come from S1. (S1.21 ->S1.22-> S1.23 → S1.24 ->…S1.40). Followed by 20 from S2 and then S3.
The only difference if grab() was used instead lock() is that S2.20 and S3.20 have not been granted and S1.21 would get an overriding priority to be started.
I am new to the UVM and hence might be trying something illogical. But nevertheless, I noticed that in the case of multiple virtual sequences running on a single virtual sequencer, Two sequences will get locked onto the sequencer.
So in general, let’s say virtual sequences running on the same sequencer lock method behavior is not defined. is my understanding correct here?
We suggest not using a virtual sequencer (use null instead), then you do not run into this problem. Only sequences sending transactions items to a driver need a sequencer.