
IBM3206K0424
Preliminary
IBM Processor for Network Resources
pnr25.chapt01.01
August 14, 2000
Transmit Path
Page 37 of 676
Transmit Path
A typical transmit operation begins with the software requesting a buffer from POOLS and filling it with data 
via slave DMA, master DMA, or processor writes. If virtual buffers are being used, the data write operation 
can fail due to lack of physical buffers. In the event of a failure, the header of the packet is updated to indicate 
the failure. The software can audit the header after the buffer has been completely transferred, and either 
take action to recover the data immediately or allow CSKED to generate an event later in the transmit cycle 
for any buffers that have had a data write failure.
Before the data can be transmitted, the buffer header must be updated to contain information required for cor-
rect transmission. Information such as data length, starting offset, and Logical Channel (LC) address are just 
a few of the fields that must be correctly reflected in the buffer header. For a complete list of the fields in the 
buffer header refer to 
Packet Header
 on page 61.
In addition to the fields in the buffer header, the scheduling and segmentation sections of the Logical Channel 
Descriptor (LCD), such as peak rate, average rate, and AAL type, must also be set up correctly prior to trans-
mission. For a complete list of the fields in the LCD, refer to 
Transmit Logical Channel Descriptor Data Struc-
tures
 on page 66.
After the data have been transferred into packet storage and both the buffer header and the LCD structure 
have been correctly initialized, the buffer address is queued to CSKED. When it receives a buffer, CSKED 
checks the buffer header (Packet Memory) to make sure that the data transfer operation that filled the buffer 
completed without error. If it finds an error, CSKED posts an event to software and does nothing further with 
this buffer. If no error is indicated in the buffer header, CSKED fetches several fields from the LCD (Control 
Memory) indicated in the buffer header to determine the current state of that LCD. If the LCD is busy sending 
another buffer, the new buffer is queued to this LCD and will be processed when all previously enqueued 
buffers have been transmitted. If the LCD is not busy, CSKED updates the LCD based on several fields in the 
buffer header and queues the LCD to the next time slot on the time wheel (Control Memory).
When CSKED detects a previously enqueued LCD on the time wheel, several fields are retrieved from the 
LCD. Among other things, these fields are used by CSKED to determine where on the time wheel to resched-
ule this LCD. The LCD address is then provided to SEGBF for processing.
When CSKED provides an LCD address to SEGBF, the segmentation portion of the LCD is retrieved from 
Control Memory to determine both the current address at which to continue buffer segmentation and the type 
of cell to construct. Depending on the AAL type bits in the segmentation portion of the LCD, the cell is con-
structed in an internal array using data from the LCD as well as data fetched from Packet Memory. When the 
cell construction is complete, status is raised to LINKC indicating that a new cell is available for transmission.
Transmit opportunities are repeatedly provided to SEGBF by CSKED at the desired rate until all the data in 
the buffer has been passed to LINKC via the cell buffer array. When SEGBF detects that no more data exists 
for a buffer, the LCD address is passed back to CSKED, indicating buffer completion. At this point, CSKED 
removes the LCD from the time wheel if no more buffers are queued in it. If more buffers are queued, the LCD 
is updated and the segmentation process continues until all buffers on the LCD queue are serviced. A bit in 
the buffer header generates a transmit complete event when no buffers remain in the queue.