Hi, I’m quite curious about the purpose of these recording interfaces - accept_tr, begin_tr, and end_tr.
I’ve read that the purpose of these is to “mark the acceptance of transaction, the beginning of transaction, and end of transaction.”
Now, what I’m confuse about is, if the purpose of it is just to mark, then why not just use `uvm_info to report that a transaction has been accepted, started, or ended?
Is there any special on the recording interfaces I mentioned?
In reply to Reuben:
Hi Reuben,
I have captured more details from the UVM Class Reference manual.
Calling accept_tr indicates that the transaction item has been received by a consumer component. Typically a <uvm_driver> 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::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 begining to execute the request.
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.
For begin_tr :
This function indicates that the transaction has been started and is not the child of another transaction. Generally, a consumer component begins execution of a transactions it receives.
Typically a <uvm_driver> would call uvm_component::begin_tr, which calls this method, before actual execution of a sequence item transaction. Sequence items received by a driver are always a child of a parent sequence. In this case, begin_tr obtains the parent handle and delegates to begin_child_tr.
See accept_tr for more information on how the begin-time might differ from when the transaction item was received.
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.
For 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> 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
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.
Best Regards,
Chetan Shah
Sr. ASIC Verification Engineer
Product Engineering Services
Software | Embedded | Semiconductor
www.einfochips.com
Frost & Sullivan Company of the Year 2013-14