Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

  • State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 30 subscribers
  • Views 370 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TLV320AIC22C fsync between two clock domains

Dr. Haensse
Prodigy 170 points
Other Parts Discussed in Thread: TLV320AIC22C

Hi 

we have a the TLV320AIC22C design, with two clock domains and the codec is used as in slave mode.

Unfortunately the first clock has a big jitter with makes it impossible to generate an adequate clock for the codec.

For this reason a second low jitter clock is used to drive the codec (MCLK). The two clocks are not synchronized to each other (time shift). 

The data stream from the first clock has a framing signal. The codec also requires a framing (fsync).

The fsync signal uses a fixed ration of 256 clocks per fsync.

The only way to lock the codec to the data stream is to violate the 256 clocks per frame ratio "sometimes". 

"Sometimes" means if the data stream starts or if it need resynchronization if the lock is lost.

Is there a way to do so, without degrade the audio quality of the audio streams in any direction. Does the codec crash if the 256 ratio is violated? What is the best time window to adjust the number of clocks (e.g. end of the frame, make it a clock longer or shorter)? Thank you

  • 0
    TI__Guru**** 189399 points

    Hi, Dr Haensse,

    I talked to one of the apps engineers who used to work on this device, and here was his advice:

    Best I can say is that they cannot violate datasheet specs and expect the device to operate normally.  A few specific areas:

     -          There’s no specific spec for BCLK quality, HOWEVER there’s the following statement in the BCLK pin description.  They are using the codec in slave mode, but is BCLK sync with MCLK?  Is FSYNC synced with MCLK?  These are not clear from the description below. 

    • When configured as an input (slave mode), BCLK is an input and must be synchronous with the master clock and frame synchronization.

    -          Delay from BCLK to FSYNC rising can never be more than 15 ns in slave mode – looks like they will violate this. 

    • td(1) Delay time, BCLK↑ to FSYNC↑ (slave mode) 15 ns

    -          Delay from MCLK to BCLK rising can never be more than 29 ns in slave mode – looks like they will violate this. 

    • td(3) Delay time, MCLK↑ to BCLK↑ (slave mode) 29 ns

     

    They would need to do experiments on what happens in their system when they violate these specs to see if the behavior is acceptable.  

  • 0 in reply to Don Dapkus
    Prodigy 170 points

    Hi Don,

    thank you for your reply. The fpga is also synchronized on the BCLK. So we could assert FSYNC on the falling edge of the BCLK to fullfill the timing requirement.

    Unfortunately the guys who made the hardware design seems to have little knowledge of what they are actually doing. We have several hundered boards in the field and need to fix the problem somehow.

    What happens if the FSYNC comes one clock too early or too late? Is it possible to give any prediction of what might happen, before we start to implement it this way?

    best regards


    Dani

  • 0 in reply to Dr. Haensse
    TI__Guru**** 189399 points

    Dani,

    Wow, it sounds like we're all in the same situation here.

    My best advice to you is play around with a few parts and see what you can determine.

    I wish I could give you a better answer, but I can't.

    -d2