CS8412 + filterless Non-OS dual AD1865

[CraigBuckingham]

Hey Cathode,

.........Look at the datasheet. SCLK is MCLK divided by four. MCLK is the output of the VCO, which is spec’ed at 200 psRMS jitter. But that’s not the whole story. Look at the spec for Tsfdm (on page 4). It says SCLK has +/- 20ns jitter with respect to FSYNC. The question is: Which clock, FSYNC or SCLK, is more accurate and which clock are you going to trust to strobe your DAC chips?.............

20ns for tsfdmis is not a jitter specification. It is a timing margin specification. What this means is the FSYNC transition is +/- 20 ns maximum with respect to the -ve going transition of SCK. That is the design specification limits.

FSYNC will have slightly more jitter than the MCK output since it will be a divided down MCK.

 

[cathode_leak]

Of course, if you don’t trust the CDP to get the timing of the preambles right, you should put the oscillator of your choice in the DAC, slave the CDP to it and run the CS8412 in mode 1. That way the master clock without PLLs or reclocking voodoo generates every clock edge.

I'm not trying to make everything as complicated as possible, I'd actually prefer to do this as simple as possible (exept the SPDIF input ) but with a good result... I would very much like to get away with a sync cable running the CD-player from the DAC clock, instead of this VCXO methods... But I'd like my DAC to work with different transports too, I could, I suppose, make a master clock arrangement where I can "hardswitch" between two XOs one 11.2986MHz and one 33.8688MHz. This will let me sync players operating at 11.2986MHz, 16.9344MHz, and 33.8688MHz, wich covers probably 99% of available CDPs..

But say I sync a CDP with a 11.2896MHz clock freq with my master DAC clock running at the same frequency, and internally in my DAC divide the master clock (4040 bin counter) to match SCK frequency.. the frequencies from the CS8412 SCK output and from my divider will then be an exact match, right? (cause they are referenced by the same clock) but how will the phase compare between the clocks? will they be in phase, inverted, or something in-between...?

 

[Ulas]

This is why I rarely post in this forum: It is populated by people who can’t read and can’t think.

Hey Craig, I quoted directly from the CS8412 datasheet. FSYNC is derived from the timing of the subframe preambles it is not divided from MCLK. Think about it for a moment. If FSYNC were a divided from MCLK it wouldn’t have a +/- 20ns variance with SCLK, which is divided from MCLK.

Good binary counters don’t introduce +/- 20ns variances between stages and intelligent digital circuit designers only use good binary counters, right? That’s why intelligent designers don’t use the ‘4040. I know the ‘4040 is the most popular binary counter here and everybody uses it. Why? Because everybody uses it and the newbies would rather copy an existing schematic, even if it is wrong, than try to read a datasheet. The only thing a ‘4040 is good for is turning LEDs on and off to demonstrate the binary counting sequence for a high school science project.

Hey Cathode, phase doesn’t matter, RTFM and think. That’s all I have to say.

 

[gmarsh]

But say I sync a CDP with a 11.2896MHz clock freq with my master DAC clock running at the same frequency, and internally in my DAC divide the master clock (4040 bin counter) to match SCK frequency.. the frequencies from the CS8412 SCK output and from my divider will then be an exact match, right? (cause they are referenced by the same clock) but how will the phase compare between the clocks? will they be in phase, inverted, or something in-between...? [/B]

The phase will be ambiguous. If you cycle power on your DAC, you'll get a different phase.

 

[cathode_leak]

Hey Cathode, phase doesn’t matter, RTFM and think. That’s all I have to say.

OK.. so say I operate my DAC from a 11.2896MHz XO, synced to the player... I divide the clock by 8 to get a 1.4112MHz SCK for reclocking.. Will I be safe off throwing the CS8412 SCK out (it'll be the same clock only different phase, wich apparently doesn't matter) and feeding my clean 1.4112MHz SCK to the DAC as well as using it to reclock FSYNC and DATA lines?

And can I possibly throw out the CS8412 FSYNC too, and feed the DAC with my own 11.2896MHz/2^8=44.1KHz clock, so that the only signal going from reciever to DAC is the SDATA, wich will be reclocked by my clean 1.4112MHz??

Probably not..?

 

[cathode_leak]

I have attached a circuit divided by a horizontal line... what's below this line is the DAC circuit, intended to be used with an external VCXO board.. The "NPLLL" input is set high by the VCXO PLL when unlocked, the "SCK_SYNC" output is the SCK from the 8412 wich the VCXO will lock to, and the n_SCK input is the new 1.4112MHz SCK generated by the VCXO...

Now, what's above the line is simply a clock and a divider. If syncronized to the CDP, this clock will, as a VCXO would, deliver a syncronized frequency, however as I understand, with phase differences... Would it be possible to implement such an "alternate clock" allowing me to use either a VCXO addon board or a syncronized XO addon board?

 

[cathode_leak]

....make sure that whenever RECLOCK goes high, the SCK/FSYNC/DATA lines are *not* transitioning....

Any idea how I can make sure of this when (if) using a CDP synced clock setup?

two flipflops in series triggered by nSCK and /nSCK?

And if I did so, the introduced delay would be increased from half a cycle to one cycle, so I'd remove the inverter I've put between nSCK and DAC's CLK? (well not remove it, but use it's output to drive the second stage of flipflops while leaving DACs CLK input uninverted)

 

[gmarsh]

Any idea how I can make sure of this when (if) using a CDP synced clock setup?

two flipflops in series triggered by nSCK and /nSCK?

And if I did so, the introduced delay would be increased from half a cycle to one cycle, so I'd remove the inverter I've put between nSCK and DAC's CLK? (well not remove it, but use it's output to drive the second stage of flipflops while leaving DACs CLK input uninverted)

Get a pad of graph paper, a few pencils and an eraser, and start drawing some timing diagrams. You'll figure it out.

I make a point of doing this with every bus interface, serial interface, clock domain handoff inside a FPGA, etc... which I design.

 

[cathode_leak]

Get a pad of graph paper, a few pencils and an eraser, and start drawing some timing diagrams. You'll figure it out.

I make a point of doing this with every bus interface, serial interface, clock domain handoff inside a FPGA, etc... which I design.

I'll get into those timing diagrams... Rest of the week I'll be kept busy with studies though, the winter holydays is coming to an end this weekend and I'm behind scedule

But I have really no way of knowing the timing of the CS8412 I2S output signals without a PLL-like circuit (phase detector), do I? 8412 locks on the frequency obtained from the SPDIF, wich again is timed from the CDP, synced to my master clock, and the 8412 SCK phase will thus vary with different transports depending on their internal circuitry..? But as I understand it, phase is not important as long as my new nSCK do not hit these I2S transition periods, so maybe I should add a PLL in the XO circuit (comparing SCK_SYNC and nSCK) with no other purpose than driving an indicator LED, and so I add a hex inverter with hard-switchable bypass on the nSCK? I would only be able to introduce a 180deg phase shift with this switch, but it might be sufficient to avoid I2S transition periods? Any better ideas?

I cannot think of any good methods for introducing phase shifts <180deg..?

 

[CraigBuckingham]

This is why I rarely post in this forum: It is populated by people who can’t read and can’t think.

Hey Craig, I quoted directly from the CS8412 datasheet. FSYNC is derived from the timing of the subframe preambles it is not divided from MCLK. Think about it for a moment. If FSYNC were a divided from MCLK it wouldn’t have a +/- 20ns variance with SCLK, which is divided from MCLK.

Good binary counters don’t introduce +/- 20ns variances between stages and intelligent digital circuit designers only use good binary counters, right? That’s why intelligent designers don’t use the ‘4040. I know the ‘4040 is the most popular binary counter here and everybody uses it. Why? Because everybody uses it and the newbies would rather copy an existing schematic, even if it is wrong, than try to read a datasheet. The only thing a ‘4040 is good for is turning LEDs on and off to demonstrate the binary counting sequence for a high school science project.

Hey Cathode, phase doesn’t matter, RTFM and think. That’s all I have to say.

Ulas,

I have received word form Cirrus Logic, the manufacturers of the CS841X rx chips.

FSYNC & SCK are derived from the MCK signal. They are synchronously divided and therfore they have virtually the same jitter spec as the MCK signal.

So FYSNC timing spec is a design constraint and not a jitter spec.

Cheers, Craig.

 

[rfbrw]

<snip>

FSYNC & SCK are derived from the MCK signal. They are synchronously divided and therfore they have virtually the same jitter spec as the MCK signal.

<snip>

Not quite so, if the datasheet is to be believed. FSYNC as a divided version of MCK is only an option on the CS8411, the other option being to derive FSYNC directly from the incoming datastream.
The CS8412 always derives FSYNC from the incoming datastream.

 

[CraigBuckingham]

Not quite so, if the datasheet is to be believed. FSYNC as a divided version of MCK is only an option on the CS8411, the other option being to derive FSYNC directly from the incoming datastream.
The CS8412 always derives FSYNC from the incoming datastream.

It would not be the first time I have received incorrect information from the applications engineers from the major semiconductor manufacturers.

I re-read the datasheet and would have to agree.

CS8411 can be programmed to derive FSYNC from MCK. CS8412 always generates FSYNC from the incoming data stream.

Thanks Ulas, rfbrw.