Driver Sequence Handshake

Introduction

In Universal Verification Methodology (UVM), The method called Driver Sequence Handshake is a mechanism, where we send the transactions from the sequence to the Driver in the order to provide stimulus to the DUT.Since we know that the whole understanding of different type of transactions is imbided into the sequences and Sequencers are being used as the physical component to execute those Sequences. A particular Sequence is directed to run on a Sequencer which in turns further breaks down into a series of transaction items and these transaction items are needs to be transferred to the Driver where these transaction items are converted into cycle based signal/pin level transitions.

The Sequencer get the series of the transaction item/sequence_item through the sequence. This transaction items are needs to be transferred to the Driver where these transaction items are converted into cycle based signal/pin level transitions.

Sequence-Driver-Sequencer communication

Based on the varieties of methods available with sequence and driver, they are two Methods

1. Using get_next_item and item_done methods in the driver

2. Using get and put methods in driver

1.Using get_next_item and item_done methods in the driver

The below Fig.1 & fig.2 show the Transaction Exchange flow between the component Having said that, sending a transaction/sequence_item from a Sequencer to a Driver is a 4 step process which is discussed below.

                                                 Fig.1:Transaction Exchange between Driver Sequencer

                                         Fig.2: Flow of Transactions between Sequencer,Driver and DUT.

• The Driver class contains the TLM port called uvm_seq_item_pull_port is connected to the uvm_seq_item_pull_Export called sequencer Both are connected in the run phase of UVM_AGENT. The driver can use the TLM function to get the next item from the Sequencer when it is required.

Sequencer side operation:

1.Creating the “transaction item” with the declared handle using factory mechanism.

2. Calling “start_item(<transaction_item_handle>)“. This call blocks the Sequencer till it grants the Sequence and transaction access to the Driver.

3. Randomizing the transaction OR randomizing the transaction with in-line constraints. Now the transaction is ready to be used by the Driver.

4. Calling “finish_item(<transaction_item_handle>)“. This call which is blocking in nature waits till Driver transfer the protocol related transaction data.

• These are the operational steps from a Sequence which we want to execute using a Sequencer that is connected to a Driver inside an Agent component. Whole of this process is shown in the Figure 1 & Figure 2 above.

Driver side operation:

1. Declaring the “transaction item” with a handle.

2. Calling the “get_next_item(<transaction_item_handle>)“. Default transaction_handle is “req”. “get_next_item()” blocks the processing until the “req” transaction object is available in the sequencer request FIFO & later “get_next_item” returns with the pointer of the “req” object.

3. Next, Driver completes its side protocol transfer while working with the virtual interface.

4. Calling the “item_done()” OR “item_done(rsp)“. It indicates to the sequencer the completion of the process. “item_done” is a non-blocking call & can be processed with an argument or without an argument. If a response is expected by the Sequencer/Sequence then item_done(rsp) is called. It results in Sequencer response FIFO is updated with the “rsp” object handle.

• when multiple sequences try to access a single driver, the sequencer that is executing the sequences, schedules them in certain order called as Arbitration based on the sequence priority. Based on that the sequencer can grant driver access to the certain sequences.

2. Using get and put methods in driver

                                    Figure.3. get() and put() method  

• Create a sequence item and register in the factory using the create_item function call.
• The wait_for_grant issues the request to the sequencer and wait for the grant from the sequencer. It returns when the sequencer has granted the sequence.
• Randomize the sequence item and send it to the sequencer using send_request call. There should not be any simulation time delay between wait_for_grant and send_request method call.
• The sequencer forwards the sequence item to the driver with the help of REQ FIFO. This unblocks the get() call and the driver receives the sequence item.
• The wait_for_item_done() call from the sequence gets blocked until the driver calls the get method.
• Once the get method is called, the wait_for_item_done() call from sequence gets unblocked immediately without caring about driving the signal from DUT.
• The get_response call is necessary to call that completes the communication. The get_response method is blocked until the driver calls put(RSP).
• In the meantime, the driver drives the sequence item to the DUT using a virtual interface handle. Once it is completed, the put(RSP) method is called. This unblocks the get_response method from the sequence. The RSP item is communicated to the sequence by a sequencer with help of RSP FIFO.