PLL mult/div Limitations DM368

To TI Apps Support: 

Our customer has issues with their board that’s using TI TMS320DM368. About half of the boards from the 30 pc. batch that they built perform slower than the other half. The board captures 1080i video and does H.264 compression using TI SDKs. Half the boards perform normally, half seem to be compressing slower (drop frames). When the customer swapped DSPs between a ”good” and a ”bad” board the problem followed the DSP.

 Customer is still experimenting trying to narrow the problem down, but I thought it might ring a bell for TI people. The marking on the chips is as following:

 DM368ZCE

28A24FW

570

GI

Hope to receive your prompt response.

Thanks,

Leo

Leo,

Just to confirm, were the markings the same on the "good" and "bad" chips? If so, this definitely seems to be an unusual circumstance if they're coming from the exact same batch as well.

-Reagan

The chips that were swapped were from different batches. But half of the boards assembled with chips from a "bad" batch work fine.

Is there any chance I can get a reply on my PLL question?

Regards,

Alexander.

Hello,

I'm looking at the data sheet (SPRS668C) page 60, and it shows an example with 24MHz-36MHz range examples for the input, and 680MHz for PLL Output.  From that perspective, your input/output seems ok. 

Could you try to simulate one of the examples in the data sheet and check on your stability?

Also double check your DDR2 timings.  Often times an improper DDR controller configuration (i.e. incorrect CAS latency, etc) can make systems unstable.

Ivan,

if I understand Table 3-9 (SPRS668C, p.61) correctly, for 27 MHz input clock the suggested values for PLL1 are:

PLLM=340,

PREDIV = 0,

POSTDIV=26,

so that 

PLL1OUT= 27 MHz / (PREDIV + 1) * 2 * PLLM / (POSTDIV + 1) = 27 / 1 * 2 * 340 / 27 = 680 MHz.

I find it very doubtful that those settings will work because they result in the PLL clock (before the post-divider) of over 18 GHz. 

That's why I was (and still am) looking for the answer from TI: what are the limits on the PLL clock frequency (both upper and lower)?

As for DDR settings: we've double and triple-checked those. We also ran a temperature test on our boards, up to +70C. Not a single problem there. Our system is not "unstable", it's very stable, just the speed varies between the boards. If there was a DDR problem, wouldn't we see data and code corruption? We don't see anything like that. On "bad" boards compression takes longer than on "good" ones, that's it.

Regards,

Alexander.

Alexander,

I also get 680MHz for PLL1's VCO.  However, if you first program the predivider (PLL1PREDIV), then you should not run into issues on over-running PLL1.  

I'm checking with the design team on what frequency ranges are acceptable for the PLL.  The concern with setting up the predivider could be the input frequency.  

Also, could you provide more details on your system failure?  How does the system hang, how often, etc.

I've just found some info.  The max PLL output frequency is actually 1GHz.  680MHz should be fine.  Also, at the input:

Given that CLKOUT = (M / N+1) * CLKINP, 

Multiplier (M) and Divider (N) Constraints:
N = 0 to 31 and CLKINP = 1 MHz to 50 MHz if:
0.4 MHz <= { CLKINP / N+1 } <= 50 MHz, in this case CLKINP / N +1 = 27MHz so this is OK

M = 2 to 2023 and N = 0 to 31 if:
2 MHz <= { CLKINP * (M/ N+1) } <= 500 MHz, in this case CLKINP * (M/ N+1) = 918MHz, which is not OK

So you're right, we need to make the PLL equations obey both of these relationships.

Ivan,

I'm not sure I understand where 0.4 MHz and 2 MHz numbers in your example came from.

There is most likely a minimum PLL input frequency limitation as well. What is it?

Also, is there a requirement on the duty cycle of the clock for various blocks of DM368? In SPRUFG5A, p.38 it mentions that "system clock dividers generate 50% duty cycle output clocks". What if the clock divider is set to 1? In this case duty cycle may not be 50%. In my case the ARM clock is taken directly from PLL2 output (432 MHz / 1). Is that OK?

Regards,

Alexander.

Got it. Looks like my settings are within those limits.

Thanks.