IBM PowerPRS Q-64G
Preliminary
Packet Routing Switch
For all packets, odd parity is calculated on the entire packet header (H0 and H1 or H0 through H2, depending
on the configuration), including reserved bits. Parity calculation always includes the number of bytes defined
by the header length, even when a header byte does not contain any information. Because this is an odd-
parity device, the parity bit is set to ‘1’ when the packet header byte calculation results in an odd number of ‘1’
bits. Parity checking ensures that the packet header is valid, and ignores the additional information carried in
idle packet headers.
Idle packet header bytes (H1 and H2) contain flow control flywheel information, and ingress data packet
header bytes (H1 and H2) contain the destination bitmap. Flow control grants are also carried in the headers
of data, control, service, and idle packets, as well as in byte 6 of idle packets. Byte 5 of idle packets carries
side communication channel (SCC) information.
Note: A flow control grant is active when the assigned bit is set to ‘1’ in the packet header. See Section
3.4 Ingress Flow Control on page 47, Section 3.5 Egress Flow Control on page 52, and Section 3.6 Subport
Flow Control on page 53 for more information about flow control grants.
3.3.1.2 Flow Control Flywheels
The grants used for ingress, egress, and multicast flow control are carried in data, control, service, and idle
packet headers. Flow control flywheels determine which grants are carried during each ingress or egress
packet cycle because multiple packet cycles are required to receive or transmit all the grants.
For example, when PowerPRS Q-64G output controllers insert flow control grants into the egress packet
headers, four internal flywheels determine which grants are carried during each egress packet cycle. To
extract the correct information from the egress packet headers, the attached devices contain corresponding
flywheels synchronized to those in the PowerPRS Q-64G. Egress idle packet headers carry the
PowerPRS Q-64G flywheel status, which is used to synchronize the attached device flywheels to those in the
PowerPRS Q-64G. See Section 3.3.6 Flow Control Flywheels for Grants Carried in Egress Packets on page
36 for more information.
Similarly, two attached device flywheels determine which grants are carried during each ingress packet cycle.
To extract the correct information from the ingress packet headers, the PowerPRS Q-64G contains corre-
sponding flywheels synchronized to those in the attached devices. The attached device flywheel status used
for flywheel synchronization is carried in the ingress idle packet headers. See Section 3.3.2 Flow Control
Flywheels for Grants Carried in Ingress Packets (below) for more information.
Note: Each PowerPRS Q-64G port has a set of flywheels synchronized to a corresponding set of flywheels
on its attached device. No flywheel synchronization exists between ports. The flow control flywheels incre-
ment according to the number of data packet priorities enabled in the number of priorities field in the
Configuration 1 Register (page 112).
3.3.2 Flow Control Flywheels for Grants Carried in Ingress Packets
There are two flow control flywheels associated with the grants carried in ingress packet headers:
• Subport grant type/subport flywheel
• Grant priority flywheel
The subport grant type/subport flywheel and the grant priority flywheel are used to extract grants from ingress
data packet and control packet headers, which carry one subport grant and one send grant for the port per
packet cycle.
prsq-64g.01.fm
December 20, 2001
Functional Description
Page 29 of 199