We are usign the tlk10232 as phy for a dual SFI application. One SFI channel connects with a SFP+ 10GBASE-SR compilant, an the other with an extended range SFP+ (10GBASE-ZR, 80km). Both XAUI sides are connected to a Xilinx FPGA. By now, the FPGA design only fodwards the incomming traffic from one interface to the other. The XAUI IP is the one provided by Xilinx.
Our test setup consist in an Anritsu MT1000A Ethernet tester conected to the SFP+ BASE-SR through a short fiber link, and a long fiber loopback of 75 km in the other SFP+. The tester produces a valid ethernet framing, and only randomizes the payload. Thas is: Tester PRBS gen -> SFP+ ->TLK10232.B -> FPGA -> TLK10232.A -> SFP+ -> 75 km fiber loopback -> SFP+ -> TLK10232.A -> FPGA -> TLK10232.B -> SFP+ -> Tester PRBS checker.
We configured the TLK10232 in 10G-KR (Auto-Negociation and Link Training disabled) and, as differents post and app notes said, HS_ENTRACK (0x1E.0004 bit 15) to 1’b1 and HS_EQPRE (0x1E.0004 bits 14:12) to 3’b101. With this settings, we saw a lot of errors of decodification (0x1E.0010) and synchronization (0x1E000F bit 10 always 1'b0) was never archieved in the Channel A (the one with the fiber loopback made).
After an intensive test procedure on the RX of the HS side, we concluded that HS_PEAKDISABLE (0x1E0004 bit 6) to 1'b1, HS_ENTRACK to 1'b0 and HS_EQPRE to 3'b101 was a better configuration. This is also a reliable configuration in 10G application, as other posts and the TLK10xxx High Speed SerDes Overview point out.
With this configuration, the errors disappeared, but we still had constant losts of synchronization. Even if the link went up, if we did open the fiber and close it again, the channel wasn't able to synchronize.
After configure the HS RX, we focused in the TX. Using the loopback,we set the PRBS31 test pattern generation and verification as the TLK10232 Bringup Procedure says. After the test, we could see the with the default values of TWPRE, TWCRF, TWPOST1 y TWPOST2 and HS_SWING set to 660mV, we were in the center of a wide area os free error configurations. But, again, the synchronization issues persist.
It was at this point when we realized that, despite the SLLA351A says, the bringup procedure also set the bit SYNC_STATUS_CHECK_DISABLE (0x1E.8021 bit 4) to 1'b1 for KR pseudo-random test pattern. This pattern wraps a randomized sequence in a valid 64/66b block, so this bit should not be set.
The point is, if we set SYNC_STATUS_CHECK_DISABLE to 1'b1 in normal operation, the synchronization problems seem to disappear, and all the design works correctly. The questions are: What does SYNC_STATUS_CHECK_DISABLE exactly do? And... SYNC_STATUS_CHECK_DISABLE = 1 is a valid "production" setting?