Asynchronous I2S FIFO project, an ultimate weapon to fight the jitter

[goldkenn]

Originally Posted by simmconn

In the DIY community, the development effort is usually not amortized into individual units, which makes the part cost the primary concern. Having a low total part cost would just benefit everyone, right?

My answer will be yes and no, yes because you are right, no because in lan's design, I think the clock section cost should be more critical and much expensive then SRAM.

[regal]

Originally Posted by goldkenn

My answer will be yes and no, yes because you are right, no because in lan's design, I think the clock section cost should be more critical and much expensive then SRAM.

But again feeding this CPLD/FPGA a high quality clock really won't improve thiings a lot. These chips have intrinsic jitter that you can't get away from and low jitter clock will be swamped. Use a high quality clock to feed the FPGA and also so you can reclock its I2S output, then your jitter levels will be near equal the clock, probably the lowest jitter device I have seen directly prior to the DAC chip, but again only if reclocked to remove the intrinsic jitter.

[simmconn]

Originally Posted by regal

No we have your FIFO, feeding your chip a high quality clock, great now we have jitter equal to intrisic jitter of the FIFO chip + clock jitter. Now I'll bet a few dollars the chip used here has more intrinsic jitter than a 9001 which was specifically layed out for digital audio. So I guess what I am saying is if your transport is very good, your FIFO will probably add overall jitter.

Solution is easy, simply reclock the output with the same crystal, this will eliminate the FIFO's potentially high intrinsic jitter. This technique has been used for years dealing with CD decoders, it works and should be considered here.

If you look closely at the picture, the local master clock doe not 'pass' the FIFO chip. It is feeding both the FIFO chip and the DAC chip at the same time. Unless your DAC chip is sensitive to jitter on signals other than the master clock (i.e. BCLK, LRCK, DATA), it would not be necessary to reclock them. Even if we choose to reclock the signals, the output registers at the pad of the FIFO chip does not necessarily perform worse than an LVCMOS logic chip, which means reclocking internally would be good enough. Price is not a reliable indication of the performance of a chip.

[guido]

Originally Posted by iancanada

Very good question, Guido. I'm afraid if the FIFO is empty, it will sound like repeating a word(around 1s for 44.K), and when it full, it will sound like short a word(around 1s for 44.K). Meanwhile, no pause,silence and other noise. Just imagine if you have a cassette, cut 1secnd length or extend it with 1 second copy, would be the same thing as FIFO full and empty.
When you play the continue live concerts, this will happen every couple of hours if the sampling clock is not that bad(with 100ppm frequency tolerance).

PLL is another solution. According to my quite limited knowledge on this issue, the key thing should the bandwidth. If you reduce that bandwidth to a certain level, you might still need a FIFO to buffer the data, but may not that big ...
Maybe I'm wrong or you have some good idea..anyway, good luck to your project. Have a good night. Ian

Sounds the same as what happens when you put an 8416 in slave mode; it skips or doubles samples (at a higher rate). So when you run full/empty, you "reset" to the other opposite; emtying or filling the memory (get the max time between the occurences)? But the frequency of such event would all depend on the sampling rate i guess.

PLL.. My knowledge is also limited :-) But i had some help on the way. You do need a FIFO, but with depth of one. So the one in the 8416 is good enough. Getting a good masterclock out of a VCXO is the challenge here.
Need to pick it up again.

I did use a small async fifo once to decouple some clock domains. But that was with one clock distributed into a cd player. With easy control; start the readout at half-full.

I have a timing analyser to do some basic jitter measurements. But it's an old beast. Let's say i see the difference between a good and a bad clock :-)

[iancanada]

Originally Posted by guido

I have a timing analyser to do some basic jitter measurements. But it's an old beast. Let's say i see the difference between a good and a bad clock :-)

Very cool, Guido. What type is that 'old beast'? Did you find any really nice clock?
BTW. I like your logo. Me too a swing arm laser pickup fan. :-)) Ian.

[guido]

Kode Odetics 3100



Very old PC AT or XT with hercules card/monitor and specific hardware...

I did compared some spdif sources at the output of a receiver (picture), compared a decent clock with the 7220 output etc. I'm using tent clocks mainly, but that is more the good availability for me. With it's resolution it is really comparing good clock/bad clock.

As for pll development, you can set it on a reduced number of counts (10000 or so) and on repeat. Then you can see the clock dancing on the noise getting into the VCXO (need to make a pcb before i can continue with the software).

[iancanada]

Originally Posted by guido

Kode Odetics 3100.

Amazing, Guido. It's old but it's working! What is the principle of this Kode 3100? It measure the jitter from frequency domain or from time domain? It seems it's measuring the RMS period jitter, right? What is the minimal resolution of it in ps? What is the background noise or tolorance? I'm still trying to find out the car price toy with jitter measurement package from universities or labs around GTA area for my project. Very impressed. Nice weekend. Ian

[guido]

The beast with more old boatanchors.



Errr. I just compare I wouldn't dare read numbers; this thing missed calibration for a long time. Resolution is 0.1 nSec.

It shows counts; it has 4000 memory locations. from the input you start a counter on a rising edge and you stop on the next rising edge. Threshold can be set (values match for 1:10 probe). So when it's stopped you have a counter value, say 3345. Now you take memory location 3345, get the value, add one and store back in memory. Then do this a lot of times 10^8 or so. In the end you have a value in memory location 3345, but also in 3444, 3446 etc. This is plotted on the screen as a histogram. horizontal the 4000 memory locations (optionally a 2 or 5 zoom). Vertical is the number of occurences, logarithmic scale. So i would say, it measures from the time domain.

You can calculate an average, stable or exponential. You get a number in seconds as standard deviation from the main time.

To increase resolution, you can set a delay between the start edge and the start of the counter. So you can "zoom in".

Also you can measure more than a clock. E.g. the output of a bitstream dac has 6 different time intervals iirc. You can segment the output into sections and then do the maths over all sections.

Think it was expensive in the days, but i got it for about a 100 usd. Danger is if something breaks, i won't be able to fix as it's a lot of ttl inside and no service manual. And the monitor part is not reliable. But modern ones are quite expensive.

Note in the first picture, the clock with the widest jitterspectrum actually has the lower standard deviation. I don't know which one would be better....

But please, back to your work. It's more interesting.
If you want me to do some measurements, please send a spare board

[iancanada]

Originally Posted by simmconn

For the most 'fun-factor', a FIFO board would be BYOC (bring your own clock).
Using an SMA tee connector on the clock line seems to indicate that you are not an RF engineer. Me either. I learned a lot from the folks at diyhifi, but still too little to tackle the clock issues.

Hi Simmconn, You are very smart guy; it seems you know all the gear. Thanks. Yes, you are right; I noticed the SMA tee problem. For the 8” cable, the first reflection comes back just at the moment of the middle of the raising edge of the MCLK (1.73ns later, the signal velocity in that 50ohm cable is around 0.77C), and so on the second, the third… Those reflections may tribute more jitter to the MCLK. To avoid this, on the clock boards I am doing right now I have standalone path to feed the clock to the FIFO, and the MCLK will output to the DAC directly from the clock board point to point without any branch via the coaxial cable after the impedance match.

I hope I was a RF engineer from a telecommunication company. So that, I could design the magic clock oscillator together with deep theories and equations posting on the thread to make everybody believe in J. But, unfortunately I am just an average person and don’t have the ability to make that ‘magic’. So, in this FIFO project, I would keep the clock oscillator as an open concept. That means the clock will be replaceable and upgradeable. No matter what kind of clock I have, I could make use of it for my FIFO. Just as you side: “a FIFO board would be BYOC (bring your own clock)”. And I would like to add a word: bring more fun!

According to my limited understanding on the jitter principle, working together with a DAC, the clock just behaves like a filter. Two clocks even they have the similar jitter level, they may sound different because of the difference on the jitter spectrum and characteristics. Things are quite similar to the vacuum tubes. Two ECC83 tubes, for example, one from Telefunken another from Mullard, they may have very closed testing results from a tube tester, but for sure, they sound different.

Keep bringing the funJ. Have a nice weekend. Ian

[iancanada]

Originally Posted by regal

Consider the intrinsic jitter of any complex chip you are using. In this design say we have an incredible transport with documented 3ps jitter delivered to the DIR9001. After the DIR9001 we will have 53ps (+- based on the mckl per the datasheet), this intrinsic jitter is always added and has nothing to do with the corner frequency, above the corner frequency is where the 3ps from the transport will be passed (worst case).

No we have your FIFO, feeding your chip a high quality clock, great now we have jitter equal to intrisic jitter of the FIFO chip + clock jitter. Now I'll bet a few dollars the chip used here has more intrinsic jitter than a 9001 which was specifically layed out for digital audio. So I guess what I am saying is if your transport is very good, your FIFO will probably add overall jitter.

Solution is easy, simply reclock the output with the same crystal, this will eliminate the FIFO's potentially high intrinsic jitter. This technique has been used for years dealing with CD decoders, it works and should be considered here.

Hi Regal, I’m sorry for the delay of replying your post. I bet didn’t lose your dollars!

First, on the reclock issue, I agree with you. Because for those NOS DACs such as TAD1541, they don’t use MCLK for the internal timing, instead, they use SCK and WS driving the internal state machine. That means those NOS DACs are sensitive to the jitter on the signals other than the MCLK. In this case, reclock the I2S signal by the same master clock is a very good idea. And after doing that, the total jitter on the I2S signal=master clock jitter + additive jitter of the reclocking flip-flop. At is meaning, just as you said, the intrinsic jitter of FIFO was eliminated. But instead, the new flip-flop jitter is introduced.

On those clock boards I’m cooking right now for my FIFO project, the reclock circuits have already been included. The only thing is we need select the flip-flop with careful. Normally the flip-flops will also introduce quite a few amount of additive jitter. The best flip-flop is the PECL series, which the additive jitter is just around 1 ps level, unbelievable! The normal TTL or LVTTL flip-flop have the similar or little bit worse jitter level than the CPLD on the FIFO board. Some new generation flip-flops, such as AUP, AUC series, have better jitter performance. I’m not recommended using the S,AS,F series TTL IC doing the reclock job, not only because the speed is not as good as the new technologies, but also, the high switching current will introduce big ripple on the power supply which will increase the clock jitter rapidly.

On the FIFO issues, the FIFO isolates the two clock domain. For example, you have a FIFO and a reclock circuit between the DIR9001 and your DAC, the DIR9001 has 53ps jitter output on all signals, and the new low jitter clock has 10ps jitter, the reclock flip-flop has 20ps additive jitter. So, the result is: You get MCLK with 10ps jitter (MCLK output directly from clock board without passing the FIFO), and you get 30ps jitter on I2S signals other than MCLK after reclock. (All the jitter should be the RMS period jitter in the above example) .

The reclock topics are very interesting. If have chance, I would be very happy to discuss with you with details. Nice weekend. Ian