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

I planned to construct this with 3 Shift registers per cannel and some XOR and NOR gates.
 

Attachments

  • FIFO I2S to AD1862.gif
    FIFO I2S to AD1862.gif
    177.3 KB · Views: 1,018
I attched the possible timing waveform (take AD1865 for example). Please let me know if there is any problem.
To have the correct sample for the L and R you should shift everything as in I2StoAD1865converting.jpg

I reviewed the timing diagram of PCM63, PCM1704 and AD1865 so I will refer only to these.

Until now I kinda misinterpreted the functionality of LE. It must be set high one (AD1865) or two clock cycles (PCM63/1704) before we want to latch data into the DAC, but it can be kept high for more cycles. For stopped clocked operation PCM63/1704 specify that: "Latch Enable must remain low until after the first clock cycle of the next data word to insure proper DAC operation" - see PCM63 timing.png

The stopped clock operation looks interesting and its probably beneficial, however AD186X doesn't specify this mode of operation at all, but I think it could work fine if we follow the correct timings.
Some thoughts about timings:
- DAC output changes state for PCM63 and AD1865 when LE goes negative, while for PCM1704 two clock cycles after LE goes negative
# With a switch we could select the stopped clock format - basically to have two clock cycles after LE or not
- The minimum width of LE high differs among these
# A good compromise could be to set LE high two/three clock cycles before it should go low
- For the above DACs the converter should support bit depths of: 18, 20, 24 - I suggest to support 16 as well

Cheers,
Zsolt
 

Attachments

  • PCM63 timing.png
    PCM63 timing.png
    32 KB · Views: 938
  • I2StoAD1865converting.jpg
    I2StoAD1865converting.jpg
    120.6 KB · Views: 919
Last edited:
[...]Until now I kinda misinterpreted the functionality of LE. It must be set high one (AD1865) or two clock cycles (PCM63/1704) before we want to latch data into the DAC[...]
Hi Zsolt

Strange that with AD1865. With AD 1862, there are no requirements of LE relative to the BCK cycles, only timing requirements:
- LE must go high at least 40ns before LE going low again
- last bit (LSB) must have been clocked in at least 60ns before LE going low
- next word (msb) has to be clocked in earliest 15ns after LE going low
- LE must at least stay low for 40ns

As i understand the function of this DAC, there is a shift register which works with BCK and DATA. As soon as all bits are loaded, you have to stop the clock OR go low with LE immediately (IE left justified data).
LE is just there to start the convesrion of all bits. Therefore the above timing requirements makes completely sense.

Edit:
Here you may see that for AD1856, the left channel bit clock is already stopped before loading the data.
 
Last edited:
Strange that with AD1865. With AD 1862, there are no requirements of LE relative to the BCK cycles, only timing requirements:
- LE must go high at least 40ns before LE going low again
- last bit (LSB) must have been clocked in at least 60ns before LE going low
- next word (msb) has to be clocked in earliest 15ns after LE going low
- LE must at least stay low for 40ns

As i understand the function of this DAC, there is a shift register which works with BCK and DATA. As soon as all bits are loaded, you have to stop the clock OR go low with LE immediately (IE left justified data).
LE is just there to start the convesrion of all bits. Therefore the above timing requirements makes completely sense.
You are right that neither AD1862 nor AD1865 has requirements of LE relative to BCK cycles and I admit that extrapolating the required LE timing to clock cycles is confusing and error prone.
After all I think the timing I proposed is still valid for AD1865, PCM63 and PCM1704.

Zsolt
 
Of course i meant:
Here you may see that for AD1856, the left channel bit clock is already stopped before LE going high.

Sorry for the confusion.
I still think there is a confusion in the middle. On figure 2b. I see the "classic" left justified data format where bit clock (CLK) is continuously running thus LE (Latch) should go down together with the LSB data (DATA).
 
Hey Ian, I think it should be noted, given that we are mostly terminal tweeters in this thread, that the u.fl cables and sockets (mostly cables I think) are only useful for a limited number of connections/disconnections and less if you dont use a suitable tool for that. perhaps I could make the suggestion for an instruction in the manual for users to use the ribbon/molex type connectors and cables that are in parallel for the testing phase and only use the u.fl once layout and testing is complete?
 
Hey Ian, I think it should be noted, given that we are mostly terminal tweeters in this thread, that the u.fl cables and sockets (mostly cables I think) are only useful for a limited number of connections/disconnections and less if you dont use a suitable tool for that. perhaps I could make the suggestion for an instruction in the manual for users to use the ribbon/molex type connectors and cables that are in parallel for the testing phase and only use the u.fl once layout and testing is complete?

That's good suggestion. I'll keep in mind in case I update the doc :).
 
cool, yeah ive never been faced with the destruction of one other than ones ive used on prototypes for shielded power connections, but it just occurred to me, since i'm doing more connect/disconnect cycles now that I have more devices using them.

For now i've gone back to using the molex connectors until ive reached a semi permanent layout. they are more robust than the manufacturer claims, but still best to avoid needless cycles and definitely the usefulness of the tool or a diy equivalent is a must.

even something as simple as levering it up with a small blade from right next to the socket while pushing down on the strain relief so it pops straight up rather than rolling over, if you know what I mean. an actual tool or equivalent is preferred though of course
 
Yes, it's possible. Seems I need cover 24bit.

Yes please -I think your FIFO right justified 24bit output plan will be widely appreciated.

There are many PCM1704 based DAC's around, so a 24bit right justified low jitter feed will be popular for modding legacy machines, currently limited by SPDIF interfaces and pre-ringing hardware filters like the DF1704.

I wonder how high a sampling rate you can design for?

The PCM1704 data sheet states "supports 8X oversampling at 96kHz" = 768kHz.

If you can manage higher sample rates it will allow computer based audio users to use a variety of oversampling software filters. This could allow for a simple mod to make a huge improvement in the sound quality of PCM1704 DAC's.

If you can add USB input it would be perfect for me?

Thanks for your amazing work so far.
 
I2S to AD18XX/PCM63/PCM1704 convertor

Taking into account zinsula's suggestions of delaying LE the stopped clock timings could be could be smtg like that:

For PCM1702, Datasheet states the following:


So I believe it needs 4 clocks.

There are so many different requirements, it's kinda difficult to have all OK for all DAC's.

24 bit AND working with the 1704/02 would be nice... Could somone build it, please...

Make sense. I suspect, inside AD18xx, there are just two shift registers and two latching registers, PCM63, maybe. But for PCM17xx, they need a couple of addition clks for some different constructions.

It seems we should:
1. Supporting 16bit, 18bit, 20bit and 24bit format with selectable setting jumpers.
2. Including a clock function jumper to enable or disable the 4 clks after negative edge of latching,in order to be compatible with pcm17xx.
3. For AD18XX, do not compromize with PCM17xx. Delay the latching and stop the clock after shifting.

I attatched the updated timing plots, taking example for both AD1865 and PCM17xx. Let me know for any problem.

*please don't care about the LL,LR signals at the next word, I forgot changing them on the plots.

Nice weekend.
 

Attachments

  • I2StoAD1865DelayLatch.jpg
    I2StoAD1865DelayLatch.jpg
    95.1 KB · Views: 862
  • I2StoPCM1704Conversion.jpg
    I2StoPCM1704Conversion.jpg
    98.4 KB · Views: 853
Last edited:
Yes please -I think your FIFO right justified 24bit output plan will be widely appreciated.

There are many PCM1704 based DAC's around, so a 24bit right justified low jitter feed will be popular for modding legacy machines, currently limited by SPDIF interfaces and pre-ringing hardware filters like the DF1704.

I wonder how high a sampling rate you can design for?

The PCM1704 data sheet states "supports 8X oversampling at 96kHz" = 768kHz.

If you can manage higher sample rates it will allow computer based audio users to use a variety of oversampling software filters. This could allow for a simple mod to make a huge improvement in the sound quality of PCM1704 DAC's.

If you can add USB input it would be perfect for me?

Thanks for your amazing work so far.

Thanks kazap,

Simultion shows the MCLK of my FIFO could go upto 125Mhz. I did a real loop testing with a 100Mhz MCLK a couple of weeks ago. Within 2 hours, I didn't catch any error. MCLK was 256Fs and Fs was 390.625Khz. So, if with 128Fs MCLK, theoretically it could go up to 768Khz, but I don't have anything to test so far. Do you know which USB could go up to 768Khz?

Have a good night.