Turn on suggestions

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

Showing results for

- Intel Community
- FPGAs and Programmable Solutions
- Programmable Devices
- Why filter output is like this ?

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page

Highlighted
##

Altera_Forum

Valued Contributor III

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

06-27-2011
10:48 AM

2,248 Views

Why filter output is like this ?

Hi . Details of FIR filter

FIR rectangular Window BPF Order 3 No. of coefficients = 4 Fc1 = 1 Hz Fc2 = 24 Hz Fs = 100 Hz figure 1 (https://picasaweb.google.com/lh/photo/twkb1ndv70nlf_yyldlubw?feat=directlink) shows the Simulink model of symmetric FIR realization. figure 2 (https://picasaweb.google.com/lh/photo/iy3punhc3homoffa0gfrfa?feat=directlink) shows the comparison of ( top to down ) input, Simulink model o/p, o/p using HDLimport after generating HDL code from the model for the filter subsystem. figure 3 (https://picasaweb.google.com/lh/photo/xpenvlyowzlwfpm2scsxrg?feat=directlink) represents complete model. My doubt is why there is a difference in the o/p values in both cases ie, normal subsystem using simulink blocks and subsystem using HDLimport. Filter coefficients were obtained using FDAtool which are [0.143537584073133 0.415799512456997 0.415799512456997 0.143537584073133] I tried with higher filter order ( 12, 16, 32 ) , but results were very poor.( some sort of square pulses at irregular intervals). i used fixed point rep. as follows for i/p = 16(10+6) for coeff. = 16(10+6) Thank you.
13 Replies

Highlighted
##

have you made sure your data is fixed to the correct number of bits (remember floating point is no appropriate for HDL)? the HDL output looks like it's clipping.

Altera_Forum

Valued Contributor III

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

06-27-2011
11:34 AM

3 Views

Highlighted
##

Altera_Forum

Valued Contributor III

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

06-27-2011
11:39 AM

3 Views

well, i tried increasing the fraction bit part also, but couldn't obtain good results

Highlighted
##

Altera_Forum

Valued Contributor III

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

06-27-2011
11:41 AM

3 Views

Just having a second look, you probably want more fractional bits and less integer, especially for the coefficients.

What is the range of inputs? what is the expected output range?
Highlighted
##

input is temperature readings which fluctuates in between 300 deg c to 400 deg C, in electrical terms : roughly 10 to 20 mV.

Altera_Forum

Valued Contributor III

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

06-27-2011
11:44 AM

3 Views

Highlighted
##

Altera_Forum

Valued Contributor III

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

06-27-2011
11:47 AM

3 Views

and output is required to denote remarkable changes in fractional parts like 0.2323 to 0.34342...etc

the main concern is : to study fluctuations of 1 Hz to 30 Hz . Also, what option could be better ? - generate coeff using MATLAB, make hdl code from coder, then implement it using simulink hdl import or - design system using dsp builder, and run as HIL - many other i m confused with all options
Highlighted
##

Altera_Forum

Valued Contributor III

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

06-27-2011
02:49 PM

3 Views

basically, the graph you have displays lots and lots of clipping, which is usually the result of not enough integer bits.

Also, the HDL output is very steppy, a sympton of not enough fractional bits. Also, the fact that the graph goes from 500 to -2500 is a bit concerning, making me think there is something not quite riught with your HDL conversion. Is this model one that is simply the model output of simulink when you're converting everything to "HDL codable" ie. you dont have any actual HDL yet? you may need to go back to basics with this - work through it yourself. Its not that hard to see how many bits you need for each step yourself. The first giveaway you have not done this is the fact you have 10.6 for your coefficients. The integer bits will never be used, and the 6 fractional bits are nowhere near enough bits to give the accuracy you seem to need for your coefficients. I suggest you change it to a 0.16 (0 integer, 16 fractional - gives you range 0 to 1 ) or 1.15 if you need it signed (range -1 to +1). Secondly, your input graph only goes from -1 to 1, but you say your temperature inputs go from 300 to 400. Is this somehow normalised to a range -1 to 1? If the input reall is only -1 to 1, you can have 1.15 numbers for your input to. thirdly - when assesing what you need, the rules are like this when you need to maintain values with no clipping or rounding: when adding, add an extra integer bit. when multiplying, add together the integer and fraction bits of both inputs. So a 1.15 x 1.15 will give you a 2.30 output (simulink should do this automatically. You can tell simulink to output any specific number format, and chose the rounding and flooring method) As multiplication actually gives you 2 sign bits, you can lose one of them and keep a 1.15 output. So as you can see, there are a few things we need to clear up.
Highlighted
##

--- Quote Start --- i m confused with all options --- Quote End --- How about going for a more basic 1st or 2nd order IIR lowpass? In can be easily written in plain HDL.

Altera_Forum

Valued Contributor III

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

06-27-2011
04:11 PM

3 Views

Highlighted
##

Altera_Forum

Valued Contributor III

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

06-28-2011
07:17 AM

3 Views

Thanks Tricky .

I tried with following details: BPF flat top window. N = 7,no. of coefficients = 8 Coefficients = [0 0 0 0.546875000000000 0.546875000000000 0 0 0] Coefficient bits = 11(2+9) I/P bits = 16(2+14) O/P bits = 28(5+23) figure (https://picasaweb.google.com/lh/photo/23iywcfc_nbyjjmpokoq0g?feat=directlink)shows the o/p for the simulation. Still , lacking something, but cant detect. figure 2 (https://picasaweb.google.com/lh/photo/_lg_qixdhikhnisxxdqeqq?feat=directlink) shows the implementation.
Highlighted
##

thats some serious clipping - There is something going wrong somewhere - have you checked the output type of each adder and multuplier, and do they match with expectations?

Altera_Forum

Valued Contributor III

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

06-28-2011
07:34 AM

3 Views

Highlighted
##

Altera_Forum

Valued Contributor III

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

06-28-2011
08:26 AM

3 Views

Actually the model is behaving fine with the normal simulink blocks as seen in the above figures.

Importing the HDL generated by HDL coder , using HDL import feature of dsp builder, its not working correct as desired. We cant check internals of the HDL import ( black box).
Highlighted
##

--- Quote Start --- We cant check internals of the HDL import ( black box). --- Quote End --- You can check the generated HDL code? Have you tried doing a co-simulation wit modelsim or another simulator to see where the clipping is occuring (doing co-simulation gives you full access to all internal signals).

Altera_Forum

Valued Contributor III

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

06-28-2011
08:48 AM

3 Views

Highlighted
##

Altera_Forum

Valued Contributor III

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

06-28-2011
08:19 PM

3 Views

try pass through for testing i.e. set your coeffs as [1 0 0 0]

and check you get your input back at output. this test will tell you if your filter scaling is right for this simple case.
Highlighted
##

Altera_Forum

Valued Contributor III

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

06-29-2011
05:56 AM

3 Views

@ kaz, in a similar fir filter (figure (https://picasaweb.google.com/lh/photo/q1uj3vk4ty7oshof7sh2eg?feat=directlink)),(figure 2 (https://picasaweb.google.com/lh/photo/4q8ig-02nc-qts7pekfesa?feat=directlink)), i set coefficients as {1 0 0 0 0....0}

the o/p is like this (figure (https://picasaweb.google.com/lh/photo/tjgypbdnwwtz88z7yqhxxa?feat=directlink)).For more complete information about compiler optimizations, see our Optimization Notice.