
IBM3209K3114
IBM Packet Routing Switch Serial Interface Converter
Advance
Functional Description
Page 8 of 142
prssi.01
July 12, 2000
RXENB and TXENB signals can not be used to perform flow control at an octet level, as is allowed in
UTOPIA-2 specifications. Each packet transfer initiated in either the ingress or egress direction will con-
tinue to flow until current packet transfer completion, eliminating the ability to insert wait states during the
current packet transfer
The assertion of the RXENB signal depends only on the ingress FIFO filling status and so may be
asserted while the RXPAV signal is de-asserted
Wait states insertion on the bus is only allowed between transmission of two different packets
All input and output signals are registered. Therefore, a device (either the PE or the converter) responds
in not less than two clock cycles after the initiating signal is sent across the interface
All output signals are generated and all input signals are sampled on low-to-high clock transitions
All signals are active high, unless the name has an overbar (xxx).
3.2.1 Ingress Interface
3.2.1.1 Bus Protocol
The ingress block is the receive path between the protocol engine device (PE) and the IBM Packet Routing
Switch Serial Interface Converter (the converter). Data is sent by the PE to the converter according to the
following protocol:
The converter provides the receive clock PE_RXCLK_OUT
The PE asserts the signal RXPAV when it is ready to send at least one complete packet on the bus
The converter asserts the signal RXENB when it is ready to receive at least one complete packet
Receive packet transfer can start once the PE detects RXENB asserted and asserts RXPAV
The assertion of the signal RXSOP during one clock cycle indicates start of a receive packet transfer
RXDATA[31:0] is transferred on each low-to-high clock transition and the first data word of the packet is
transferred simultaneously with the signal RXSOP
The converter de-asserts the RXENB signal
two clock cycles before the end of the current packet transfer
to indicate that it can not accept an immediate transfer of the subsequent packet from the PE
This protocol applies if a user wishes to use OBFC mechanisms in addition to IBFC. Under IBFC there is no
need for the use of RXENB /RXPAV protocol, as all the flow control is performed in band (through the packet
header). Also under IBFC, if there is no data packet to be sent by the protocol engine, it will insert an idle
packet that will be discarded by the IBM Packet Routing Switch Serial Interface Converter.