11. TLM-2.0 core interfaces
11. TLM-2.0 核心接口
In addition to the core interfaces from TLM-1, TLM-2.0 adds blocking and non-blocking transport interfaces,
a direct memory interface (DMI), and a debug transport interface.
在对TLM-1的改进中，TLM-2.0增加了阻塞和非阻塞传输接口、一个直接内存接口、一个调试传输接口。
11.1 Transport interfaces
11.1 传输接口
The transport interfaces are the primary interfaces used to transport transactions between initiators, targets,
and interconnect components.
事务传输接口是在发起者、目标、和互联组件之间传输事务的主要接口。
Both the blocking and non-blocking transport interfaces support timing annotation and temporal decoupling,
but only non-blocking transport supports multiple phases within the lifetime of a transaction.
阻塞和非阻塞传输接口都支持时间标注和时间解耦，但是只有非阻塞传输接口支持多相位出现在一个事务的整个生命周期里。
Blocking transport does not have an explicit phase argument, and any association
between blocking transport and the phases of the non-blocking transport interface is purely notional.
阻塞传输接口没有显式的相位参数，并且，在阻塞传输接口和非阻塞传输接口的相位之间的任何联系，都纯属猜测。
Only the non-blocking transport method returns a value indicating whether or not the return path was used.
只有非阻塞传输方法会返回一个值，这个值用来标志返回路径是否被使用。
The transport interfaces and the generic payload were designed to be used together for the fast, abstract
modeling of memory-mapped buses.
传输接口和通用载荷被设计成合作关系，它们一起对内存映射总线进行快速的抽象的建模。
The transport interface templates are specialized with the transaction type allowing them to be used separately from the generic payload,
although many of the interoperability benefits would be lost.
事务传输接口模板由事务类型来指定，也就是可以把传输接口不一定必须使用通用载荷搭配，当然，这将导致互操作性的好处丧失。
The rules governing memory management of the transaction object, transaction ordering, and the permitted
function calling sequence depend on the specific transaction type passed as a template argument to the transport interface,
which in turn depends on the protocol traits class passed as a template argument to the socket (if a socket is used).
在事务的内存管理、事务的排序、和允许的函数调用顺序方面的约束规则，依赖于指定给事务传输接口模板类的事务类的类型；
当然，这个类型要与指定给套接字的模板协议特性类型相一致。
11.1.1 Blocking transport interface
11.1.1 阻塞传输接口
11.1.1.1 Introduction
11.1.1.1 简介
The TLM-2.0 blocking transport interface is intended to support the loosely-timed coding style.
TLM-2.0中的阻塞传输接口是为支持松散时间编程风格而设计的。
The blocking transport interface is appropriate where an initiator wishes to complete a transaction with a target during
the course of a single function call, the only timing points of interest being those that mark the start and the end of the transaction.
当发起者希望在一次函数调用过程中完成与目标之间的一个事务时，阻塞传输接口是合适的选择；这种场景中，有兴趣的计时点只在乎事务的开始和结束的时间点。
（译者：套接字绑定正确后，在发起者的套接字的一次b_transport(*transaction_ptr, delay)调用中，在子函数内部会一直调用到目标自己实现的b_transport(...),并执行事务里的命令，然后再一层层返回。）.
The blocking transport interface only uses the forward path from initiator to target.
阻塞传输接口只使用从发起者到目标的前向路径。
The TLM-2.0 blocking transport interface has deliberate similarities with the transport interface from TLM-1,
which is still part of the TLM-2.0 standard, but the TLM-1 transport interface
and the TLM-2.0 blocking transport interface are not identical.
TLM-2.0的阻塞传输接口故意设计的跟TLM-1的传输接口相似，TLM-1的传输接口依然是TLM-2.0标准的一部分，
但是TLM-1的传输接口与TLM-2.0的阻塞传输接口并不完全相同。
In particular, the new b_transport method has a single transaction argument passed by non-const reference
and a second argument to annotate timing,
whereas the TLM-1 transport method takes a request as a single const reference request argument,
has no timing annotation, and returns a response by value.
特别的，TLM-2.0中的b_transport方法，有一个单独的事务的不可改变的引用来传递参数，第二个参数用来标注定时时间，
然而，TLM-1的传输方法使用一次请求事务作为一个单独的不可改变的引用请求参数，而且没有定时标注，用返回值来作为回应。
TLM-1 assumes separate request and response objects passed by value (or
const reference), whereas TLM-2.0 assumes a single transaction object passed by reference, whether using
the blocking or the non-blocking TLM-2.0 interfaces.
TLM-1假定了独立的通过值传递或常引用传递的请求和响应对象，然而，TLM-2.0假定了单个通过引用来传递的事务对象，无论是在LM-2.0的在阻塞或者非阻塞接口中。
The b_transport method has a timing annotation argument.
阻塞方法有一个定时标注参数。
This single argument is used on both the call to and the return from b_transport to indicate the time of the start and end of the transaction,
respectively, relative to the current simulation time.
在对b_transport()的调用和返回里，使用同一个参数在指示事务的开始和结束，分别就是当前的仿真时间。
11.1.1.2 Class definition
11.1.1.2 类的定义
namespace tlm {
template <typename TRANS = tlm_generic_payload>
class tlm_blocking_transport_if : public virtual sc_core::sc_interface {
public:
virtual void b_transport(TRANS& trans, sc_core::sc_time& t) = 0;
};
} // namespace tlm
11.1.1.3 The TRANS template argument
模板参数TRANS
The intent is that this core interface may be used to transport transactions of any type.
这个参数的设计意图是希望tlm_blocking_transport_if能够传输任意类型的事务。
A specific transaction type, tlm_generic_payload, is provided to ease interoperability between models
where the precise details of the transaction attributes are less important.
在一个特别的事务类型，tlm_generic_payload，用来增强模型间的互操作性，主要应用在事务属性的精确细节不怎么重要的情况。
For maximum interoperability, applications should use the default transaction type tlm_generic_payload with the base protocol (see 15.2).
为了最大化互操作性，应用程序应该使基础协议和默认的事务类型 tlm_generic_payload。
In order to model specific protocols, applications may substitute their own transaction type.
为了能够对特别的协议进行建模，应用程序可以使用自己设计的事务类型替代tlm_generic_payload。
Sockets that use interfaces specialized with different transaction types cannot be bound together,
providing compile-time checking but restricting interoperability.
指定为不同事务类型的套接字之间不能绑定在一起，这会提供编译时的检查，限制互操作性。
11.1.1.4 Rules
11.1.1.4 规则
a) The b_transport method may call wait, directly or indirectly.
a)b_transort方法可以直接或间接地调用wait调度函数。
b) The b_transport method shall not be called from a method process.
b)b_transport方法不应该被方法进程调用。{译者注：方法一般是作为硬件电路的器件功能，一般不参与传输事务。}
c) The initiator may reuse a transaction object from one call to the next
and across calls to the transport interfaces, DMI, and the debug transport interface.
c) 发起者可以重用一个事务对象，事务对象可以从一个调用到下一个调用，也可以跨越事务传输调用、DMI调用和调试传输接口。
d) The call to b_transport marks the first timing point of the transaction.
The return from b_transport marks the final timing point of the transaction.
d) 对)b_transport的调用时刻标识了事务的起始计时点，返回的时刻表示了事务的结束计时点。
e) The timing annotation argument allows the timing points to be offset from the simulation times
(value returned by sc_time_stamp()) at which the function call and return are executed.
e) 计时标注参数允许计时点偏离函数被调用和返回时的仿真时间（仿真时间也就是sc_time_stamp()返回的值。）
f) The callee may modify or update the transaction object, subject to any constraints imposed by the transaction class TRANS.
f) 被调者可以修改或更新事务对象，服从于事务类TRANS所强加的约束条件。
g) It is recommended that the transaction object should not contain timing information.
Timing should be annotated using the sc_time argument to b_transport.
g) 不推荐在事务对象中包含计时信息。计时信息应该标注在函数b_transport的sc_time类型的参数中。
h) Typically, an interconnect component should pass the b_transport call along the forward path from
initiator to target.
In other words, the implementation of b_transport for the target socket of the interconnect component
may call the b_transport method of an initiator socket.
h) 典型的方式，一个互联组件应该沿着前向路径把对b_transport的调用传递下去。也就是说，互联组件中的目标套接字的b_transport函数可以调用互联组件里的发起者套接字的b_transport方法。
i) Whether or not the implementation of b_transport is permitted to call nb_transport_fw depends on the rules associated with the protocol.
For the base protocol, the convenience socket simple_target_socket is able to make this conversion automatically (see 16.1.2).
i) b_transport的实现中是否可以调用nb_transport_fw，是由协议的规则决定的。对于基础协议而言，便利套接字simple_target_socket是能够自动转换两类调用的。
j) The implementation of b_transport shall not call nb_transport_bw.
j) b_transport的实现不能够调用nb_transport_bw.
11.1.1.5 Message sequence chart—blocking transport
11.1.1.5 消息序列图 之阻塞传输
The blocking transport method may return immediately (that is, in the current SystemC evaluation phase)
or may yield control to the scheduler and only return to the initiator at a later point in simulation time (Figure 20).
阻塞传输方法可以理解返回(也就是说，在当前的System C的评估阶段)，或者会让出控制权给调度器，并且在仿真时间上稍晚的一个时间点返回发起者。
Although the initiator thread may be blocked, another thread in the initiator may be permitted to call b_transport
before the first call has returned, depending on the protocol.
虽然发起者进程可能被阻塞，在这个被阻塞的进程返回之前，发起者的的另一个进程可以调用b_transport()，这取决与协议。
===
图20
===
11.1.1.6 Message sequence chart—temporal decoupling
11.1.1.6 消息序列图 之时间解耦
A temporally decoupled initiator may run at a notional local time in advance of the current simulation time,
in which case it should pass a non-zero value for the time argument to b_transport, as shown below.
一个时间解耦的发起者可以运行在一个超过当前仿真时间的想象的局部时间上，在这种情况下，它应当传递给b_transport一个非零值作为时间参数，如下图所示。
The initiator and target may each further advance the local time offset by increasing the value of the time argument.
发起者和目标任何一个都可能进一步推进这个局部时间偏移，这通过增加这个时间参数的值来实现。
Adding the time argument returned from the call to the current simulation time gives the notional time at which each the transaction completes,
but simulation time itself cannot advance until the initiator thread yields.
把从调用返回的时间参数加到当前仿真时间上，就给出了每一个事务结束的想象时间；但是指导发起者进程让出控制权，仿真时间才可以继续向前推进。
The body of b_transport may itself call wait, in which case the local time offset should be reset to zero.
b_transport的函数体自己可能会调用wait函数，在这种情况下，本地时间便宜应当归零。
In Figure 21, the final return from the initiator happens at simulation time 140 ns, but with an annotated delay
of 5 ns, giving an effective local time of 145 ns.
在图21中，从发起者最后的返回发生在仿真时间点140纳秒时，但是标注的延迟时间为5纳秒，给出的有效本地时间就是145纳秒。
===
图21
===
11.1.1.7 Message sequence chart—the time quantum
11.1.1.7 消息序列图 之时间量子
（译者：在使用时间量子时，系统的仿真时间是一个量子一个量子地往前统计的。每个模型自己在线程里统计自己本次运行累计的局部运行时间，当超过应当运行的时间时就运行wait之类的函数，归还控制权。只有当所有的模型的仿真时间都运行完本量子时间段后，认为同步结束。然后系统的仿真时间再开始进入下一个量子。【不知道说的清不清楚】）
A temporally decoupled initiator will continue to advance local time until the time quantum is exceeded
(Figure 22).
时间解耦的发起者将继续推进本地时间直到超越了时间量子的时候（如图22）.
At that point, the initiator is obliged to synchronize by suspending execution, directly or
indirectly calling the wait method with the local time as an argument.
在这个时刻，发起者会被通过挂起执行来强制同步，以本地时间作为参数直接或间接地调用wait方法。
This allows other initiators in the model to run and to catch up, which effectively means that the initiators execute in turn,
each being responsible for determining when to hand back control by keeping track of its own local time.
这样会允许模型中的其他发起者运行并追赶上来，这在效果上意味着这些发起者会轮流执行，
每一个发起者通过跟踪自己的本地时间自己负责决定何时归还控制权。
The original initiator should only run again after simulation time has advanced to the next quantum.
只有在仿真时间推进到了下一个量子时间段中时，起初的发起者才可以重新运行。
The primary purpose of delays in the loosely-timed coding style is to allow each initiator to determine when to hand back control.
松散时间编程风格中引入时间延迟，起初是为了允许每一个发起者自己决定什么时候归还控制权。
It is best if the model does not rely on the details of the timing in order to function correctly.
如果一个模型不需要依赖计时细节就能够正确发挥功能，这当然是最好的建模方式。
Within each quantum, the transactions generated by a given initiator happen in strict sequential order
but without advancing simulation time. The local time is not tracked by the SystemC scheduler.
在每一个量子时间段里，一个特定的发起者所产生的哪些事务会严格按照顺序发生，这个过程中系统的仿真时间并不会向前推进。
另外，SystemC的调度器并不负责跟踪模块的局部时间。
===
图22
===
11.1.2 Non-blocking transport interface
11.1.2 非阻塞传输接口
11.1.2.1 Introduction
11.1.2.1 简介
The non-blocking transport interface is intended to support the approximately-timed coding style.
设计非阻塞传输接口是为了支持近似时间编程风格。
The nonblocking transport interface is appropriate where it is desired to model the detailed sequence of interactions
between initiator and target during the course of each transaction.
非阻塞传输接口 适合的情景是，希望对在一个事务的传输过程中发起者和目标之间互动的详细顺序进行建模。
In other words, to break down a transaction into multiple phases, where each phase transition is associated with a timing point.
换句话说，把一个事务的传输过程分解成多个相位(阶段)，每次相位的变换与一个定时点相对应。
Each call to and return from the non-blocking transport method may correspond to a phase transition.
对非阻塞传输方法的每一次调用和每一次该方法的返回，都对应一次相位变换。
By restricting the number of timing points to two, it is possible to use the non-blocking transport interface
with the loosely-timed coding style, but this is not generally recommended.
把计时点的个数限制在两个，在松散时间编程风格中使用非阻塞传输接口是可能的，但是一般不建议这么做。
For loosely-timed modeling, the blocking transport interface is generally preferred for its simplicity.
对松散时间的建模时，一般更倾向于使用阻塞传输接口，因为它更简单。
The non-blocking transport interface is particularly suited for modeling pipelined transactions,
which would be awkward to model using blocking transport.
非阻塞传输接口特别适合对流水管线型的事务进行建模，这种模型不适合用阻塞传输接口建模。
The non-blocking transport interface uses both the forward path from initiator to target and the backward path from target to initiator.
非阻塞传输接口既使用从发起者到目标的前向路径，也使用从目标到发起者的后向路径。
There are two distinct interfaces, tlm_fw_nonblocking_transport_if and tlm_bw_nonblocking_transport_if, for use on opposite paths.
接口tlm_fw_nonblocking_transport_if 和 tlm_bw_nonblocking_transport_if 是用于搭配相互逆向的两个不同的接口。
The non-blocking transport interface uses a similar argument-passing mechanism to the blocking transport
interface in that the non-blocking transport methods pass a non-const reference to the transaction object and
a timing annotation, but there the similarity ends.
非阻塞传输接口用类似于阻塞传输接口的参数传递机制，在这种机制里面，非阻塞传输接口传递一个可修改的事务对象的应用和计时标注，不过两类传输的相似性也就这些了。
The non-blocking transport method also passes a phase to indicate the state of the transaction,
and it returns an enumeration value to indicate whether the return from the function also represents a phase transition.
为了指示事务的状态，非阻塞传输接口也传递一个相位参数；同时，非阻塞传输接口会返回一个枚举值，用来指示函数的这次返回是否代表了一个相位变换。
Both blocking and non-blocking transport support timing annotation,
but only non-blocking transport supports multiple phases within the lifetime of a transaction.
阻塞和非阻塞传输接口都支持计时标注，但是非阻塞传输接口支持一个事务的整个生命周期中出现多个相位。
The blocking and non-blocking transport interface and the generic payload were designed to be used together for the fast,
abstract modeling of memory-mapped buses.
阻塞和非阻塞传输接口以及通用载荷设计在一块，是为了对内存映射总线系统创建快速的抽象的模型。
However, the transport interfaces can be used separately from the generic payload to model specific protocols.
然而，传输接口也可以不跟通用载荷搭配，单独用来给特定协议建模。
Both the transaction type and the phase type are template parameters of the nonblocking transport interface.
非阻塞传输接口的事务类型和相位类型都是模板参数。
11.1.2.2 Class definition
11.1.2.2 类的定义
namespace tlm {
enum tlm_sync_enum { TLM_ACCEPTED, TLM_UPDATED, TLM_COMPLETED };
template <typename TRANS = tlm_generic_payload, typename PHASE = tlm_phase>
class tlm_fw_nonblocking_transport_if : public virtual sc_core::sc_interface {
public:
virtual tlm_sync_enum nb_transport_fw(TRANS& trans, PHASE& phase, sc_core::sc_time& t) = 0;
};
template <typename TRANS = tlm_generic_payload, typename PHASE = tlm_phase>
class tlm_bw_nonblocking_transport_if : public virtual sc_core::sc_interface {
public:
virtual tlm_sync_enum nb_transport_bw(TRANS& trans, PHASE& phase, sc_core::sc_time& t) = 0;
};
} // namespace tlm
11.1.2.3 The TRANS and PHASE template arguments
11.1.2.3 TRANS和PHASE模板参数
The intent is that the non-blocking transport interface may be used to transport transactions of any type and
with any number of phases and timing points.
非阻塞传输接口有意设计成为可以传输任意类型的事务，以及任意多个相位和计时点。
A specific transaction type, tlm_generic_payload, is provided to ease interoperability between models
where the precise details of the transaction attributes are less important,
and a specific type tlm_phase is provided for use with the base protocol (see 15.2).
TLM定义特定的通用载荷类tlm_generic_payload 是为了提供模型之间的良好的互操作性，它适合应用在那些事务的属性的精确细节不重要的情形，
而且TLM提供了一个特定的相位类类型用于基础协议。
For maximum interoperability, applications should use the default transaction type tlm_generic_payload
and the default phase type tlm_phase with the base protocol.
为了获得最大的互操作性，应用程序应该使用默认的事务类tlm_generic_payload，而且在基础协议里一起使用默认的相位类型tlm_phase类.
In order to model specific protocols, applications may substitute their own transaction type and phase type.
为了对特定的协议建模，应用程序可以替代成自己定义的事务类型和相位类型。
Sockets that use interfaces specialized with different transaction types cannot be bound together,
providing compile-time checking but restricting interoperability.
指定了不同类型的事务类作为模板参数的套接字之间是不可以绑定在一起的，这会导致编译时告知，但是仅仅是限制了互操作性而已。
11.1.2.4 The nb_transport_fw and nb_transport_bw calls
11.1.2.4 对 nb_transport_fw 和 nb_transport_bw 的调用
a) There are two non-blocking transport methods, nb_transport_fw for use on the forward path, and
nb_transport_bw for use on the backward path.
这里又两种非阻塞传输接口，一种是用于前向路径的 nb_transport_fw， 另一种是用于后向路径的 nb_transport_bw。
Aside from their names and calling direction these two methods have similar semantics.
除了他们的名字和调用方向之外，这两个方法的语义是相似的。
In this document, the italicized term nb_transport is used to describe both methods in situations
where there is no need to distinguish between them.
本文档中，用斜体字打印的 nb_transport 用于同时描述这两个方法的情形，这时不需要区分两者。
b) In the case of the base protocol, the forward and backward paths should pass through exactly the
same sequence of components and sockets in opposing order.
b)在使用基础协议的时候，前向路径和后向路径应该穿过完全一样的组件和套接字序列，只是方向相反。
It is the responsibility of each component to route any transaction returning toward the initiator using the target socket through
which that transaction was first received.
每一个发起者应该自己负责利用目标套接字把返还给发起者的事务传递给发起者，当然这个套接字首先会接受到这个事务。
c) nb_transport_fw shall only be called on the forward path, and nb_transport_bw shall only be called on the backward path.
c)nb_transport_fw 应该仅仅在前向路径中调用，而 nb_transport_bw 应该仅仅在后向路径中调用。
d) An nb_transport_fw call on the forward path shall under no circumstances directly or indirectly make a call to nb_transport_bw
on the backward path, and vice versa.
d) 在一个前向路径里对nb_transport_fw 的调用中，无论是直接或间接，绝对不能调用一个后向路径里的 nb_transport_bw，反之也是一样不行。
e) The nb_transport methods shall not call wait, directly or indirectly.
e)无论直接或间接，阻塞传输函数不能调用wait函数。
f) The nb_transport methods may be called from a thread process or from a method process.
f)非阻塞传输函数可以在一个线程进程中被调用，也可以在一个方法进程中被调用。
g) nb_transport is not permitted to call b_transport. One solution would be to call b_transport from
a separate thread process, spawned or notified by the original nb_transport_fw method.
g) 非阻塞传输函数 不允许调用阻塞传输函数。如果有需要，一个解决方案是，由 nb_transport_fw 在一个单独的线程进程中引起或通知一个在单独线程进程里运行的阻塞传输函数。
For the base protocol, a convenience socket simple_target_socket is provided,
which is able to make this conversion automatically (see 16.1.2).
对于基础协议来说，TLM提供了一个便利套接字 simple_target_socket，它能够自动完成非阻塞传输与阻塞传输的转换(见16.1.2)。
h) The non-blocking transport interface is explicitly intended to support pipelined transactions.
h) 非阻塞传输接口明显的引入意图是支持流水线的事务传输。
In other words, several successive calls to nb_transport_fw from the same process could each initiate
separate transactions without having to wait for the first transaction to complete.
换句话说，从同一个进程中对nb_transport_fw的连续几次调用，可以分别初始化不同的事务，而且并不需要等待第一个事务完成。
i) In principle, the final timing point of a transaction may be marked by a call to or a return from
nb_transport on either the forward path or the backward path.
i) 原则上，一个事务的最后计时点应该通过调用一个nb_transport或从一个nb_transport中返回来标志它，无论是前向路径还是后向路径的调用。
11.1.2.5 The trans argument
11.1.2.5 事务参数
a) The lifetime of a given transaction object may extend beyond the return from nb_transport such that
a series of calls to nb_transport may pass a single transaction object forward and backward between
initiators, interconnect components, and targets.
a)一个给定事务对象的生命周期可以扩展到对一个nb_transport函数调用的返回之外，如此一来，
一系列对nb_transport函数的调用可以在发起者、互联组件和目标之间，前向或后向地传递单独一个事务象。
b) If there are multiple calls to nb_transport associated with a given transaction instance, one and the
same transaction object shall be passed as an argument to every such call.
b)如果多个对nb_transport的调用作用在同一个给定的事务实例上，那么这同一个事务实例应该作为参数传递给每一次调用的传输函数。
In other words, a given transaction instance shall be represented by a single transaction object.
也就是说，一个给定的事务实例应该由同一个事务对象来代表。
c) An initiator may re-use a given transaction object to represent more than one transaction instance, or
across calls to the transport interfaces, DMI, and the debug transport interface.
c) 一个发起者可以重新使用一个给定的事务对象来表示不止一个事务的实例，或者可以应用在跨三种接口的调用中。
d) Since the lifetime of the transaction object may extend over several calls to nb_transport,
either the caller or the callee may modify or update the transaction object,
subject to any constraints imposed by the transaction class TRANS.
d)自从一个事务对象的生命周期可以扩展到覆盖对nb_tranport的多次调用，所以无论是调用者还是被调用者都可以修改和更新这个事务对象，
当然这要服从这个事务类类型TRANS的施加的任何约束。
For example, for the generic payload, the target may update the data array of the transaction object in the case of a read command
but shall not update the command field (see 14.7).
例如，在使用通用载荷的情形下，当事务中的命令是读命令时，目标可能会更新事务对象的数据数组，但是应该不会更新命令字段。
11.1.2.6 The phase argument
11.1.2.6 相位参数
a) Each call to nb_transport passes a reference to a phase object.
a) 每一次对nb_transport的调用都需要传递一个对相位对象的引用作为参数。
In the case of the base protocol, successive calls to nb_transport with the same phase are not permitted.
在基础协议里，在对nb_transport的邻近的连续的调用中传递相同的相位时不允许的。
Each phase transition has an associated timing point.
每一个香味的转换都对应一个计时点。
A timing annotation using the sc_time argument shall delay the timing point relative to the phase transition.
使用一个sc_time类型的参数作为时间标注，应该会延迟与相位转换相关的计时点。
b) The phase argument is passed by reference. Either caller or callee may modify the phase.
b) 相位参数使用引用来传递。无论是调用者或者被调用者，都可以修改相位。
c) The intent is that the phase argument should be used to inform components
as to whether and when they are permitted to read or modify the attributes of a transaction.
c) 从设计意图上讲，相位参数应该用来告知组件关于是否被允许以及何时被允许去读取或修改事务的属性值。
If the rules of a protocol allow a given component to modify the value of a transaction attribute during a particular phase,
then that component may modify the value at any time during that phase and any number of times during that phase.
如果一个协议的规则允许一个给定的组件在一个特定的相位阶段里修改一个事务的属性的值，
那么，这个组件可以在这个相位阶段中的任何时候、对这个事务的值做任意次数的修改。
The protocol should forbid other components from reading the value of that attribute during that phase,
only permitting the value to be read after the next phase transition.
同时在这个相位阶段里，这个协议应该禁止其他组件来读取这个属性的值，至少要在下一个相位阶段里才可以读取这个属性的值。
d) The value of the phase argument represents the current state of the protocol state machine for the given hop.
d) 相位参数的值代表了协议状态机在给定跳跃的当前状态。
Where a single transaction object is passed between more than two components (initiator, interconnect, target),
each hop requires (notionally, at least) a separate protocol state machine.
在一个单独的事务对象传递在多于两个组件的场景，单独一个跳跃(理论上，至少)需要一个单独的协议状态机。
e) Whereas the transaction object has a lifetime and a scope that may extend beyond any single call to nb_transport,
the phase object is normally local to the caller.
e) 然而一个事务对象的生命周期和作用域可以扩展超过任何一个单独的对nb_transport的调用，相位对象对于调用者而言通常是局部的。
Each nb_transport call for a given transaction may have a separate phase object.
每一次对nb_transport的调用，对一个给定的事务来说可能拥有一个独立的相位对象。
Corresponding phase transitions on different hops may occur at different points in simulation time.
在不同跳跃上的对应的相位的转换，可能发生在仿真时间的不同时间点上。
f) The default phase type tlm_phase is specific to the base protocol.
f) 默认的相位类型tlm_phase 是专门用于基础协议的类型。
Other protocols may use or extend type tlm_phase or may substitute their own phase type
(with a corresponding loss of interoperability) (see 15.1).
不同的协议也可以使用或扩展使用tlm_phase，或者可以替代成自己的相位类型(这回产生相应的互操作性损失)（见15.1节）。
11.1.2.7 The tlm_sync_enum return value
11.1.2.7 返回值类型tlm_sync_enum
a) The concept of sychronization is referred to in several places.
a)同步这个概念在好几个地方出现。
To synchronize is to yield control to the SystemC scheduler in order that other processes may run,
but it has additional connotations for temporal decoupling.
做同步操作，就是让出控制权给SystemC调度器，以便让其他进程可以运行，但是对于时间解耦来说却具有额外的内涵。
This is discussed more fully elsewhere (see 16.2.4).
这将在别处做更充分的讨论（见16.2.4段）
b) In principle, synchronization can be accomplished by yielding
(calling wait in the case of a thread process or returning to the kernel in the case of a method process),
but a temporally decoupled initiator should synchronize by calling the sync method of class tlm_quantumkeeper.
b)原则上讲，同步操作可以通过让出控制来实现（在线程进程中调用wait，或者方法进程自己返回核心）
但是，一个时间解耦的发起者应该调用tlm_quantumkeeper的sync方法来实现同步操作。
In general, it is necessary for an initiator to synchronize from time-to-time in order to allow other SystemC processes to run.
一般来说，对于一个发起者而言，有必要不时地做一下同步操作，允许其他SystemC进程可以运行。
c) The following rules apply to both the forward and backward paths.
下面的规则既作用于前向路径，也作用域后向路径。
d) The meaning of the return value from nb_transport is fixed and does not vary according to the transaction type or phase type.
nb_transport方法的返回值的含义是固定的，并不会随着不同的事务类型和相位类型而改变。
Hence the following rules are not restricted to the base protocol
but apply to every transaction and phase type used to parameterize the non-blocking transport interface.
所以，下面的这些规则不仅限于基础协议，而且适用于每一种被用于参数化非阻塞传输接口的事务类型和相位类型。
e) TLM_ACCEPTED. The callee shall not have modified the state of the transaction object, the phase, or the time argument during the call.
e) TLM_ACCEPTED. 被调用者将不会改变事务对象的状态，相位状态，或者调用过程中的计时参数。
In other words, TLM_ACCEPTED indicates that the return path is not being used.
换句话说，TLM_ACCEPTED 表示返回路径将不会被使用。
The caller may ignore the values of the nb_transport arguments
following the call, since the callee is obliged to leave them unchanged.
调用者可以忽略调用nb_transport之后的参数的值，因为被调者有义务保证这些参数不被改变。
In general, the caller will have to yield before the component containing the callee can respond to the transaction.
一般而言，这个调用者必须在包含被吊着的组件能够对事务做出反应之前让出控制权。
For the base protocol, a callee that is ignoring an ignorable phase should return TLM_ACCEPTED.
对于基础协议而言，一个被吊着如果忽略一个可以忽略的相位，那么这个被调者应该返回TLM_ACCEPTED.
f) TLM_UPDATED. The callee has updated the transaction object.
f) TLM_UPDATE. 被调者已经更新了事务对象。
The callee may have modified the state of the phase argument,
may have modified the state of the transaction object, and may have increased the value of the time argument during the call.
被调者可能已经修改了相位参数的状态，可能以及修改了事务对象的状态，可能已经增加了调用期间造成的计时参数的值。
In other words, TLM_UPDATED indicates that the return path is being used,
and the callee has advanced the state of the protocol state machine associated with the transaction.
换句话说，TLM_UPDATED，表示返回路径被使用了，而且被调者已经推进了与事务相关的协议状态机的状态。
Whether or not the callee is actually obliged to modify each of the arguments depends on the protocol.
被调用者是否真的必须修改每一个参数，是由协议决定的。
Following the call to nb_transport, the caller should inspect the phase, transaction, and time arguments and take the appropriate action.
在调用nb_transport之后，调用者应该检查相位、事务和定时参数，并且采取适当的业务行动。
g) TLM_COMPLETED. The callee has updated the transaction object, and the transaction is complete.
g) TLM_COMPLETED. 被调者已经更新了事务对象，并且事务已经完成。
The callee may have modified the state of the transaction object and may have increased the value of the time argument during the call.
被调者可能已经修改了事务对象的状态，并且可能已经增加了这个调用期间导致的定时参数的值。
The value of the phase argument is undefined.
这个相位参数的值没有定义。
In other words, TLM_COMPLETED indicates that the return path is being used
and the transaction is complete with respect to a particular socket.
换句话说，TLM_COMPLETED 表示返回路径被使用，而且事务在一个特定的套接字中已经完成。
Following the call to nb_transport, the caller should inspect the transaction object
and take the appropriate action but should ignore the phase argument.
在调用nb_transport之后，调用者应该检查事务对象，并且采取适当的业务动作，但是应该忽略相位参数。
There shall be no further transport calls associated with this particular transaction
through the current socket along either the forward or backward paths.
跟这个特定事务相关的进一步的跟当前通过套接字对传输函数的调用再也不会发生了，无论是前向路径的，还是后向路径的。
Completion in this sense does not necessarily imply successful completion, so depending on the transaction type,
the caller may need to inspect a response status embedded in the transaction object.
这种场景下的完成，不需要暗示为一个成功的完成，这取决于事务的类型，这个调用者可能需要检查嵌入在事务对象里的应答状态。
h) In general there is no obligation to complete a transaction by having nb_transport return
TLM_COMPLETED.
通常，并不需要强制使用nb_transport返回一个TLM_COMPLETED来完成一个事务。
A transaction is in any case complete with respect to a particular socket when
the final phase of the protocol is passed as an argument to nb_transport.
一个特定套接字的一个事务，当协议中的最后一个相位作为参数传递给nb_tranport时，无论如何就算完成了。
(For the base protocol, the final phase is END_RESP.) In other words, TLM_COMPLETED is not mandatory.
(在基础协议中，最后一个相位时END_RESP。)也就是说，TLM_COMPLETED没有强制力。
i) For any of the three return values, and depending on the protocol, following the call to nb_transport the caller may need to yield
in order to allow the component containing the callee to generate a response or to release the transaction object.
对于这三个返回值中的任何一个，依赖于协议内容本身，沿着对nb_transport的调用，调用者可能需要让出控制权，以便允许包含了被调者的组件能够产生一个应答，或者释放这个事务对象。
11.1.2.8 tlm_sync_enum summary
11.1.2.8 tlm_sync_enum总结
Table 53 provides a summary of tlm_sync_enum.
表53提供了对tlm_sync_enum的总结。
===
表53
===
11.1.2.9 Message sequence chart—using the backward path
11.1.2.9 使用后向路径的信息序列表
The following message sequence charts illustrate various calling sequences to nb_transport.
下面的信息序列表说明了对nb_transport的多种调用序列。
The arguments and return value passed to and from nb_transport are shown using the notation return, phase, delay, where
return is the value returned from the function call, phase is the value of the phase argument,
and delay is the value of the sc_time argument.
传递给nb_transport的参数，和nb_transort返回的值，标注为return、phase、delay等，
“return”是从函数调用返回的值，“phase”是相位参数，“delay”是sc_time类型的参数。
The notation '-' indicates that the value is unused.
符号‘-’表示这个对应值没有用到。
The following message sequence charts use the phases of the base protocol as an example, that is, BEGIN_REQ, END_REQ and so on.
下面的消息顺序图表使用了基础协议中相位作为示例，也就是BEGIN_REQ, END_RED等等。
With the approximately-timed coding style and the base protocol, a transaction is passed back-and-forth twice between initiator and target.
在近似时间编程风格中使用了基础协议，一个事务会在发起者和目标之间来回传递两次。
For other protocols, the number of phases and their names may be different.
对于其他协议来说，相位的个数和名称可能是不一样的。
If the recipient of an nb_transport call is unable immediately to calculate the next state of the transaction or
the delay to the next timing point, it should return a value of TLM_ACCEPTED.
如果一个nb_transport调用的接收者，不能立即计算出事务的下一个状态或者不能计算出到下一个计时点的延迟，那么，这个接收者应该返回一个TLM_ACCEPTED.
The caller should yield control to the scheduler and expect to receive a call to nb_transport on the opposite path
when the callee is ready to respond.
调用者应该让出控制权给调度器，并且期待被调者预备好应答的时候，向调用者调用一个相反路径的nb_transport函数。
Notice that in this case, unlike the loosely-timed case, the caller could be the initiator or the target (Figure 23).
这种用例中需要注意，跟松散时间的用例不像，调用者既可以是一个发起者，也可以是一个目标（见图23）.
Transactions may be pipelined.
事务可以被做成管道流水线。
The initiator could call nb_transport to send another transaction to the target before having seen the final phase transition of the previous transaction.
发起者，在看到前一个事务的最后相位变换之前，就可以调用nb_transport发送另一个新事务给目标。
Because processes are regularly yielding control to the scheduler in order to allow simulation time to advance,
the approximately-timed coding style is expected to simulate a lot more slowly than the looselytimed coding style.
因为进程会规则地让出控制权给调度器，以便让仿真时间向前推进，近似时间编程风格会比松散时间编程风格的仿真慢很多。
=====
图23
=====
11.1.2.10 Message sequence chart—using the return path
11.1.2.10 使用返回路径的消息序列表
If the recipient of an nb_transport call can immediately calculate the next state of the transaction and the delay to the next timing point,
it may return the new state on return from nb_transport rather than using the opposite path.
如果一个nb_transport函数调用的接收者能够都立即计算出事务的下一个状态和到下一个计时点的延迟大小，
那么被调用者应该使用return路径返回一个新的状态，而不是使用反向路径传输函数来完成此事。
If the next timing point marks the end of the transaction, the recipient can return either
TLM_UPDATED or TLM_COMPLETED.
如果下一个定时点标识了事务的结束，那么接收者可以返回TLM_UPDATED或者返回TLM_COMPLETED.
A callee can return TLM_COMPLETED at any stage (subject to the rules of the protocol) to indicate to the caller
that it has pre-empted the other phases and jumped to the final phase, completing the transaction.
一个被调者可以根据协议的规则吗，在任意阶段返回一个TLM_COMPLETED，来告诉调用者自己已经抢先取得了其他几个相位，并且已经跳入了最后一个相位，并要结束这个事务。
This applies to initiator and target alike.
这同样地可以适用于发起者和目标。
With TLM_UPDATED, the callee should update the transaction, the phase, and the timing annotation.
返回一个TLM_UPDATED时，被调用者应该更新事务的属性、相位值和计时标注。
In Figure 24, the non-zero timing annotation argument passed on return from the function calls indicates to
the caller the delay between the phase transition on the hop and the corresponding timing point.
在图24中，从函数调用中传递返回的非零的计时标注参数，告知调用者在此次跳跃中的相位变换和对应的计时点之间的时间延迟之大小。
====
图24
====
11.1.2.11 Message sequence chart—early completion
11.1.2.11 提早结束的消息序列图表
Depending on the protocol, an initiator or a target may return TLM_COMPLETED from nb_transport at
any point in order to complete the transaction early.
看协议具体内容而定，为了提前结束一个事务，一个发起者或者一个目标可以在任意时刻从nb_transport调用中返回TLM_COMPLETED，
Neither initiator nor target may make any further nb_transport calls for this particular transaction instance.
然后，无论是发起者还是目标，都不可以针对这个事务实例进一步调用nb_transport函数了。
Whether or not an initiator or target is actually permitted to shortcut a transaction
in this way depends on the rules of the specific protocol.
一个发起者或一个目标，是否被允许用这种方式快捷处理一个事务，是由特定协议决定的。
In Figure 25, the timing annotation on the return path indicates to the initiator
that the final timing point is to occur after the given delay.
从图25可见，返回路径的计时标注对发起者表明最后的计时点发生在给定的延迟后
The phase transitions from BEGIN_REQ through END_REQ and
BEGIN_RESP to END_RESP are implicit, rather than being passed explicitly as arguments to nb_transport.
相位变换从BEGIN_REQ 穿过了 END_REQ 和 BEGIN_RESP 到了 END_RESP，是暗含的，而不是通过nb_transporth函数显式传递的。
====
图25
====
11.1.2.12 Message sequence chart—timing annotation
11.1.2.12 计时标注的消息序列图表
A caller may annotate a delay onto an nb_transport call (Figure 26).
见图26，一个调用者可能在一个nb_transport函数调用中标注一个延迟。
This is an indication to the callee that the transaction should be processed as if it had been received after the given delay.
这是指示被调者，应该把这个事务当成在给定的延迟后收到的，然后进行处理。
An approximately-timed callee would typically handle this situation by putting the transaction into a payload event queue for processing
when simulation time has caught up with the annotated delay.
一个近似时间的被调者处理这个情形的典型做法是把这个事务放入一个的载荷事件队列中，当仿真时间追上所标注的延迟时就会处理队列中的事务。
Depending on the implementation of the payload event queue, this processing may occur
either in a SystemC process sensitive to an event notification from the payload event queue
or in a callback registered with the payload event queue.
具体取决于载荷事件队列的实现，对这个事务的处理可能发生在一个对载荷事件队列的事件通知敏感的SystemC进程中，
也可能发生在一个载荷事件队列所注册的回调函数中。
Delays can be annotated onto calls on the forward and backward paths and the corresponding return paths.
可以在前向路径、后向路径和对应的返回路径的调用中标注时间延迟。
An approximately-timed initiator would be expected to handle incoming transactions on both the forward
return path and the backward path in the same way.
在前向返回路径和后向路径中，一个近似时间的发起者应该采用相同的方式处理即将到来的事务。
Similarly, an approximately-timed target would be
expected to handle incoming transactions on both the backward return path and the forward path in the same way.
类似地，在后向返回路径和前向路径中，要给近似时间的目标应该采用相同的方式处理即将到来的事务。
===
图26
===
11.1.3 Timing annotation with the transport interfaces
11.1.3 传输接口参数中的计时标注
Timing annotation is a shared feature of the blocking and non-blocking transport interfaces,
expressed using the sc_time argument to the b_transport, nb_transport_fw, and nb_transport_bw methods.
计时标注时阻塞和非阻塞传输接口共享的特性，使用一个sc_time参数告知b_transport, nb_transport_fw, 和 nb_transport_bw方法。
In this document, the italicized term transport is used to denote the three methods b_transport, nb_transport_fw, and nb_transport_bw.
在本文档中，用斜体书写的术语transport来同时表示这三种接口：b_transport, nb_transport_fw, 和 nb_transport_bw。
Transaction ordering is governed by a combination of the core interface rules and the protocol rules.
事务排序由核心接口的规则和协议的规则共同来管理。
The rules in the following clause apply to the core interfaces regardless of the choice of protocol.
无论选择什么样的协议，下面的规则时适用于核心接口的。
For the base protocol, the rules given here should be read in conjunction with those in 15.2.7.
对于基础协议，下面这些规则应该结合第15.2.7节一起阅读思考。
11.1.3.1 The sc_time argument
11.1.3.1 sc_time类型的参数
a) It is recommended that the transaction object should not contain timing information.
a) 事务对象不建议包含有计时信息。
Any timing annotation should be expressed using the sc_time argument to transport.
任何的计时标注，都应该通过传递一个sc_time类型的参数给transport函数来表示。
b) The time argument shall be non-negative and shall be expressed relative to the current simulation time sc_time_stamp().
b) 时间参数应该是非负值的，而且应该被表示成相对于当前仿真时间的值，当前仿真时间是用sc_time_stamp()函数获得。
c) The time argument shall apply on both the call to and the return from transport
(subject to the rules of the tlm_sync_enum return value of nb_transport).
c) 时间参数既适用于对transport函数的调用参数，也适用于从transport函数的返回值
(这时应该遵从nb_transport函数返回值tlm_sync_enum类型的规则)。
d) The nb_transport method may itself increase the value of the time argument but shall not decrease the value.
d) nb_transport方法可能自身会增加时间参数的值，但是应该不会减少时间参数的值。
The b_transport method may increase the value of the time argument
or may decrease the value in the case that it has called wait and thus synchronized with simulation time,
but only by an amount that is less than or equal to the time for which the process was suspended.
而b_transport函数既可以增加时间参数的值，也可以减少时间参数的值。
减少时间参数的值的情形是当b_transport函数调用了wait函数导致需要跟仿真时间做同步，但是减少的时间值只能少于或等于本进程被挂起的时间长度。
This rule is consistent with time not running backward in a SystemC simulation.
这个规则跟在SystemC仿真中不运行后向路径的时间是一致的。
e) In the following description, the recipient of the transaction on the call to transport is the callee, and
the recipient of the transaction on return from transport is the caller.
在下面的表述中，调用一个tranport函数过程中的事务的接收者时被调者；而从一个transport函数调用中返回的过程中的事务的接收者是调用者。
f) The recipient shall behave as if it had received the transaction at an effective local time of
sc_time_stamp() + t, where t is the value of the time argument.
接收者应该假装接收到事务的有效局部时间是sc_time_stamp()+t，这里的t是时间参数的值。
In other words, the recipient shall behave
as if the timing point associated with the interface method call is to occur at the effective local time.
也就是说，接收者应该假装认为对相应时间点的接口方法的调用发生在有效的局部时间。
g) Given a sequence of calls to transport, the effective local times at which the transactions are to be
processed may or may not be in increasing time order in general.
考虑到对transport调用的顺序，这些事务被处理的有效本地时间可能是按照增长的时间顺序，也能能不按照增长的时间顺序。
For transactions created by different initiators,
it is fundamental to temporal decoupling that interface method call order may be different from effective local time order.
由不同发起者创建的事务，这些接口方法的调用顺序可能不同于有效的本地时间顺序，这对于时间解耦是很重要的。
The responsibility to handle transactions with out-of-order timing annotations lies with the recipient.
处理好无序的计时标注的事务的责任在于接收者。
h) On receipt of a transaction with a non-zero timing annotation,
any recipient always has choices that reflect the modeling trade-off between speed and accuracy.
在接收一个携带了非零计时标注的事务时，任意一接收者的设计总是要在仿真速度和仿真精度上谨慎权衡。
The recipient can execute any state changes caused by the transaction immediately and pass on the timing annotation, possibly increased,
or it can schedule some internal process to resume after part or all of the annotated time
has elapsed and execute the state changes only then.
接收者可以立即执行由一个事务引起的状态改变，并且继续传递可能被增加了的计时标注，
或者在一部分或者全部标注的时间流失以后，接收者能调度一个内部的进程来恢复并执行状态的改变。
The choice is not enforced by the transport
interface but may be documented as part of a protocol traits class or coding style.
这个选择不是由传输接口强制的，但是可能作为协议特写类或编程风格的一部分被记录。
i) If the recipient is not concerned with timing accuracy or with processing a sequence of incoming
transactions in the order given by their timing annotations,
it may process each transaction immediately, without delay.
i)如果接收者不关心计时精度或者不关心处理由计时标注产生的即将到来的事务的顺序，那么这个接收者可以毫不延迟地立即处理每一个事务。
Having done so, the recipient may also choose to increase the value of
the timing annotation to model the time needed to process the transaction.
处理完后，接收者可以选择增加计时标注的值，用来表示自己处理这个事务所需要的时间。
This scenario assumes that the system design can tolerate out-of-order execution
because of the existence of some explicit mechanism (over and above the TLM-2.0 interfaces) to enforce the correct causal chain of events.
假设因为一些显式机制(在TLM-2.0接口以上的机制)可以保证正确的时间因果链条，所以这个场景假设这个系统的设计能够忍受无序的执行。
j) If the recipient is to implement an accurate model of timing and execution order, it should ensure
that the transaction is indeed processed at the correct time relative to any other SystemC processes
with which it may interact.
如果接收者实现了一个计时和执行顺序的精确模型，那么必须确保，相对于任何可能需要跟该事务进行交互的其他SystemC进程，事务确实在正确的时间被执行了。
In SystemC, the appropriate mechanism to schedule an event at a future time is the timed event notification.
在SystemC中，在未来的时间里调度一个事件的机制，是时间事件通知。
For convenience, TLM-2.0 provides a family of utility classes,known as payload event queues,
which can be used to queue transactions for processing at the proper simulation time according to the natural semantics of SystemC (see 16.3).
为了方便起见，TLM-2.0提供了一组实用类，就是众所周知的载荷事件队列，它可以把需要在合适的仿真时间处理的事务排队（在16.3节详细说明）。
In other words, an approximately-timed recipient should typically put the transaction into a payload event queue.
换句话说，一个近似时间的接收者，典型的处理方式，应该把事务放进载荷事件队列。
k) Rather than processing the transaction directly,
the recipient may pass the transaction on with a
further call to or return from a transport method without modification to the transaction
and using the same phase and timing annotation (or with an increased timing annotation).
k) 除了直接处理一个事务，接收者可以通过传输方法的调用或返回，无修改地把一个事务传递下去，而且使用相同的相位和计时标注（或者增加计时标注）
l) With the loosely-timed coding style, transactions are typically executed immediately such that
execution order matches interface method call order, and the b_transport method is recommended.
l) 在松散时间编程风格，典型的做法，事务会被立即执行，如此一来，执行顺序与接口调用的顺序是匹配的，并且推荐使用b_transport方法。
m) With the approximately-timed coding style,
transactions are typically delayed such that their execution order matches the effective local time order,
and the nb_transport method is recommended.
m) 用近似时间建模风格时，典型的情况，事务一般会被延迟，如此一来，事务的执行顺序跟有效的局部时间顺序是匹配的，而且建议使用nb_transport方法。
n) Each component can make the above choice dynamically on a call-by-call basis.
每一个组件可以基于一次一次的调用的不同，而动态地做出选择。
For example, a loosely-timed component may execute a series of transactions immediately in call order,
passing on the timing annotations but may then choose to schedule the very next transaction for execution only
after the delay given by the timing annotation has elapsed (known as synchronization on demand).
例如，一个松散时间组件可以按照调用顺序立即执行一系列事务，并且传递计时标注，但是会在由计时标注给定的延迟流逝后恰恰选择调度下一个事务来执行。（别扭）
This is a matter of coding style.
这跟编程风格有关，
o) The above choice exists for both blocking and non-blocking transport.
o) 上述选择既存在于阻塞传输中，也存在于非阻塞传输接口中。
For example, b_transport may increase the timing annotation and return immediately
or may wait for the timing annotation to elapse before returning.
例如，b_transport可以增加时间标注并立即返回，或者可以在返回以前先等待时间标注流逝掉。
nb_transport may increase the timing annotation and return TLM_COMPLETED or may return TLM_ACCEPTED
and schedule the transaction for execution later.
nb_transport 可以增加时间标注，并且返回TLM_COMPLETED或者返回TLM_ACCEPTED,并且在晚些时候调度执行事务。
p) As a consequence of the above rules, if a component is the recipient of a series of transactions where
the order of the incoming interface method calls is different from the effective local time order,
the component is free to choose the mutual execution order of those particular transactions.
p)由以上规则可以推断，如果组件是一系列事务的接收者，并且即将到来的接口方法的调用顺序与有效的局部时间的顺序不相同，
这个组件选择那些个别的事务的彼此执行顺序是任意的。
The recommendation is to execute all transactions in call order or to execute all transactions in effective
local time order, but this is not an obligation.
推荐做法有两个，一个是按照传输接口被调用的顺序来执行，另一个是按照事务的有效局部时间顺序执行，但这都不是必须的。
q) Note that the order in which incoming transactions are executed by a component
should in effect always be the same as interface method call order
because a component will either execute an incoming transaction
before returning from the interface method call regardless of the timing annotation (loosely-timed),
or will schedule the transaction for execution at the proper future time and return TLM_ACCEPTED (approximately-timed),
thus indicating to the caller that it should wait before issuing the next transaction.
注意如下这点，那些即将到来的事务被一个组件执行的顺序，应该实际上总是跟接口方法调用顺序一样，
因为一个组件，要么将会在从接口方法调用返回之前、不顾计时标注地执行一个即将到来的事务（松散时间的），
要么将会调度一个事务到一个未来合适的时间执行并且返回一个TLM_ACCEPTED(近似时间的)，
因此，这个TLM_ACCEPTED会告知调用者应该在发布下一个事务之前稍作等待。
(TLM_ACCEPTED alone does not forbid the caller from issuing the next transaction,
but in the case of the base protocol, the request and response exclusion rules may do so.)
（单独返回TLM_ACCEPTED并不能禁止调用者发布下一个事务，但是在使用基础协议的情况下， 请求和应答的互斥规则可以禁止。）
r) Timing annotation can also be described in terms of temporal decoupling.
r) 计时标注能按照时间解耦来描述。
A non-zero timing annotation can be considered as an invitation to the recipient to “warp time.”
一个非零的计时标注可以被视为对接收者进入时间隧道的一个邀请。
The recipient can choose to enter a time warp, or it can put the transaction in a queue for later processing and yield.
接收者能够选择进入时间隧道，或者它能够把这个事务放入一个队列中，等到后来再处理这个事务，并暂时让出控制权。
In a loosely-timed model, time warping is generally acceptable.
在一个松散时间模型中，时间隧道通常是可以接受的。
On the other hand, if the target has dependencies on other asynchronous events,
the target may have to wait for simulation time to advance before it can predict the future state of the transaction with certainty.
另一方面，如果目标依赖于其他异步事件，在目标能够确定地预测这个事务的未来状态之前，目标可能不得不等待仿真时间前进。
s) For a general description of temporal decoupling, see 10.3.2.
s) 对于时间解耦的一般描述，可见10.3.2节。
t) For a description of the quantum, see 16.2.
t)对时间量子的描述，可见16.2.
Example:
示例：
The following pseudo-code fragments illustrate just some of the many possible coding styles:
下面的伪代码片段只说明了很多可能的编程风格中的一些：
// ---------------------------------------------
// Various interface method definitions
//各种各样的接口方法的定义
// ---------------------------------------------
void b_transport( TRANS& trans, sc_core::sc_time& t )
{
// Loosely-timed coding style
execute_transaction( trans );
t = t + latency;
}
void b_transport( TRANS& trans, sc_core::sc_time& t )
{
// Loosely-timed with synchronization at the target or synchronization-on-demand
wait( t );
execute_transaction( trans );
t = SC_ZERO_TIME;
}
tlm_sync_enum nb_transport_fw( TRANS& trans, PHASE& phase, sc_core::sc_time& t )
{
// Pseudo-loosely-timed coding style using non-blocking transport (not recommended)
execute_transaction( trans );
t = t + latency;
return TLM_COMPLETED;
}
tlm_sync_enum nb_transport_fw( TRANS& trans, PHASE& phase, sc_core::sc_time& t )
{
// Approximately-timed coding style
// Post the transaction into a payload event queue for execution at time sc_time_stamp() + t
payload_event_queue->notify( trans, phase, t );
// Increment the transaction reference count
trans.acquire();
return TLM_ACCEPTED;
}
tlm_sync_enum nb_transport_fw( TRANS& trans, PHASE& phase, sc_core::sc_time& t )
{
// Approximately-timed coding style making use of the backward path
payload_event_queue->notify( trans, phase, t );
trans.acquire();
// Modify the phase and time arguments
phase = END_REQ;
t = t + accept_delay;
return TLM_UPDATED;
}
// ---------------------------------------------------------------------------
// b_transport interface method calls, loosely-timed coding style
// ---------------------------------------------------------------------------
initialize_transaction( T1 );
socket->b_transport( T1, t ); // t may increase
process_response( T1 );
initialize_transaction( T2 );
socket->b_transport( T2, t ); // t may increase
process_response( T2 );
// Initiator may sync after each transaction or after a series of transactions
quantum_keeper->set( t );
if ( quantum_keeper->need_sync() )
quantum_keeper->sync();
// -------------------------------------------------------------------------------------
// nb_transport interface method call, approximately-timed coding style
// -------------------------------------------------------------------------------------
initialize_transaction( T3 );
status = socket->nb_transport_fw( T3, phase, t );
if ( status == TLM_ACCEPTED )
{
// No action, but expect an incoming nb_transport_bw method call
}
else if ( status == TLM_UPDATED ) // Backward path is being used
{
payload_event_queue->notify( T3, phase, t );
}
else if ( status == TLM_COMPLETED ) // Early completion
{
// Timing annotation may be taken into account in one of several ways
// Either (1) by waiting, as shown here
wait ( t );
process_response( T3 );
// or (2) by creating an event notification
// response_event.notify( t );
// or (3) by being passed on to the next transport method call (code not shown here)
}
11.1.4 Migration path from TLM-1
11.1.4 从TLM-1的迁移路径
The old TLM-1 and the new TLM-2.0 interfaces are both part of the TLM-2.0 standard.
旧的TLM-1 和新的TLM-2.0的接口都是 TLM-2.0标准的一部分。
The TLM-1 blocking and non-blocking interfaces are still useful in their own right.
TLM-1的阻塞接口和非阻塞接口仍然在凭它们本身的实力而发挥作用。
For example, a number of vendors have used these interfaces in building functional verification environments for HDL designs.
例如，很多厂家已经使用这些接口构建了对HDL设计的验证环境。
The intent is that the similarity between the old and new blocking transport interfaces should ease the task of
building adapters between legacy models using the TLM-1 interfaces and the new TLM-2.0 interfaces.
旧版阻塞传输接口与新版阻塞传输接口的相似性，是为了构建那些使用TLM-1的遗留模型与TLM-2.0接口之间的适配器会比较容易。
11.2 Direct memory interface
11.2 直接内存接口
11.2.1 Introduction
11.2.1 介绍