Separate audio for clock: why?
jotego opened this issue · comments
I have found today that a new PLL and a new clock signal was defined for audio. This makes no sense. What you care about is the sampling rate of the signals, not the actual clock. You can use whatever clock you want as long as your sampling period is uniform.
With this extra PLL you are consuming resources and now you have another clock tree to balance in the design. Compilation time goes up too. How about the synchronizer flip flops needed to convert from the emu clock domain to the audio clock? Did you see all the timing violations that the new clock brings up?
What you need is not a different clock. What you need is each core to provide a sample strobe to tell you when there is a new sample.
I propose to remove the clock signal. If you want to let the users play with cheap IIR filters you can do it with a clock enable signal to serve as your sample period.
Audio clock has specific rate to make i2s and spdif work without jitter. It's impossible to use the same PLL for HDMI and audio as HDMI has variable clock. It also fixes the audio for some TVs. So this fixed clock is necessary. Core is not required to use this clock for audio as framework has proper clock domain crossing. But if core will use it, then it may supply a samples without aliasing (where it is possible) which will be good for clean audio.
There is no timing violations because of new clock.
FPGA has 6 PLLs. 2 of which are used by framework which is fine. Still 4 left for core.
I see. The variable HDMI clock does complicate things. In any case, consider adding a sample output signal to the emu module so it can be used in upsampling filters to get clean 96kHz audio.
24.576MHz (CLK_AUDIO) clock is a clean clock for 96KHz audio. So simple division by 256 of this clock gives exact 96KHz sample rate. So, it's there already. If core wants to provide a high fidelity audio, then it has to use CLK_AUDIO for audio part of core.