numeric_std verwenden sehe ich ein. Konkret

> Es wird allgemein empfohlen, das package numeric_std zu verwenden...
> Das wird von der Mehrheit der thematisch orientierten Seiten allerdings
> nicht gemacht.
Ganz einfach, weil die alten Synopsis-Libs in allen Lehrbüchern und 
Skripten und daraus resultierend in dem herunterladebaren Code verwendet 
werden. So werden z.B. auch heute noch beim Generieren eines Projekts 
bei Xilinx diese Libs eingebunden.

Weil (wie schon geschrieben) bei der numeric_std jede Umwandlung 
explizit geschrieben werden muß, kann es z.B. nicht passieren, dass ein 
Codeschnipsel, der aus einer Beschreibung mit IEEE.STD_LOGIC_SIGNED.ALL 
herauskopiert und in eine andere mit IEEE.STD_LOGIC_UNSIGNED.ALL 
hineinkopiert und dort ganz anders interpretiert wird.

> Das wird von der Mehrheit der thematisch orientierten Seiten allerdings
> nicht gemacht.
Aber genauso steht noch in jedem Lehrbuch die Schreibweise eines 
getakteten Prozesses mit asynchronem globalem Reset. Und das ist 
anerkanntermaßen ein für FPGAs suboptimaler Beschreibungsstil.

dito schrieb:
>> Aber genauso steht noch in jedem Lehrbuch die Schreibweise eines
>> getakteten Prozesses mit asynchronem globalem Reset. Und das ist
>> anerkanntermaßen ein für FPGAs suboptimaler Beschreibungsstil.
>
> Ja, so habe ich es auch in der Uni gelernt. Heißt das, ich könnte
> ruhigen Gewissens in meinem Design alle asynchronen resets durch einen
> synchronen globalen reset ersetzen? Wäre das tatsächlich die technisch
> bessere Lösung?

Für ein synchrones Signal kann das PAR-Tool die Laufzeiten berechnen und 
dafür sorgen, dass alle Register in demselben Takt (rück)gesetzt werden. 
Probleme gibt es, wenn das Netz zu umfangreich wird und viele Eingänge 
daran hängen. Darum gibt es in einigen FPGAs dafür spezielle 
Routing-Ressourcen (Netze)

>
> Irgendwie habe ich da Hemmungen, aber ich denke ich werd's bald mal
> machen...


> Oder sollte ich die Resets ganz rausnehmen?
Das hängt vom FPGA ab. Xilinx empfiehlt für seine FPGAs mit einer 
Signalinitialisierung zu arbeiten und rät von einem Reset ab 
(www.xilinx.com/support/documentation/white_papers/wp272.pdf).
In Actel (ProASIC3) und Lattice FPGAs (ECP2(M) und ECP-S, ECP3) wird ein 
Reset benötigt. Lattice hält dafür ein spezielle Netz vor. Mit Altera 
FPGAs kenne ich mich nicht aus.

Tom

> Ich finde asynchrone Resets praktischer als die Zuweisung bei der
> Deklaration, weil die vom restlichen Code so weit weg ist.
Die Gefahr dabei ist nur, dass dieser Reset dann irgendwann mal 
wirklich verwendet wird...
Und was dabei herauskommen kann sieht man im 
Beitrag "Hardware mit VHDL "richtig" beschreiben."

> Nur weil Unerfahrene sich damit ins Knie schiessen können,
> ist das doch kein Grund gleich alles zu verbannen :)
Ein Anfänger FPGA-Design hat genau 1 Takt und 0 Reset. Punkt.

Wenn es mehr sein muss, dann mit fundierter Begründung. Und genau 
mit/an/bei dieser Begründung lernen Unerfahrene. Und einmal fertig 
gelernt dürfen alle Tricks aus der FPGA-Trickkiste geholt werden.

Wie war nochmal die Geschichte mit dem Zauberlehrling, der die Geister 
rief...

>> Ein Anfänger FPGA-Design hat genau 1 Takt und 0 Reset. Punkt.
> Klasse Argumentation.
Das war keine Argumentation sondern ein Postulat. Ich versuche mich 
selber daran zu halten. Und es ist erstaunlich, wie oft das geht  ;-)
Das ist so ähnlich, wie z.B. auf Landstaßen die Maximalgeschwindigkeit 
auf 100 km/h festgelegt ist. Ich kenne etliche Landstraßen, die deutlich 
mehr aushalten...

Von mir aus kann jeder zehn Takte (also z.B. 2 mehr als er Taktnetze 
hat) und 36 Resets (gerne auch lokal und kombinatorisch) in seine 
Designs einbauen. Aber dann darf er sich hinterher nicht wundern warum 
das nicht zuverlässig geht.


> wenn du bei einem synchronen Reset ein Timing-Problem kriegst
Mit so einem synchronen Reset wie hier kannst du durchaus Probleme 
bekommen:

1

library IEEE;

2

use IEEE.STD_LOGIC_1164.ALL;

3

use IEEE.NUMERIC_STD.ALL;

4

5

entity SYNCRST is

6

    Port ( clk        : in  STD_LOGIC;

7

           reset      : in  STD_LOGIC;

8

           :

9

          );

10

end SYNCRST;

11

12

architecture Behavioral of SYNCRST is

13

begin

14

  P1: process (clk) begin

15

    if rising_edge(clk) then

16

      if (reset='1') then 

17

         -- tuwas

18

      else

19

         -- tuwasanderes

20

      end if;

21

    end if;

22

  end process;

23

24

  P2: process (clk) begin

25

    if rising_edge(clk) then

26

      if (reset='1') then 

27

         -- tusonstwas

28

      else

29

         -- tusonstwasanderes

30

      end if;

31

    end if;

32

  end process;

33

end Behavioral;

Hier steht in beiden Prozessen bildhübsch ein synchroner Reset. 
Allerdings wird der beim P1 und beim P2 u.U. zu unterschiedlichen Zeiten 
inaktiv werden. Und das kann durchaus zu eigenartigem Verhalten 
führen...