• 0

# Fir compiler core as a decimation

## Question

I am trying to implement Decimation on FPGA and Matlab
For this task i chose following design parameters

Filter type=window hamming hamming method
filter order=30
decimation factor=10
input sample rate=2Ms/s
output sample rate=200ks/s
Normalized cuttof =1/decimation factor

First i implement it on MATLAB and use this sequence

Filter
handle filter delay
downsample
Using above sequence i successfuly implement it on MATLAB

For FPGA i use fir compiler core in which i paste the same coefficients that is generated through matlab
But the problem i face is fir compiler core directly gives you the decimated output without handling fitler delay
so what should i do if want to handle this filter delay in xilinx

Fir compiler core sequence
Filter-downsample

## Recommended Posts

• 0

I don't understand what you mean with "handle this filter delay in Xilinx".

Causality requires the FIR filter to look 14 samples into the future before it delivers "the" output sample (formally: "group delay").
The implementation will need a little more, depending on what options you chose (e.g. "transposed" would be the fastest)

Without coefficient-dependent optimization (odd-/even symmetry, halfband zeros), a FIR filter doesn't care about the "delay", it just spits out a weighted sum of input samples.

But as said, I'm guessing at the question.

##### Share on other sites
• 0

Filtering a signal introduces a delay. This means that the output signal is shifted in time with respect to the input.
For example my input is [1 2 3 4 5 6 7 8 9 10]
decimation factor is 2
filter type is fir

first i apply to a filter to input and filtered output is for example
0.0001 0.0003 0.1 0.15 0.17 0.16 0.18 0.16 0.17 0.15

I need to discard first two values that is a transient response(group delay)
after discarding i have these values
0.1 0.15 0.17 0.16 0.18 0.16 0.17 0.15

now i pad some values at the end to make the vector length equal
0.1 0.15 0.17 0.16 0.18 0.16 0.17 0.15 0.15 0.15

finaly down sample it by factor of 2
0.1 0.17 0.18 0.16 0.15

fir compiler doesn't give option to handle this transient response which is known
group delay of a filter so how i manage this problem in verilog

Below you can find a matlab code that explain the complete scenario

following flow is follow in the below code
bits->interpolation->decimation->bits
detail flow
bits->upsample->interpolation filter->decimation_filter->downsample->bits

you can find its explanation from this link as well
https://www.mathworks.com/help/signal/ug/compensate-for-delay-and-distortion-introduced-by-filters.html

clc;
clear all;
close all;
idata=ones(1,100);
nfilt=30;
factor = 10;
alpha = 0.5;

idata = randi([0 1],100,1);
//bits that becomes the input of upsample

//****************** below code represent the interpolation implementation in which first
we upsample the code and then filter it and finaly discard transient response
xr = upsample(idata,factor);
h1 = intfilt(factor,2,alpha);
y = filter(h1,1,xr);
delay_int = mean(grpdelay(h1));
y(1:delay_int) = [];
//*******************

///**pad some values at the end of data so that my vector length is eqa
y=[y;repelem(y(end),delay_int)'];

//**decimation fir filter which
[B,A]=fir1(30,1/factor);
dec_filter=filter(B,A,y);
delay_dec = mean(grpdelay(B));
dec_filter(1:delay_dec) = [];
//** discard the transient responese of a filter at a start

///**pad some values at the end of data so that my vector length is equal
dec_filter=[dec_filter;repelem(y(end),delay_dec)'];

///** finaly down sample it to complete decimation
dec=downsample(dec_filter,factor);
deb=round(dec);
bits=de2bi(deb,'left-msb');

[er,bit]=biterr(idata,bits);

##### Share on other sites
• 0

So .... your issue with the output of the FIR compiled decimator is that it doesn't remove the runup?  Why not just remove it yourself?  Either within your own logic or after you bring the filter's results back to your PC to examine?

In many if not most of the signal processing applications I've dealt with, the signal is an infinite stream of numbers and the transient just washes out quickly--enough so that it's not really relevant.  It seems like the FIR filter produced this type of result.

There are other applications where the DSP is applied to a finite data set.  It's just that these have been the exception rather than the rule in my humble experience.  In these examples, the transient response becomes relevant.

For testing a filter, knowing when/where the transient begins can be a difficulty.  For testing a decimator, it can become even more of a challenge, as the test harness must now also know the phase of the decimator.

Dan

##### Share on other sites
• 0
On 2/16/2018 at 4:57 PM, [email protected] said:

So .... your issue with the output of the FIR compiled decimator is that it doesn't remove the runup?  Why not just remove it yourself?  Either within your own logic or after you bring the filter's results back to your PC to examine?

In many if not most of the signal processing applications I've dealt with, the signal is an infinite stream of numbers and the transient just washes out quickly--enough so that it's not really relevant.  It seems like the FIR filter produced this type of result.

There are other applications where the DSP is applied to a finite data set.  It's just that these have been the exception rather than the rule in my humble experience.  In these examples, the transient response becomes relevant.

For testing a filter, knowing when/where the transient begins can be a difficulty.  For testing a decimator, it can become even more of a challenge, as the test harness must now also know the phase of the decimator.

Dan

Sir fir decimator gives output after complete  implementation of (filter->down sample) it does give me the independent output of filter so i cannot remove this transient response by myself

one of the implementation is that i only use fir compiler for filter not for decimator and then down-sample it by myself using my own logic but

i cannot satisfy with this type of implementation because if fir compiler give us a feature of decimator then why not we use it efficiently