ADAU1467 -FIR filters maximum taps
I am interested in the ADAU1467 DSP. The datasheet indicates that the DSP is able to handle “24,000 FIR filter taps per sample at the standard 48 kHz audio sampling rate”.
I am unsure what this exactly mean. Could you please explain this in more detail?
I am planning to use the DSP in a 4 channel in and 8 channel out configuration. Does this mean that per output channel I can only use 1.750 taps (24.000 divided by 8) per cycle or can the DSP handle 24.000 taps per channel per cycle (therefore 192.000 taps in total)?
Furthermore, do you have an estimate how much delay is introduced when using the maximum number of taps?
Thank you very much for explaining.
Audio Signal Processors
adau1467
taps
SigmaDSP Audio Processors
fir
I must say I am quite suprised how potential costumers are handled by ADI. When reaching out for information on ADI's products you are "redirected" to this "EngineerZone", however neither a support nor a sales staff of ADI seems to be willing to answer a potential costumers question leaving potential costumers in the dark.
Hello Mareus,
Sorry, we have been rather overwhelmed in recent months.
Here is what is in the datasheet, I will go on to add more info...
The core consists of four multipliers and two accumulators.
At an operating frequency of 294.912 MHz, the core performs 1.2 billion MAC operations per second. At maximum efficiency,
the core processes 3072 IIR biquad filters (single or double
precision) per sample at a sample rate of 48 kHz. At maximum efficiency, the core processes approximately 24,000 FIR filter
taps per sample at a sample rate of 48 kHz
When the part is setup for a system clock speed of 294.912MHz, which is the normal core frequency for the 48kHZ base fs. This is the instruction clock. It will perform this many instructions in a second.
So with a 48kHz sampling rate, 294.912MHz / 48k = 6,144 instructions per sample period.
The quad MAC core can do four multiplications in one instruction cycle. So that means it can execute four taps per instruction. That would be 6,144 x 4 = 24,576 multiplies per sample.
So the datasheet says approximately 24,000 FIR filter taps because there will always be some other instructions to do other things other than a filter. It is unlikely that any application would ever be able to get to 24,000 taps because an application usually ends up doing a lot of other things and also the program cannot always end up using all four multiplies in one cycle. If you have a filter grown to four channels then it will use the quad MAC to its greatest efficiency. If you grow it to three channels or to five channels then it will not be as efficient. So you have to setup the SigmaStudio program with this in mind and you cannot always set it up to be the most efficient. For single channels it usually is able to make it efficient but it is wise to have the filter taps be divisible by four.
Regarding the delay. I think I understand your question,... All the filter taps are calculated every sample period but it does take time for the sample to progress through the filter. So if it is a 256 tap filter it will take 256 samples for the first sample get through the filter.
I just did a quick experiment using SigmaStudio and looking at the compiler output window.
I added a general FIR filter into a project and looked at the instruction cycles used.
256 tap filter uses 71 cycles per sample period. 256/4 = 64 then the other seven samples will be used for the bypass and gain features of the General FIR Filter block. So the filter is calculated in 64 samples.
If I change the filter to 200 taps. I get 57 samples. So again, the compiler is able to use the Quad MAC to do the 200 tap filter in 50 cycles.
If I change it to 201 samples it still uses 57 instructions. 202 = 57, 203 = 57, 204 = 58 instructions. So it looks like if the number of taps is exactly divisible by four will have one sample period that has only one multiply.
If I go to 199 taps it uses 56 instructions. So it looks like the absolute most efficient is to have the number of taps be divisible by four and then subtract one tap. This should give you an idea of how the compiler tries to use the core in the most efficient way.
Dave T
.
Please log in to reply.