Texas Instruments TMS320C645X - Manual (Page 60)

www.ti.com
SRIO Functional Description
2.3.7 Congestion Control
The RapidIO Flow Control specification is referenced in Table 1 . This section describes the requirements
and implementation of congestion control within the peripheral.
The peripheral is notified of switch fabric congestion through type 7 RapidIO packets. The packets are
referred to as Congestion Control Packets (CCPs). The purpose of these packets is to turn off (Xoff), or
turn on (Xon) specific flows defined by DESTID and PRIORITY of outgoing packets. CCPs are sent at the
highest priority in an attempt to address fabric congestion as quickly as possible. CCPs do not have a
response packet and they do not have guaranteed delivery.
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 may arrive from different switches within the fabric, it is possible to receive multiple Xoff CCPs for
the same flow. For this reason, the peripheral must maintain a table and count of Xoff CCPs for each flow.
For example, if two Xoff CCPs are received for a given flow, two Xon CCPs must be received before the
flow is 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 is used. Additionally, flow control checks can
be enabled or disabled through the Transmit Source Flow Control Masks. Received CCPs are not passed
through the DMA bus interface.
2.3.7.1 Detailed Description
To avoid large and complex table management, a basic scheme is implemented for RIO congestion
management. The primary goal is to avoid large parallel searches of a centralized congested route table
for each outgoing packet request. The congested route table requirements and subsequent searches
would be overwhelming if each possible DESTID and PRIORITY combination had its own entry. To
implement a more basic scheme, the following assumptions have been made:
•
A small number of flows constitute the majority of traffic, and these flows are most likely to cause
congestion
•
HOL blocking is undesired, but allowable for TX CPPI queues
•
Flow control will be based on DESTID only, regardless of PRIORITY
The congested route table is therefore more static in nature. Instead of dynamically updating a table with
each CCP’s flow information as it arrives, a small finite-entry table is set up and configured by software to
reflect the more critical flows it is using. Only these flows have a discrete table entry. A 16 entry table
reflects 15 critical flows, leaving the sixteenth entry for general other flows, which are categorized
together.
Figure 27 shows the MMR table entries that are programmable by the CPU through the
configuration bus. A 3-bit hardware counter is implemented for table entries 0 through 14, to maintain a
count of Xoff CCPs for that flow. The other flows table entry counts Xoff CCPs for all flows other than the
discrete entries. The counter for this table entry is 5-bit. All outgoing 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. For this reason, each transmission
source will add 2 bits to its 4-bit response time-out counter described in
Section 2.3.3.3 and
Section 2.3.4.2 . The additional 2 bits count three timecode revolutions and provide an implicit Xon timer
equal to 3X the Response time-out counter value.
60 Serial RapidIO (SRIO) SPRU976 – March 2006
Submit Documentation Feedback