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.

PLL on OMAPL138

Other Parts Discussed in Thread: OMAPL138

TI,

We have the OMAPL138 on our design and are seeing jitter on the EMIFA output.  We have not isolated the problem and wanted to know what the jitter specifications were for the internal PLL. We have a low jitter clock source externally but wanted to understand what sources could be causing our jitter on the EMIFA interface. 

Thanks,

Jason

  • What is the application whereby "jitter" on the EMIFA is important?  Is this application using the EMA_CLK for something other than a SDRAM?

  • I am considering using that clock as the FPGA clock.  However, that clock will go into another PLL in the FPGA.  Therefore a constant  cascade of PLL's must be evaluated to prevent nuisance issues.
     
    The reason this issue keeps coming up is we need to be able to move data in and out of FPGA at a fairly high bandwidth.  While there are lots of solutions, reality often limits them(e.g. we have to use EMIF, not uPP).  Secondarily, the EMIF clock and the FPGA are NOT synchronous (the FPGA is 50 MHz and the EMIF is 101.33...).  Even if the EMIF was 100 MHz and we did a divide by 2, the phases would be not aligned.    We also NEED the FPGA to be a very fixed frequency since they is part of our real time controls system.  A lot of things hinge on that 20 ns PERIOD.  What the proposed, while it will "work", will still not need our bandwidth requirements without a high level of parallelism and high "in"-efficiency.
     
    Therefore, if we somehow tweak the DSP core to a 450 MHz (I have asked out staff to see if the PLL's can be adjusted to that with a new input oscillator). If we can do that, the output frequency of the EMIF would be exactly 100 MHz.  This signal could be used internally and divided by 2 and would be phase locked (another PLL).  Now, all of a sudden, life gets a bunch easier and we can still move data @ 50 MByte/sec and keep the FPGA core as desired.