Questions on Lock() a sequencer

Question

Hi,

I was trying to understand the difference between grab() vs lock(). The page below says

https://verificationacademy.com/cookbook/sequences/lockgrab

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?

Thanks,
V

Answer 1

dave_59

Forum Moderator

11289 posts

February 01, 2020 at 9:29 pm

In reply to vbabusr:

Quote:

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.

— Dave Rich, Verification Architect, Siemens EDA

Answer 2

vbabusr

Full Access

15 posts

February 02, 2020 at 12:28 am

In reply to dave_59:

Hi Dave,

Thanks for your response.

Yes as you said, It should be the sequence item that get exclusive access to driver when use lock () from sequence body.

But as the cookbook says, lock() gives a sequence item exclusive access to driver when it gets next slot via arbitration mechanism.

The same thing happens even if we dont use lock right ? when it is the sequence_item's turn it will get exclusive access to the driver , am i right ?

Thanks,
V

Answer 3

dave_59

Forum Moderator

11289 posts

February 02, 2020 at 8:23 am

In reply to vbabusr:

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.

the Cookbook wrote:

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.

— Dave Rich, Verification Architect, Siemens EDA

Answer 4

haykp

Full Access

133 posts

February 02, 2020 at 10:36 pm

In reply to dave_59:

Hi Dave,

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?

Answer 5

vbabusr

Full Access

15 posts

February 02, 2020 at 11:02 pm

In reply to dave_59:

Hi Dave,

Thanks for the response.

Let us consider two difference scenarios

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.

Or am i missing anything here ?

Thanks,
V

Answer 6

vbabusr

Full Access

15 posts

February 02, 2020 at 11:03 pm

In reply to haykp:

Yes. That is the difference between lock and grab. grab will get to access the driver first than lock.

Thanks,
V

Answer 7

Solution

dave_59

Forum Moderator

11289 posts

February 04, 2020 at 11:44 am

In reply to vbabusr:

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.

— Dave Rich, Verification Architect, Siemens EDA

Answer 8

vbabusr

Full Access

15 posts

February 05, 2020 at 12:22 pm

In reply to dave_59:

Thanks for the explanation.

Answer 9

BharadwajSP

Full Access

1 post

May 20, 2023 at 6:40 am

In reply to dave_59:

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?

Answer 10

dave_59

Forum Moderator

11289 posts

May 21, 2023 at 9:08 am

In reply to BharadwajSP:

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.

— Dave Rich, Verification Architect, Siemens EDA

Languages & Standards

Methodologies

Techniques & Tools

Universal Verification Methodology (UVM)

Featured Courses

Additional Courses

Formal-Based Techniques

Analog/Mixed Signal

UVM Forum

SystemVerilog Forum

Coverage Forum

Additional Forums

Implementation Patterns

Specification Patterns

Pattern Resources

UVM Cookbook

Coding Guidelines & Deployment

Coverage Cookbook

Featured & On-Demand

On-Demand Library

Recording Archive

Conferences & WRG

Siemens EDA Learning Center

Blog & News

Verification Horizons Publication

About Us

Training

Solution

Portfolio

Explore

Siemens

Contact