Verständnisproblem: Variablen in Prozessen

[Karl (Gast)]

Hallo,

zu untenstehenden Beispielprogramm eines Volladierers habe ich folgende 
Aussage in einem VHDL-Buch gefunden und verstehe sie nicht so ganz:

"Die Wahl einer Variablen ist ist in dieser Anwendung zwingend, da 
sofort nach der Wertzuweisung in der case-Anweisung auf den 
Variablenwert zugegriffen werden soll. Bei Verwendung eines Signals 
würde in der case-Anweisung fehlerhafterweise immer auf den im letzten 
Prozessdurchlauf zugewiesenen Signalwert zugegriffen"

Diese Aussage verstehe ich nicht. Werte werden lediglich an 
Ausgangssignale zugewiesen aber diese haben ohnehin keinen Einfluss auf 
den Durchlauf des Prozesses. Abgerfragt werden lediglich die 
Eingangssignale.  Sinn würde es evt. machen, wenn die Ausgänge auf die 
Eingänge rückwirken aber dies ist hier nicht der Fall.
Vielleicht mach ich aber auch einen Denkfehler und jemand kann mir das 
erklären?

entity VOLLADD_TAB is 
  port( CIN, AI, BI: in bit; 
        SI, COUT: out bit); 
end VOLLADD_TAB; 
 
architecture ARCH1 of VOLLADD_TAB is
begin
  P1: process(CIN, BI, AI) 
    variable TEMP_IN: bit_vector(2 downto 0); -- temporaerer Vektor 
    variable TEMP_OUT: bit_vector(1 downto 0); -- temporaerer Vektor 
    begin 
      TEMP_IN := CIN & BI & AI; 
      case TEMP_IN is 
         when "000" => TEMP_OUT := "00"; 
         when "011" => TEMP_OUT := "10"; 
         when "101" => TEMP_OUT := "10"; 
         when "110" => TEMP_OUT := "10"; 
         when "111" => TEMP_OUT := "11"; 
         when others => TEMP_OUT := "01"; 
      end case; 
      SI <= TEMP_OUT(0); -- Kopie ins Summenbit 
      COUT <= TEMP_OUT(1); -- Kopie ins Carry-Bit 
    end process P1; 
end ARCH1;

[Klaus (Gast)]

Aus meiner Sicht, hast du Recht. Die Ausgänge werden nur geschrieben und 
die Eingänge nur gelesen. Somit brauchst man die Variablen gar nicht. 
Und selbst wenn, macht es in diesem Fall keinen Unterschied, ob es ein 
Signal oder Variable ist.

[berndl (Gast)]

Mein Eindruck beim drueberfliegen: Verklag' den Autor!
Wer wegen 2-3 Zeilen weniger Code so einen Schwachsinn produziert der 
soll Baeckerei-Fachverkaeufer werden...

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

Hier liegt der unnötige Knackpunkt:

      TEMP_IN := CIN & BI & AI; 
      case TEMP_IN is ...

Wenn du hier Signale hättest, müsstest du schreiben

      TEMP_IN <= CIN & BI & AI; 
      case TEMP_IN is ...

und TEMP_IN in dei Sensitivliste aufnehmen.

Insgesamt ist das Beispiel so unnötig kompliziert an den Haaren durch 
die Brust gezogen...  :-/

BTW:
Ein "normaler" Mensch würde TEMP_IN weglassen und schreiben:

      case CIN & BI & AI is ...

Oder gleich so:

  P1: process(CIN, BI, AI) 
    begin 
      case CIN & BI & AI is 
         when "000" =>  COUT <= '0'; SI <= '0'; 
         when "011" =>  COUT <= '1'; SI <= '0'; 
         when "101" =>  COUT <= '1'; SI <= '0';  
         when "110" =>  COUT <= '1'; SI <= '0';  
         when "111" =>  COUT <= '1'; SI <= '1';  
         when others => COUT <= '0'; SI <= '1'; 
      end case; 
    end process P1;

Da sehe ich gleich, wie Carry und Sum sich verhalten.
Das scheint mir sogar noch besser lesbar ;-)

[Karl (Gast)]

OK, dann bin ich ja beruhigt.Danke für eure Antworten  :)

[berndl (Gast)]

  P1: process(CIN, BI, AI) 
    begin 
      case CIN & BI & AI is 
         when "000" =>  COUT <= '0'; SI <= '0'; 
         when "011" =>  COUT <= '1'; SI <= '0'; 
         when "101" =>  COUT <= '1'; SI <= '0';  
         when "110" =>  COUT <= '1'; SI <= '0';  
         when "111" =>  COUT <= '1'; SI <= '1';  
         when others => COUT <= '0'; SI <= '1'; 
      end case; 
    end process P1;

...und das ganze wegen der elendigen Sensitivity-List noch in ein 
concurrent-statement verpackt. Dann ist's richtig einfach und robust

[Klaus (Gast)]

Ja, ich hab auch das Gefühl, dass viel zu oft Sachen in einen Prozess 
gesteckt werden, die auch mit nem einfachen concurrent-statement 
beschrieben werden könnten.

Gibts irgendeinen Grund dafür, das zu machen? Oder ist das nur die Macht 
der Gewohnheit, alles sequenziell Formulieren zu wollen?

[Karl (Gast)]

Die andere Frage ist, ob es einen Grund dagegen gibt, wenn sich der 
Entwickler damit wohler fühlt.

Das Beispiel oben ist sicher auch ohne Variablen lösbar, aber es ist aus 
einem LEHRBUCH! Irgendwelche Beispiele muss es da auch geben. Streng 
genommen könnte man alles auch ohne Variablen lösen, aber sie sind halt 
Bestandteil der Sprache und wenn man weiß was man tut geht die Welt auch 
nicht unter.

(Ja, ich weiß das die Designrules vieler Firmen Variablen verbieten. War 
bei uns auch so.)

[Klaus (Gast)]

> Die andere Frage ist, ob es einen Grund dagegen gibt, wenn sich der
> Entwickler damit wohler fühlt.

Ja, die gibt es aus meiner Sicht. Bei concurrent hat man weniger 
Fehlerquellen. Sensitivitylist, ungewollte Latches...

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

> Bei concurrent hat man weniger ... ungewollte Latches...
Das geht auch concurrent ganz einfach  :-o
Ich habe mir angewöhnt, nach Möglichkeit Prozesse zu takten und 
Kombinatorik concurrent zu beschreiben. Wobei eine Abweichung in die 
eine oder andere Richtung nur die Regel bestätigt:

   toggle <= not toggle when rising_egde(clk); -- concurrent getaktet  ;-)

[berndl (Gast)]

toggle <= not toggle when rising_egde(clk); -- concurrent getaktet  ;-)

Das ist jetzt aber nicht wirklich dein Ernst :o)
Sowas macht man einfach nicht!
Ansonsten fullack zu den beiden obigen Posts...

[Karl (Gast)]

>Ja, die gibt es aus meiner Sicht. Bei concurrent hat man weniger
>Fehlerquellen. Sensitivitylist, ungewollte Latches...

Da warnt der Synthesizer und folglich sollte man dem dann auch 
nachgehen.

Ich finde, dass sich Logik in einem prozess meist besser lesen lässt, 
aber das ist dann wohl geschmacksache.

[berndl (Gast)]

Meine Meinung:
Krause Logik wird mit concurrent Statements beschrieben.
Getaktete Logik innerhalb eines 'process'.

Macht den Code lesbarer und klarer/verstaendlicher.

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

> Das ist jetzt aber nicht wirklich dein Ernst :o)
Oh, doch... ;-)
> Sowas macht man einfach nicht!
Synthesizer können heute einiges mehr als vor 10 Jahren, warum sollte 
man diese Möglichkeiten nicht ausnutzen?
http://www.lothar-miller.de/s9y/archives/47-wait-im-Prozess.html


Ich werde bei Gelegenheit mal ausprobieren, was aus dieser Beschreibung 
wird:

   toggle <= not toggle when rising_egde(clk) and doit='1'; -- concurrent getaktet mit enable  ;-)

So langsam sollte die Software das schon interpretieren können. Ist ja 
eigentlich klar, was da steht. Und im Prozess gehen auch alle möglichen 
enable-Beschreibungen:
http://www.lothar-miller.de/s9y/categories/6-Clock-Enable

[nixda (Gast)]

hi,

naja ab einer nennenswerten designgroesse wuerde ich micht nicht mehr 
mit einer kombinatorischen beschreibung abgeben. das ist nicht mehr 
sinnvoll debugbar. ich setzte daher lieber auf sequentielle prozesse. 
mit ein paar einfachen regeln und synthesechecks ist das auch fuer 
komplexe module zu handhaben.

rdg
/uwe