Frage zu Pseudozufallsgenerator!?

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

Olli R. schrieb:

1

    if D_OUT = "00000000" then

2

        D_OUT <= "00000001" after 5 ns;

3

    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":

1

signal  D_OUT : std_logic_vector(7 downto 0)  := x"01";

2

:

3

:

4

              if reset_PZGV = '1' then

5

                 D_OUT <= "00000001";

6

              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 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":

1

library IEEE;

2

use IEEE.STD_LOGIC_1164.ALL;

3

use IEEE.NUMERIC_STD.ALL;

4

5

entity Pseudotakt is

6

    Port ( run   : in  std_logic;

7

           clock : out std_logic;

8

           countA: out std_logic_vector(3 downto 0);

9

           countB: out std_logic_vector(3 downto 0);

10

           countC: out std_logic_vector(3 downto 0)

11

          );

12

end Pseudotakt;

13

14

architecture Behavioral of Pseudotakt is

15

signal clk  : std_logic := '0';

16

signal cntA : unsigned(3 downto 0) := x"0";

17

signal cntB : unsigned(3 downto 0) := x"0";

18

signal cntC : unsigned(3 downto 0) := x"0";

19

begin

20

21

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

22

   clock <= clk;

23

24

   cntA   <= cntA+1 after 10 ns when run='1';

25

   countA <= std_logic_vector(cntA);

26

27

   process (clk) begin

28

      if rising_edge(clk) then

29

         if run='1' then

30

            cntB <= cntB+1 after 5 ns;

31

         end if;

32

      end if;

33

   end process;

34

   countB <= std_logic_vector(cntB);

35

36

   process (clk) begin

37

      if rising_edge(clk) then

38

         if run='1' then

39

            cntC <= cntC+1 after 15 ns;

40

         end if;

41

      end if;

42

   end process;

43

   countC <= std_logic_vector(cntC);

44

45

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 Miller schrieb:
> Was kommt da in der Simulation raus?
Siehe Waveform im nächsten Beitrag...

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

1

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

XST sagt:

1

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:

1

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

Beim Aldec Simulator ist das etwas versteckter:

1

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.

Hier die vergessene Waveform zur scheinbar funktionierenden 
Simulation...