Mittelwertfilter

Dieter schrieb:
> Ist der Reset so richtig beschrieben?
Wozu überhaupt ein Reset?   ;-)
Seis drum...

R. K. schrieb:
> Kann mir jemand sagen, wie ich diese 4 Bits zusammenzählen kann?
Der erste logische Schritt wäre der, das eine Bit zu einem Vektor zu 
erweitern, dann diesen Vektor für die Addition zum unsigned zu casten:

1

  ReadyxSO <= std_logic_vector(unsigned("00"&DataBufxD(0))+unsigned("00"&DataBufxD(1))+

2

                               unsigned("00"&DataBufxD(2))+unsigned("00"&DataBufxD(3)));

Dann kommt aber die Meldung

1

Expression in type conversion to unsigned has 4 possible definitions 

2

in this scope, for example, SIGNED and UNSIGNED.

Das bedeutet, das die Cast-Funktion nicht weiß, welchen Datentypen sie 
da konvertieren soll, denn "00" kann ja ein bit_vector, ein 
std_logic_vector, ein signed oder ein unsigned sein.
Abhilfe schafft, hier nicht einen Cast sondern einen Qualifier zu 
verwenden, der der Addition sagt, dass die Vektoren als unsigned 
Operanden verwendet werden sollen:

1

  ReadyxSO <= std_logic_vector(unsigned'("00"&DataBufxD(0))+unsigned'("00"&DataBufxD(1))+

2

                               unsigned'("00"&DataBufxD(2))+unsigned'("00"&DataBufxD(3)));

Zum Hintergrund:
http://www.lothar-miller.de/s9y/archives/82-Qualifier.html


Darüber hinaus gibt es natürlich noch zig andere Methoden, die zum 
gewünschten Resultat führen würden...  ;-)

R. K. schrieb:
> FIR_comb:  process  (ClkxCI, RstxRBI)
Der Prozess hat seinen Namen nicht verdient, weil er nicht 
kombinatorisch ist...

Ich hätte da noch einen:

1

    FIR_comb:  process  (DataBufxD)

2

    variable cnt : integer range 0 to 4;

3

    begin

4

        cnt := 0;

5

        for i in 0 to 3 loop

6

           if DataBufxD(i)='1' then 

7

              cnt := cnt + 1;

8

           end if;

9

        end loop;

10

        ReadyxSO <= std_logic_vector(to_unsigned(cnt,3));

11

    end process  FIR_comb ;

Ergebnis:
Macro Statistics
# Adders/Subtractors     : 3
 3-bit adder             : 3


EDIT: Hoppala, zu spät.
Aber wenigstens ist meine Lösung richtiger (4 Bits statt 16)...  ;-)
Und ausserdem wird die vorgeschlagene Addition eines integers auf einen 
std_logic_vector mit der numeric_std nicht funktionieren:
 vBitsInWord := vBitsInWord + 1;

Super danke.

Mir gefällt die Lösung von Lothar Miller am besten, da ich die 
for-schleifen in einem VHDL-Code irgendwie "unpassend" finde. (so lange 
man diese vermeiden kann).
Oder ist das sowiso egal und man hofft dass der Compiler was schlaues 
daraus macht?

R. K. schrieb:
> Oder ist das sowiso egal und man hofft dass der Compiler was schlaues
> daraus macht?
Nein, Hoffen hilft da nicht. Das hier ist z.B. am schnellsten und 
ressourcensparendsten:

1

 ReadyxSO <= "000" when DataBufxD="0000" else

2

             "001" when DataBufxD="0001" or DataBufxD="0010" or DataBufxD="0100" or DataBufxD="1000" else

3

             "010" when DataBufxD="0011" or DataBufxD="0110" or DataBufxD="1100" or DataBufxD="1001" else

4

             "011" when DataBufxD="0111" or DataBufxD="1110" or DataBufxD="1101" or DataBufxD="1011" else

5

             "100";

Letztlich muss die Lösung sogar in 3 simple 4er-LUTs passen, weil du 4 
Eingangssignale und je 1 Ausgangssignal (pro Zählerbit) hast:

1

 ReadyxSO(0) <= '1' when DataBufxD="0001" or DataBufxD="0010" or 

2

                         DataBufxD="0100" or DataBufxD="1000" or

3

                         DataBufxD="0111" or DataBufxD="1110" or        

4

                         DataBufxD="1101" or DataBufxD="1011" else

5

                '0';

6

 ReadyxSO(1) <= '1' when DataBufxD="0011" or DataBufxD="0110" or 

7

                         DataBufxD="1100" or DataBufxD="1001" or

8

                         DataBufxD="0111" or DataBufxD="1110" or        

9

                         DataBufxD="1101" or DataBufxD="1011" else

10

                '0';

11

 ReadyxSO(2) <= '1' when DataBufxD="1111"  else

12

                '0';

Dise beiden Lösungen sind allerdings wieder äquivalent.

Matthias schrieb:
> der counter hochzählt.
Da zählt kein Counter!
Dieser Counter ist nur eine Hilfestellung für den Synthesizer. Damit 
weiß der Synthesizer, wei viele Addierer er verwenden muss. Der Counter 
taucht in der Realität nirgends auf...

Stimmt. Lookup-Tabellen waren schon im Studium immer die schnellsten 
Varianten um so was zu wandeln. Jedoch hatte ich dies 
verdrängt/vergessen.
Um das Hoffen ein bisschen zu "vebessern" gehe ich meistens so vor:
1)Überlegen was ich will
2) Code schreiben
3) Im RTL schauen was der Compiler gemacht hat

Bronco schrieb:
>> Und ausserdem wird die vorgeschlagene Addition eines integers auf einen
>> std_logic_vector mit der numeric_std nicht funktionieren:
>>  vBitsInWord := vBitsInWord + 1;
> Doch, funktioniert, nachweislich! Ich hab mich auch gewundert...
Kann nicht sein. Und wie erwartet:

1

ERROR:HDLParsers:808 - "C:/..../sob.vhd" Line 39. + can not have such operands in this context.

Das bekomme ich mit diesen Zeilen:

1

process (ClkxCI) 

2

  variable vBitsInWord : std_logic_vector(2 downto 0);

3

begin

4

  if (rising_edge(ClkxCI)) then

5

    vBitsInWord := "000";

6

    for c in 0 to 3 loop

7

      if ( DataBufxD(c) = '1' ) then 

8

        vBitsInWord := vBitsInWord + 1;  --   Zeile 39

9

      end if;

10

    end loop;

11

    ReadyxSO <= vBitsInWord; 

12

  end if;

13

end process;

Das mit der parallelen Logik ist wirklich ein gutes Argument. (Ich werde 
dies später sicher noch brauche, wenn ich die Dezimation etc. 
implementiere)

Wenn ich mir mein Programm so genau anschaue, dann würde ich die 
1-Bit-Quantisierung gerne mal ein wenig aufweichen. Meine Signal ist 
somit nicht mehr 1-Bit, sondern 4 Bit breit. Kann ich in meinem Programm 
die Vektoren durch Arrays ersetzen?

1

2

TYPE   DataBufxDS IS ARRAY(0 to 63) OF std_logic_vector(3 downto 0);

Ich war wohl ein wenig voreilig. Eine möglich Lösung lautet prinzipiell 
wie folgt: (der Ausgang mit einer Breite von 3 Bits macht jedoch altell 
noch keinen Sinn)

1

library ieee;

2

use ieee.std_logic_1164.all;

3

use work.IPoTP_constants.all;

4

5

use IEEE.NUMERIC_STD.ALL;

6

7

entity sync_chip is

8

  port (

9

    ClkxCI    : in std_logic;

10

    RstxRBI    : in std_logic;

11

    DataInxDI  : in std_logic_vector (2 downto 0);

12

    MetrikxDO   : out std_logic_vector (3 downto 0)

13

  );

14

end sync_chip;

15

16

architecture rtl of sync_chip is  

17

18

  TYPE   DataBufxD IS ARRAY(0 to 64) OF std_logic_vector(3 downto 0);

19

20

  signal DataBufxDS : DataBufxD :=(others =>(others=>'0'));

21

begin

22

23

 FIR_ff : process(ClkxCI,RstxRBI)

24

   begin

25

    if RstxRBI = '1' then

26

      DataBufxDS <= (others =>(others=>'0'));

27

28

    elsif rising_edge (ClkxCI) then

29

      DataBufxDS(3 downto 1) <= DataBufxDS(2 downto 0);

30

      DataBufxDS(0)          <= DataInxDI;

31

    end if;  

32

 end process FIR_ff;

33

34

35

FIR_comb:  process  (DataBufxDS)

36

  variable tmp : integer range 0 to 127;

37

    begin

38

      for c in 0 to 63 loop

39

        tmp := tmp + to_integer(unsigned(DataBufxDS(c)));

40

      end loop;

41

      MetrikxDO <= std_logic_vector(to_unsigned(tmp,3)); 

42

     end process  FIR_comb ;

43

end rtl;

R. K. schrieb:

1

 FIR_comb:  process  (DataBufxDS)

2

   variable tmp : integer range 0 to 127;

3

     begin

4

       for c in 0 to 63 loop

5

         tmp := tmp + to_integer(unsigned(DataBufxDS(c)));

6

       end loop;

Ich würde zur Sicherheit vor die for-Schleife noch ein
 tmp := 0;
einfügen. Denn sonst könnte die Variable blitzschnell zur 
kombinatorischen Schleife ausarten:

1

Xst:2170 - Unit preamble_correlator : the following signal(s) form a combinatorial loop: tmp

Zum Hintergrund:
http://www.lothar-miller.de/s9y/categories/36-Kombinatorische-Schleife

Das Schlimme daran:
das wirst du bei einer Simulation nicht feststellen, weil die Änderdung 
von tmp die Neuberechnung des Prozesses anstossen sollte, das aber nicht 
kann, weil Variablen nicht in die Sensitivliste genommen werden können.
Siehe dazu den recht lesenswerten 
Beitrag "Variable vs Signal"
Mit dem Fazit: Keine Variablen für Anfänger.  ;-)

Danke. Das mit dem tmp := 0; sehe ich aus deinem Argument ein.

Wenn ich jedoch mein RTL anschaue, bin ich mir  eigentlich ziemlich 
sicher, dass ich nach einem Reset einen definierten Zustand von Null 
haben sollte. Oder liege ich hier falsch?

R. K. schrieb:
> dass ich nach einem Reset einen definierten Zustand von Null
> haben sollte. Oder liege ich hier falsch?
Für die Simulation: nach den Reset hat ein integer den maximal negativen 
Wert (integer'left).
Für die Hardware: schnurzegal. Denn nach dem Loop-Unrolling hast du 
einfach nur 63 Addierer (mit einer entsprechend langen und langsamen 
Carry-Chain!!!).


Ich würde da eine "Buchführung" empfehlen: wenn du eine '1' 
hereinbekommst, dann zählst du einen Zähler eins hoch. Wenn du eine '1' 
hinausgibst, dann zählst du den Zähler runter. Wenn Eingang=Ausgang, 
dann tust du nichts. Ergebnis: nur zwei kleine Addierer = schnelles 
Design.

Das mit der langen und langsamen Logik ist mir klar. Für den gegebenen 
Fall mit dem Moving Average gebe ich dir natürlich recht, da hilft die 
Buchführung.
Ich werde später jedoch eine Korrelation bestimmen müssen. Das ganze 
führt dann auf eine FIR -Struktur, welch dank dem rein logischen 
Referenzsignal (also 1er und -1er) immerhin einfach implementierbar ist. 
Jedoch bleibt meine grosse Logik.

R. K. schrieb:
> da hilft die Buchführung.

Buchführung? Seit wann heisst das denn so? Zu meiner Zeit hiess das 
Integrator (?)