TLK10232: Sync Status

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?

See description for the channel synchronization function.

3.3 Channel Synchronization Block When parallel data is clocked into a parallel-to-serial converter, the byte boundary that was associated with the parallel data is lost in the serialization of the data. When the serial data is received and converted to parallel format again, a method is needed to be able to recognize the byte boundary again. Generally, this is accomplished through the use of a synchronization pattern. This is a unique pattern of 1’s and 0’s that either cannot occur as part of valid data or is a pattern that repeats at defined intervals. 8B/10B encoding contains a character called the comma (b’0011111’ or b’1100000’) which is used by the comma detect circuit to align the received serial data back to its original byte boundary. The TLK10232 channel synchronization block detects the comma pattern found in the K28.5 character, generating a synchronization signal aligning the data to their 10-bit boundaries for decoding. It is important to note that the comma can be either a (b’0011111’) or the inverse (b’1100000’) depending on the running disparity. The TLK10232 decoder will detect both patterns. The TLK10232 performs channel synchronization per lane as shown in the flowchart of Figure 3-2.

Based on the datasheet you would want this sync function enabled for mission mode data case, and you would only disable it for PRBS testing.

Thanks,

Rodrigo Natal

Hi Rodrigo,

Thanks for the quick anwer, but it doesn't clear our minds up. Our synchronization issues are located on the HS, which works with 64/66b encoding. The bit HS_CHANNEL_SYNC in the CHANNEL_STAUS_1 (0x1E.000F bit 10) register never goes up when we made a loopback in the optic fiber unless we set the bit SYNC_STATUS_CHECK_DISABLE. Our tester generates real ethernet traffic with randomized payload.

With SYNC_STATUS_CHECK_DISABLE, the synchronization is always archieve (bit HS_CHANNEL_SYNC always reads 1'b1), and the tester does not detect any errors. So, we understand that with this setting set the synchronization block is enable, but probably later checks are not. Could you please tell us what does SYNC_STATUS_CHECK_DISABLE do, or what effects have to set this bit?

Another thing that confuses us is that in the bringup procedure also set SYNC_STATUS_CHECK_DISABLE when KR pseudo-random test pattern is selected, when the link optimization application note says explicitly to only set this bit when PRBS testing. KR pseudo-random test pattern generate valid 64/66b blocks. Is this bit also necessary with this test pattern?

Regards,

Daniel

Could you provide a block diagram for your TLK device test system?

Thanks,

Rodrigo Natal

Hi Rodrigo,

I send you a couple of test scenarios we have made. Note that the green background means the test ran with succefully results, and the red background did not.

Regards,

Daniel

Hi Daniel,

Thanks for the block diagrams with various test cases.  Can you confirm that the signal flow I annotated on the FPGA is correct?  I have also numbed the test cases for ease of discussion.

I have a couple of questions related to your setup.

• Is my understanding correct that the only difference between TC#1 and TC#2 is the loopback arrangement on CHA?
• Can you also clarify what the difference between the local vs remote SFP+ is?
• Are you currently using the TLK10232EVM, or is the device in your system?

Regarding SYNC_STATUS_CHECK_DISABLE, I have done some digging and think I have a bit more clarity to offer.  This bit controls whether channel sync is a gating item to reach 10G link up state.  During typical operation, I would not expect that it is necessary to set this bit.  With this said, it's not exactly clear what criteria factor into the sync status, although I have a hypothesis for this.  In typical XAUI operation, my understanding is that K28.5 characters are periodically sent.  On the 10G link, I suspect these result in a 64b/66b encoded sync character.  I'm wondering if this sync character is used to set the HS sync status.

Do you know if the test pattern you are using occasionally inserts synchronization data?

Thanks,

Drew

Hi Drew,

Yes, it is correct. The FPGA only redirect thre traffic from one PHY channel to the other one.

Answering your questions...

• In TC#1, we made a loopback using a 75km fiber reel. We have also test the fiber directly with the teste, and the reel is OK. In TC#2, the loopback is made in the TLK10232 using the Shallow Local Loopback feature (0x1E.000B bit 0 to 1'b1).
• Local and remote is the nomenclature we use to distinguish between the client side, which is usually a short range connection, and remote refers to the line side, normally dozens of kilometers. It also is usefull to know what kind of transceiver is used. In this setup, the local side has a Finisar FTLX1471D3BCV 10GBASE-LR and remote side has a Finisar FTLX6872MCC 10GBASE-ZR (80km). Each one of the tranceivers have been tested individually without errors.
• No, were not using the TLK10232EVM. We're using our own design.

To add more details, the sync issue is practically persistent in the remote side, even if we reduce the distance of the loopback. The local side seems to be less problematic, but we've also seen the issue in this side.

When the CHA (remote side) is out of HS sync, the LS side seems to be unable to sync too, whe when we coinfigure the phy shallow local loopback, automatically reach the synchronization on the LS side. That make us to think the LS side and the FPGA works correctly.

As TLK10232 has both XAUI (LS side) interface an 10GBASE-R PCS (HS side), it has to synchronize and deskew the LS side and the HS side. LS synchronization and deskew is made via /K/ and /A/ characters inserted when the traffic is IDLE. HS synchronization is made by checking the sync header along the 64/66 blocks. As far I know, both side should be able to synchonize independenly.

In TC#1 the tester generates real traffic with randomized payload, which means that the stream is 64/66b encoded, has the adecuate IDLE count and the ethernet frames are well formed. This setup fails to synchronize HS side with the fiber loopback if we don't set SYNC_STATUS_CHECK_DISABLE. And it seems it causes the LS side to loss synchronization too.

In TC#3, the randomized sequence is encapsulate in 64/66 block, so it should be able to sinchronize to this stream but, again, if we don't set SYNC_STATUS_CHECK_DISABLE, synchronization is never archieved. Moreover, enabling this test pattern generation isolates the HS side from whatever is happening on the LS side, so the issue must be on the HS side.

We understand that with raw PRBS31 testing this bit must be set, since PRBS31 is not 64/66 valid block but... Why setting this feature allow our setup to sync and work properly?

Regards,

Daniel

Hi Daniel,

Thanks for the detailed response.

It seems odd that you're observing synchronization issues more on the remote side than the local side, but I'm not sure it that's worth dwelling on too much at the moment.  Correct me if I'm wrong, but I assume the primary difference between these would be the signal integrity.  I would expect that as long as the TLK10232 is receiving a clean eye, there shouldn't be a difference between remote and local links,

Regarding synchronization, it seems particularly odd that you're unable to achieve synchronization even with a payload that contains adequate IDLE count and ethernet frames.  Unfortunately, so far I have not found any additional clarity as to what exactly the TLK10232 HS sync consists of.  I would have assumed that it corresponded to whatever sync is required in 10GBASE-R system.

Could you try an additional test case?  This case would be similar to TC#2, but should implement a deep local loopback.  This can be achieved by setting 0x1E.000B bit 1 to 1'b1.  I'm curious to see how the HS block behaves in loopback.

Thanks,
Drew

Hi Drew,

You're right, this is really odd.

Unfortunatelly, we can't analyze the eye because the lack of instrumentation. The signal integrity in both interfaces has to be tested indirectly using the test pattern generation/verification, and so we did with the PRBS31 test pattern. After set the proper RX configuration, we sweeped the parameters TWPRE, TWPOST1 and TWPOST2 using the fiber loopback and the PRBS31 test pattern in the remote side. The default values were already in the center of a wide no-errrors area. We spent 5 minutes in every combination to get enough confident of the result. So apparently, the link is well equalized.

More info about synchronization process. We've also tested to enable the FEC feature in CHA. It only works if the other peer of the link also has this feature, and this is not standar in 10GBASE-S/L/ER, but since we've made a loopback it's OK. The reason why we've done this is, as datasheet says in section "3.10 Receive Gearbox", when FEC is enable, the synchronization is made in the FEC block. With this feature enable, the TLK10232 is able to archieve sync, but what is more interesting, no errors are corrected.

As you suggested, we've tested the TC#2 setting the deep local loopback too. Same result as original TC#2. Everything works well. Mention that AGC is unable to lock, but we suppose that is a expected behaviour.

Any idea of what could be going on with the sync?

Regards,

Dani

Hi Daniel,

It seems like you've done appropriate testing to ensure that the signal integrity is adequate.

Unfortunately I don't have a clear idea about what's going on with the sync.  I know the device has been used successfully for 10G links in the past, so it's not clear why your implementation seems to have synchronization issues.  In general, I think it's important to test with real traffic that has appropriate idles and well formed packets.

The fact that deep local loopback works seems to imply that something about receiving data externally may be contributing to the issue, but I'm not sure if this is the right path to pursue.

Section "3.7 Forward Error Correction" says "Frame alignment is handled inside the RX FEC block during FEC operation, and the RX gearbox sync header alignment is bypassed."  I wonder if this explains why synchronization is made with FEC enabled.  It's definitely interesting that no errors are corrected.

Another thought: Have you had any issues with lane alignment?  Can you confirm that LS_OK_IN is asserted in your testing?  The procedure for lane alignment is described in section 5.7.

Also for TC#1, have you tried replacing your fiber loop with a SFP loopback module?  Just curious if this changes the behavior at all.

Thanks,

Drew