> the code is attached
Not really readable.
Here attached as VHDL-file

The incoming reset signal is not used, the init_counter is not clocked.

Yes some signals are not used because at first, I just want to integrate 
my code to an existing product.
So I just modify one of the functions of the firmware to add my code.

here is the original code

thanks

You forgot to post the COEFFs, They might be most relvant for these 
issues.

You also should post the simulation

Jürgen S. wrote:
> You forgot to post the COEFFs, They might be most relvant for these
> issues.

There is a section with a comment coefficients in the code:

1

  constant coeff_0 : signed(NB_Bit downto 0) := X"003FBE";  -- Coefficients

2

  constant coeff_1 : signed(NB_Bit downto 0) := X"FF8087";

3

  constant coeff_2 : signed(NB_Bit downto 0) := X"003FBE";

4

  constant coeff_3 : signed(NB_Bit downto 0) := X"007F78";

5

  constant coeff_4 : signed(NB_Bit downto 0) := X"FFC082";

number format is not clear

> You also should post the simulation
A clear documentation of the utilized algorithm would help (number of 
pads, expected cut-off, precision of incoming data) and a glimpse of the 
intended fpga-type (one witw a DSP-slice/hardware-multiplier-macro or 
not ).

But so far,

Your arithmetic is obviously not pipelined, so in the best case, the 
hardware computes one multiplication and three additions (all depending) 
in a single clock cycle of 4ns period. Unfortunately you did not mention 
anything about your hardware (why not?) but this sounds challenging for 
a non-highend FPGA. Did you specify correct timing constraints? Did you 
look into the timing report? Did you try to reduce the clock frequency? 
What did you try at all to find the root of the problem?

Good morning,

Yesterday, I managed to operate this filter with the coefficients for a 
notch. I split the clock, and it worked. Now, I have some questions and 
I'm conducting tests with different sampling frequencies and 
coefficients (high frequency).

Thank you for your response.

"Your arithmetic is obviously not pipelined, so in the best case, the 
hardware computes one multiplication and three additions (all dependent) 
in a single clock cycle of 4ns period."

This seems very interesting; I will look into it further.

I am also wondering how it is possible that with a non-recursive filter, 
such as:

 Y_n = X_n  C1 + X_{n-10}  C2 + X_{n-20}  C3

It works very well with a sampling frequency equal to the clock 
frequency, which is 250 MHz (ADC). (3 Mux)

Or even with an equation like (using integer coefficients,  1, 2, -1, 
-2) :

 Y_n = X_n  C1 + X_{n-10}  C2 + X_{n-20}  C3 + Y_{n-1}  C4 + Y_{n-2}  C5

I think it is necessary for me to have a pipelined architecture.

thanks

ps : I use Xilinx Artix-7 FPGA (XC7A35T)

When using small integer coeffs as in your example, only a few bits are 
used for representation. Since the coeffs are constant in your design, 
the logic synthesis may optimize away parts of the design. Carry chains 
become shorter, and the design gets faster. For longer coeffs, this is 
not the case and the timing may fail.
Since your IIR works correctly in simulation, I'm quite sure there is a 
timing problem. Again: Did you specify clock constraints and check the 
timing report?
Running a filter design @250MHz on a XC7A is quite challenging (its one 
of the smallest in the 7 series), you will need pipelining here for 
sure. I suggest to use pipelined multipliers and also put a pipe stage 
in each level of the final adder tree.

Vancouver wrote:
> When using small integer coeffs as in your example, only a few bits are
> used for representation. Since the coeffs are constant in your design,
> the logic synthesis may optimize away parts of the design.

Not sure. The opening was "it works well in simulation". If this is the 
case, then there are other reasons. Unused bits as a result of false 
usage will suddenly cause misbehaviour. However I also thought that 
coefficients might be not wide enough.

Anyway we need the full code and the full simulation. It then should be 
evident, what is goging wrong.

about the coefficients,

the format is the hexa :
There are 10 bits for the integers (input data).
Then, there is a number of bits x for the decimals; this number x 
depends on the precision I want for my coefficients (I ensure that the 
total is a multiple of four).

The filter with long coefficients works in real-time. I divided the 
clock by 4 and recalculated the coefficients with a different sampling 
frequency from the clock (250Mhz/4).

I understand the issue a little better now, even though I still have 
some questions.


"
    constant coeff_0 : signed(NB_Bit downto 0):= X"000006707EC7";
    constant coeff_1 : signed(NB_Bit downto 0):= X"00000CE0FD8E";
    constant coeff_2 : signed(NB_Bit downto 0):= X"000006707EC7";
    constant coeff_3 : signed(NB_Bit downto 0):= X"007C5C8026EB";
    constant coeff_4 : signed(NB_Bit downto 0):= X"FFC389BDDDF7";
"
(NB_Bit = 47)