SRIO XOFF reporting time?

Hi,

When the peripheral receives an Xoff CCP, the peripheral must block outgoing LSU, and CPPI packets that are destined for that flow. When the peripheral receives an Xon, the flow may be enabled.

Since CCPs do not have guaranteed delivery and can be dropped by the fabric, an implicit method of enabling an Xoff’d flow must exist. A simple timeout method will be used. Additionally, flow control checks can be enabled/disabled through the Transmit Source Flow Control Masks. Received CCPs do not get passed through the VBUS interface.

XOff Check: The DestId is checked against the TX_CPPI_Flow_Mask register to determine which queues are available for transmission and which are flow controlled (see congestion control). If the queue has been flow controlled, it is temporarily disallowed and is not part of the scheduling algorithm and is stalled, resulting in HOL blocking for that queue. If it is not flow controlled, the queue can be used by the scheduler algorithm.

Thanks,

Hi,

That answer is totally non-responsive to my question. I did read SPRUGW1 before I posted my question. The closest thing to an answer that I found was text below Table 2-13, which says "All the interrupts associated with the errors above are reported immediately" -- but this does not say when the error is asserted, which is the core of my question.

I am trying to figure out how the software should restart or abort a transaction that failed, and the best scheme will look different based on whether the errors are frequently asserted before the XOn might arrive. In particular, if the hardware has no delay before reporting the error, the software really should enforce a delay before it restarts a Direct I/O operation. If the hardware has a delay, and the flow control is likely to clear quickly, the software might not need to enforce an additional delay.

Michael

Hi,

All out-going flows with non-zero Xoff counts, are disabled. The counter value is decremented for each corresponding Xon CCP that is received, but it should not decrement below zero. Additionally, a hardware timer is needed for each table entry to turn on flows that may have been abandoned by lost Xon CCPs. The timer value needs to be an order of magnitude larger than the 32b Port Response Time-out CSR value.

Thanks,

Ganapathi,

Let me try to restate my question, because I did read the part of the User's Guide that you quoted in your second answer, and do not think it addresses my question.

A transaction comes to the front of an LSU's queue. This transaction maps to an XOFF'ed flow. Does the transaction immediately fail with CC=2 ("Transaction complete, Packet not sent due to flow control blockade (Xoff)"), or is there a delay before it fails? If there is a delay, how long is that delay?

Michael

Thanks. When you say "move to the next shadow register", do you mean after either the application writes LSU_REG6.FLUSH=1 (with the correct value of SrcID_MAP) or the timeout that is configured in LSU_SETUP_REG1's Timeout_cnt field? Or does it immediately move to the next shadow register?