LVDS SERDES rx_inclock idle

Hi,
if PLL doesn't lose lock, there's most probably no need to change anything.

Hi,

"Is there any reason why the transmitted clock should be modified depending on data content in the sender?"

We are working with the IC vendor to understand that.

"What is the primary problem, do you experience data corruption?" 

As i mentioned, we do not see any data corruption in practice. The issue is that the jitter on this clock does not meet the IO PLL cycle to cycle jitter requirements and we would like to understand if we might have some robustness issue here. 

unfortunately, such a major design change like using CDR is not an option right now. 

Hi,
thanks for clarification. I was misleaded by a comment in initial post "for example clock is only running when the transmitter outputs data". This would in fact exclude usage of transmitted clock as PLL reference, or at least require up-to 1 ms lock delay.

Is there any reason why the transmitted clock should be modified depending on data content in the sender? If not, I guess you are seeing just some kind of data-to-clock crosstalk. Or, the worse case, an actually unstable TX PLL clock.

What is the primary problem, do you experience data corruption?

Personally I'd tried to get rid of a dedicated clock channel and use CDR receiver with 8b/10b encoded data. 

P.S.: If you are sending unencoded binary data and can't use CDR, TX clock is discontinuous but frequency tightly defined, there is most likely a way to regenerate a continuous clock in a kind of soft PLL.

i will clarify, 

First we are talking about an existing design which is used for years in multiple systems that are in mass production. I would say that the design is functionally working, we do not see any actual data integrity issues.

The transmitter is an IC which output an 200MHz clock and a few channels of DDR data.  The receiver is implemented in a cyclone 10 GX device using the LVDS SERDES IP. 

Lately, we found that there are some inconsistency in the IC LVDS output clock behavior and that the clock show some correlation to output data. i.e. the clock does not behave like a free running clock with a constant period and duty cycle. I'm trying to understand if this is an issue and if the LVDS SERDES can handle a clock that is not free running.

see picture below to see clock pulse width variations for data transaction MSB and LSB. 

Hi,
I might have misunderstood the question. You have an existing multichannel LVDS transmitter with discontinuous 200 MHz DDR clock and want to design a receiver for it in Cyclone 10 GX?

I suggested to receive it without a PLL driven SERDES and asked for clock and data waveforms. 

Regards
Frank 

Hi, 

This is a design already used in mass production products, it is not that simple to update the design. 

As i understand from Altera LVDS SERDES IP Core User Guide, rx_inclock goes into I/O PLL and the designer has not much say about this. I'm adding screenshots from my LVDS SERDES IP settings. 

Hi,
PLL reference clock must be continuous, PLL isn't able to lock to a gated clock immediately.

Your signal description suggests that the discontinuous clock send along with LVDS data can be used to sample the data directly without a PLL. 200 MHz DDR clock (400 MBPS) isn't particularly fast, Cyclone 10 GX should be able to receive it through GPIO DDR registers and deserializer in core logic.

Can you show exact relation of tx clock and data?

Regards
Frank