TMS320C6748: C6748 CLKOUT limitations

Dean Hofstetter

Part Number: TMS320C6748
Other Parts Discussed in Thread: TLV320AIC20K

In the link above, I found the following statement under the "Clocking" section. It reads as follows: "Do not use CLKOUT as MCLK for any device such as CODEC. CLKOUT is for debugging purposes only. CLKOUT contains clock jitter, and is not glitch free". Well guess what, all our products use CLKOUT to drive MCLK on a CODEC.

DSP = C6748 (CVDD = 1.2V, running at 364.8MHz)
CODEC = TLV320AIC20K
CLKOUT = 19.2MHz, which drives MCLK on the CODEC
Sample rate for the CODEC = 8kHz

1. I have ONLY seen this statement on the wiki page. Neither the C6748 datasheet, or the C6748 Tech Manual, mentions that CLKOUT can't be used to drive devices. If this statement is real, why why why is there not a warning mentioned in both the datasheet and the tech manual?

2. Assuming that using CLKOUT to drive MCLK is bad, how bad is it? I need to report to my management on the severity of this problem, so I need details like: amount of jitter, what does "glitch" really mean, etc. Please provide as much detail as possible. The DSP side of support may need to bring in the CODEC side of support to truly answer this question. I checked the TLV320AIC20K datasheet, and there is nothing mentioned about jitter or glitches regarding the MCLK input.

3. How long has the wiki page had this CLKOUT warning? I see the wiki page was last updated in Nov. 2016. Multiple people at my company have referenced this wiki in the past. We've been using the C6748 for 5+ years. I'm trying to understand if we all somehow missed it, or it was recently added.

Please respond ASAP. All R&D is currently on hold, and we are debating on how to handle production.

Thanks, Dean

over 8 years ago

0 Cvetolin Shulev-XID over 8 years ago

TI__Guru 65405 points

Hi Dean,

I've forwarded this to the design team. Their feedback should be posted here.

BR
Tsvetolin Shulev

0 Mukul Bhatnagar over 8 years ago

TI__Guru* 84075 points

Hi Dean

With schematic checklist we typically try to put all typical mistakes/gotchas that we see in customer schematic reviews - the intent is to call out some key things that customers may miss out or have been mis interpreting from our documentation.
the CLKOUT description was added in August 2013.

The datasheet terminal function description for CLKOUT is PLL observation clock and really that is what it is for - to help debug.

The reasons we do not recommend CLKOUT to be used for such use-cases, is what we have more explicitly stated in some other datasheets like AM335x

The AM335x CLKOUT1 and CLKOUT2 clock outputs should not be used as a synchronous
clock for any of the peripheral interfaces because they were not timing closed to any other
signals. These clock outputs also were not designed to source any time critical external
circuits that require a low jitter reference clock. The jitter performance of these outputs is
unpredictable due to complex combinations of many system variables. For example,
CLKOUT2 may be sourced from several PLLs with each PLL supporting many configurations
that yield different jitter performance. There are also other unpredictable contributors to jitter
performance such as application specific noise or crosstalk into the clock circuits. Therefore,
there are no plans to specify jitter performance for these outputs.

We have no characterization data on CLKOUT that allows us to say whether or not this can/should be used for MCLK for AIC codec. That was not the design intended use-case for this CLKOUT pin.

If you are products are working w/o issue , then it may be best for your team to do the risk assessment based on your product design.

I apologize for the inconvenience, i do not have a better answer for you on this.

Hope this helps.
regards
Mukul

0 Mukul Bhatnagar over 8 years ago in reply to Mukul Bhatnagar

TI__Guru* 84075 points

FWIW , I am also investigating if we added the "contains clock jitter, not glitch free" due to any specific customer issue or observation. We simply do no recommend customers using CLKOUT for MCLK primarily for the reasons stated in my previous post.

You will see our EVM designs also adhere to this.

0 Dean Hofstetter over 8 years ago in reply to Mukul Bhatnagar

Expert 2585 points

Mukul,

Thanks for the quick response. I understand the best answer TI can give is "your mileage will vary". We do see odd behavior in our products from time to time, that so far we've haven't been unable to explain. Could a glitch, or jitter, of CLKOUT explain why we see a higher percentage of modem retrains ..or.. audio static ..or.. poor echo canceler performance on a unit or two? Perhaps. For existing products there is not much we can do.

Which leads to new designs. Going forward we will NOT use CLKOUT from the C6748 to drive MCLK of the CODEC. So the question is: what is the best way to drive MCLK? I see two options, and wonder if one is better than the other. #1 Use an oscillator, #2 Switch to McASP and have that generate MCLK. Do you know of any upsides/downsides to either option?

By the way, if we do go the oscillator route, I'm thinking XO, TCXO, or MEMS. I'm not familiar with oscillators (we've always used crystals), so any guidance you can offer is appreciated. Their is nothing in the TLV320AIC20k datasheet about ppm tolerance of the MCLK. I see the LC Dev kit uses an oscillator with +/-50ppm. Is +/- 25 ppm "better", or is that overkill?

Finally, I would like to suggest you update the C6748 datasheet and tech manual. The datasheet never really warns about CLKOUT being used for test/debug only. All it says is "PLL Observation Clock". The Tech manual doesn't go into a lot of detail regarding CLKOUT, but if you updated Figure 7-1 with wording like: "CLKOUT only used for test/debugging", that would help. I do acknowledge that the description for the OCSEL register (7.3.7) does use the wording "test and debug purposes" when referencing CLKOUT. We simply missed that statement.

Thanks, Dean

0 Mukul Bhatnagar over 8 years ago in reply to Dean Hofstetter

TI__Guru* 84075 points

Hi Dean
Appreciate the update and feedback.
I confirmed looking through archives that there is no device specific issue with c6748, the "wording" for that wiki got carried over from c55x schematic checklist where i believe there are some known issues that required us to make a more assertive statement.
I plan to fix the wiki wording to match the note in the AM335x datasheet , to clarify our intent on why this should not be used.

I will double check with my audio gurus to see use of oscillator (I wouldn't recommend McASP clock either) and ppm requirements. As you mention there is no jitter requirement stated in this AIC datasheet either (and I did not that in that datasheet it still shows older c54x / c64x style designs with CLKOUT sourced from device).
I will get back to you on this.

I appreciate the feedback on the collateral. My plan is to add more specifics in the clocking section of the TRM/user guide. I will evaluate if I should add something in the DM too, I am usually resistant of changing datasheets unless they have serious bugs specifically for a device that has been out there for a long time.

In the longer run I am also hoping that these schematic checklist be folded in some ti.com like collateral, with more stringent revision control, so that updates are not missed by end users.

0 Mukul Bhatnagar over 8 years ago in reply to Mukul Bhatnagar

TI__Guru* 84075 points

Hi Dean

The suggestions from the team were

For the use case you have , XO should be fine.The best audio performance is when an oscillator that generates Master CLK is placed close to the Codec with the McASP operating as a clock slave.This configuration minimizes the master clock jitter for conversion.

If it is necessary for the clock to be provided by the McASP - then the Master Clock then clock noise management techniques can be employed to minimize clock jitter such as using layout signal shielding, passive termination, clock driver with termination or using a differential driver/ receiver. Do note that because we didn’t want PLL jitter discussions , for these devices we spec’d the McASP to take the OSCIN as a clock source. So using the McASP AHCLKx/r pins you can bypass the on chip PLL completely

I am also curious why you are using 19.2 MHz? The possible masterclock frequencies for the codec without using the PLL is where MCLK is roughly any integer multiple of 1.024 MHz e.g 24.576 MHz. If you USB in the system, then you likely need to use 24 MHz (which will not give you 8k multiple sample rates - but that is likely the case with 19.2 MHz?)

Hope this helps.

Regards

Mukul

0 Mukul Bhatnagar over 8 years ago in reply to Dean Hofstetter

TI__Guru* 84075 points

Hi Dean
To close the original issue out i have
1) Updated the schematic checklist wiki wording on CLKOUT
2) Have authorized a change in the datasheet to further put a note on the CLKOUT terminal description to highlight it is for test and debug purpose only. This datasheet should hopefully come out on ti.com in a week or so.

Regards
Mukul

0 Dean Hofstetter over 8 years ago in reply to Mukul Bhatnagar

Expert 2585 points

Hi Mukul,

To answer your question regarding why 19.2MHz is used for the input clock, it is because one of our products did use the USB 2.0. 19.2MHz is a magically frequency that satisfies the USB clocking requirements, and almost all the codec clocking requirements. The only clocking requirement we can't meet for the codec(with 19.2MHz) is it recommends to have OSR set to 512 if using 8kHz sampling. Instead we use OSR set to 256.

Thanks for the feedback on the oscillator. We plan on using a XO oscillator placed right next to the codec.

Finally I appreciate the updates to the wiki and datasheet. Won't help me much, but if it can help someone down the road, then your job just got a little easier :)

Thanks for all your help,
Dean

Processors

Processors forum

TMS320C6748: C6748 CLKOUT limitations