mikrocontroller.net

Forum: FPGA, VHDL & Co. Verständnisproblem: Variablen in Prozessen


Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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;  

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: berndl (Gast)
Datum:

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

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Karl (Gast)
Datum:

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

Autor: berndl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
  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

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.)

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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...

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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  ;-)

Autor: berndl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: berndl (Gast)
Datum:

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

Macht den Code lesbarer und klarer/verstaendlicher.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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-i...


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

Autor: nixda (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.