ich krabble die VHDL-Lernkurve und sehe mir http://www.mikrocontroller.net/articles/Drehgeber#Beispielcode_in_VHDL an, da steht: -- Abtastung und Verzoegerung der Quadratursignale process(clk) begin if rising_edge(clk) then a_in <= A; a_old <= a_in; b_in <= B; b_old <= b_in; end if; end process; wenn das sequentiell abläuft, dann ist a_old immer gleich a_in (b_in und b_old detto), was die Entprellung funktionslos macht (?) sollte es nicht heissen: process(clk) begin if rising_edge(clk) then a_old <= a_in; a_in <= A; b_old <= b_in; b_in <= B; end if; end process; -Michael
Bei Signalen wird die Zuweisung erst am Ende des Prozesses ausgeführt, somit ist die Reihenfolge egal.
> ich krabble die VHDL-Lernkurve
Offenbar kommend aus der Software-Ecke ;-)
Ein paar kleine Worte zu Andreas kompakter Zusammenfassung:
Bei Signalen gibt es im Prozess ein vorher und nachher. Vorher ist
alles rechts vom Zuweisungspfeil, nachher das Signal links davon.
Wäahrend des Prozesses behalten alle Signale den Wert von vorher. Am
Ende des Prozesses (oder beim nächsten wait) werden die berechneten
Werte zugewiesen.
Sieh dir diesen Code an:
1 | process(clk) |
2 | begin
|
3 | if rising_edge(clk) then |
4 | -- nachher | vorher
|
5 | a_in <= B and A; |
6 | b_in <= B or A; |
7 | a_old <= a_in; |
8 | b_old <= b_in; |
9 | b_in <= B; |
10 | a_in <= A; |
11 | end if; |
12 | end process; --- erst hier erfolgt die Zuweisung |
Auch mit diesem Code wird die Entprellung problemlos funktionieren, weil a_in und b_in immer nur den Wert von A und B zugewiesen wird. BTW: Mit Variablen hättest du dein erwartetes sequentielles Verhalten. Aber vor du dich jetzt vor Freude überschlägst: du wirst diverse unschöne andere Probleme bekommen :-(
Vielleicht sollte man sich mal von der abstrakten Prozessebene lösen und einfach mal darlegen, dass "vorher" vor dem FF bedeutet und "nachher" hinter dem FF, also ein neues Signal.
> dass "vorher" vor dem FF bedeutet und "nachher" hinter dem FF
Richtig, ein
1 | if rising_edge(clk) then |
beschreibt ein D-Flipflop, und die ganzen Zuweisungen "vorher" beschreiben irgendwelche Logik und/oder Verdrahtung am FF-Eingang. "Nachher" ist ganz einfach der FF-Ausgang. Etwas schwieriger wirds dann schon bei einem kombinatorischen Prozess:
1 | process(A,B) |
2 | begin
|
3 | -- nachher | vorher
|
4 | a_in <= B and A; |
5 | b_in <= B or A; |
6 | b_in <= B; |
7 | a_in <= A; |
8 | end process; --- erst hier erfolgt die Zuweisung |
hier ist b_in = B und a_in = A. Allerdings ist dieses Beispiel ziemlich witzlos, weil keinerlei Verzögerung oder Speicherung modelliert wird. Dieser Prozess ist gleichbedeutend mit diesen Concurrent-Zuweisungen:
1 | b_in <= B; |
2 | a_in <= A; |
> Vielleicht sollte man sich mal von der abstrakten Prozessebene lösen Ich denke schon ganz automatisch "in Hardware", und deshalb war mir schon beim Schreiben klar, war "vorher" und "nachher" ist. Aber du hast recht, die VHDL als Sprache für die Hardwaresynthese verleitet zu abstrakten Ansichten. In der FPGA-Hardware gibt es (vereinfacht) nur Flipflops und LUTs (Logik). Und nur das kann aus einer VHDL-Beschreibung synthetisiert werden.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.