Outputsignal bleibt gleich

[Eren Y. (kaitou)]

Hallo Leute

Sitze nun seit 3 Stunden am gleichen Code und schaffe es nicht, das 
ganze korrekt zum laufen zu bringen.
Es handelt sich um einen PRN Generator. Genauer gesagt, ein 
Schieberegister, der pseudozufällig '1' oder '0' rausspuckt. Der Code 
ist ziemlich selbsterklärend.

Simulation und alles funktioniert problemlos, jedoch kommt immer nur der 
gleiche Wert raus (lfsr_out = '0').

Code:

library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
use ieee.numeric_std.all;

entity lfsr_counter is
  generic(
    WIDTH : integer := 10
  );
  port(
    clk      : in  std_logic;       --clock
    rst      : in  std_logic;       --positiv rst
    lfsr_out : out std_logic        --1 bit output of lfsr
  );
end lfsr_counter;

-------------------------------------------------------------------

architecture behavioral of lfsr_counter is
  type state_type is (state_rst, state_go); --rst: reset; go: lfsr shifts

  signal present_state : state_type;
  signal next_state    : state_type;
  signal lfsr          : std_logic_vector((WIDTH - 1) downto 0) := (others => '0');
  signal d0            : std_logic                              := '0'; --stores the current feedbackvalue

begin

  --sequencial logic:
  -------------------------------------------------------------------
  state_register : process(clk, rst)
  begin
    if (rst = '1') then
      present_state <= state_rst; --default state on reset.
    elsif (rising_edge(clk)) then
      present_state <= next_state; --state change
    end if;
  end process;

  --  combinatorial logic
  -------------------------------------------------------------------    

  comb_logic : process(present_state, rst)
  begin
    case present_state is
      when state_rst =>
        if (rst = '1') then
          next_state <= state_rst;
        else
          next_state <= state_go;
        end if;
      when state_go =>
        if (rst = '1') then
          next_state <= state_rst;
        else
          next_state <= state_go;
        end if;
    end case;
  end process;

  output_logic : process(present_state)
  begin
    if (present_state = state_go) then
      --assert ((WIDTH >= 3) and (WIDTH <= 10))
      --report "Error: the LFSR width must be between 3 and 10" severity failure;
      case WIDTH is               --definitions for the feedback
        when 3      => d0 <= lfsr(2) xnor lfsr(1);
        when 4      => d0 <= lfsr(3) xnor lfsr(2);
        when 5      => d0 <= lfsr(4) xnor lfsr(2);
        when 6      => d0 <= lfsr(5) xnor lfsr(4);
        when 7      => d0 <= lfsr(6) xnor lfsr(5);
        when 8      => d0 <= lfsr(7) xnor lfsr(5) xnor lfsr(4) xnor lfsr(3);
        when 9      => d0 <= lfsr(8) xnor lfsr(4);
        when 10     => d0 <= lfsr(9) xnor lfsr(6);
        when others => null;
      end case;
      lfsr     <= std_logic_vector(unsigned(lfsr) sll 1); --shifting all bits to left by 1
      lfsr_out <= lfsr(WIDTH - 1); --MSB to output
      lfsr     <= lfsr(WIDTH - 1 downto 1) & d0; --concatenate the feedback to the lfsr
    else
      lfsr     <= (others => '0'); --reset state -> lfsr contains only '0'
      lfsr_out <= '0';
    end if;
  end process;
end architecture;

Wenn ich in der output_logic den lfsr_out <= '1' setze, kommt bei der 
simulation immer 1 heraus. Die Testbench beginnt 1 clkzyklus lang mit 
reset, danach ist reset 0 für 1024 Taktzyklen... Seht jemand grad den 
Fehler?

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

Eren Y. schrieb:
> Die Testbench beginnt 1 clkzyklus lang mit reset, danach ist reset 0 für
> 1024 Taktzyklen... Seht jemand grad den Fehler?
Wie wäre es, wenn du die paar VHDL Dateien hier einfach mal anhängst? 
Damit kann man sich leichter ein Projekt aufsetzen und ein Bild 
machen...

BTW: Wenn deine Simulation schon läuft, dann musst du nur überlegen, was 
du beim Schreiben der Zeilen gedacht hast, und kontrollieren ob genau 
das passiert.

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

Ein Wort zum Verhalten von Signalen in Prozessen (und zum eigentlichen 
Problem hier):
Eren Y. schrieb:

  lfsr     <= std_logic_vector(unsigned(lfsr) sll 1); --shifting all bits to left by 1
  lfsr_out <= lfsr(WIDTH - 1); --MSB to output
  lfsr     <= lfsr(WIDTH - 1 downto 1) & d0; --concatenate the feedback to the lfsr

lfsr behält seinen "alten" Wert während des gesamten Prozesses. Und am 
Ende des Prozesses "gewinnt" die letzte Zuweisung. Also ist die erste 
der obigen drei Zeilen wirkungslos, weil der in der ersten Zeile 
zugewiesene Wert in der dritten Zeile wieder überschreiben wird.

BTW: zum Formatieren von VHDL-Code bitte die [vhdl] Tags verwenden.

BTW2:
Hierzu ein Wort:
use ieee.std_logic_unsigned.all;
use ieee.numeric_std.all;
Damit hast du doppelte Typdefinitionen und irgendwann sicher seltsame 
Fehlermeldungen. Fazit: diese beiden niemals zusammen einbinden.
Siehe den Beitrag "IEEE.STD_LOGIC_ARITH.ALL obsolete"

[Eren Y. (kaitou)]

Hallo Lothar

> BTW: zum Formatieren von VHDL-Code bitte die vhdl Tags verwenden.

Vielen Dank für das Bearbeiten meines Beitrages.


Lothar M. schrieb:
> use ieee.std_logic_unsigned.all;
> use ieee.numeric_std.all;
> Damit hast du doppelte Typdefinitionen und irgendwann sicher seltsame
> Fehlermeldungen. Fazit: diese beiden niemals zusammen einbinden.

Ich hatte Probleme mit "sll" in Vivado. Dieses Pkg hatte ich noch 
eingefügt gehabt, da ich ungeduldig wurde. Aber war überflüssig ja, 
danke!

Lothar M. schrieb:
> Ein Wort zum Verhalten von Signalen in Prozessen (und zum eigentlichen
> Problem hier):
> lfsr behält seinen "alten" Wert während des gesamten Prozesses. Und am
> Ende des Prozesses "gewinnt" die letzte Zuweisung. Also ist die erste
> der obigen drei Zeilen wirkungslos, weil der in der ersten Zeile
> zugewiesene Wert in der dritten Zeile wieder überschreiben wird.

Ich nehme an, zwei Zuweisungen des gleichen Signals sind in einem 
Prozess also nicht zulässig, da man Hardware beschreibt und somit alles 
gleichzeitig abläuft? Ich habe jetzt versucht dies zu korrigieren indem 
ich die Shift-Left Anweisung und das Anhängen des Feedbacks in einem 
letzten Schritt durchführe:

      lfsr_out                 <= lfsr(WIDTH - 1); --MSB to output
      lfsr(WIDTH - 1 downto 0) <= lfsr(WIDTH - 2 downto 0) & d0;

Aber ich sehe keine Veränderung. Ich denke dass der Fehler irgendwo in 
der Outputlogic liegt. Was passiert da zuerst, was danach? Der Inhalt 
von lfsr bleibt doch nach dem process erhalten oder geht der wieder in 
den Default-Zustand?

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

Eren Y. schrieb:
> Ich denke dass der Fehler irgendwo in der Outputlogic liegt.
Wie kommst du darauf? Ändert sich der Wert des lfsr irgendwann? Nein? 
den Grund habe ich genannt: das Verhalten von Signalen in Prozessen...

> Ich nehme an, zwei Zuweisungen des gleichen Signals sind in einem
> Prozess also nicht zulässig, da man Hardware beschreibt und somit alles
> gleichzeitig abläuft?
Genau andersrum: du kannst zigtausemal irgendwas an ein Signal zuweisen. 
Das Signal ändert seinen Wert während des gesamten Prozesses nicht. Er 
am Schluss des Prozesses (oder beim nächsten wait) übernimmt das signal 
den zuletzt zugewiesenen Wert. Ein echt praktisches Verhalten, wenn 
man sich dran gewöhnt hat. Mal angenommen, hier komme ich mit a=2 in den 
Prozess:

signal a : integer;
signal b : integer;

process (clk) begin
  if rising_edge(clk) begin 
     a <= 5;      -- a wird am Ende des Prozesses 5, behält aber vorerst den Wert 2
     b <= a+1     -- b wird am Ende des Prozesses 3, behält aber vorerst den Wert
     a <= a+4;    -- a wird am Ende des Prozesses 5, a bleibt aber vorerst 2          
     a <= b+3;    -- a bleibt 2
     a <= a+1;    -- a bleibt 2          
  end if;
end process;    -- jetzt "bekommt" a den zuletzut zugewiesenen Wert 3

Des Witz daran ist, dass ich bis auf die letzte Zeile alle vorigen 
Zeilen ohne Funktionsänderung beliebig durcheinander mischen kann.

Und bei dir ist das die letzte Zuweisung:
lfsr <= lfsr(WIDTH - 1 downto 1) & d0;
Und nur die ist interessant. Also wird das lfsr laufend sich selber 
zugewisen. nur das unterste Bit könnte mal 1 oder auch 0 sein.

Das hier ist übrigens eine kombinatorische Schleife, die du aber wegen 
der unvollständigen Sensitivliste nicht bemerkst:
lfsr     <= std_logic_vector(unsigned(lfsr) sll 1);
Denn ein LFSR muss getaktet sein. Und ein Takt ist immer ein 
xxx_edge() oder ein 'event.
http://www.lothar-miller.de/s9y/archives/42-Kombinatorische-Schleifen.html

[Mampf F. (mampf)]

Für mich sieht es so aus, als würden Latche gebildet werden ...

Ich würde erstmal alles auf clk-getaktete Prozesse umbauen ...

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

Mampf F. schrieb:
> Für mich sieht es so aus, als würden Latche gebildet werden ...
Das ist das Problem der Zwei-Prozess-Schreibweise: der Takt wird dann 
von Anfängern nur für die FSM verwendet, Zähler (oder hier das LFSR) 
laufen ungetaktet als (versteckte) kombinatorische Schleife.
http://www.lothar-miller.de/s9y/archives/43-Ein-oder-Zwei-Prozess-Schreibweise-fuer-FSM.html

Der Synthesizer meldet solche gegateten kombinatorischen Schleifen dann 
gern als Latch.

Ich hol mal den Prozess mit der unvollständigen Sensitivliste extra raus 
und kürze ihn etwas ein:

  output_logic : process(present_state)
  begin
    if (present_state = state_go) then
      case WIDTH is               --definitions for the feedback
        when 3      => d0 <= lfsr(2) xnor lfsr(1); -- lfsr fehlt in der Sensitivliste, denn eine Änderung 
        when 4      => d0 <= lfsr(3) xnor lfsr(2); -- von lfsr müsste eine Neuberechnung des Prozesses anstoßen
        ...
        when others => null; 
      end case;
      lfsr     <= std_logic_vector(unsigned(lfsr) sll 1); -- wenn lfsr in der Sensitivliste steht, dann wird hier
                                                          -- bei jeder Änderung von lfsr ein neuer Wert für lfsr berechnet
                                                          -- und weil ein neuer Wert berechnet wird, ändert sich lfsr --> Endlosschleife
    else
      lfsr     <= (others => '0'); --reset state -> lfsr contains only '0'
      lfsr_out <= '0';
    end if;
  end process;

[Mampf F. (mampf)]

Lothar M. schrieb:
> Ich hol mal den Prozess mit der unvollständigen Sensitivliste extra raus
> und kürze ihn etwas ein

Deshalb hatte ich mir angwohnt, (nahezu) alles als getakteten Prozess 
zu schreiben ... Dann muss ich mir auch keine Gedanken um die 
Sensitivity-Liste machen.

Wenn ich kombinatorisch etwas mache, dann nicht in Prozessen :)

Bin damit bisher gut gefahren^^