Dirver components in the UVM

The driver component in the general UVM environment, derived from Uvm_driver.

Uvm_dirver derived from Uvm_component.

Class Uvm_driver # (Type REQ = Uvm_sequence_item, type RSP = REQ) extends Uvm_component

Which defines two ports:seq_item_port,driver generally use this interface to sequencer request sequence.

Rsp_port,driver sends response to the corresponding sequencer.

There is also a new function, nothing more.

The corresponding uvm_sequencer, derived from Uvm_sequencer_param_base, are derived from uvm_sequencer_base.

Class Uvm_sequencer # (Type Req=uvm_sequence_item, rsp=req) extends Uvm_sequencer_param_base (#REQ, RSP)

There is a seq_item_export defined. Provides access to this sequencer interface implementation.

Uvm_seq_item_pull_imp # (Req,rsp,this_type) Seq_item_export

Where the type of interface is Uvm_sqr_if_base # (REQ,RSP).

It implements the method: Get_next_item/try_next_item, first select the highest priority sequence in the sequencer, then the sequence wait_for_grant,

Then uvm_sequence_base::p re_do,randomized,post_do.

Item_done, once the previous task is called, the task must also be called. Indicates that a sequence end, FIFO can be moved out.

After obtaining sequence in the driver, the sequence needs to be changed to the type of signal the DUT can receive.

In the agent, you must connect Driver.seq_item_port.connect (Sequencer.seq_item_export) in Connect_phase. So sequence at the time of execution

The sequencer must be specified, and the sequencer is connected with the driver to finalize the purpose of sending transaction to the DUT. Of course, for a very simple

Transaction can also send a signal to the DUT directly in the sequence.

There is, however, a doubt about the relationship between the task body () in sequence and the execution of Sequencer's seq_item_port.

Dirver components in the UVM