Forum: FPGA, VHDL & Co. Wie funktioniert dieses VHDL Programm?


von Dirk (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

habe hier eine Aufgabe aus einer Altklausur und bin mir nicht sicher, ob 
ich das Programm so richtig verstanden habe.

Frage 1: Ab der mit Frage 1 gekennzeichneten Programmzeile wird ein dann 
folgender Anweisungsteil mittels einer PROCESS (clk) und END PROCESS; 
Anweisung umklammert. Welchen Einfluss hat diese Klammerung bzgl. der 
Abarbeitung der umschlossenen Anweisungen?

Meine Antwort auf Frage 1: Der PROCESS ist Taktabhängig. Die Anweisungen 
innerhalb des PROCESS werden nur bei einem bestimmten Pegel 
abgearbeitet.

Frage 2: Welche Funktionalität wird mit der Anweisung in der mit Frage 2 
gekennzeichneten Programmzeile beschrieben?

Meine Antwort auf Frage 2: Es wird nur auf eine positive Taktflanke 
reagiert.


Allgemein zum Programm:

clk stellt den Pegel dar -> entweder 0 oder 1, also low oder high

d ist ein integer von 0 bis 255

up_down legt Zählrichtung fest -> 0 für negativ, 1 für positiv

qa ist ein Integer und stellt den Ausgang dar

bei ld = 0 wird nicht gezählt

bei enable = 1 und ld = 1 wird gezählt

Das Programm wird beendet wenn cnt den Wert von qa erreicht.

Hab ich das alles so richtig verstanden?

von Dussel (Gast)


Lesenswert?

Dirk schrieb:
> Frage 2: Welche Funktionalität wird mit der Anweisung in der mit Frage 2
> gekennzeichneten Programmzeile beschrieben?
>
> Meine Antwort auf Frage 2: Es wird nur auf eine positive Taktflanke
> reagiert.
Kann man so sagen.

Dirk schrieb:
> Meine Antwort auf Frage 1: Der PROCESS ist Taktabhängig. Die Anweisungen
> innerhalb des PROCESS werden nur bei einem bestimmten Pegel
> abgearbeitet.
Das ist nur teilweise richtig.
Ein Prozess ist eine Art Sammlung von Anweisungen. Die Sensitivity List, 
also das was in Klammern steht, sagt dem Simulator, dass er den Prozess 
nur ausführen soll, wenn sich clk ändert. Für die Synthese hat das aber 
keine Bedeutung. Deshalb braucht man für die Synthese nochmal die 
explizite Bedingung aus Frage 2.
Ein Prozess muss übrigens nicht getaktet sein, es gibt auch Prozesse 
ohne Takt.
Bestimmte Konstrukte funktionieren nur innerhalb oder außerhalb von 
Prozessen.

Das jetzt mal als Einstieg.

von Achim S. (Gast)


Lesenswert?

ein paar kleine Ergänzungen:

Dirk schrieb:
> bei ld = 0 wird nicht gezählt

... sondern cnt wird auf einen von außen kommenden Wert geladen

Dirk schrieb:
> Das Programm wird beendet wenn cnt den Wert von qa erreicht.

Nö. das qa <= cnt ist keine Abbruchbedingung, sondern eine Zuweisung: 
der aktuelle Wert von cnt wird auf qa ausgegeben.

Der Prozess wird im Simulator immer wieder neu ausgeführt, wenn es zu 
einer Änderung am Signal clk kommt -  so lange, bis der Simulator die 
Ausführung stoppt.

von Blechbieger (Gast)


Lesenswert?

Achim S. schrieb:
> Der Prozess wird im Simulator immer wieder neu ausgeführt, wenn es zu
> einer Änderung am Signal clk kommt -  so lange, bis der Simulator die
> Ausführung stoppt.

Und das wird passieren wenn der Schritt 255 + 1 oder 0 - 1 erreicht 
wird. Der Simulator hält sich nämlich streng an die VHDL-Spezifikation 
und erfindet im Gegensatz zum Synthesizer keinen Wrap-Around wenn er 
nicht explizit hingeschrieben wurde.

von Dirk (Gast)


Lesenswert?

Alles klar, habs jetzt einigermaßen verstanden. Danke für die Antworten.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Dirk schrieb:
> habe hier eine Aufgabe aus einer Altklausur
Das ist mal ein echt unschöner synchron-asynchron-Mischmasch. Entweder 
beschreibe ich einen Prozess getaktet, dann passiert aber vor dem Takt 
(ausser evtl. einem asynchronen Reset) nichts, oder ich beschreibe 
einen kombinatorischen Prozess, dann kommt aber kein 'event darin vor. 
Aber ich schreibe nicht vor oder nach den Takt noch eine kombinatorische 
Zuweisung.

> bin mir nicht sicher, ob ich das Programm so richtig verstanden habe.
Weil du eine VH-Description-L verwendest, ist das wegen des "D" eine 
"Beschreibung". Zum "Programmieren" würdest du ja mit einer 
VH-Programming-L arbeiten müssen. Ich erwähne das nur, weil du dir 
sicher eine blutige Nase holst, wenn du mit VHDL so "programmierst", wie 
du mit C(++) oder Java oder sonst einer prozeduralen Programmiersprache 
programmierst.

Dussel schrieb:
> Ein Prozess muss übrigens nicht getaktet sein, es gibt auch Prozesse
> ohne Takt.
Und dann heißt es: Aufpassen bei der Sensitivliste! Denn jedes Signal, 
das eine Neuberechnung des Prozesses nötig macht, muss dort hinein.

> Ein Prozess muss übrigens nicht getaktet sein, es gibt auch Prozesse
> ohne Takt.
Für den Synthesizer ist das eine einfache Rechnung: sobald ein 'event im 
Prozess auftaucht, ist ein Takt im Spiel und es werden Flipflops 
erzeugt. Das 'event kann z.B. auch im rising_edge() oder falling_edge() 
"versteckt" sein.

> Bestimmte Konstrukte funktionieren nur innerhalb oder außerhalb von
> Prozessen.
Dazu solltest du aber sagen, dass du mit "Konstrukten" keine Bauteile 
wie Flipflops, Multiplexer oder Logik meinst, sondern bestimmte 
Syntaxelemente. Eine case-Abfrage darf z.B. nur in einem Prozess 
verwendet werden. Wenn ich die selbe Logik nebenläufig ohne Prozess 
beschreiben will, dann muss ich mit with-select oder when-else arbeiten:
https://insights.sigasi.com/tech/signal-assignments-vhdl-withselect-whenelse-and-case/
Ich würde es eher so sagen: für bestimmte Konstrukte gibt es innerhalb 
von Prozessen einen anderen Syntax, als wenn sie ausserhalb von 
Prozessen nebenläufig beschreiben werden.

von Dussel (Gast)


Lesenswert?

Lothar M. schrieb:
> Dussel schrieb:
>> Ein Prozess muss übrigens nicht getaktet sein, es gibt auch Prozesse
>> ohne Takt.
> Und dann heißt es: Aufpassen bei der Sensitivliste! Denn jedes Signal,
> das eine Neuberechnung des Prozesses nötig macht, muss dort hinein.
Also praktisch all Signals. ;-)

Lothar M. schrieb:
>> Bestimmte Konstrukte funktionieren nur innerhalb oder außerhalb von
>> Prozessen.
> Dazu solltest du aber sagen, dass du mit "Konstrukten" keine Bauteile
> wie Flipflops, Multiplexer oder Logik meinst, sondern bestimmte
> Syntaxelemente.
Richtig.

Lothar M. schrieb:
> Ich würde es eher so sagen: für bestimmte Konstrukte gibt es innerhalb
> von Prozessen einen anderen Syntax, als wenn sie ausserhalb von
> Prozessen nebenläufig beschreiben werden.
Ich überlege gerade, gibt es Registrierung außerhalb von Prozessen? Also 
ein Äquivalent zu if rising_edge()? Ich habe es noch nie gebraucht, aber 
geht das?

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Dussel schrieb:
> Also praktisch all Signals. ;-)
Wenn man sich das Mitdenken sparen will, dann ja... ;-)

> Ich überlege gerade, gibt es Registrierung außerhalb von Prozessen? Also
> ein Äquivalent zu if rising_edge()? Ich habe es noch nie gebraucht, aber
> geht das?
Ich mache das gern z.B. bei Schieberegistern zum Eintakten asynchroner 
Signale:
1
   sr <= sr(1 downto 0) & eingang when rising_edge(clk);
Z.B. dort im RC-5 Empfänger:
http://www.lothar-miller.de/s9y/archives/63-RC-5-Empfaenger.html

von Dussel (Gast)


Lesenswert?

Lothar M. schrieb:
>> Ich überlege gerade, gibt es Registrierung außerhalb von Prozessen? Also
>> ein Äquivalent zu if rising_edge()? Ich habe es noch nie gebraucht, aber
>> geht das?
> Ich mache das gern z.B. bei Schieberegistern zum Eintakten asynchroner
> Signale:
Interessant, danke. Ich war unsicher, ob rising_edge außerhalb von 
Prozessen funktioniert. Mein Rechner mit dem VHDL-Zeug ist gerade aus 
und belagert.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Dussel schrieb:
> ob rising_edge außerhalb von Prozessen funktioniert.
"Funktionieren" tut das in VHDL schon immer. In der Simulation.

Ob sich das Ganze in Hardware umbiegen lässt, das sagt dir das Handbuch 
zum Synthesizer. Aber seit gut 10 Jahren bin ich keinem begegnet, der 
das nicht kann... ;-)

von dfIas (Gast)


Lesenswert?

Lothar M. schrieb:
> Weil du eine VH-Description-L verwendest, ist das wegen des "D" eine
> "Beschreibung". Zum "Programmieren" würdest du ja mit einer
> VH-Programming-L arbeiten müssen. Ich erwähne das nur, weil du dir
> sicher eine blutige Nase holst, wenn du mit VHDL so "programmierst", wie
> du mit C(++) oder Java oder sonst einer prozeduralen Programmiersprache
> programmierst.
Das sehe ich nicht so eng mit den Begriffen. Ein FPGA ist deshalb doch 
kein FDGA, oder? Der Name ist Programm, wie es so schön heißt - 
letzteres etymologisch eine Bekanntmachung. Das Sequenzielle steckt 
hingegen in den "S"-Zellen, im Gegensatz zur Kombinatorik (C-Zellen). 
Seit wir von Schematic Entry auf Texteingabe (PAL/GAL seinerzeit) 
umgestiegen sind, haben wir das immer Programmieren und nie Beschreiben 
genannt.
Eine gute Übung ist das Umsetzen der Schaltung in eine bildliche 
Darstellung mit Gattern, FFs etc., zumindest gedanklich. Kann man 
übrigens mit aktuellen IDEs auch heute noch bewerkstelligen. Oder sich 
mal eine automatische Umsetzung anseen (kleinere Schaltungen).

von Duke Scarring (Gast)


Lesenswert?

dfIas schrieb:
> Ein FPGA ist deshalb doch kein FDGA, oder?
Das 'P' in FPGA kommt m.E, eher aus der Richtung 'programmable 
resistor'...

Duke

von Fpgakuechle K. (Gast)


Lesenswert?

Duke Scarring schrieb:
> dfIas schrieb:
>> Ein FPGA ist deshalb doch kein FDGA, oder?
> Das 'P' in FPGA kommt m.E, eher aus der Richtung 'programmable
> resistor'...


Eher Programmierbare 'Gatter-schaltung'. Wobei eben nicht im 
Halbleiter-'Ofen` programmiert, sondern easy auf der Platine hier 
'Field'.

Das ist dann auch schon die grösste Gemeinsamkeit in der 
'Programmierung' zwischen FPGA und ISP (in-system programmable) 
mikrocontroller.

Man kann ja auch mit 74*** Gatter gräbern Ablaufsteuerungen 
programmieren. Da die aus Gattern aufgebaute Version der Graphik-,DMA 
und Peripheriecontroller für den späteren Commodore Amiga Homecomputer:

https://pbs.twimg.com/media/CpMsQd4UMAEtznY?format=jpg&name=large

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Das P in FPGA kommt eher historisch davon, dass etwas (wie z.B. ein 
EPROM) in einem "Programmiergerät" programmiert wurde. Und

dfIas schrieb:
> Das sehe ich nicht so eng mit den Begriffen.
Ich im Grunde auch nicht, weil ich den Unterschied kenne. Aber die 
Anfänger, die C-programmierenderweise aus der µC-Ecke oder mit C#/Java 
vom PC kommen, sollten sich an diesen Begrifflichkeiten kurz mal stoßen.

> Eine gute Übung ist das Umsetzen der Schaltung in eine bildliche
> Darstellung mit Gattern, FFs etc., zumindest gedanklich.
Ja klar. Und dann wird dieses (gedankliche) Bild mit Worten 
beschrieben (**). Und dann sieht man sich das an, was der Synthesizer 
draus gemacht hat (entweder als Schematic oder beim Ressourcenverbrauch 
im Report) und denkt drüber nach, ob das zum Bild passt, dass man sich 
selber gemacht hat.


(**) wenn ich vor einem schönen Bild oder in einer netten Landschaft 
stehe und dir in einem Brief schreibe, was ich da sehe, was mache ich 
dann?
"Programmiere" ich das, was ich sehe, in meinem Text oder "beschreibe" 
ich es?

: Bearbeitet durch Moderator
von Vancouver (Gast)


Lesenswert?

Der Mischmasch von synchronen und kombinatorischen Statements im selben 
Process-Kontext ist einer großen Schwachpunkte bei VHDL. Seit einigen 
Jahren arbeite ich (aus beruflichen Anforderungen) verstärkt mit 
SystemVerilog, und da sind die Dinge eindeutiger geregelt.

Synchrone Prozesse werden mit always_ff gekennzeichnet, z.B.
1
always_ff @(posedge clk) begin
2
...
3
end

Alles zwischen begin und end wird hier nur bei der steigenden Flanke 
von clk getriggert.
Kombinatorsche Prozesse heißen always_comb und haben implizit eine 
Sensitivitätsliste, die alle Signale enthält, die in dem Kontext 
verwendet werden.

Natürlich kann man auch in SV noch unbeabsichtigte Latches fabrizieren, 
aber für gewollte Latches gibt es die always_latch Umgebung.

Man muss diese Konstrukte nicht zwingend benutzen, aber wenn man es tut, 
dann fliegen einem solche Konstruktionen wie im Beispiel des TO gleich 
beim compilieren um die Ohren und nicht erst später, wenn man sich in 
der Simulation den Wolf sucht.

Dafür gibt es in SV andere Dinge, die einen in den Wahnsinn treiben, 
z.B. die automatische Deklaration von Signalen.

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
Noch kein Account? Hier anmelden.