Wie zwei Taktsignale in einem Prozess verarbeiten?

> Sind a und b wirklich echte Clocks aus einem Oszillator oder doch nur
> irgendwelche Signale?
Es sind echte Clocks, runtergeteilt von einem 1 MHz Oszillator, die über 
zwei Tasten ein- und ausgeschaltet werden können (mit einer 
UND-Verknüpfung).

Das geht so nicht! Du musst dir immer vorstellen, dass du das auch in 
Hardware diskret aufbauen würdest. Und da hast auch kein Flipflop mit 2 
Takteingängen.

Ich würd es so lösen:

Systemtakt auf Zähler und dann zwei Stuerleitungen, die die Zählrichtung 
angeben. Wenn du das so machst, dann zählt er so lange rauf oder runter, 
wie du deine Taste gedrückt hältst.
Wenn du bei jedem Tastendruck nur ein Inkrement zählen willst, dann 
musst du dir ne Flankenerkennung für die Tasten bauen. Das geht recht 
einfach, indem du das Tastensignal durch zwei Register schiebst (die 
auch mit dem Systemtakt getaktet sind) und dann die beiden Register 
miteinander verlgeichst. (ist das eine High und das andere noch Low, 
dann hast z.B. ne steigende Flanke am Eingang)

>Mit
>>    c <= a or b;
>generierst du eine Flanke.

Ich dachte ein Wechsel von a oder b von 0 nach 1 würde eine Flanke 
generieren. ist das nicht so?

> Was sollte/würde denn deiner Meinung nach passieren,
> wenn beide Signale gleichzeitig den Zustand von 0 nach 1 wechseln?
Dann sollte c auch von 0 nach 1 wechseln.

> Normalerweise erzeugt man nicht zwei neue Takte, sondern ein
> Clock-Enable-Signal, und taktet die Logik weiterhin mit dem Takt aus dem
> Oszillator.
Es ist der gleiche Takt, nur auf 2 verschiedenen Leitungen, den ich 
getrennt über 2 Taster zuführen kann.
Hintergrund: ich möchte mit der einen Taste ein 7-Segment Display 
hochzählen und mit der anderen soll es runterzählen.

> Ich würd es so lösen:
> Systemtakt auf Zähler und dann zwei Stuerleitungen, die die Zählrichtung
> angeben. Wenn du das so machst, dann zählt er so lange rauf oder runter,
> wie du deine Taste gedrückt hältst.
Danke, das ist eine gute Idee. Das werde ich so machen!

Ach, was mir noch einfällt: meine Zähler für die 7-segment Displays (es 
sind insgesmt 4) haben Ausgänge für Über- und Unterlauf, um das 
benachbarte Display anzutriggern. Wenn ich jetzt alle Zähler 
taktsynchron laufen lasse, dann müssen diese Ausgangssignale lang genug 
sein, aber auch nicht zu kurz, sonst würde das benachbarte Display gar 
nicht, oder zu weit zählen. Kann das zu Problemen führen?

> Was willst du denn in welchem Coolrunner-CPLD machen?
Mal sehen. Erst mal ist es nur ein Spielzeug, um zu sehen, was man mit 
programmierbarer Logik alles anstellen kann.

> Hast du einen globalen Takt mit deutlich höherer Frequenz (z.B. 4MHz)
> als deine Ereignisse (z.B. 1MHz)?
Ich habe einen globalen Takt vom 1Mhz, den habe ich z.B. runtergeteilt 
um die die Displays zu multiplexen. Bei 1Mhz leuchten die LEDs zu lange 
nach. Dann hatte ich ihn nochmal runtergeteilt, für die beiden Up/Down 
Clocks für die Zähler. Eigentlich ist alles Taktgetrieben. 
Rückkopplungen und Schleifen sind doof, das habe ich schon gelernt.

> Wenn du mehrere Takte hast, hast du ein asynchrones Design.
> Dann kann ich dir nur die Daumen drücken... :-(
Ich habe mehrere Takte, aber alle sind von der 1Mhz "main"-Clock 
abgeleitet. Das ist dann wohl auch ein synchrones Design.

Übrigens, Danke für deinen Code. Leider habe ich ihn erst jetzt gesehen 
und  gestern Abend habe ich mir schon was gebaut, das prima 
funktioniert. Das sieht so aus:

1

LIBRARY ieee;

2

USE ieee.std_logic_1164.ALL;

3

USE ieee.numeric_std.ALL;

4

5

ENTITY count_10 IS

6

  PORT

7

  (

8

    up_enable : in std_logic;               -- count down input

9

    down_enable : in std_logic;              -- count up input   

10

    clk : in std_logic;                  -- system clock

11

    value : out std_logic_vector (3 downto 0);   -- output value

12

    ov : out std_logic;                   -- overflow signal

13

    uv : out std_logic                    -- underflow signal

14

  );

15

END count_10;

16

17

ARCHITECTURE synth1 OF count_10 IS

18

  BEGIN

19

20

  process (clk, up_enable, down_enable)

21

  type state_t is (idle, ovset, uvset);

22

  variable counter : unsigned(3 downto 0);

23

  variable state : state_t;

24

  begin

25

    if (rising_edge(clk)) then                  -- system clock goes high

26

      case state is

27

28

        when idle => if (up_enable = '1') then      -- count up

29

                  counter := counter + 1;

30

                  if (counter = "1010") then    -- overflow?

31

                    counter := "0000";      -- reset counter

32

                    ov <= '1';            -- set overflow signal

33

                    state := ovset;    

34

                  end if;

35

                 end if;

36

                 if (down_enable = '1') then    -- count down

37

                  counter := counter - 1;      

38

                  if (counter = "1111") then    -- underflow?

39

                    counter := "1001";      -- reset counter

40

                    uv <= '1';            -- set underflow signal

41

                    state := uvset;

42

                  end if;

43

                 end if;

44

45

        when ovset => ov <= '0';              -- reset overflow signal on next clock cycle

46

                  state := idle;

47

48

        when uvset => uv <= '0';              -- reset underflow signal on next clock cycle

49

                  state := idle;

50

      end case;

51

    end if;

52

    value <= std_logic_vector(counter);            -- send counter value to parent

53

  end process;

54

55

END synth1;

[Das Ganze sieht hier etwas zerfetzt aus. Ich hoffe ihr könnt es 
trotzdem lesen]

ov und uv sind die beiden Impulse, die das benachbarte 7-Segment Display 
ansteuern, um entweder rauf- oder runterzuzählen. Sie werden dort als 
up_enable und down_enable benutzt. Beim ersten Segment kommen up_enable 
und down_enable entweder direkt von zwei Tasten (=Zählgeschwindigkeit 
abhängig von clk), oder von einer anderen entity, die aus einem 
Tastendruck einen Einzelimpuls mach (=pro Tatendruck wird eins rauf- 
oder runtergezählt).

Das ganze funktioniert zwar prächtig, aber vielleicht habt ihr trotzdem 
ein paar Verbesserungsvorschläge für mich...?

Ach ja: großes Lob an Euch. Das Forum ist spitze!

  Peterchen

> Mein Vorschlag: Lass die Zustände ganz raus.
Danke für den Code. Das werde ich mal so probieren.

> Damit beschreibst du eigentlich einen Glitch, denn der counter muß nach
> deiner Definition erst einen ungültigen Zustand (10 oder -1) erreichen,
> bevor du was machst.
Schon, aber der Glitch kommt im Ausgangsvektor ja nicht an, weil die 
Variable erst am Ende des Prozesses rüberkopiert wird. Wäre es so, dann 
würde ich bei  geringer Taktfrequenz z.B. ein A sehen, was aber nicht 
passiert.

Ach ja: bei langsamer Tasktfrequenz ist übrigens erst eine Änderung von 
9 nach 0 sichtbar, bevor das Nachbar-Display (im nächsten Takt) 
weitergezählt wird. Das fällt bei hoher Frequenz nicht auf, ist aber 
trotzdem unschön. Gibt es dafür eine Erklärung? Eigentlich reagiert das 
Design doch auf die "Rising Edge", d.h. beide Displays müssten sich 
gleichzeitig ändern. Aber vielleicht habe ich an anderer Stelle noch 
einen Fehler drin.

> Und erst mit dem nächsten Takt kann diese Stelle den Übertrag auswerten.
Das war der entscheidende Hinweis! Vielen Dank noch mal.

Hier ist meine endgültige Version. Der Prozess braucht noch nicht mal 
eigene Signale oder Variablen:

1

LIBRARY ieee;

2

USE ieee.std_logic_1164.ALL;

3

USE ieee.numeric_std.ALL;

4

5

ENTITY count_10 IS

6

  PORT

7

  (

8

    up_enable : in std_logic;                 -- count down input

9

    down_enable : in std_logic;                -- count up input   

10

    clk : in std_logic;                    -- system clock

11

    value : buffer std_logic_vector (3 downto 0) := "0000";   -- output value

12

    ov : out std_logic;                     -- overflow signal

13

    uv : out std_logic                      -- underflow signal

14

  );

15

END count_10;

16

17

ARCHITECTURE synth1 OF count_10 IS

18

19

  BEGIN

20

21

  process 

22

  begin

23

    wait until clk = '1';

24

    uv <= '0';

25

    ov <= '0';

26

    if (up_enable = '1') then

27

      if (value = "1001") then

28

        value <= "0000";

29

        ov <= '1';

30

      else

31

        value <= std_logic_vector(unsigned(value) + 1);

32

      end if;

33

    end if;

34

    if (down_enable = '1') then

35

      if (value = "0000") then

36

        value <= "1001";

37

        uv <= '1';

38

      else

39

        value <= std_logic_vector(unsigned(value) - 1);

40

      end if;

41

    end if;

42

  end process;

43

44

END synth1;

>>  wait until clk = '1';
> Krass. Das habe ich jetzt auch noch nie gesehen :-o
> Gibt das wirklich einen getakteten Prozess?
> Formal korrekt wäre das:
> wait until rising_edge(clk);
> Das geht, so mache ich das auch..
OK, das werde ich noch abändern. Mich hats auch erstaunt daß es 
funktioniert. Eigentlich müsste er immer wieder durch den Prozess 
sausen, so lange clk auf '1' steht.

> Aber die Simulation geht schief...
Bei mir gehen Simulationen fast immer schief, weil ich z.B. vergesse, 
Signale zu initialisieren. Der CoolRunner setzt beim Starten sowieso 
alles auf 0. Aber auf den CPLD ist es ja schnell draufgeflashed. Gibt es 
eigentlich bessere Simulationstools als das im ISE WebPack?

Modelsim von mentor kann man da nur empfehlen. inner xilinx starter 
edition sogar kostenlos erhältlich. muss man sich nur bei xilinx für 
registrieren.

> Modelsim von mentor kann man da nur empfehlen. inner xilinx starter
> edition sogar kostenlos erhältlich. muss man sich nur bei xilinx für
> registrieren.

Das ist gut. Ich dachte schon, ich muß mir irgendwelche virenbehafteten 
Cracks runterladen. ;-)