Moving Average zu langsam

[Achim (Gast)]

Hallo Zusammen,

in meinem Design habe ich ein Moving Average Filter, das bisher so 
aussieht:

library IEEE;
use IEEE.Std_Logic_1164.all;
use IEEE.Numeric_std.all;
use IEEE.math_real.log2;
use IEEE.math_real.ceil;


entity moving_average is
   generic (
      c_width          : integer := 14;               -- Bit width of input values
      c_average_depth   : integer := 4                 -- Amount of averaging
      );
   port (
      CLK           : in  std_logic;
      RESET         : in  std_logic;
      DATA_IN       : in  std_logic_vector(c_width - 1 downto 0);               -- Data input
      VALID_IN      : in  std_logic;                              -- Data valid input
      DATA_OUT      : out std_logic_vector(c_width - 1 downto 0);               -- Data output
      DATA_OUT_LONG : out std_logic_vector(c_width + (integer(ceil(log2(real(c_average_depth))))) - 1 downto 0) -- Data output (not rounded to input with)
      );
end moving_average;


architecture rtl of moving_average is

  constant c_count_width : integer := integer(ceil(log2(real(c_average_depth))));
  type   taverage_array is array (c_average_depth - 1 downto 0) of unsigned(c_width - 1 downto 0);
    signal s_average_array : taverage_array   := (others => (others => '0'));
  signal s_add_reg : unsigned(c_width + c_count_width - 1 downto 0) := (others => '0');
   
begin

  pfifo : process (CLK) is
    variable i : integer range 0 to c_average_depth - 1 := 0;
  begin
    if rising_edge (CLK) then
      if RESET = '1' then
        s_average_array <= (others => (others => '0'));
      else
        if VALID_IN = '1' then
          s_average_array(0) <= unsigned(DATA_IN);
          for i in 0 to c_average_depth - 2 loop
            s_average_array(i+1) <= s_average_array(i);
          end loop;
        end if;
      end if;
    end if;
  end process pfifo;
  
  padd : process (s_average_array)
    variable v_add_reg_temp : unsigned(c_width + c_count_width - 1 downto 0) := (others => '0');
  begin
    v_add_reg_temp := (others => '0');
    for i in 0 to c_average_depth - 1 loop
      v_add_reg_temp := v_add_reg_temp + s_average_array(i);
    end loop;
    s_add_reg <= v_add_reg_temp;
  end process padd;
            
   DATA_OUT      <= std_logic_vector(s_add_reg(c_width + c_count_width - 1 downto c_count_width));
   DATA_OUT_LONG <= std_logic_vector(s_add_reg);
   
end rtl;

Wird hier z.B. der gleitende Mittelwert über 4-8 Werte gebildet, 
funktioniert die Sache super. Nun muss ich aber über 64 Werte mitteln. 
Da aus einem anderen Porzess getaktet auf "DATA_OUT" zugegriffen wird, 
ist das Design viel zu langsam - etwa 13MHz auf einem Spartan 3e (es 
müsste mindestens 25 schaffen). Eine Möglichkeit wäre, nicht den jeweils 
ersten Wert von der Summe abzuziehen, sondern den Mittelwert. Gibt es 
einen Weg das Design schneller zu machen, ohne auf diesen Trick zurück 
zu greifen?

Danke und viele Grüße

Achim

[Tobias L. (murxwitz)]

einen etwas anderen Ansatz: du musst ja nicht jedesmal die komplette 
Summe berechnen, sondern nur den neuen Wert dazu addieren und den n't 
letzten Wert abziehen, du musst ja eh alle Werte speichern

pseudocode:

summe += neu
summe -= alt(n)
for (k=1;k<=n;k++)
  alt(k-1) = alt(k)
alt(0) = neu

mittelwert = summe / n

finde leider den Link zu dem Beispiel gerade nicht

[Achim (Gast)]

Unfassbar, dass ich da nicht selbst drauf gekommen bin. 141MHz indem auf 
den Akku jeweils nur der neue Wert aufaddiert und der letzte im Array 
subtrahiert wird. Vielen Dank :D

[Achim (Gast)]

Was mir grade noch einfällt: könnte man xst eigentlich dazu bringen, 
dass Shift Register in ein BRAM zu packen?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Achim schrieb:
> könnte man xst eigentlich dazu bringen, dass Shift Register in ein BRAM
> zu packen?
Ja. Dazu müsstest du nur die Beschreibung so ändern, dass die Synthese 
ein BRAM erkennt. Siehe dort: 
http://www.lothar-miller.de/s9y/archives/20-RAM.html
Und im XST Users Guide...

Eine ressourcensparende Alternative wäre auch, ein PT1 Glied 
nachzubilden. Das ist dann ein Zweizeiler wie im 
Beitrag "Re: CPLD-Problem: moving average"

[Uli der Troll (Gast)]

Allenfalls koennte man auch den exponentiellen Average verwenden, der 
braucht nur eine Speicherstelle.

[Fpgakuechle K. (Gast)]

Achim schrieb:
> Was mir grade noch einfällt: könnte man xst eigentlich dazu bringen,
> dass Shift Register in ein BRAM zu packen?

Nimm den reset raus:

      if RESET = '1' then
        s_average_array <= (others => (others => '0'));
      else

Dein Ziel sollte allerdings kein mapping auf BRAM sondern auf 
Distributed RAM liegen, eigentlich auf SRL16. Gegenfalls kannst du ja 
ein FIFO per coregen generieren und einbauen, da hat es die Synthese 
einfacher.

MfG,

[VHDL-Fredi (Gast)]

Lothar Miller schrieb:
>> könnte man xst eigentlich dazu bringen, dass Shift Register in ein BRAM
>> zu packen?
> Ja. Dazu müsstest du nur die Beschreibung so ändern, dass die Synthese
> ein BRAM erkennt. Siehe dort:

Oder noch einfacher:

Einen Haken bei XST Setting "pack slice logic into unused BRAM" setzen.

[Fpgakuechle K. (Gast)]

VHDL-Fredi schrieb im Beitrag #3680965:
> Lothar Miller schrieb:
>>> könnte man xst eigentlich dazu bringen, dass Shift Register in ein BRAM
>>> zu packen?
>> Ja. Dazu müsstest du nur die Beschreibung so ändern, dass die Synthese
>> ein BRAM erkennt. Siehe dort:
>
> Oder noch einfacher:
>
> Einen Haken bei XST Setting "pack slice logic into unused BRAM" setzen.

Ein Shift register ist keine logic, das funktioniert also nicht.

Diese Funktion map nur Logic also was sich als LUT beschreiben läßt in 
einen (read-only) memory. Die logische Funktion wird bei FPGA start in 
den ROM "geschrieben". Ob '+' so ohne weiteres zu einer LUT umgewandelt 
wird, bezweifle ich. Gegegebenfalls müsste man die Addition als logische 
Funktion hinschreiben. Vorher mal abschätzen wie groß die LUT wird.



MfG,

[Sabine W. (sabine_w)]

Eine Verständnisfrage, warum werden die Werte in s_average_array jeweils 
um eine Position verschoben und nicht einfach als Ring-Puffer 
eingetragen und ausgelesen? Grade bei einer Zweierpotenz- Puffergröße 
sollte das doch effizienter sein.