How to interpret polyphase coefficients generated in MATLAB

rickman wrote:
[...]

"Let the dumb lead the blind"

VLV

> The polyphase implementation will certainly reduce the hardware
> complexity. But polyphase length of 51 is still very demanding in terms of
> both power and area consumption. �
> You can read this document :http://www.altera.com/literature/hb/stx/ch_7_vol_2.pdf
> starting from page 17.
Thanks Alexander. Though I am designing this on Xilinx, this document
did help me in understanding that though the total number of taps is
higher, the polyphase design saves the no of multipliers on the FPGA.
The good thing here is that the polyphase design has a demultiplexer
built-in to do the necessary scramble for the polyphase filter.

Regards,
vizziee.

Thanks Rick for your response.

> filter, but if you are going to decimate by 20, don't you need a
> multiple of 20 coefficients? �Otherwise you can't distribute the taps
> between the phases.

I am zero-padding the filter in practice.

> The poly phase filter calculates the filter output in pieces so that
> for a 20x decimation the filter only does 5 multiplies and 4 adds for
> each input value, but still does 100 multiplies and 99 adds (counting
> the combining of the phases) for each output.

A polyphase decimator filter would perform fewer computations for each
output *per cycle*.

> number of coefficients. �I don't recall the requirement to make this
> true, but often the coefficients are symmetrical so that coef(0) = coef
> (n-1). �This can be true even if you have an odd number of taps, the
> middle coefficient is not used twice.

Symmetry of coefficients is related with Linear Phase FIR filters.
Symmetry is taken care within the usual Xilinx FIR Compiler. So I
don't see an issue with this.

Regards,

vizziee.

On Jul 6, 3:05&#4294967295;pm, Vladimir Vassilevsky <antispam_bo...@hotmail.com>
wrote:
> rickman wrote:
>
> [...]
>
> "Let the dumb lead the blind"
>
> VLV

"And let the deaf watch"

vizziee.

vizziee <vizziee@gmail.com> writes:
> [...]
> The signal bandwidth is 8 MHz 
> [...]
> the signal lies between -4MHz and 4MHz 

These two statements cannot both be true. If you're talking about a real
signal, then "bandwidth" is defined as the non-zero portion of the
positive frequency spectrum (not positive and negative). Thus the
signal as you've defined it in the latter statement would have a
4 MHz bandwidth, not an 8 MHz bandwidth. 
--
Randy Yates                      % "Maybe one day I'll feel her cold embrace,
Digital Signal Labs              %                    and kiss her interface, 
mailto://yates@ieee.org          %            til then, I'll leave her alone."
http://www.digitalsignallabs.com %        'Yours Truly, 2095', *Time*, ELO   

On Jul 6, 1:51&#4294967295;pm, vizziee <vizz...@gmail.com> wrote:
> > be ceil(1005/M1) = 50 and so I would have M1=20 such filters. Would
>
> A correction here: &#4294967295;ceil(1005/M1) = 51.
>
> Regards,
> vizziee.

Vizzie,

You should check out using multistage decimation if you want to
decimate by 20.  A halfband decimating filter, another halfband
decimating filter, then a decimate by 5 filter.  In the first two
stages, in order to cut down the number of taps, don't preserve (alias
free) any bandwidth you don't need.  Design the final filter as a
cleanup to remove aliasing from the 1st 2 filters and do bandlimiting
for the final decimation.  This is standard practice.

This is also NOT a detailed description of how to design these
filters.

Dirk Bell

On Jul 6, 8:26&#4294967295;pm, Dirk Bell <bellda2...@cox.net> wrote:
> On Jul 6, 1:51&#4294967295;pm, vizziee <vizz...@gmail.com> wrote:
>
> > > be ceil(1005/M1) = 50 and so I would have M1=20 such filters. Would
>
> > A correction here: &#4294967295;ceil(1005/M1) = 51.
>
> > Regards,
> > vizziee.
>
You could use a graychip directly instead of reimplementing that
functionality in a FPGA. The graychip functionality provides a CIC
filter  followed by 2 stages of decimation. The CIC provides a simple
but effective decimation mechanism  - the next filter also performs
decimation but it is also meant to compensate for the droop of the
passband in the CIC filter. To understand how to design the multistage
decimation filters I would recommend reading Crochiere and Rabiner's
(Multirate Signal Processing) - I'm not sure if I've got that
reference exactly right.

Cheers,
David

> Vizzie,
>
> You should check out using multistage decimation if you want to
> decimate by 20. &#4294967295;A halfband decimating filter, another halfband
> decimating filter, then a decimate by 5 filter. &#4294967295;In the first two
> stages, in order to cut down the number of taps, don't preserve (alias
> free) any bandwidth you don't need. &#4294967295;Design the final filter as a
> cleanup to remove aliasing from the 1st 2 filters and do bandlimiting
> for the final decimation. &#4294967295;This is standard practice.
>
> This is also NOT a detailed description of how to design these
> filters.
>
> Dirk Bell

> You should check out using multistage decimation if you want to
> decimate by 20. �A halfband decimating filter, another halfband
> decimating filter, then a decimate by 5 filter. �In the first two
> stages, in order to cut down the number of taps, don't preserve (alias
> free) any bandwidth you don't need. �Design the final filter as a
> cleanup to remove aliasing from the 1st 2 filters and do bandlimiting
> for the final decimation. �This is standard practice.
>
> Dirk Bell

Thanks Dirk. I tried this design and the number of taps vis-a-vis
number of polyphase filters got reduced by 4 (discounting the number
of taps in Half-band filters). This is a great savings as. earlier.
for the same roll-off I had 200taps for some 20 filters in the
polyphase structure.

However, my calculations for the processing delay don't match up with
my results in the MATLAB:
No of taps in the first (Direct Form Polyphase) Half-band filter = N1
= 22
Processing delay at the output of first Half-band filter = D1 = ceil
(((N1/2) - 1)/2) = 5
No of taps in the first (Direct Form Polyphase) Half-band filter = N2
= 22
Processing delay at the output of first Half-band filter = D2 =ceil
( ((N2/2) - 1)/2) = 5
No of taps in the first (Direct Form Polyphase) Decimate-by-5 filter =
N3 = 1010
Processing delay in Polyphase (decimate by 5) filter = D3 = ceil
(((N3/5) - 1)/2) = 101

Total delay = sum(D1, D2, D3) = 5+5+101 = 111 samples

However my output only shows a delay of 102 samples after the last
filter stage.


Regards,

vizziee.

> functionality in a FPGA. The graychip functionality provides a CIC
> filter �followed by 2 stages of decimation. The CIC provides a simple
> but effective decimation mechanism �- the next filter also performs
> decimation but it is also meant to compensate for the droop of the
> passband in the CIC filter. To understand how to design the multistage
> decimation filters I would recommend reading Crochiere and Rabiner's
> (Multirate Signal Processing) - I'm not sure if I've got that
> reference exactly right.

Thanks David. But as I wrote before, I am not satisfied with the
response of CIC-Compensator-HalfBand filter. One of the primary
reasons for this is I have three frequency channels to filter and the
response of CIC-et.al. filter allows some leakage of the adjacent
channels to the output. This is not a problem with the polyphase LPF
implementation.

Regards,

vizziee.

On Jul 7, 2:49&#4294967295;pm, vizziee <vizz...@gmail.com> wrote:
> > You should check out using multistage decimation if you want to
> > decimate by 20. &#4294967295;A halfband decimating filter, another halfband
> > decimating filter, then a decimate by 5 filter. &#4294967295;In the first two
> > stages, in order to cut down the number of taps, don't preserve (alias
> > free) any bandwidth you don't need. &#4294967295;Design the final filter as a
> > cleanup to remove aliasing from the 1st 2 filters and do bandlimiting
> > for the final decimation. &#4294967295;This is standard practice.
>
> > Dirk Bell
>
> Thanks Dirk. I tried this design and the number of taps vis-a-vis
> number of polyphase filters got reduced by 4 (discounting the number
> of taps in Half-band filters). This is a great savings as. earlier.
> for the same roll-off I had 200taps for some 20 filters in the
> polyphase structure.
>
> However, my calculations for the processing delay don't match up with
> my results in the MATLAB:
> No of taps in the first (Direct Form Polyphase) Half-band filter = N1
> = 22
> Processing delay at the output of first Half-band filter = D1 = ceil
> (((N1/2) - 1)/2) = 5
> No of taps in the first (Direct Form Polyphase) Half-band filter = N2
> = 22
> Processing delay at the output of first Half-band filter = D2 =ceil
> ( ((N2/2) - 1)/2) = 5
> No of taps in the first (Direct Form Polyphase) Decimate-by-5 filter =
> N3 = 1010
> Processing delay in Polyphase (decimate by 5) filter = D3 = ceil
> (((N3/5) - 1)/2) = 101
>
> Total delay = sum(D1, D2, D3) = 5+5+101 = 111 samples
>
> However my output only shows a delay of 102 samples after the last
> filter stage.
>
> Regards,
>
> vizziee.

Vizzee,

Check your equations.  I get

( ( (22-1)/2 )/20 + ( (22-1)/2 )/10 + ( (1010-1)/2 )/5 ) = 102.4750
which is consistant with what you are actually getting, not what you
are calculating.

Also note that the filters you are identifying as half-band filters
are not actually half-band filters.  Half-band filters have the
property that almost half of the coefficients are zero, saving
calculations, which may be useful to you. But, among other properties,
the lengths of halfband filters are constrained to {3, 7, 11, 15, 19,
23, 27, ..., previous+4, ...}, so a filter of length 22 isn't a half-
band filter.

Dirk Bell