UVM Driver sequencer handshaking

UVM Driver sequencer handshaking

1. DRIVER AND SEQUENCER

2. Sequencer G enerates stimulus data and passes it to a driver for execution. The sequencer controls the flow of request and response sequence items between sequences and the driver Uses uvm_sequencer base class, which is parameterized by the request and response item types. The uvm_sequencer base class contains all of the base functionality required to allow a sequence to communicate with a driver. class  sequencer  extends   uvm_sequencer #( seqss_item );      ` uvm_sequencer_utils (sequencer)    function   new  ( string  name,  uvm_component parent);      super . new (name, parent);    endfunction  :  new endclass  

3. Driver The driver’s role is to drive data items to the bus following the interface protocol. The UVM Class Library provides the uvm_driver base class, from which all driver classes should be extended. The driver has a TLM port through which it communicates with the sequencer. The driver implement the run phase define its operation. To create a driver: a) Derive from the uvm_driver base class. b) If desired, add UVM infrastructure macros for class properties to implement utilities for printing, copying, comparing, and so on. c) Obtain the next data item from the sequencer and execute it. d) Declare a virtual interface in the driver to connect the driver to the DUT.

4. Driver Example code

5. Connecting the Driver and Sequencer The driver and the sequencer are connected via TLM, with the driver’s seq_item_port connected to the sequencer’s seq_item_export . The sequencer produces data items to provide via the export. The driver consumes data items through its seq_item_port and, optionally, provides responses. function void mas_agt :: connect_phase ( uvm_phase phase);     if( m_cfg.is_active == UVM_ACTIVE) begin     m_dri.seq_item_port.connect ( m_seqr.seq_item_export ); end endfunction

6. Basic Sequencer and Driver Interaction Basic interaction between the driver and the sequencer is done using the tasks get_next_item () and item_done (). the driver uses get_next_item () to fetch the next randomized item to be sent. After sending it to the DUT, the driver signals the sequencer that the item was processed using item_done (). forever begin get_next_item ( req ); // Send item following the protocol. item_done (); end get_next_item () is blocking until an item is provided by the sequences running on that sequencer.

7. Try_next_item Try_next_item will return in the same simulation step if no data items are available for execution. we can use this task to have the driver execute some idle transactions, such as when the DUT has to be stimulated when there are no meaningful data to transmit.

8. Sending Processed Data back to the Sequencer In some sequences, a generated value depends on the response to previously generated data. So the driver needs to return the processed response back to the sequencer. Do this using the optional argument to item_done (), seq_item_port.item_done ( rsp ); or using the put_response () method, seq_item_port.put_response ( rsp ); or using the built-in analysis port in uvm_driver . rsp_port.write ( rsp ); Before providing the response, the response’s sequence and transaction id must be set to correspond to the request transaction using rsp.set_id_info ( req ). put_response () is a blocking method, so the sequence must do a corresponding get_response ( rsp ).

9. Using TLM-Based Drivers The seq_item_port , which is built into uvm_driver , is a bidirectional port. It also includes the standard TLM methods get() and peek() for requesting an item from the sequencer, and put() to provide a response. peek() is a blocking method, so the driver may block waiting for an item to be returned. peek( req ); // Pause sequencer operation while the driver operates on the transaction. The get() operation notifies the sequencer to proceed to the next transaction. It returns the same transaction as the peek(), so the transaction may be ignored. get( req );//Allow sequencer to proceed immediately upon driver receiving transaction. To provide a response using the blocking_slave_port , the driver would call: seq_item_port.put ( rsp ); The response may also be sent back using an analysis_port as well.

10. Declaring User-Defined Sequences Sequences are made up of several data items, which together form an interesting scenario or pattern of data. To create a user-defined sequence: a) Derive a sequence from the uvm_sequence base class and specify the request and response item type parameters. In the example below, only the request type is specified, simple_item . This will result in the response type also being of type simple_item . b) Use the ` uvm_object_utils macro to register the sequence type with the factory. c) If the sequence requires access to the derived type-specific functionality of its associated sequencer, add code or use the ‘ uvm_declare_p_sequencer macro to declare and set the desired sequencer pointer. d) Implement the sequence’s body task with the specific scenario you want the sequence to execute. In the body task, you can execute data items and other sequences

11. Sequence Example code

12. Basic Flow for Sequences and Sequence Items To send a sequence item, the body() of a sequence needs to create() the item (use the factory)., call start_item () on the item, optionally randomize the item, and call finish_item () on the item. To send a subsequence, the body() of the parent sequence needs to create the subsequence, optionally randomize it, and call start() for the subsequence. If the subsequence item has an associated response, the parent sequence can call get_response ().

13. Fig.Sequence Item Flow

14. Sequencer Arbitration Multiple sequences can interact concurrently with a driver connected to a single interface. The sequencer supports an arbitration mechanism to ensure that at any point of time only one sequence has access to the driver. The choice of which sequence can send a sequence_item is dependent on a user selectable sequencer arbitration algorithm. T here are five built-in sequencer arbitration mechanisms that are implemented in UVM.

15. SEQ_ARB_FIFO (Default if none specified). If this arbitration mode is specified, then the sequencer picks sequence items in a FIFO order from all sequences running on the sequencer. For Example: if seq0, seq1,seq2 and seq3 are running on a sequencer, it will pick an item from seq0 first, followed by seq1, followed by seq2 and then seq3 if available, and continue .

16. SEQ_ARB_WEIGHTED: If this arbitration mode is selected, sequence items from the highest priority sequence are always picked first until none available, then the sequence items from next priority sequence, and so on. If two sequences have equal priority, then the items from them are picked in a random order.

17. SEQ_ARB_RANDOM: If this arbitration mode is selected, sequence items from different sequences are picked in a random order by ignoring all priorities .

18. SEQ_ARB_STRICT_FIFO: This is similar to SEQ_ARB_WEIGHTED except that if two sequences have same priority, then the items from those sequences are picked in a FIFO order rather than in a random order.

19. SEQ_ARB_STRICT_RANDOM: This is similar to SEQ_ARB_RANDOM except that the priorities are NOT ignored. The items are picked randomly from sequences with highest priority first followed by next and in that order . SEQ_ARB_USER : This algorithm allows a user to define a custom algorithm for arbitration between sequences. This is done by extending the uvm_sequencer class and overriding the user_priority_arbitration () method .