Released
PMC-Sierra, Inc.
PM9311/2/3/5 ETT1™ CHIP SET
Data Sheet
PMC-2000164
ISSUE 3
ENHANCED TT1™ SWITCH FABRIC
Figure 24 shows ingress cell requests and data cells being forwarded to the ETT1 port. These cells are of
a fixed size and format: an LCS cell consists of an eight byte LCS header followed by a fixed length
payload. The payload can be 64 or 76 bytes (depending on the number of Dataslices and Crossbars used),
but all ports in the switch must use the same size payload. The TT1 Chip Set never examines or modifies
the cell payload unless the cell is used for internal control purposes.
The linecard can send a new cell request whenever a new cell arrives at the linecard and the linecard has
at least one request credit remaining for the appropriate queue. So the linecard must keep track of the
number of outstanding requests that it can send, and must not issue a request unless it has a
corresponding credit.
The ETT1 port returns grant/credit information to the linecard. This grant/credit information reflects the
occupancy of the ingress queues in the ETT1 port. The linecard can only send a cell to a given ingress
queue within the ETT1 port when it receives a grant from the ETT1 port. The linecard increments its
corresponding credit counter when it receives a grant/credit.
In order to sustain the maximum possible throughput, the linecard must be able to send a new cell within a
short time of receiving a grant/credit from the ETT1 port. If the linecard cannot do this then the VOQ at the
ingress ETT1 port may become empty which might, in turn, affect the throughput of the switch. The system
designer must be aware of the time budget that is really available to the linecard devices.
The grant/credit mechanism is not used in the egress direction. Rather, a simpler Xon/Xoff-like mechanism
is used. The oEPP will forward cells to the egress linecard whenever it has cells waiting in its output
queues. The linecard can request the EPP to not send a cell of a given priority, or any combination of
priorities, by asserting the hole request bits in the LCS header. If a hole request bit is asserted at a given
priority, then it is a request from the linecard to the EPP that the EPP should not forward a cell of that
priority at one cell time in the future. The time between the EPP receiving the hole request and observing it
is guaranteed to be no more than 64 cell times. Future LCS compliant products will have different response
times. Linecard designs requiring backpressure features should accommodate all LCS products to which
they will attach.
If a linecard has nearly exhausted its egress buffers for priority 2 cells, then it might continuously assert
hole request for priority 2 until it can recover some additional buffers.
NOTE: The hole request mechanism operates per-priority and not per-source port.
Refer to the “LCS Protocol Specification - Protocol Version 2”, available from PMC-Sierra, Inc., for further
details on the LCS protocol and the definition of the various fields used within the LCS header in each
direction.
1.4 EXPLICIT BACKPRESSURE FROM OEPP TO IEPP
The iEPP does not make a unicast request to the Scheduler unless the destination VIQ has a sufficient
number of empty buffers. For each unicast egress VIQ there is one corresponding ingress VOQ. Every
iEPP maintains state information on the occupancy of the relevant egress VIQs in all of the EPPs
(including itself) in order to ensure that it does not forward a cell to a full VIQ.
52
PROPRIETARY AND CONFIDENTIAL TO PMC-SIERRA, INC., AND FOR ITS CUSTOMERS’ INTERNAL USE
PMC [ PMC-SIERRA, INC ]
