Verständnisproblem: Variablen in Prozessen

Karl Gast #1506761
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?

1
entity VOLLADD_TAB is 

2
  port( CIN, AI, BI: in bit; 

3
        SI, COUT: out bit); 

4
end VOLLADD_TAB; 

5
 

6
architecture ARCH1 of VOLLADD_TAB is

7
begin

8
  P1: process(CIN, BI, AI) 

9
    variable TEMP_IN: bit_vector(2 downto 0); -- temporaerer Vektor 

10
    variable TEMP_OUT: bit_vector(1 downto 0); -- temporaerer Vektor 

11
    begin 

12
      TEMP_IN := CIN & BI & AI; 

13
      case TEMP_IN is 

14
         when "000" => TEMP_OUT := "00"; 

15
         when "011" => TEMP_OUT := "10"; 

16
         when "101" => TEMP_OUT := "10"; 

17
         when "110" => TEMP_OUT := "10"; 

18
         when "111" => TEMP_OUT := "11"; 

19
         when others => TEMP_OUT := "01"; 

20
      end case; 

21
      SI <= TEMP_OUT(0); -- Kopie ins Summenbit 

22
      COUT <= TEMP_OUT(1); -- Kopie ins Carry-Bit 

23
    end process P1; 

24
end ARCH1;
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Klaus Gast #1506793
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Lothar M. Moderator (Firma: Titel) Persönliche Seite #1506865
Lesenswert?
• ▲
▼ 
Hier liegt der unnötige Knackpunkt:
1
      TEMP_IN := CIN & BI & AI; 

2
      case TEMP_IN is ...

Wenn du hier Signale hättest, müsstest du schreiben
1
      TEMP_IN <= CIN & BI & AI; 

2
      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:
1
      case CIN & BI & AI is ...


Oder gleich so:
1
  P1: process(CIN, BI, AI) 

2
    begin 

3
      case CIN & BI & AI is 

4
         when "000" =>  COUT <= '0'; SI <= '0'; 

5
         when "011" =>  COUT <= '1'; SI <= '0'; 

6
         when "101" =>  COUT <= '1'; SI <= '0';  

7
         when "110" =>  COUT <= '1'; SI <= '0';  

8
         when "111" =>  COUT <= '1'; SI <= '1';  

9
         when others => COUT <= '0'; SI <= '1'; 

10
      end case; 

11
    end process P1;

Da sehe ich gleich, wie Carry und Sum sich verhalten.
Das scheint mir sogar noch besser lesbar ;-)
Antwort Zitieren Bearbeiten Löschen Beitrag melden
berndl Gast #1507834
Lesenswert?
• ▲
▼ 
1
  P1: process(CIN, BI, AI) 

2
    begin 

3
      case CIN & BI & AI is 

4
         when "000" =>  COUT <= '0'; SI <= '0'; 

5
         when "011" =>  COUT <= '1'; SI <= '0'; 

6
         when "101" =>  COUT <= '1'; SI <= '0';  

7
         when "110" =>  COUT <= '1'; SI <= '0';  

8
         when "111" =>  COUT <= '1'; SI <= '1';  

9
         when others => COUT <= '0'; SI <= '1'; 

10
      end case; 

11
    end process P1;

...und das ganze wegen der elendigen Sensitivity-List noch in ein 
concurrent-statement verpackt. Dann ist's richtig einfach und robust
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Klaus Gast #1507858
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?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Karl Gast #1508286
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.)
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Klaus Gast #1508395
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...
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Lothar M. Moderator (Firma: Titel) Persönliche Seite #1508486
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:
1
   toggle <= not toggle when rising_egde(clk); -- concurrent getaktet  ;-)
Antwort Zitieren Bearbeiten Löschen Beitrag melden
berndl Gast #1508631
Lesenswert?
• ▲
▼ 
1
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...
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Karl Gast #1508635
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Lothar M. Moderator (Firma: Titel) Persönliche Seite #1508771
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-im-Prozess.html


Ich werde bei Gelegenheit mal ausprobieren, was aus dieser Beschreibung 
wird:
1
   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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
nixda Gast #1508816
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 Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren