Intel IXP2800 Personal Computer User Manual


 
Hardware Reference Manual 309
Intel
®
IXP2800 Network Processor
Media and Switch Fabric Interface
The training pattern for the flow control data signals consists of 10 nibbles of 0xc followed by 10
nibbles of 0x3. The parity and serial “ready bits” signal is de-asserted for the first 10 nibbles and
asserted for the second 10 nibbles. The start-of-frame signal is asserted for the first 10 nibbles and
de-asserted for the second 10 nibbles. See Section 8.6.2 for more information.
When a training sequence is received, the receiver should update the state of the received CRdy
and DRdy “ready bits” to a de-asserted state until they are updated by a subsequent CFrame.
8.9.4.3 CSIX-L1 Protocol Receiver Support
The Intel
®
IXP2800 Network Processor receiver support for the CSIX-L1 protocol is similar to
that for SPI-4.2. CFrames are stored in the receiver data buffers. The buffers are configured to be of
a size of 64, 128, or 256 bytes. The contents of the CFrame base header and extension header are
stored in separate storage with the reception status of the CFrame. Unlike SPI-4.2 data bursts, the
entire CFrame must fit into a single buffer. The receiver does not progress to the next buffer to
store subsequent parts of a single CFrame. (The buffer is required only to be sufficiently large to
accommodate the payload, not the header, the padding, or the vertical parity.) Designated CFrame
types, typically Flow Control CFrames, are forwarded in cut-through mode directly to the flow
control egress FIFO and not stored in the receiver buffers.
The receiver resources are separately allocated to the processing of data and control CFrames.
Separate free lists of buffers and Microengine threads for each category of CFrame type are
maintained. The size of the buffers in each resource pool is separately configurable. The mapping
of CFrame type to data or control category is completely configurable via the CSIX_Type_Map
register. This register also allows for any types to be designated for cut-through forwarding to the
flow control egress FIFO. Typically, only the Flow Control CFrame type is configured in this way.
The receiver buffers are partitioned into two pools via MSF_Rx_Control[RBUF_Partition],
providing 75% of the buffer memory (6 Kbytes) for data CFrames and 25% of the buffer memory
(2 Kbytes) for control CFrames. The number of buffers available per pool depends on the
configured buffer size. For 64-byte buffers, there are 96 and 32 buffers, respectively. For 128-byte
buffers, there are 48 and 16 buffers, respectively. For 256-byte buffers, there are 24 and 8 buffers,
respectively.
As with SPI-4.2, link-level flow control for a buffer pool can be asserted by configuration when
buffer consumption reaches 25%, 50%, 75%, or 87.5% within that pool. The receiver has an
additional 1024 bytes of packed FIFO storage for each traffic category to accept additional
CFrames after link-level flow control (CRdy or DRdy) is asserted. Link-level flow control for
control CFrames (CRdy) is also asserted if the flow-control egress FIFO contents exceeds a
threshold as configured by HWM_Control[FCEFIFO_HWM]. The threshold may be set to 16, 32,
64, or 128 32-bit words. The total capacity of the FIFO is 512 32-bit words.
Within the base header, the receiver hardware processes the CRdy bit, the DRdy bit, the Type field,
and the Payload Length. Only the Flow Control Frame CFrame is expected to lack the 32-bit
extension header. The receiver hardware validates the vertical parity of the CFrame and only writes
it to the receiver buffer if the write operation also includes payload data. The hardware supports
configuration options for processing all 16 CFrame types. In all other respects, processing of the
CFrame contents is done entirely by software. Variations in the CSIX-L1 protocol are supported
that only affect the software processing. These variations might include address swapping (egress
port address swapping with ingress port address) and use of reserve bits to encode start and end of
packets.
When the network processor is configured to forward Flow Control Frame CFrames to the flow
control egress FIFO, software does not process those CFrames. Processor interrupts occur if there
are reception errors, but the actual CFrames are not made available for further processing.