This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DCAN bit rate accuracy or error

Other Parts Discussed in Thread: CDC5801A

 

Hello,
My customer needs to define the DCAN bit rate accuracy. Could you please advise?

- The final accuracy was not found in the DS or TRM.

- Therefore I'm trying to calculate from the clock path, but it is not successful.
  I think the only error source is the PLL1 jitter. And the error will be reduced by dividers:

    • The clock path is:
      • Xtal: 16MHz +- 200ppm  --> OSCIN
      • PLL1: 160MHz
      • VCLKA1 = DCAN clock input: 80MHz
      • DCAN bit rate:  500kHz

Best regards,

  • Hi Hideaki,

    To me disregarding the PLL as a source of error makes sense.   The input clock is 16MHz which means the PLL is getting reference information 32x faster than the DCAN bit rate - since it can make many corrections within 1 DCAN bit time then the average of all the PLL jitter should be close to zero.

    I would just assume that the PLL is tracking the input clock and use the accuracy of the input clock as your number.

  • Hideaki,

    Typically the VCLKA1 domain is mapped to using the main oscillator (clock source # 0) as its source. This way, the CAN baud clock is only affected by any drift in the main oscillator.

    This is done by configuring the VCLKA1S field of the VCLKASRC register (address 0xFFFFFF4C).

    Regards, Sunil

  • Anthony and Sunil,
    I appreciate your replies. My customer has two ways:
      - The average of all the PLL jitter should be close to zero.
      - The main oscillator can be directly supplied to the DCAN to avoid PLL jitters.

    By the way, is it possible to tell a worst case value of the PLL1 jitter?
    The value is requested because my customer is trying to explain the performance of existing CLK setting with the fPLL1=160MHz. Please add a large margin if needed.

    As long as I study "CDC5801A", Their point is not the average but "Period p-p".

              http://www.ti.com/lit/ds/symlink/cdc5801a.pdf

     

  • Hi Hideaki,

    Sorry we don't have this information in our datasheet.  One might be able to make an inference about jitter being good enough for CAN given we meet the FlexRay specifications for parts with FlexRay. (spns162b - page 132) but that is an indirect understanding and it assumes that the PLL is not used in spread-spectrum mode.  For this purpose we actually include 2x PLLs on the device.    Normally customers use the spread spectrum mode on the primary PLL to introduce large amounts of jitter (%) so that the EMC emissions / energy is spread among many frequencies and peaks are avoided.   Whereas the CDC chip's job in life is to create low jitter clocks.

  •  

    Anthony,

    a>  FlexRay. (spns162b - page 132)

    tjit(SCLK)    Jitter for the 80MHz Sample Clock generated by the PLL    0.5 ns

     

    Could you please explain the parameter "tjit(SCLK)" on the page ?  Does it mean that the PLL jitter is 0.5nsec when it outputs 80MHz?

     

    -n

     

     

     

  • Hi Hideaki,

    Yes I think so although I don't think you can easily see the SCLK except in a test mode.

    The bottom line here though is that we are saying we meet the tight requirements of the flexray protocol w.r.t. jitter. 

    We'd need to look up the FlexRay standard to get all the details on how this is measured exactly - but I think it will be much more lax for CAN than it is for FlexRay.

  •  

    Anthony, please forgive me to repeat the same question. My customer requests TI's comment:

    Could you please tell a worst case value of the PLL1 jitter?  

    Please add a sufficient margin in your reply.  Do you agree, like 20nsec ?

     

    -n

     

  • Hi Nambu,

    Sorry - we do not characterize or spec this parameter.