Response handling between UVM Driver and Sequencer for Pipelined Protocols

In the pipelined protocols, the handling of response requires a different approach as compared to other non-pipelined protocols. In other protocols, the Driver and Sequencer synchronization can be implemented in a simpler way, where the Driver gets the transaction item from the Sequencer, drives it on the interface and then sends the response back to the Sequencer just after calling the item done and before getting the new transaction item again from the Sequencer. However, the same method of sending response cannot be used while dealing with the protocols where the response is pipelined.

In case of pipelined response, the Driver cannot send the response to the Sequencer at the time when no response has been driven on the bus by the Slave. If Driver waits for sampling the response at the right clock cycle before sending it to the Sequencer then it will get the next packet from the Sequencer with some delay. During the time when Driver is waiting for the response and also it has not fetched the new transaction packet from the Sequencer, it has to drive Idle transfers on the interface. If we want the scenario of continuous back to back transactions on the interface without Idle transfers in between, it cannot be achieved in this case.

Let us take the example of AHB protocol, according to AHB a simple transfer proceeds with the below given steps (also shown in figure 1):

1. The master drives the address and control signals onto the bus after the rising edge of HCLK.

2. The slave then samples the address and control information on the next rising edge of HCLK.

3. After the slave has sampled the address and control it can start to drive the appropriate HREADY response.   This response is sampled by the master on the third rising edge of HCLK.

                                                           Figure 1: Simple AHB write and read transfers with Idle in between

To get the continuous back to back transactions (shown in figure 2), Driver needs to put response immediately (this response would be a dummy response just to get the next packet from Sequencer) or call the item done without sending any response so that the next burst can be started without an Idle transfer. But, till that time response or read data is not sampled by the Driver as it is available after two clock cycles or at the third posedge. Therefore, we will not be able to use the response / read data in the Sequence if required.

                                                            Figure 2: AHB back to back write and read transfers without Idle

To meet the requirements of synchronizing Sequencer and Driver with no Idle transfers in between the bursts, along with sampling the correct response/read data, we can use the methods as suggested in UVM User’s Guide for the pipelined protocols operating on several transactions at the same time. One of these methods is using “rsp_port” (shown in Figure 3) which is an inbuilt analysis port of uvm_driver and is used to send the response back to the Sequencer.

                       Figure 3: Response handling for pipelined protocols using “rsp_port”

The code snippets below are showing the cases of response handling between Driver and Sequencer without using “rsp_port”:

A). Putting response after collecting the response / read data from bus - Able to collect and send the correct response / read data but not able to generate back to back transfers without Idle 

             seq_item_port.get_next_item(req);  // Get the transaction packet from Sequencer

…..             

…..                                                            // Drive transaction on the interface and sample response / read data

…..

seq_item_port.item_done(rsp);        // Send the response packet to Sequencer

B). Putting response immediately without waiting for the response / read data on the bus or do not put response - Back to back transfers possible without Idle but not able to collect and send correct response / read data

seq_item_port.get_next_item(req);  // Get the transaction packet from Sequencer

seq_item_port.item_done(rsp);        // Send the response packet to Sequencer

…..             

…..                                                          // Drive transaction on the interface and sample response / read data

…..

or

seq_item_port.get_next_item(req);  // Get the transaction packet from Sequencer

seq_item_port.item_done();             // Do not send any response to Sequencer

…..             

…..                                                          // Drive transaction on the interface and sample response / read data

…..

The code snippet below shows the response handling between Driver and Sequencer using “rsp_port”:

C).Using “rsp_port” to put response after collecting the response from bus - Able to collect and send the correct response / read data along with the back to back transfers without Idle -

              seq_item_port.get_next_item(req); // Get the transaction packet from Sequencer

 seq_item_port.item_done(rsp);       // Send the dummy response packet to Sequencer

…..             

…..                                                         // Drive transaction on the interface and sample response / read data

…..

rsp_port.write(rsp);                          // Sending the response sampled from the bus to the Sequencer in parallel

Summary: By using “rsp_port”, we can complete the Driver and Sequencer synchronization with collecting and sending the right response and read data and can also achieve the requirement of continuous back to back transfers in case of pipelined protocols.