PRELIMINARY
PMC-Sierra, Inc.
PM9311/2/3/5 ETT1™ CHIP SET
Data Sheet
PMC-2000164
ISSUE 3
ENHANCED TT1™ SWITCH FABRIC
3.1.2.3 LCS Grant Manager Arbitration
The LCS Grant Manager arbiter makes a linecard grant decision every celltime, based on information from
the Linecard Request Counters and Input Queue Debit Counters. When the EPP is in OC-48c mode, each
queue is shared by 4 request counters, one per subport. Therefore, in OC-48c mode, additional state
information about multicast and unicast flows is used in the decision, in order to prevent any request
counter from being starved by the other request counters contending for the same queue.
When the EPP is in OC-48c mode, the LCS Grant Manager arbitrates between the eligible flows requested
by each subport in turn (subport 0, subport 1, subport 2, subport 3, subport 0,...). Thus each OC-48c
linecard will receive at most one grant every 4 celltimes.
A flow is eligible for arbitration if its request counter is nonzero and its debit counter is less than the queue
size. The arbiter enforces the ETT1 service class priority scheme (Control Packets > TDM > MC0 > UC0 >
MC1 > ... > UC3). Within each unicast priority, the arbiter performs a round-robin on eligible flows. The
order of flows considered in the round-robin is increasing {egress_subport, egress_port}. So for an egress
port that is in OC-48c mode, its subports will appear once each 32 steps in the ordering. For an egress port
in OC-192c mode, there is only one valid subport (0), but each egress_subport step for that port will map to
subport 0.
Because of the strict order in which grants are given to each subport in OC-48c mode, and the
unpredictable timing of cells leaving a congested queue, it would be possible for some request counters to
never receive grants if the arbitration were left as a free-for-all. In order to avoid this, the LCS Grant
Manager “reserves” the last space in each unicast or multicast queue for a rotating favorite subport. When
a debit counter indicates that there is only one space left in a queue, only the request counter of the
favorite subport for that queue is eligible. Whenever the favorite subport gets a grant, regardless of
whether the queue is down to its last space, the favorite subport changes to the next subport with a
non-zero request count. This algorithm ensures that no request counter can be starved.
3.1.3 Scheduler Request Modulator
The purpose of the Scheduler Request Modulator is to prevent unicast output queues from overflowing.
The Scheduler’s backpressure mechanism only supports port-granularity backpressuring, which is not
acceptable for unicast (subport-granularity) queues. So instead of sending backpressure commands from
the oEPP to the Scheduler, all oEPPs send queue occupancy information to all iEPPs via the Flow Control
Crossbars. The Scheduler Request Modulator uses the output queue occupancy information to prevent
overflowing any unicast output queue; if there is not enough room left in an output queue, no more
requests for that output queue will be sent to the Scheduler until more room becomes available.
Since unicast and multicast are interleaved per-priority in the overall ETT1 priority scheme, multicast
requests are also arbitrated by the SRM.
The SRM consists of input queue request counters, output queue debit counters, an arbiter for deciding
which flow to request to the Scheduler, and state for restoring subport information to Scheduler grants.
3.1.3.1 Input Queue Request Counters
Input Queue request counters are initialized to 0 at reset. Unicast and multicast request counters behave
slightly differently.
158
PROPRIETARY AND CONFIDENTIAL TO PMC-SIERRA, INC., AND FOR ITS CUSTOMERS’ INTERNAL USE
PMC [ PMC-SIERRA, INC ]
