AM4376: AM4376 Pixel Clock Jitter

Hi Barrie, 

I'm looking into this and will get back to you as soon as I find out more. Please expect an answer by end of day on Monday. 

Best Regards,

Andrei

Barrie,

Can you please clarify the measurement period. It looks like you used an extended character in your description that is not showing correctly in Firefox, IE or Edge.

Please clarify the ? below...

"(Input clock jitter is estimated by triggering a digital scope at the rising edge of input clock, and measuring peak-to-peak time spread of the rising edge of the input clock 1 ?s after the triggering)"

If possible can you also pose a picture of the scope capture showing the jitter edge so I can see if there is a characteristic pattern or not.

I assume your clock to clock jitter measurements are within spec, just the long term jitter that is out of spec?

In the meantime some things to consider are your analog/PLL power supply decoupling, stability, ground planes since these can have a large effect on the PLL.

Kind regards,

Steve

The HDMI section is on a sub board, this is the signal going to the encoder, so it's purely the AM4376.  
Linux version 4.9.119 (gcc version 7.4.0 (Ubuntu/Linaro 7.4.0-1 ubuntu1~18.04.1)) #299 PREEMPT

The period was 1uS, per the SIL datasheet 2nS max, I'm at 4nS, see below.
Linux handles the DPLL settings; beyond the jitter issue, frequency deviation is also out of spec.

I'll scope the power rails next.
Barrie

Perfect. Thanks for the clarification.

The frequency variation is really just the instantaneous clock to clock jitter, so that measurement is a red herring. The true average frequency is highlighted by the first capture that also shows the long term jitter. You should use a frequency counter to verify the actual frequency.

My gut feeling is that the PLL is not getting configured in the optimal range but unfortunately I am not familiar with the PLL.

Andrei, can we check with the PLL experts on the expectations of the PLL with the current configuration?

BR,

Steve

Hi Steve,

Thank you for the clarifications. 

Barrie, I'll forward this up to get some more information on the PLL config and get back to you as soon as I know more. 

Best Regards,

Andrei

Hi Barrie,

Are you able to provide any details on how you're setting the PLL? Predivider, m, n etc.

Regards,

Andrei

Hi Andrei.
Linux has calculated & is using the following:

clock: dpll_disp_ck: m = 297: n = 48: new_rate = 148500000


Can you offer guidance, on what would be better values to use & why?

Thanks
Barrie

Hi Barrie,

I've forwarded your reply to someone more familiar with PLL settings and have not received a reply yet. I will get back to you as soon as I know more. 

Regards,

Andrei

Hi Andrei, thanks for the input.

1. Tested n= 16,m= 495
   1. no measurable improvement @ pixel clk 742500000
2. Tested n=4, m= 99, M2 8. @ pixel clk 742500000
   1. This made the jitter worse ~5.2nS (on the same board) explain that?
3. I looked at the EVM, stock software pixel clk 33Mhz,
   1. ~3.8nS of jitter. Which is only slightly better than what I’m measuring on custom h/w @ 2x the frequency.

 
I’m to be convened this hardware is capable of achieving significant improvement in jitter.
Did the EVM pass HDMI CTS testing?

Do you have any other suggestions?
Thanks
Barrie

Thank you for the tests and results Barrie. I'm reviewing this internally and will get back to you as soon as I know more. 

Hi Barrie,

If increasing the reference frequency to the PFD increases jitter, it may mean that the source of noise is coming from your input reference clock. How are you feeding the input ref. clk? 

Does the pixel clock have to be 74.25 Mhz? The DSS PLL is not a low jitter PLL, if you are able to use something divisible by 192Mhz you can use the Peripheral PLL which IS low jitter. 

Barrie,

If you are changing the N & M directly through writing to the hardware registers make sure that you issue a PLL reset after changing them.

Kind regards,

Steve

24Mhz, xtal. Pixel clk must be 74.25 per CEA-861, referenced by the HDMI std for 720p/1080p.
The EVM is no better. TI code. TI hw. 

Linux is loading the PLL registers, we simply forced the N, prior to the M calculation, with a defined pclk.
For Each test, it's a different build of code (N) we are not on the fly changing the pll parameters.
Hope that makes sense.
Barrie

Perfect. Just checking :)

Regards,

Steve