Multiple ADAU1772's and MCLK
You liked running the ADAU1772 as a slave off the APx55 MCLK. I actually saw worse S/N doing that, but anyway, what if I have multiple 1772's all driven off a MCLK sent by an FPGA. Is this better than running each 1772 with its own oscillator? I2S data will be shared by this fpga/1772 network. I don't have experience with this but don't like the idea of MCLK traversing across perhaps two boards, through connectors, etc.to accomplish this.
Also please review my other issue with what looks like the ADC data before the DSP block is dead (low or no level). Maybe a secret register to awaken them?
hardware
adau1772
Integrated/Special Purpose A/D Converters
Audio CODECs
Hello bklein,
This part has a really great feature in that it had ASRCs on the serial input and output. So the ADCs and DACs and the Core can run using its own master clock and you do not have to run master clock to all the parts. What I suggest is to operate the serial ports as clock slaves and send the serial port clocks from the FPGA to all the ADAU1772 parts. Then the serial ports will just match the sampling rate of the FPGA. Then you can change the sampling rate of the FPGA any time you want with no need to change anything on the ADAU1772 parts. The ASRCs will just follow the clocks from the FPGA. You may need to use a clock buffer if you have a lot of 1772s and the clocks have to go a long way and onto other boards. So but a clock buffer at the input of each board so there will be minimal reflections from long lines and connectors.
Dave T
We still need MCLK though to configure the codecs on power up though, correct? The assumption was we could eliminate the oscillator if we had an external MCLK connected.
Hello bklien,
No, you misunderstood what I meant. Each ADAU1772 will have its own crystal as an MCLK source. So no need to send it an external MCLK, each one would have its own source nearby. A crystal or small clock-osc module.
I explained why you do not need all of the parts to operate on the same master clock. Just have each one on its own clock domain and then if you are using the serial ports then operate the serial ports as clock slaves and they will follow what is being sent to them. No need for everything to be on the same master clock.
Dave T
(rewriting this again...)
So if I have two 1772's on one board, possibilities:
1) FPGA sends master clock 12.288 MHz to both chips, pin 39. No xtal or osc. on either chip.
2) Each has xtal or osc. and no master clock is received from the FPGA.
3) One chip either receives master clock from FPGA or its xtal or osc., then it sends it out via pin 35 to second chip pin 39. Second chip doesn't need the xtal/osc.
Other than parts count, what would be the benefits or detriments to each option?
Hello bklein,
Any of the three options would work, you are correct.
The output if an FPGA usually has a bit more jitter than a crystal and depending on how it is dividing down its clock to get this clock output it might have a lot of jitter.
The PLL in the 1772 will help remove the jitter but I do not have great numbers to show you how much jitter would be too much. It will depend on the details of the jitter of course.
The best would be for each to have its own crystal but the third option is almost the same. The CLKOUT pin is the output of the PLL so it will be clean but then it has to travel to the other part and so it can pick up some noise along the way.
The best option depends on your application. If it needs to be super high quality audio then I would probably go for option 2. Chances are I am guessing that you need good audio but not studio quality or high end audio quality. A long as the FPGA is sending out a decent clock that would be fine. The thing to check is it is dividing down the clock such that every X amount of frames it needs to have a shorter or longer frame because it does not divide evenly, then that jitter might be too much. For that I would look at it carefully on a scope and try it. Then see how clean the CLKOUT or the Bit clock is coming out of the 1772. That would certainly be the lowest cost option.
Dave T
Please log in to reply.