RX_OOBFC - 2.4 English - PG169

For correct operation of the RX_OOBFC to occur, two things are essential:

• The user-side clock, clk, must be faster than the receiving clock, RX_FC_CLK, by at least 33%. For example, if the frequency of RX_FC_CLK is 100 MHz, then the frequency of clk must be at least 133 MHz.
• The reset input, reset, must be asserted until after several cycles of both input clocks, clk and RX_FC_CLK.

Reception of flow control information starts as soon as the reset input is deasserted. However, the RX_OOBFC does not consider itself initialized and does not supply the received information until it has seen several correct transitions on the RX_FC_SYNC input. During this initialization procedure, the rx_fc output bus is set to XOFF (that is, 0). After the initialization procedure is completed, the RX_OOBFC supplies status and flow-control information as received through the interface.

The Interlaken Protocol does not require the transmission of status information if the interface is healthy. As a result, RX_OOBFC assumes the interface is healthy if it receives two back-to-back valid calendars of flow control information. In healthy conditions, the rx_intf_status and rx_lane_status outputs are all set to 1.

Additionally, in healthy conditions, the received flow control information is presented on the rx_fc output bus. The first calendar value received is presented on rx_fc[0], the second on rx_fc[1], the third on rx_fc[2], and so on. If the received calendar has fewer entries than the total width of rx_fc bus, the "unreceived" bits in rx_fc will be undetermined and must be ignored by the user logic.

Whenever unhealthy status information is received, all the bits of rx_fc are forced to XOFF (that is, 0). When healthy status information is determined, rx_fc is updated to reflect the most recently received values of flow control information.

If a CRC4 error is ever detected during the receipt of a calendar of flow control information or during the receipt of status information, the rx_crcerr output is asserted (set to 1). Whenever rx_crcerr has a value of 1, the rx_fc, rx_intf_status, and rx_lane_status outputs are not updated and should be considered invalid (the Interlaken Protocol requires you to take appropriate action when rx_crcerr is asserted). The rx_fc, rx_intf_status, and rx_lane_status outputs should be considered valid only when rx_crcerr is negated (that is, 0).

The rx_overflow output is an aid to help identify incorrect clock rates. It is asserted (set to 1) when the clk input is not fast enough relative to RX_FC_CLK.

The RX_OOBFC accepts any calendar length up to MAX_CAL. The most recently received calendar length is reported on the output rx_callen_minus1.

The rx_fc output is updated in groups of 64 bits. When the first group is updated, rx_update[0] is asserted. Then the second group of 64 bits is updated, rx_update[1] is asserted, and so forth.