User Guide

www.ti.com
SRIO Functional Description
For posted WRITE operations, which do not require a RapidIO response packet, a core may submit
multiple outstanding requests. For instance, a single core may have many streaming write packets
buffered at any given time, given outgoing resources. In this application, the control/command registers
can be released (BSY = 0) to the CPU as soon as the header info is written into the shared TX buffer
pool. If the request has been flow controlled, the peripheral will set the completion code status register and
appropriate interrupt bit of the ICSR. The control/command registers can be released after the interrupt
service routine completes.
For non-posted WRITE operations, which do require a RapidIO response packet, there can be only one
outstanding request per core at any given time. The payload data and header information is written to the
shared TX buffer pool as described above; however, the command registers cannot be released (BSY =
1) until the response packet is routed back to the module and the appropriate completion code is set in the
status register. One special case exists for outgoing test-and-swap packets (Ftype 5, Transaction 1110b).
This is the only WRITE class packet that expects a response with payload. This response payload is
routed to the LSU, it is examined to verify whether the semaphore was accepted, and then the appropriate
completion code is set. The payload is not transferred out of the peripheral via the DMA bus.
So the general flow is as follows:
• LSU registers are written using the configuration bus
• Flow control is determined
• TX FIFO free buffer availability is determined
• DMA bus read request for data payload
• DMA bus response writes data to specified module buffer in the shared TX buffer space
• DMA bus read response is monitored for last byte of payload
• Header data in the LSU registers is written to the shared TX buffer space
• Payload and header are transferred to the TX FIFO
• The LSU registers are released if no RapidIO response is needed
• Transfer from the TX FIFO to external device based on priority
READ Transactions:
The flow for generating READ transactions is similar to non-posted WRITE with response transactions.
There are two main differences: READ packets contain no data payload, and READ responses have a
payload. So READ commands simply require a non-payload TX buffer within the shared pool. In addition,
they require a shared RX data buffer. This buffer is not pre-allocated before transmitting the READ
request packet, since doing so could cause traffic congestion of other in-bound packets destined to other
functional blocks.
Again, the control/command registers cannot be released (BSY = 1) until the response packet is routed
back to the module and appropriate completion code is set in the status register.
So the general flow would be:
• LSU registers are written using the configuration bus
• Flow control is determined
• TX FIFO buffer is allocated
• Header data in the LSU registers is written to the shared TX buffer
• Payload and header are transferred to the TX FIFO
• The LSU registers are released if no RapidIO response is needed
• Transfer from the TX FIFO to external device based on priority
For all transactions, the shared TX buffers are released as soon as the packet is forwarded to the TX
FIFOs. If an ERROR or RETRY response is received for a non-posted transaction, the CPU must either
reinitiate the process by writing to the LSU register, or initiate a new transaction altogether.
38 Serial RapidIO (SRIO) SPRU976 – March 2006
Submit Documentation Feedback