TMS320C6655: Jitter Measurements: Peak-to-peak converted to RMS

Hi Luke,

Our expert is currently unavailable, please expect a delay in responses.

Thanks,

Neehar

Hi Neehar, 

When can I expect a response back for this issue?

Best,

Luke

Hello Luke,

Our expert on this topic/device is out of the office from August 6th to 9th, so please expect a response next week.

Thanks.

Hi Praveen,

Understood, thanks for the update! 

- Luke

Luke,

I don't quite understand what you're trying to do.  Can you point to the sections of the datasheet that you are interested in?  Generally when we specify jitter, it is informative.  We are not expecting/requiring you to measure/calculate the p2p or RMS jitter.

Regards.

Kyle

Hi Kyle,

My customer took measurements of the core clock and DDR and is telling us they have them in RMS currently. They are unsure of what BER to select to convert their measurements from RMS to peak-to-peak in order to compare with the datasheet values listed in section 5.7.4 (Table 5-6 & Table 5-7).

I am not positive of the exact reason they are looking to measure these values themselves. Is there a way to convert the values listed in the datasheet from peak-to-peak to RMS and vice versa?

Thanks,

Luke

Luke,

Does TI documentation link BER to jitter?  Can you point to that?

Regards,

Kyle

Kyle,

This HW design guide has a subsection within its Clocking section titled "BER and Jitter" (Section 3.3.1). If this is not related to this device at all or I'm incorrect in drawing this comparison, please let me know. I am not the most familiar with these devices unfortunately.

Thanks,

Luke

Kyle,

Any update here?

Thanks,

Luke

Luke,

In reviewing that section the HW design guide, it appears highly theoretical.  If they want to convince themselves they have a robust DDR interface they should focus on memory tests (or application level tests) that stress the DDR interface.

Regards,

Kyle

Kyle,

I shared this with the customer and he responded with the following: 

"See below two specs.  I measured the clocks but my measurement tool gives me the period jitter in RMS. Would like a RMS value for below as there are other Jitter specs in TI data sheet listed with RMS value"

Thanks,

Luke

Hi,

Following up on this one.

Thanks,

Luke

Hi Kyle, 

Following up on this one as there is still some confusion on the calculation part. What exactly is the equation that should be used to calculate the P2P jitter if the RMS jitter/standard deviation is known?

Thanks,

Luke

Adding context from the email thread to consolidate:

Kyle: "The general idea is that the RMS jitter is ~1 sigma assuming a normal distribution.  If you multiply that number by 6 (or 3 or 4 or 5 as you prefer) that means 0.999999998027 (from Wikipedia) chance that a real world cycle of jitter of that magnitude will occur.

As I mentioned to Luke and is mentioned in email below … this is purely theoretical, and I’m skeptical as to how this plays out in the real world. 

I would emphasize overall physical validation of the SoC in your system using some basic memory tests to convince yourself that the interface is robust."

Mike: "Correct I am doing memory tests, but we also measured clock jitter and trying to confirm it meets some level of spec to ensure layout of clock trace is sufficient.   As mentioned some other TI clock specs list it as RMS value so I thought if they can list them in RMS in some sections of data sheet TI should be able to give a us a RMS value for the others rather than p-p.  Please LMK if this is not possible?  See below"

Thanks,

Luke

Mike,

What are you measuring for RMS jitter on the DDR interface clock?   And what type/model of scope are you using?

Thanks,

Kyle