17.

VIA Protocol signals Transfer Pending (TP): This signal is driven by the master and is asserted for one clock cycle at the beginning of a transaction. It indicates that a transaction is being initiated on the interconnect. Transfer Direction (TD): This signal is driven by the master and defines the direction of the transfer and thus the type of the transaction being initiated: 1 write 0 read Transfer Acknowledge (TA): This signal is driven by the slaves and is used to signal the completion of the transaction. A slave not involved in a transaction drives the TA to all logic 1 to enable resolution of the acknowledgement signals by an AND network.The signal is a bit vector whose value is interpreted as an integer number. Any value between the two extremes is interpreted as a special condition: the transaction is completed but something special occurred during it. Transaction attributes (Attr) The signals of this class are driven by the master and define the attributes of the transaction. The exact interpretation of the attributes is defined by the application, in a typical arrangement the attributes describe aspects such as the address and the operand size of the transaction. Read data (DataR) data bus driven by the slave and used in read transactions to transmit the data being read from slave to host. A slave not involved in a transaction provides the read data lines with a constant value of all ones to enable the resolution of the read data value using an AND network. Write data (DataW) data bus driven by the master and used in write transactions to transmit the data being written from master to slave. Transaction phases Each transaction consists of two phases: the address phase the reply phase. The operation of a VIA interconnect is pipelined: the address phase of one transaction can overlap the reply phase of another transaction.

AXI protocol main features Properties High-bandwidth & low-latency design Good performance with long initial latency peripherals Flexibility in interconnection architecture Features Separate address/control and data phases Separate read & write channels, request/response channels Multiple outstanding addresses Out-of-order transaction completion AXI protocol the 5 channels Read and write address channels Read and write transactions each have their own address channel which carries all of the required

address and control information for a transaction. The following mechanisms are supported: variable-length bursts, from 1 to 16 data transfers per burst (AxLEN signal) bursts with a transfer size of 8-1024 bits (AxSIZE signal) wrapping, incrementing, and non-incrementing bursts (AxBURST signal) atomic operations, using exclusive or locked accesses (AxLOCK signal) system-level caching and buffering control (AxCACHE signal) protection information (AxPROT signal) control information on read/write channels are maintained until the corresponding XReady signal is asserted Read data channel The read data channel conveys both the read data and read response information from the slave back to the master. It includes: the data bus, which can be 8, 16, 32, 64, 128, 256, 512, or 1024 bits wide (RDATA) a read response indicating the completion status of the read transaction. data and response group signals are maintained until the RReady signal is asserted Write data channel The write data channel conveys the write data from the master to the slave and includes: the data bus, which can be 8, 16, 32, 64, 128, 256, 512, or 1024 bits wide (WDATA) one byte lane strobe for every byte, indicating which bytes of the data bus are valid (WSTRB) the last transfer inside a burst must be signalled through the WLAST signal data, strobe and wlast information are maintained until the WReady signal is asserted Write Response channel The write response channel provides a way for the slave to respond to write transactions. All write transactions use completion signaling. The completion signal occurs once for each burst, not for each individual data transfer within the burst. Response group signals are maintained until the BReady signal is asserted AXI Protocol Transaction Ordering Transactions from different masters can complete in any order Read and write transactions from the same master can complete in any order Done using transaction IDs for each channel ARM1176 does not support it yet! feature not implemented into RAPU PSS bridges

OCP protocol main features Features The Open Core Protocol (OCP) defines a high-performance, bus-independent interface between IP cores Defines a point-to-point interface between two communicating entities: One entity acts as the master of the OCP instance, and the other as the slave. Only the master can present commands and is the controlling entity. The slave responds to commands presented to it, either by accepting data from the master, or presenting data to the master. Basic signals

OCP protocol signals - MCmd Normal Write operations are posted: the slave is not configured to response to a write or, if a response is required, this is given immediately to the master, even if the write operation to the slave has not completed. The WriteNonPost explicitly instructs the slave not to post a write. For the Broadcast command, the master indicates that it is attempting to write to several or all remote target devices that are connected on the other side of the slave. ReadExclusive is paired with Write or WriteNonPost, and has blocking semantics. ReadLinked, used in conjunction with WriteConditional has non-blocking semantics. These synchronization primitives correspond to those available natively in the instruction sets of different processors. OCP protocol signals - SResp OCP protocol simple extentions MByteEn, MReqInfo MByteEn: This field indicates which bytes within the OCP word are part of the current transfer. There is one bit in MByteEn for each byte in the OCP word. Setting MByteEn[n] to 1 indicates that the byte associated with data wires [(8n + 7):8n] should be transferred. MReqInfo The master uses this field to send additional information sequenced with the request. The encoding of the information is core-specific. OCP protocol signals Burst Extensions MBurstLength: The number of transfers in a burst. For precise bursts, it indicates the total number of transfers in the burst, and is constant throughout the burst. For imprecise bursts, it indicates the best guess of the number of transfers remaining (including the current request), and may change with every request. MBurstSeq: This field indicates the sequence of addresses for requests in a burst. MReqLast: This field indicates whether the current request is the last in this burst OCP protocol signals Thread Extensions To support concurrency and out-of-order processing of transfers, the OCP supports the notion of multiple threads. Transactions within different threads have no ordering requirements, and so can be processed out of order. Within a single thread of data flow, all OCP transfers must remain ordered.

OCP protocol signals Request/Response phases Request Phase:

 starts when the master put a valid value onto MCmd and drives all the other control signals (MAddr, burst signals, MReqInfo, MReqLast, etc. whenever the request group becomes active ends when the slaves accepts the transfer by asserting SCmdAccept MCmd and all control signals must be left unchanged until SCmdAccept is asserted Response Phase: starts when the response group becomes active SResp takes a valid value if MRespAccept is present, the response phase ends when MRespAccept is sampled high during a response phase if MRespAccept is absent, the response phase lasts one cycle as long as MRespAccept is present and deasserted, all signals in the response group must be left unchanged.