Class uvm_pkg::uvm_transaction
Inheritance Diagram of uvm_transaction
Collaboration Diagram of uvm_transaction
Name |
Type |
Description |
---|---|---|
events |
Variable events The event pool instance for this transaction. This pool is used to track various milestones: by default, begin, accept, and end |
|
begin_event |
Variable begin_event A uvm_event#(uvm_object) that is triggered when this transaction's actual execution on the bus begins, typically as a result of a driver calling uvm_component::begin_tr. Processes that wait on this event will block until the transaction has begun. For more information, see the general discussion for uvm_transaction. See <uvm_event#(T)> for details on the event API. |
|
end_event |
Variable end_event A uvm_event#(uvm_object) that is triggered when this transaction's actual execution on the bus ends, typically as a result of a driver calling uvm_component::end_tr. Processes that wait on this event will block until the transaction has ended. For more information, see the general discussion for uvm_transaction. See <uvm_event#(T)> for details on the event API. virtual task my_sequence::body(); ... start_item(item); \ item.randomize(); } `uvm_do(item) finish_item(item); / // return from finish item does not always mean item is completed item.end_event.wait_on(); ... |
Constructors
- new(string name = "", uvm_component initiator = null)
Function
new
Creates a new transaction object. The name is the instance name of the transaction. If not supplied, then the object is unnamed. New
- Parameters:
name (string)
initiator (uvm_component)
Functions
- accept_tr(time accept_time = 0)
Function
accept_tr
Calling accept_tr indicates that the transaction item has been received by a consumer component. Typically a <uvm_driver #(REQ,RSP)> would call uvm_component::accept_tr, which calls this method-- upon return from a get_next_item() , get() , or peek() call on its sequencer port, <uvm_driver#(REQ,RSP)::seq_item_port>.
With some protocols, the received item may not be started immediately after it is accepted. For example, a bus driver, having accepted a request transaction, may still have to wait for a bus grant before beginning to execute the request.
This function performs the following actions
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. Accept_tr
- Parameters:
accept_time (time)
- begin_tr(time begin_time = 0)
Begin_tr
- Parameters:
begin_time (time)
- begin_child_tr(time begin_time = 0, integer parent_handle = 0)
Function
begin_child_tr
This function indicates that the transaction has been started as a child of a parent transaction given by parent_handle . Generally, a consumer component calls this method via uvm_component::begin_child_tr to indicate the actual start of execution of this transaction.
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
If recording is enabled, then a new database-transaction is started with the same begin time as above. The inherited uvm_object::record method 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. Use a parent handle of zero to link to the parent after begin
- Parameters:
begin_time (time)
parent_handle (integer)
- end_tr(time end_time = 0, bit free_handle = 1)
Function
end_tr
This function indicates that the transaction execution has ended. Generally, a consumer component ends execution of the transactions it receives.
You must have previously called begin_tr or begin_child_tr for this call to be successful.
Typically a <uvm_driver #(REQ,RSP)> would call uvm_component::end_tr, which calls this method, upon completion of a sequence item transaction. Sequence items received by a driver are always a child of a parent sequence. In this case, begin_tr obtain the parent handle and delegate to begin_child_tr.
This function performs the following actions
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. End_tr
- Parameters:
end_time (time)
free_handle (bit)
- get_tr_handle()
Function
get_tr_handle
Returns the handle associated with the transaction, as set by a previous call to begin_child_tr or begin_tr with transaction recording enabled. Get_tr_handle
- disable_recording()
Function
disable_recording
Turns off recording for the transaction stream. This method does not effect a uvm_component's recording streams. Disable_recording
- enable_recording(uvm_tr_stream stream)
Function
enable_recording
Turns on recording to the stream specified.
If transaction recording is on, then a call to record is made when the transaction is ended. Enable_recording
- Parameters:
stream (uvm_tr_stream)
- is_recording_enabled()
Function
is_recording_enabled
Returns 1 if recording is currently on, 0 otherwise. Is_recording_enabled
- is_active()
Function
is_active
Returns 1 if the transaction has been started but has not yet been ended. Returns 0 if the transaction has not been started. Is_active
- get_event_pool()
Function
get_event_pool
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 <uvm_pool#(KEY,T)>, e.g. a uvm_pool#(uvm_event) . Get_event_pool
- Return type:
- set_initiator(uvm_component initiator)
Function
set_initiator
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. Set_initiator
- Parameters:
initiator (uvm_component)
- get_initiator()
Function
get_initiator
Returns the component that produced or started the transaction, as set by a previous call to set_initiator. Get_initiator
- Return type:
- get_accept_time()
Function
get_accept_time. Get_accept_time
- get_begin_time()
Function
get_begin_time. Get_begin_time
- get_end_time()
Function
get_end_time
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. Get_end_time
- set_transaction_id(integer id)
Function
set_transaction_id
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. Set_transaction_id
- Parameters:
id (integer)
- get_transaction_id()
Function
get_transaction_id
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. Get_transaction_id
- do_print(uvm_printer printer)
Override data control methods for internal properties. Do_print
- Parameters:
printer (uvm_printer)
- do_record(uvm_recorder recorder)
Do_record
- Parameters:
recorder (uvm_recorder)
- do_copy(uvm_object rhs)
- Parameters:
rhs (uvm_object)
CLASS
uvm_transaction
The uvm_transaction class is the root base class for UVM transactions. Inheriting all the methods of uvm_object, uvm_transaction adds a timing and recording interface.
This class provides timestamp properties, notification events, and transaction recording support.
Use of this class as a base for user-defined transactions is deprecated. Its subtype, uvm_sequence_item, shall be used as the base class for all user-defined transaction types.
The intended use of this API is via a <uvm_driver #(REQ,RSP)> to call uvm_component::accept_tr, uvm_component::begin_tr, and uvm_component::end_tr during the course of sequence item execution. These methods in the component base class will call into the corresponding methods in this class to set the corresponding timestamps ( accept_time , begin_time , and end_time ), trigger the corresponding event (begin_event and end_event, and, if enabled, record the transaction contents to a vendor-specific transaction database.
Note that get_next_item/item_done when called on a uvm_seq_item_pull_port will automatically trigger the begin_event and end_events via calls to begin_tr and end_tr. While convenient, it is generally the responsibility of drivers to mark a transaction's progress during execution. To allow the driver or layering sequence to control sequence item timestamps, events, and recording, you must call <uvm_sqr_if_base#(REQ,RSP)::disable_auto_item_recording> at the beginning of the driver's run_phase task.
Users may also use the transaction's event pool, events, to define custom events for the driver to trigger and the sequences to wait on. Any in-between events such as marking the beginning of the address and data phases of transaction execution could be implemented via the events pool.
In pipelined protocols, the driver may release a sequence (return from finish_item() or it's `uvm_do macro) before the item has been completed. If the driver uses the begin_tr/end_tr API in uvm_component, the sequence can wait on the item's end_event to block until the item was fully executed, as in the following example.
A simple two-stage pipeline driver that can execute address and data phases concurrently might be implemented as follows: