| Title: Sequencer Classes | |
| The sequencer serves as an arbiter for controlling transaction flow from multiple | |
| stimulus generators. More specifically, the sequencer controls the flow of | |
| <uvm_sequence_item>-based transactions generated by one or more | |
| <uvm_sequence #(REQ,RSP)>-based sequences. | |
| (see uvm_ref_sequencer.gif) | |
| There are two sequencer variants available. | |
| - <uvm_sequencer #(REQ,RSP)> - Requests for new sequence items are initiated by | |
| the driver. Upon such requests, the sequencer selects a sequence from a list | |
| of available sequences to produce and deliver the next item to execute. | |
| This sequencer is typically connected to a user-extension of | |
| <uvm_driver #(REQ,RSP)>. | |
| - <uvm_push_sequencer #(REQ,RSP)> - Sequence items (from the currently running | |
| sequences) are pushed by the sequencer to the driver, which blocks item flow | |
| when it is not ready to accept new transactions. This sequencer is typically | |
| connected to a user-extension of <uvm_push_driver #(REQ,RSP)>. | |
| Sequencer-driver communication follows a ~pull~ or ~push~ semantic, depending | |
| on which sequencer type is used. However, sequence-sequencer communication is | |
| ~always~ initiated by the user-defined sequence, i.e. follows a push semantic. | |
| See <Sequence Classes> for an overview on sequences and sequence items. | |
| Sequence Item Ports: | |
| As with all UVM components, the sequencers and drivers described above use | |
| <TLM Interfaces> to communicate transactions. | |
| The <uvm_sequencer #(REQ,RSP)> and <uvm_driver #(REQ,RSP)> pair also uses a | |
| ~sequence item pull port~ to achieve the special execution semantic | |
| needed by the sequencer-driver pair. | |
| (see uvm_ref_seq_item_ports.gif) | |
| Sequencers and drivers use a ~seq_item_port~ specifically supports sequencer-driver | |
| communication. Connections to these ports are made in the same fashion as the | |
| TLM ports. | |