uvm_transaction

Creates a new transaction object.  The name is the instance name of the transaction.  If not supplied, then the object is unnamed.

Calling accept_tr indicates that the transaction has been accepted for processing by a consumer component, such as an uvm_driver.  With some protocols, the transaction may not be started immediately after it is accepted.  For example, a bus driver may have to wait for a bus grant before starting the transaction.

This function performs the following actions

• The transaction’s internal accept time is set to the current simulation time, or to accept_time if provided and non-zero.  The accept_time may be any time, past or future.
• The transaction’s internal accept event is triggered.  Any processes waiting on the this event will resume in the next delta cycle.
• The do_accept_tr method is called to allow for any post-accept action in derived classes.

This user-definable callback is called by accept_tr just before the accept event is triggered.  Implementations should call super.do_accept_tr to ensure correct operation.

This function indicates that the transaction has been started and is not the child of another transaction.  Generally, a consumer component begins execution of the transactions it receives.

This function performs the following actions

• The transaction’s internal start time is set to the current simulation time, or to begin_time if provided and non-zero.  The begin_time may be any time, past or future, but should not be less than the accept time.
• If recording is enabled, then a new database-transaction is started with the same begin time as above.
• The do_begin_tr method is called to allow for any post-begin action in derived classes.
• The transaction’s internal begin event is triggered.  Any processes waiting on this event will resume in the next delta cycle.

The return value is a transaction handle, which is valid (non-zero) only if recording is enabled.  The meaning of the handle is implementation specific.

This function indicates that the transaction has been started as a child of a parent transaction given by parent_handle.  Generally, a consumer component begins execution of the transactions it receives.

The parent handle is obtained by a previous call to begin_tr or begin_child_tr.  If the parent_handle is invalid (=0), then this function behaves the same as begin_tr.

This function performs the following actions

• The transaction’s internal start time is set to the current simulation time, or to begin_time if provided and non-zero.  The begin_time may be any time, past or future, but should not be less than the accept time.
• If recording is enabled, then a new database-transaction is started with the same begin time as above.  The record method inherited from uvm_object is then called, which records the current property values to this new transaction.  Finally, the newly started transaction is linked to the parent transaction given by parent_handle.
• The do_begin_tr method is called to allow for any post-begin action in derived classes.
• The transaction’s internal begin event is triggered.  Any processes waiting on this event will resume in the next delta cycle.

The return value is a transaction handle, which is valid (non-zero) only if recording is enabled.  The meaning of the handle is implementation specific.

This user-definable callback is called by begin_tr and begin_child_tr just before the begin event is triggered.  Implementations should call super.do_begin_tr to ensure correct operation.

This function indicates that the transaction execution has ended.  Generally, a consumer component ends execution of the transactions it receives.

This function performs the following actions

• The transaction’s internal end time is set to the current simulation time, or to end_time if provided and non-zero.  The end_time may be any time, past or future, but should not be less than the begin time.
• If recording is enabled and a database-transaction is currently active, then the record method inherited from uvm_object is called, which records the final property values.  The transaction is then ended.  If free_handle is set, the transaction is released and can no longer be linked to (if supported by the implementation).
• The do_end_tr method is called to allow for any post-end action in derived classes.
• The transaction’s internal end event is triggered.  Any processes waiting on this event will resume in the next delta cycle.

This user-definable callback is called by end_tr just before the end event is triggered.  Implementations should call super.do_end_tr to ensure correct operation.

Returns the handle associated with the transaction, as set by a previous call to begin_child_tr or begin_tr with transaction recording enabled.

Turns off recording for the transaction stream.  This method does not effect a uvm_component’s recording streams.

Turns on recording to the stream specified by stream, whose interpretation is implementation specific.  The optional recorder argument specifies

If transaction recording is on, then a call to record is made when the transaction is started and when it is ended.

Returns 1 if recording is currently on, 0 otherwise.

Returns 1 if the transaction has been started but has not yet been ended.  Returns 0 if the transaction has not been started.

Returns the event pool associated with this transaction.

By default, the event pool contains the events: begin, accept, and end.  Events can also be added by derivative objects.  An event pool is a specialization of an <uvm_pool #(T)>, e.g. a uvm_pool#(uvm_event).

Sets initiator as the initiator of this transaction.

The initiator can be the component that produces the transaction.  It can also be the component that started the transaction.  This or any other usage is up to the transaction designer.

Returns the component that produced or started the transaction, as set by a previous call to set_initiator.

Returns the time at which this transaction was accepted, begun, or ended, as by a previous call to accept_tr, begin_tr, begin_child_tr, or end_tr.

Sets this transaction’s numeric identifier to id.  If not set via this method, the transaction ID defaults to -1.

When using sequences to generate stimulus, the transaction ID is used along with the sequence ID to route responses in sequencers and to correlate responses to requests.

Returns this transaction’s numeric identifier, which is -1 if not set explicitly by set_transaction_id.

When using a uvm_sequence #(REQ,RSP) to generate stimulus, the transaction ID is used along with the sequence ID to route responses in sequencers and to correlate responses to requests.