IBM3229P2035
IBM Packet Routing Switch Serial Interface Converter
Advance
• 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.
Functional Description
Page 20 of 154
prssi.02.fm
March 1, 2001
IBM [ IBM ]
