2.driver sequence handshake - DilipKrishnappa/UVM GitHub Wiki

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.

Generally, the Sequence as six function/operation for to communicate with the Driver they are

1.create_item() / create req. 2.wait_for_grant(). 3.randomize the req. 4.send the req. 5.wait for item done. 6.get response.

The above Sequence can

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.

Untitled Diagram (14)

                                                 Fig.1:Transaction Exchange between Driver Sequencer
  • 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.

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

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

  3. 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.

Copy of driver_sequence handshake

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

The sequence

2. Using get and put methods in driver

get_put

                                    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.