Frage zu Pseudozufallsgenerator!?

[Olli R. (Gast)]

Hallo ich wollte
eigentlich
das irreversible Polynom:
x^8+x^6+x^5+x^3+1   darstellen:

das ist mein Code dazu:
 P2: process(CLK, RESET)
  begin
    if RESET = '0' then   -- low active reset am Spartan3E-Board!
    D_OUT2 <= "00000001" after 5 ns;
    elsif CLK = '1' and CLK'event then
         if gen_PZGV2 = '1' then      -- PZG_aktiviert
              if D_OUT2 = "00000000" then
                 D_OUT2 <= "00000001" after 5 ns;
              else
                 D_OUT2 <= (D_OUT2(6 downto 0) & SERIAL_IN2) after 5 ns;
              end if;
           else
              if reset_PZGV2 = '1' then
                 D_OUT2 <= "00000000";
              end if;
           end if;
    D_OUT2(2) <= D_OUT2(1) xor D_OUT2(7); --after 5 ns;
   D_OUT2(4) <= D_OUT2(3) xor D_OUT2(7); --after 5 ns;
   D_OUT2(5) <= D_OUT2(4) xor D_OUT2(7); --after 5 ns;
    D_OUT2(7) <= D_OUT2(6) xor D_OUT2(7); --after 5 ns;
   end if;
  end process P2;

aber irgend wie schein das eingestellte Polynom nicht dem von mir 
gewünscht zu entsprechen? was ist den falsch!=??

[Duke Scarring (Gast)]

Olli R. schrieb:
> aber irgend wie schein das eingestellte Polynom nicht dem von mir
> gewünscht zu entsprechen?
Woher weißt Du denn das? Hast Du eine Testbench dazu?

Duke

[Olli R. (downunderthunder42)]

Duke Scarring schrieb:
> Woher weißt Du denn das? Hast Du eine Testbench dazu?

Ich habe eine Entity, in der dieser Zufallszahlengenerator aktiviert 
wird und die aktuelle Zufallszahl binär auf einem LCD ausgibt.

Ich habe das Problem allerdings gelöst, indem ich mir ein einfach mal 
ein Buch zum Thema ausgeliehen habe der Code sieht jetzt wie folgt aus:


--------------------------Pseudozufalsszahlengenerator------------------ 
-------------------------------------------
-- Erläuterung:

-- gen_PZGV = '1' --> der PZG läuft. Es werden stetig Zufallszahlen 
generiert
-- gen_PZGV = '0' --> der PZG läuft nicht. Es werden keine Zufallszahlen 
generiert
-- reset_PZGV = '1' --> der Zufallszahlengenerator wird auf den Wert 
"00000000" zurückgesetzt, (nur wenn auch gen_PZGV = '0'

 P1: process(CLK, RESET)
  begin
    if RESET = '0' then   -- low active reset am Spartan3E-Board!
    D_OUT <= "00000001" after 5 ns;
    elsif CLK = '1' and CLK'event then
         if gen_PZGV = '1' then      -- PZG_aktiviert
              if D_OUT = "00000000" then
                 D_OUT <= "00000001" after 5 ns;
              else
                 D_OUT <= (D_OUT(6 downto 0) & SERIAL_IN1) after 5 ns;
              end if;
           else
              if reset_PZGV = '1' then
                 D_OUT <= "00000000";
              end if;
           end if;
      SERIAL_IN1 <= D_OUT(7) xor D_OUT(3) xor D_OUT(2) xor D_OUT(1);
--    D_OUT(2) <= D_OUT(1) xor D_OUT(7); --after 5 ns;
--   D_OUT(4) <= D_OUT(3) xor D_OUT(7); --after 5 ns;
--   D_OUT(5) <= D_OUT(4) xor D_OUT(7); --after 5 ns;
--    D_OUT(7) <= D_OUT(6) xor D_OUT(7); --after 5 ns;
   end if;
  end process P1;

-- 8-Bit Rückkopplungsschaltnetz

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

Olli R. schrieb:

    if D_OUT = "00000000" then
        D_OUT <= "00000001" after 5 ns;
    else

Warum machst du das?
Wenn du erst gar nicht alles zu 0 machst, dann brauchst du diese windige 
Abfrage nicht. Das braucht nur unnötige Ressourcen fürs Zurücksetzen. 
Wenn du das Register auf "00000001" initialisierst und zurücksetzt, dann 
bekommst du niemals eine "00000000":

signal  D_OUT : std_logic_vector(7 downto 0)  := x"01";
:
:
              if reset_PZGV = '1' then
                 D_OUT <= "00000001";
              end if;

Ganz trickreich wäre natürlich ein Polynom, das sich selber aus der 
"00000000" Bredouille herausholt... ;-)
Siehe dort: http://www.lothar-miller.de/s9y/categories/38-LFSR

[Duke Scarring (Gast)]

Olli R. schrieb:
> P2: process(CLK, RESET)
>   begin
>     if RESET = '0' then   -- low active reset am Spartan3E-Board!
Kommt der Reset von einem Taster? Ist der entprellt? Und sinnvollerweise 
einsynchronisiert?
Wenn nicht, kann das später zu rätselhaftem Verhalten führen...

>     D_OUT2 <= "00000001" after 5 ns;
Soll das after mit synthetisiert werden?

>     elsif CLK = '1' and CLK'event then
Warum schreibst Du nicht

rising_edge( clk)

 Das ist u.a. besser lesbar.

Olli R. schrieb:
> Ich habe eine Entity, in der dieser Zufallszahlengenerator aktiviert
> wird und die aktuelle Zufallszahl binär auf einem LCD ausgibt.
Also keine Testbench, sondern Test auf Hardware. Eieiei.
Ich teste erst auf der Hardware, wenn es im Simulator funktioniert.

Duke

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

Duke Scarring schrieb:
>>     D_OUT2 <= "00000001" after 5 ns;
> Soll das after mit synthetisiert werden?
Vermutlich nicht, aber es scheint offenbar eine gute Idee zu sein, in 
die Verhaltenssimulation so eine Art Zeitverhalten mit rein zu bringen. 
Und das obwohl diese Zeiten sicher falsch sind...
Ich zitiere mal aus dem 
Beitrag "Re: Feedback für Drehgeber Design"
>>>   SECCOUNTER  <=   "00000000000000"  after 5 ns;
>> Lass dieses after 5ns weg. Es ist unnötig und hat rein gar nichts mit
>> der Hardware zu tun, die ist nämlich viel schneller! Und es verfälscht
>> deine Simulation, weil es "Pseudotakte" erzeugen kann, wo keine sind...
> Symbolische Signallaufzeiten sind haufenweise in den genannten Büchern
> zu finden und ich habe diesen Stil auch in der Uni (mit diesen Büchern)
> gelernt.

Zum Thema Pseudotakte...
Nehmen wir mal diesen kurzen Code mit einem "Takt" und ein paar 
"Zählern":

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity Pseudotakt is
    Port ( run   : in  std_logic;
           clock : out std_logic;
           countA: out std_logic_vector(3 downto 0);
           countB: out std_logic_vector(3 downto 0);
           countC: out std_logic_vector(3 downto 0)
          );
end Pseudotakt;

architecture Behavioral of Pseudotakt is
signal clk  : std_logic := '0';
signal cntA : unsigned(3 downto 0) := x"0";
signal cntB : unsigned(3 downto 0) := x"0";
signal cntC : unsigned(3 downto 0) := x"0";
begin

   clk   <= not clk after 10 ns when run='1';
   clock <= clk;

   cntA   <= cntA+1 after 10 ns when run='1';
   countA <= std_logic_vector(cntA);
   
   process (clk) begin
      if rising_edge(clk) then
         if run='1' then
            cntB <= cntB+1 after 5 ns;
         end if;
      end if;
   end process;
   countB <= std_logic_vector(cntB);
   
   process (clk) begin
      if rising_edge(clk) then
         if run='1' then
            cntC <= cntC+1 after 15 ns;
         end if;
      end if;
   end process;
   countC <= std_logic_vector(cntC);
   
end Behavioral;

Was kommt da in der Simualtion raus?
Was bei der Synthese?
Und was käme raus, wenn diese unseligen after nicht dastehen würden?

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

Lothar Miller schrieb:
> Was kommt da in der Simulation raus?
Siehe Waveform im nächsten Beitrag...

> Was bei der Synthese?
Synplify sagt ein paar Mal:

@W: BN137 :|Found combinational loop during mapping at net cntA

XST sagt:

Xst:737 - Found 4-bit latch for signal <cntA>

Hier wird die kombinatorische Schleife durch das run versteckt... :-/
http://www.lothar-miller.de/s9y/categories/36-Kombinatorische-Schleife

> Und was käme raus, wenn diese unseligen after nicht dastehen würden?
Es kommt in der Simulation (wie auch in der Hardware) mit ISIMsofort der 
Fehler:

ERROR: at 100 ns(10000): Iteration limit 10000 is reached. Possible zero delay oscillation detected

Beim Aldec Simulator ist das etwas versteckter:

KERNEL: Delta count overflow - stopped. Try to increase the iterations limit in simulator preferences.

Aber auch hier wird nicht eine scheinbar funktionierende Schaltung 
vorgegaukelt, sondern mit einem Fehler abgebrochen.

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

Hier die vergessene Waveform zur scheinbar funktionierenden 
Simulation...