New Contributor
Regular ContributorHi Hank,
Thank you for reaching out. To make sure we’re aligned, I’d like to clarify a couple of points regarding your inquiry on the SIV CDR lock time:
Please note that these timings refer to the duration required for the CDR to recover valid data and do not include the time for word alignment.
Feel free to share any additional details or questions you may have—we’re here to help.
New ContributorHi Cheepin,
Thanks for your reply.
The CDR is currently running in manual mode, meaning we switch between LTD and LTR depending on the optical signal availability.
I’ve checked the parameters for CDR switching time in the specification, but they seem not directly applicable to our case because:
Here are our test observations:
In our tests, manually switching between LTR and LTD appears to break the CDR inside the XCVR, so it no longer locks to incoming data during LTR. When returning to LTD, it relocks within tens of nanoseconds — much faster than our previous results.
Our hypothesis is that the SFP module’s internal CDR loses lock when the light drops, causing incorrect retimed data when the signal returns. This in turn may mislead the XCVR’s CDR. We recently purchased a customized SFP module with the onboard CDR bypassed at the factory. The new SFP module without CDR should help eliminate this issue. Does this make sense to you?
By the way, could you share how long it typically takes for the word aligner to lock to correctly timed data? I assume it should be in the nanosecond range rather than microseconds. We are currently toggling the aligner enable (high–low–high) to reset it after setting the CDR back to LTD. Do you think this approach might extend the alignment time, or would you recommend a faster method?
Thank you very much.
Best regards,
Hank
Regular ContributorHi Hank,
Thank you for sharing the details. Please see my comments below:
We are not toggling rx_analog_reset due to its long recovery delay.
[CP] The diagram shows signals after reset release. You likely do not need to toggle rx_analog_reset.
Our frame size is 109 µs, so LTR remains high for about 109 µs in each frame gap, which is much longer than tLTR_LTD_manual.
[CP] tLTR_LTD_manual specifies only a minimum value. As long as your duration exceeds that minimum, it should be fine.
The spec only lists the maximum tLTD_manual (4 µs) without a typical value.
[CP] Lock-to-data time can vary based on factors such as data rate, transition frequency, and signal integrity. This variability explains why a typical value is not provided—it depends on specific use cases.
Our hypothesis is that the SFP module’s internal CDR loses lock when the light drops, causing incorrect retimed data when the signal returns. This in turn may mislead the XCVR’s CDR. We recently purchased a customized SFP module with the onboard CDR bypassed at the factory. The new SFP module without CDR should help eliminate this issue. Does this make sense to you?
[CP] That seems plausible. The XCVR CDR will attempt to track incoming data when switching to LTD mode. If incorrect data rate is presented, the CDR may lock incorrectly. Note that my understanding is that typically there is a threshold—if the deviation is too large, the CDR will lose lock even in LTD mode.
By the way, could you share how long it typically takes for the word aligner to lock to correctly timed data?
[CP] This depends on your XCVR configuration. A functional simulation with your specific setup is recommended to estimate the number of parallel clock cycles required.
We are currently toggling the aligner enable (high–low–high) to reset it after setting the CDR back to LTD. Do you think this approach might extend the alignment time, or would you recommend a faster method?
[CP] I believe you are referring to rx_enapatternalign. Generally, this should be asserted only when a valid alignment pattern is present to avoid false alignment. Your method should not significantly increase alignment time, but you can confirm via simulation.
Please let me know if you have further questions. Thank you.
New ContributorDear Cheepin,
Thanks a lot for this additional information.
I will give it a try on my end and get back to you if I have further questions. Thanks!
Best regards,
Hank
