UVM/uvm-1.2/docs/html/src/overviews/tlm2.txt

Section: TLM2 Interfaces, Ports, Exports and Transport Interfaces Subset

Sockets group together all the necessary core interfaces for
transportation and binding, allowing more generic usage models
than just TLM core interfaces.

A socket is like a port or export; in fact it is derived from the 
same base class as ports and export, namely <uvm_port_base #(IF)>. 
However, unlike a port or export a socket provides both a 
forward and backward path. Thus you can enable asynchronous 
(pipelined) bi-directional communication by connecting sockets 
together. To enable this, a socket contains both a port and an export.
Components that initiate transactions are called initiators, 
and components that receive transactions sent by an initiator 
are called targets. Initiators have initiator sockets and targets have target
 sockets. Initiator sockets can connect to target sockets. You cannot connect
 initiator sockets to other initiator sockets and you cannot connect target 
sockets to target sockets.

The UVM TLM2 subset provides the following two transport interfaces:

 Blocking (b_transport) - completes the entire transaction
within a single method call

 Non-blocking (nb_transport) - describes the progress of a
transaction using multiple nb_transport() method calls going
back-and-forth between initiator and target

In general, any component might modify a transaction object during
its lifetime (subject to the rules of the protocol). Significant timing
points during the lifetime of a transaction (for example: start of response-
phase) are indicated by calling nb_transport() in either
forward or backward direction, the specific timing point being given
by the phase argument.
Protocol-specific rules for reading or writing the attributes of a
transaction can be expressed relative to the phase. The phase can
be used for flow control, and for that reason might have a different
value at each hop taken by a transaction; the phase is not an
attribute of the transaction object.

A call to nb_transport() always represents a phase transition.
However, the return from nb_transport() might or might not do so,
the choice being indicated by the value returned from the function
(<UVM_TLM_ACCEPTED> versus <UVM_TLM_UPDATED>).
Generally, you indicate the completion of a transaction over a
particular hop using the value of the phase argument. As a shortcut,
a target might indicate the completion of the transaction by returning
a special value of <UVM_TLM_COMPLETED>. However, this is an option,
not a necessity.

The transaction object itself does not contain any timing information
by design. Or even events and status information concerning the
API. You can pass the delays as arguments to b_transport()/
nb_transport() and push the actual realization of any delay in the
simulator kernel downstream and defer (for simulation speed).

Use Models:
Since sockets are derived from <uvm_port_base #(IF)>
they are created and connected 
in the same way as port, and exports. Create them in the build phase and connect 
them in the connect phase by calling connect().
Initiator and target termination sockets are on the ends of any connection. 
There can be an arbitrary number of pass-through sockets in the path between 
initiator and target.
Some socket types must be bound to imps  implementations of the transport 
tasks and functions. Blocking terminator sockets must be bound to an 
implementation of b_transport(), for example. Nonblocking initiator 
sockets must be bound to an implementation of nb_transport_bw() and 
nonblocking target sockets must be bound to an implementation of 
nb_transport_fw(). Typically, the task or function is implemented in the 
component in which the socket is instantiated and the component type and 
instance are provided to complete the binding.

Consider for example a consumer component with a blocking target socket.

Example:
| class consumer extends uvm_component;
|    tlm2_b_target_socket #(consumer, trans) target_socket;
|    function new(string name, uvm_component parent);
|      super.new(name, parent);
|    endfunction
|    function void build();
|      target_socket = new("target_socket", this, this);
|    endfunction
|    task b_transport(trans t, uvm_tlm_time delay);
|      #5;
|      uvm_report_info("consumer", t.convert2string());
|    endtask
| endclass
| 
The interface task b_transport() is implemented in the consumer component. 
The consumer component type is used in the declaration of the target socket. 
This informs the socket object the type of the object that contains the 
interface task, in this case b_transport(). When the socket is instantiated 
"this" is passed in twice, once as the parent just like any other component 
instantiation and again to identify the object that holds the implementation 
of b_transport(). Finally, in order to complete the binding, an implementation 
of b_transport() must be present in the consumer component.
Any component that has either a blocking termination socket, a nonblocking
 initiator socket, or a nonblocking termination socket must provide 
implementations of the relevant components. This includes initiator and 
target components as well as interconnect components that have these kinds 
of sockets. Components with pass-through sockets do not need to provide 
implementations of any sort. Of course, they must ultimately be connected 
to sockets that do that the necessary implementations.

In summary:
 Call to b_transport() - start-of-life of transaction
 Return from b_transport() - end-of-life of transaction
 Phase argument to nb_transport() - timing point within lifetime
of transaction
 Return value of nb_transport() - whether return path is being
used (also shortcut to final phase)
 Response status within transaction object - protocol-specific
status, success/failure of transaction

On top of this, TLM-2.0 defines a generic payload and base protocol
to enhance interoperability for models with a memory-mapped bus
interface.

It is possible to use the interfaces described above with user-defined
transaction types and protocols for the sake of interoperability.
However, TLM-2.0 strongly recommends either using the base
protocol off-the-shelf or creating models of specific protocols on top
of the base protocol.

The UVM 1.2 standard only defines and supports this TLM2 style interface for
SystemVerilog to SystemVerilog communication. Mixed language TLM
communication is saved for future extension.