[VHDL] Signal wird nicht gesetzt!

[Unnormaley (Gast)]

Hallo,

ich habe ein Riesenproblem! Ich simuliere meine VHDL-Dateien mit 
ModelSim und es wird ein Signal nicht gesetzt, obwohl es eigentlich der 
Fall sein sollte. Hier zunächst meine VHDL-Beschreibung:

library IEEE;

use IEEE.std_logic_misc.all;

use IEEE.std_logic_1164.all;



entity ctrl is

  port (

    PC_ENABLE : out std_logic;

    PC_MODE : out std_logic;

    RST : in std_logic;

    CLK : in std_logic;

    mem_req : out std_logic;

    irq_adr_switch: out std_logic_vector(1 downto 0);

    PC_bakup : out std_logic

  );

end ctrl;



architecture verhalten of ctrl is

  type state_type is (start, fetch0, fetch1, decode);

  signal state : state_type;

  signal interrupted : std_logic;

begin


  process(RST, CLK)

  begin

    if (RST = '1') then

      interrupted <= '0';

      state <= start;

    end if;

  end process;



  process(state)

  begin

    case state is

      when start =>

        mem_req <= '0';

      when fetch0 =>

        irq_adr_switch <= "00";

        PC_MODE <= '1';

        PC_ENABLE <= '1';

      when fetch1 =>

        PC_bakup <= '1';

        interrupted  <= '1';

      when decode =>
        interrupted <= '0';

      when others => null;

    end case;

  end process;

end verhalten;

Das Problem ist nun folgendes: Von außen wird ein Reset angestoßen, so 
dass RST=1 ist, dann sollte aber interrupted auf 0 gestzt werden. 
(oberer Prozess will das so) Es bleibt aber undefiniert! Das lustige: 
Die darauffolgende Zeile state <= start; wird richtig ausgeführt, hatte 
testweise mal state <= decode drin und funktioniert.
Es wird aber nocht lustiger: Lasse ich die Zeile mit interrupted in 
decode, fetch1 weg (unterer Prozess) wird interrupted dann doch wieder 
richtig gesetzt bei einem Reset.

WTF?! Bitte dringend um Hilfe!

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

Wo hast du gesehen, dass man aus 2 Prozessen auf 1 Signal treiben kann?
Nirgends?
Warum tust du es dann trotzdem?

Bei der Synthese würde dir ein "Multiple Source Signal" gemeldet werden. 
Die Simulation versucht, den Konflikt entsprechend der 
Auflösungsfunktion eines std_logic zu lösen, kommt dabei aber leider nur 
auf 'U', nicht auf 'X', was richtiger wäre...

Ein 'X' (= Konflikt) würdest du bekommen, wenn das Signal initialisiert 
würde:

signal interrupted : std_logic := '0';

[Unnormaley (Gast)]

Naja,

ich dachte eigentlich das funktioniert soweit. Wo genau ist denn das 
Problem, ich kann in verschiedenen Prozessen nicht ein und dasselbe 
Signal setzen? Unabhängig davon ob dieses Signal gleichzeitig von beiden 
Prozessen gesetzt wird bzw,. nacheinander gesetzt wird?

Danke schon mal für die Erleuchtung! ;]

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

Unnormaley schrieb:
> Wo genau ist denn das
> Problem, ich kann in verschiedenen Prozessen nicht ein und dasselbe
> Signal setzen? Unabhängig davon ob dieses Signal gleichzeitig von beiden
> Prozessen gesetzt wird bzw,. nacheinander gesetzt wird?
Ist dir klar, dass du mit VHDL Hardware beschreibst?

Was ist ein Signal? Erst mal nur eine Leitung (**). Und was passiert bei 
der Hardware, wenn du 2 Treiber auf 1 Leitung schaltest?
Richtig: ein Kurzschluss.
Und dieser Kurzschluss geht nur dann unbeschadet ab, wenn beide Signale 
den selben Pegel haben, oder einer der Pegel so schwach ist, dass er 
unbeschadet "niedergeknüppelt" werden kann.


(**) Ein Signal kann auch ein Speicherelement sein, das vereinfacht die 
Sache aber keinesfalls, denn der zu speichernde wert muss dann ja auch 
aus den anliegenden Eingangswerten "ausgeknobelt" werden.

> Danke schon mal für die Erleuchtung! ;]
Mein Tipp: lies das Buch VHDL-Synthese von Reichardt&Schwarz, und dir 
wird ein ganzer Kronleuchter aufgehen...

[Weltbester FPGA Pongo (Gast)]

Unnormaley schrieb:
> Wo genau ist denn das
>
> Problem, ich kann in verschiedenen Prozessen nicht ein und dasselbe
>
> Signal setzen?

Die Zeit! Je nachdem wann das ModelGesimmse was tut, wird der Prozess a 
oder b gewinnen, wenn es ein echter Konflikt ist. Das Ganze hängt dann, 
wie ich schon gesehen habe, auch noch von der Nutzung der Optimierungen 
beim Compilieren von ModelSim ab.

Also:

Entweder, du kannst es funktionell managen, dass die prozesse so laufen, 
dass rein timingtechnisch die signale korrekt gesetzt werden

oder

du löst die Problematik durch korrektes synthesefähiges oder 
synthesenahes VHDL auf sodass immer und zu jder Zeit immer nur eine 
einzige klare Definition für jedes Signal vorliegt.

Zum X-ten male meine These:

VHDL Programme NICHT wie C Programme ereignisgetrieben von vorne 
ansetzen (also es passiert was, was passiert wohl dann?)

sondern "von hinten", also ALLE Ausgänge abklappern und für alle 
Betriebsfälle die komplette Funktion hinterlegen.

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

Weltbester FPGA Pongo schrieb im Beitrag #2724624:
> Das Ganze hängt dann, wie ich schon gesehen habe, auch noch von der
> Nutzung der Optimierungen beim Compilieren von ModelSim ab.
Hört sich nach einer "Urban Legend" an. Kannst du da mal einen kleinen 
Dreizeiler schreiben, der so ein Problem aufzeigt?

In dem gezeigten Beispiel ist nichts, was nicht allein mit dem Lesen der 
VHDL-Dokumentation zu erklären ist. Und das trotz Konflikt (= 'X') ein 
'U' übrigbleit, das ist (eigentlich) ein Fehler in der Spezifikation. 
Das wurde vor kurzem im 
Beitrag "Re: Seriell-Parallel-Wandlung mit VHDL" angesprochen...