Hardware Reference
In-Depth Information
Flow-control strategies are connected in one or in another way with the avail-
ability of buffering positions either at the other end of the link or at the destination.
Therefore, the semantics of the flow-control protocol lead to various constraints
regarding the implementation of the buffering alternatives.
The messages transferred across any two peers depend on the applications
running on the system. Therefore, it is very common the granularity of the messages
that are transferred at the application level to be different from the physical wiring
resources available on the links. The selection of the channel width depends on a
mix of constraints that span from application-level requirements down to physical
chip-level integration limitations.
The messages between a source and a destination can be short and fit the
channel width or can be longer and need to be serialized to many words that
traverse the link in multiple cycles. This attribute should be also reflected to
the flow-control mechanism that decides the granularity to which it allocates the
channels and the buffers at the receive side. Coarse-grained flow control treats each
message (or packet) as an atomic entity, while fine-grained flow control mechanisms
operate at the sub-message (sub-packet) level, allowing parts of the message to be
distributed to several stages.
1.3
Read-Write Transactions
Besides simple data transfers between two IP cores on the same chip, the exchange
of information across multiple IP cores requires the implementation of multiple
interfaces between them that would allow them to communicate efficiently and
implement high-level protocol semantics. In widely accepted interfaces such as
AMBA AXI and OCP-IP, each core should implement distinct and independently
flow-controlled interfaces for writing, and reading from another IP core, including
also interfaces for transferring additional notification messages (ARM 2013 ; Accel-
era 2013 ). An example of two connected cores via a single channel, where each core
implements the full set of interfaces needed by AXI is shown in Fig. 1.4 .
In most cases, where such address-based load/store transactions are used for
the communication of two IPs the interfaces shown in Fig. 1.4 suffice to describe
the needed functionality. The implementation of these interfaces and respect-
ing the rules that come with the associated interconnect protocol, e.g., AXI,
constitute the transaction layer of the network-on-chip communication architecture.
Every transaction is initiated by a core (called the master for this transaction) via
the request interface (read or write) and completed via the corresponding reply
interface, while it may include an additional transaction response. Each transaction
always involves a master and a slave core (that receives and services the request),
while the two peers of a transaction are identified by the address used in the request
and reply interfaces. Transaction-layer communication is an end-to-end operation
between a master and slave and its definition, besides the support for the necessary
physical interfaces, does not constrain the designer on how to implement it.
Search WWH ::




Custom Search