Why filter output is like this ?

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?

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

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.

--- 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.

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.

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).