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?
Angehängte Dateien:
-
vhdlaufgabe.png
310 KB
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.
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.
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.
Alles klar, habs jetzt einigermaßen verstanden. Danke für die Antworten.
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.
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?
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
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.
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... ;-)
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).
dfIas schrieb: > Ein FPGA ist deshalb doch kein FDGA, oder? Das 'P' in FPGA kommt m.E, eher aus der Richtung 'programmable resistor'... Duke
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
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
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.