Hallo Leute :) Ich bin gerade dabei, mir anhand von Büchern die Programmiersprache VHDL etwas näher zu bringen, jedoch gibt es ein Thema, welches mich zum grübeln bringt. Wahrscheinlich sollte ich mich zu Grund und Boden schämen, wenn ich die Antwort höre aber ich habe bis jetzt keine plausible Erklärung gefunden und hoffe, dass ihr mir weiter helfen könnt. Also soweit ich mitbekommen habe, sollte man bei der kombinatorischer Logik unvollständige IF-Anweisungen vermeiden, sprich alle Möglichkeiten abdecken, da sonst Latches entstehen können. Meine Frage wäre jetzt, ob diese "Regel" genauso für eine sequentielle Logik gilt und ob falls nein, warum? Liebe Grüße Johannes
Du solltest Dich deswegen in Grund und Boden schämen, weil Du VHDL als Programmiersprache bezeichnet hast :-) Aber das nur am Rande. Ein if-statement kannst Du nur innerhalb eines Prozesses verwenden, und damit ist es immer sequenzielle Logik. Also gilt die Regel nur für sequenzielle Logik. Ein unvollständiges if-statement sagt z.B. aus, welchen Wert ein Signal A annehmen soll, wenn Bedingung B erfüllt ist. Es sagt nichts darüber aus, was geschehen soll, wenn B nicht erfüllt ist. Daher muss der Wert von A erhalten bleiben, und genau dzu brauchst Du einen Speicher in Form eines Latches.
Was in der Kombinatorik ein asynchrones Latch ist, ist in einer getakteten Schaltung ein getaktetes Flipflop. Weil sich dort der Ausgang nur mit dem Takt ändert, verletzt du die Setup- und Hold-Zeiten nicht unkontrolliert wie bei Latches und hast daher kein Problem.
Ein Latch übernimmt das Eingangssignal sofort an seinem Ausgang, wenn der Schaltpegel stimmt. Ein FlipFlop übernimmt den Wert zum Zeitpunkt einer Taktflanke. Vermeiden kann man sowas natürlich, wenn du folgendes machst:
1 | if (en = '1') then |
2 | a <= b; |
3 | else
|
4 | a <= (others => '0'); |
5 | end if; |
In sequentieller Logik hast du diese Problem nicht, da die direkt ein FlipFlop erzeugt wird:
1 | if rising_edge(clk) then |
2 | if (en = '1') then |
3 | a <= b; |
4 | end if; |
5 | end if; |
Vancouver schrieb: > Du solltest Dich deswegen in Grund und Boden schämen, weil Du VHDL als > Programmiersprache bezeichnet hast :-) Aber das nur am Rande. Immer die gleiche Leier und immer wieder die falsche Vorstellung, daß das Wort "Programmierung" nicht stimmt, weil Hardware im Spiel ist. Wikipedia lesen! VHDL ist AUCH eine Programmiersprache und besonders, wenn es um state machines geht. Da wird eben nicht Struktur beschrieben, sondern Ablauf festgelegt, also Software gemacht. Die Struktur dahinter baut der Synthesizer und zwar so, wie er will. S. R. schrieb: > Was in der Kombinatorik ein asynchrones Latch ist, ist in einer > getakteten Schaltung ein getaktetes Flipflop. Weswegen man bei dem Begriff auch aufpassen sollte, immer von "asynchronen Latches" zu sprechen. Die synchronen nämlich, gibt es in jedem VHDL-Programm, z.B. bei der Zuweisung i.A des Taktes. Übrigens ist das Ganze ein FPGA-Problem und zwar konkret der Synthesesoftware. ASIC-Compiler haben da keine Probleme. Sie vervollständigen die Pfade sinngemäß. Etwas, was man in VHDL ausdrücklich als "ELSE" hinschreiben sollte.
Johannes H. schrieb: > Meine Frage wäre jetzt, ob diese "Regel" genauso für eine sequentielle > Logik gilt und ob falls nein, warum? Was ist "sequentielle Logik"? Ich kenne nur "sequentielle" oder "concurrent" Anweisungen. Die Regel "keine Latches" gilt für das Design. Und ist deshalb unabhängig von der Beschreibungssprache oder Beschreibungsdetails (nebenläufig oder im Prozess). Ein Latch entsteht, wenn etwas ohne Takt gespeichert werden muss. Natürlich gibt also das hier abhängig von der vektorbreite ganz ohne Prozess auch ein oder viele Latches: A <= E when X='1'; Weltbester FPGA-Pongo schrieb im Beitrag #4817420: > VHDL ist AUCH eine Programmiersprache Und heißt natürlich deshalb ab heute auch VHPL... Aber zu der Diskussion möchte ich auf den alten Beitrag "eBay-Board in VHDL Programmieren" hinweisen. Die Quintessenz daraus: wer (als Anfänger) in VHDL "programmiert" wie er auch Mikrocontroller "programmiert", der fällt auf die Nase.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Und heißt natürlich deshalb ab heute auch VHPL... VHDL kommt aus einer anderen Zeit und Begriffe sind Schall und Rauch, weil sie oft ohne Weitsicht geprägt werden. Zudem sind es oft Studenten und NERDs ohne erweiterte kommunikative Fähigkeiten, die Begriffe festlegen, denen Rhetorik ein Fremdwort ist. Wer möchte sich daran aufhängen? Ich zitiere aus dem thread: PittyJ schrieb: > Steht nicht das P in FPGA für Programmable? > http://de.wikipedia.org/wiki/Field_Programmable_Gate_Array > Also wird ein FPGA letztendlich programmiert.
Weltbester FPGA-Pongo schrieb im Beitrag #4817420: > VHDL ist AUCH eine Programmiersprache und besonders, wenn es um state > machines geht. Da wird eben nicht Struktur beschrieben, sondern Ablauf > festgelegt, also Software gemacht. Die Struktur dahinter baut der > Synthesizer und zwar so, wie er will. Der Zweck von VHDL ist die Spezifikation einer Hardware. Diese kannst Du strukturell oder algorithmisch beschreiben, das spielt im Endeffekt keine Rolle, solange eine korrekte Architektur dabei herauskommt. Ich will es mal so formulieren: Ein Softwareprogramm bedeutet "führe folgendes aus". Eine VHDL-Beschreibung bedeutet "erzeuge folgende Struktur" (strukturell) oder "erzeuge eine Struktur, die folgendes tut" (algorithmisch). VHDL-Code wird nirgendwo ausgeführt (außer im Simulator, und das auch nur mit massiven Einschränkungen) und es ist daher kein Programm. Wenn Du unbedingt willst, kannst Du bestenfalls Testbenchcode als Programm auffassen. Genauswenig wird C zu einer Hardwarebeschreibungssprache, nur weil sie das Verhalten der Prozessorhardware zur Laufzeit beschreibt. Unterschied klar geworden? Ansonsten gibt es weiterführende Literatur als Wikipedia, die das detaillierter erläutert.
Vancouver schrieb: > VHDL-Code wird nirgendwo ausgeführt (außer im Simulator, und das auch > nur mit massiven Einschränkungen) und es ist daher kein Programm. Das war nicht die Aussage, wobei Du aber selber etwas richtiges sagst: In der Simulation ist VHDL ein Programm. Aber auch im FPGA ist VHDL ein Programm, da es auswechselbar (Soft!) definiert, was die Hardware tut. Damit wird der FPGA programmiert. Lädt man ein anderes Programm, ist eine andere Software drin.
das Dumme am Vergleich mit einer Programmiersprache ist: viele denken dabei automatisch an eine imperative Programmiersprache wie C. Und weil in C z.B. eine for Schleife zu einem sequentiellen Abarbeiten des Schleifeninhalts führt, und weil in VHDL ebenfalls for-Schleifen existieren liegt der Trugschluss nahe, dass das in VHDL so sei wie in C (obwohl es tatsächlich etwas ganz anderes bedeutet). Um diese häufig auftretende Missinterpretation zu vermeiden ist es schon sehr sinnvoll darauf hinzuweisen, dass Hardwarebeschreibung in VHDL etwas ganz anderes ist als Programmieren in C. (Auch wenn man meinetwegen beides Programmieren nennen darf ;-)
Vancouver schrieb: > VHDL-Code wird nirgendwo ausgeführt (außer im Simulator, Oha, aber sicher wird der ausgeführt, nämlich in der Synthese-Software. Und da wird der sogar minutiös ausgeführt, sogar unter Beachtung der Befehlsreihenfolgen im Code - siehe Defaults. Das ist doch gerade der Knackpunkt, warum z.B. ein LOOP nicht zu einem Zeitverhalten im Zielsystem, sondern mitunter zu einer flächigen Hardware führt: Die Synthese-Software führt den programmierten Verlauf aus, was dazu führt, dass mehrere Schritte getan werden. Nur der Ausgang ist offen: Bei der Ausführung von Zwischenrechnungen kommt dann durch dieses Zeitverhalten ein einziges verwertbares festes Ergebnis raus. Bei der Ausführung von Erzeugungskonstrukten kommt ein strukturelles Ergebnis in der HW-Beschreibung raus, diesmal aber was n-dimensionales. > Wikipedia Ich bin gewählter Editor in der Wiki mit Sperr- und Sichtungsrechten und wir haben das Thema "Programmierung von FPGAs" ausführlich erörtert. So, wie es hauptsächlich von mir eingetragen wurde (und auch momentan drin steht), ist es der "widely agreed" Konsens! Tenor in der Kurzfassung: ************************************************************** - VHDL ist formell eine "Beschreibungssprache" - "Beschrieben" wird eine Struktur und / der ein Ablauf oder die Funktion einer Struktur - Eine solche Beschreibung ist - wie jeder Ablauf - eine -> Software! Ergo ist auch das VHDL und eine reine Schaltungsstruktur eine Software, so wie es ein Schaltplan als PDF oder als *.SCH ist. - Ein Schaltplan auf Papier ist eine Hardware, da Papier eine Hardware ist. Ein Schaltplan ist zudem eine explizite Hardwarebeschreibung und implizite Funktionsbeschreibung. - Die spätere reale Schaltung ist eine Hardware. Die Funktion der Schaltung eine Software. - Der Begriff "Programmieren" ist NICHT auf Abläufe begrenzt! Ein Programm ist auch eine vollkommen zeitfreie "Strukturvorschrift". - Der Begriff "Programmieren" ist auch nicht auf Hardware wie MCUs reduziert. Auch eine Software kann programmiert werden, wenn sie programmierbar ist, z.B. durch Scripte. Die Xilinx-Software ist eine solche programmierbare Software. - "Programmiert" wird der FPGA! Diesen kann man direkt durch den download "programmieren" oder dessen Funktion indirekt durch die Vorschriften in der Synthesesoftware. Programmiert werden ferner alle Abläufe in z.B. FSMs. - Den Begriff "VHDL-Programmierung" gibt es nicht, da man Sprachen nicht programmieren kann. Als kleinen Einschub von mir, gibt es daher auch den Begriff "VHPL" nicht, es sei denn, es sei es wäre eine neue Form von VHDL oder Verilog, mit der man HW sehr "schnell" oder "hoch" beschreiben könnte. Python ist gfs so eine "VHPL". (?) - Es gibt nur die "VHDL-Entwicklung" oder die "VHDL-Erstellung", welche eine Softwaretätigkeit darstellt, auch wenn sie sich auf Hardware bezieht. - Der Begriff "FPGA-Entwickler" ist misverständlich, da nur Altera und Xilinx FPGAs entwicklen. Ein sinnvoller Begriff ist der "Schaltungsentwickler mit FPGAs", was wiederum eindeutig der Harwareentwicklung zuzuordnen ist. ****************************************************************** Wer aufgepasst hat, kann hier vier Sachen lernen: 1. Es ist unter mehrerlei Sichtweisen sinnvoll und zulässig von "FPGA-Programmierung" zu sprechen. 2. Die beiden Thesen "FPGA wird programmiert" und "VHDL = Beschreibungssprache" sind KEIN Widerspruch, sondern beides richtige und sinnvolle Bezeichnungen. 3. Die Bezeichnung "Programmierung" ist NICHT direkt an die Thematik Software oder Hardware gekoppelt. Sie ist nicht einmal an den Ablauf gekoppelt - sie z.B. den Begriff "Parteiprogramm". Es kann vollkommen statisch sein, wie z.B. das PP der SPD :D 4. Die beiden Tätigkeiten "FPGA-Entwicklung" und "VHDL-Entwicklung" sind zwei verschiedene Dinge. Sie treten gepaart auf und sind begrifflich nicht gegeneinander auszutauschen.
:
Bearbeitet durch User
Achim S. schrieb: > Um diese häufig auftretende Missinterpretation zu vermeiden ist es schon > sehr sinnvoll darauf hinzuweisen, dass Hardwarebeschreibung in VHDL > etwas ganz anderes ist als Programmieren in C. Auch in C kann ich Hardware beschreiben, dass ist nicht der Unterschied. Der Unterschied ist, WO die Beschreibung ausgeführt wird. Beim FPGA ist es die Synthesesoftware. Ob das mit VHDL oder mit System-C passiert, ist genau genommen, egal. Wer da jetzt immer noch ein Verständnisproblem haben sollte: Auch ein Mikrocontroller und eine SPS sind Hardwarestücke, die durch Softwarestücke programmiert werden und ihre Funktion mit dieser Software ändern. Genau das passiert beim FPGA auch. Dass hier das "Reinprogrammierte" zufällig eine Schaltungsbeschreibung ist und gfs einer Elektronik ähnelt, ändert rein gar nichts an der systemtheoretischen Einstufung des Vorgangs und der Sinnhaftigkeit des Begriffes. Der entscheidende Punkt hier ist, dass man erkennt, dass die ->Hardware, die man "beschreibt", nicht etwa der FPGA oder der ASIC ist, sondern die zu erzeugende virtuelle Schaltung darin! Das durch VHDL "Beschriebene" ist als z.B. ein RAM-Controller, oder was auch immer. Das ganze Gehoppel, das hier und in anderen Foren immer wieder veranstaltet wird, entsteht mithin dadurch, dass manche bestimmte Begriffe nicht auseinanderhalten können. Wir merken uns also: Die Hardware "FPGA" wird durch die Software "BIT-file" aus der Hardware "Flash" programmiert, welche zuvor von einer Software "Synthese+XST" erzeugt wurde, die ihrerseits durch einen Programmierer (Mensch) mittels Erstellung einer Software (VHDL und TCL) "programmiert" wurde. > Ansonsten gibt es weiterführende Literatur > als Wikipedia, die das detaillierter erläutert. Ich war bereits mehrfach bei der Erstellung solcher "weiterführender Literatur" beteiligt und da steht nirgendwo was Anderes :-)
Ich danke jedem für die hilfreichen Antworten :) eine Frage hätte ich noch und zwar gibt es einen großen Unterscheid zwischen selektiven Zuweisung und der Case-Anweisung? Mir kommt es so vor als ob Sie eigentlich die selbe Funktion haben..
Weltbester FPGA-Pongo schrieb im Beitrag #4817420: > Übrigens ist das Ganze ein FPGA-Problem und zwar konkret der > Synthesesoftware. ASIC-Compiler haben da keine Probleme. Sie > vervollständigen die Pfade sinngemäß. nope, zumindest die zwei welche ich kenne Synopsys+Cadence teuer compiler machen auch da ein "latch":
1 | if (en = '1') then |
2 | a <= b; |
3 | end if; |
Denn dort steht: behalte den Wert von A bei solange "en" nicht '1' ist. Das geht nur mit einem Speicherelement zu erfüllen.
Johannes H. schrieb: > eine Frage hätte ich noch und zwar gibt es einen großen Unterscheid > zwischen selektiven Zuweisung und der Case-Anweisung? Größe ist relativ. Das eine geht nur außerhalb vom Prozess, das andere nur innerhalb... Duke
Jürgen S. schrieb: > Das durch VHDL "Beschriebene" ist als z.B. ein RAM-Controller, oder was > auch immer. Diesem Satz fehlen doch ein paar Worte, oder? > Wir merken uns also: ... Dass ich mit dem exakt selben Code (= Beschreibung bzw. Programm) entweder ein FPGA programmieren oder ein ASIC beschreiben könnte... > Ich war bereits mehrfach bei der Erstellung solcher "weiterführender > Literatur" beteiligt und da steht nirgendwo was Anderes :-) Dann werde ich in Zukunft versuchen, öfter mal ein FPGA zu "programmieren", auch wenn das sicher einige Anfänger hübsch aus der Kurve wirft, wenn ich sie nicht mehr explizit auf den Unterschied zwischen C und VHDL hinweisen kann. BTW: Welcher Schritt ist eigentlich gemeint, wenn mich einer fragt, ob ich den uC schon "programmiert" habe? Das Coden, das Compilieren oder das Flashen? Johannes H. schrieb: > Mir kommt es so vor als ob Sie eigentlich die selbe Funktion haben.. Das ist richtig. In VHDL gibt es für fast jedes sequentielle Statement einen passenden nebenläufigen Ausdruck. Fast könnte man meinen, das sei bei der Sprachdefinition irgendwie schief gegangen. Aber dafür gibt's sicher einen Grund...
:
Bearbeitet durch Moderator
Jürgen S. schrieb: > - "Programmiert" wird der FPGA! Diesen kann man direkt durch den > download "programmieren" Allerdings sprechen alle Hersteller, die es angeht, von der "Konfigurierung" des FPGAs aus einem "Config-Flash". Insofern wäre die Wortwahl FCGA (Field Configurable Gate Array) "richtiger" gewesen. Jürgen S. schrieb: > Auch ein Mikrocontroller und eine SPS sind Hardwarestücke, die durch > Softwarestücke programmiert werden und ihre Funktion mit dieser Software > ändern. Genau das passiert beim FPGA auch. Dass hier das > "Reinprogrammierte" zufällig eine Schaltungsbeschreibung ist und gfs > einer Elektronik ähnelt, ändert rein gar nichts an der > systemtheoretischen Einstufung des Vorgangs und der Sinnhaftigkeit des > Begriffes. Ich hatte zu Anfang der Computertechnik als die ersten Textverarbeitungsprogramme für Windows 3.11 auf den Markt kamen und auch Hubers Liesel(*) mit Computern zu tun bekam ein diesbezügliches Schlüsselerlebnis. Besagte Hubers Liesel meinte nämlich mal zu später Stunde, sie würde jetzt auch "den Computer programmieren". Da hats mir das Auge weggehauen und ich musste mal genauer nachfragen. Nach relativ kurzer Zeit kamen wir darauf, dass sie ihre Texte jetzt statt auf der Gabriele in "das Word-Programm einprogrammieren" würde. Ich lachte damals innerlich, aber heute muss ich sagen: die Frau hatte es schon damals drauf... (*)Name anonymisiert
:
Bearbeitet durch Moderator
Im Grunde gibt es schon Probleme, wenn du Kombinatorische schleifen erzeugst, also der Asynchrone Output in irgendeiner Form im Input(if case) wieder auftaucht. Das muss nicht unbedingt ein Latch geben, sondern kann auch wild oszillieren. Ich weiss auch nicht ob da ein jedes Synthese Programm einen davor warnt. (Fehlende Klause sind wohl einfacher zu detektieren).
Jürgen S. schrieb: > - Eine solche Beschreibung ist - wie jeder Ablauf - eine -> Software! Software ist nicht notwendigerweise ein Programm. Die Wav-Dateien auf einer Audio-CD sind auch Software, aber kein Programm, und die Musiker im Studio würden sich etwas wundern, wenn ich ihnen erkläre, dass sie meinen CD-Player programmieren. > - Ein Schaltplan auf Papier ist eine Hardware, da Papier eine Hardware > ist. Nur weil man einen Schaltplan anfassen kann, ist er keine Hardware im üblichen Sinn. Wir sollten die Begriffe Hardware und Software hier im Kontext der Informatik/Informatinsverarbeitung verwenden. Außerhalb sind diese Dinge gar nicht richtig definiert. > Ein Schaltplan ist zudem eine explizite Hardwarebeschreibung und > implizite Funktionsbeschreibung. Das klingt schon vernünftiger. Wobei die Hardwarebescheibung nicht so explizit sein muss. Du kannst irgendwelche Gatterschaltungen aufmalen, die später in der Zieltechnologie nicht auftreten, weil z.B. eine LUT verwendet wird. > - Der Begriff "Programmieren" ist NICHT auf Abläufe begrenzt! Ein > Programm ist auch eine vollkommen zeitfreie "Strukturvorschrift". Nein. Ein Programm ist eine Vorschrift zur Transformation von Speicherzuständen in andere Speicherzustände. Sie ist "zeitfrei" im den Sinne, dass sie keine Aussagen darüber macht, wie schnell diese Transformation stattfindet, aber die beschreibt sehr wohl eine Reihenfolge der Transformationen. Bestes Beispiel: Ein Turing-Programm. Eine Schaltungsbeschreibung tut das nicht, sie ist vollkommen statisch. Sie beschreibt nur eine Struktur, die auf der Zieltechnologie realisiert wird. Sie beschreibt weder eine Reihenfolge noch ein Zeitverhalten. Eine Struktur hat nichts von dem, sie ist einfach da. Was ein Zeitverhalten und eine Reihenfolge hat, sind die Zustandsänderungen, die auf der Struktur im Betrieb stattinden. Du kannst auch eine Struktur in VHDL beschreiben, Dir mit einer Synthesesoftware eine Gatelevel-Netzliste erzeugen lassen und diese dann mit TTL-Bausteinen auf einem Steckbrett aufbauen. Ab der Gatelevel-Netzliste hast Du keine Verhaltensbeschreibung mehr, keinen Algorithmus, keine Schleifen und keine Abfolgen vor irgendwas, nur noch eine statische Struktur. Vor irgend einer Uni gibt es eine Software zur Verkehrsplanung. Du kannst dort eingeben, dass Du z.B. zwei Städte verbinden wilst, wenn jeden Tag x Menschen von A nach B und zurück wollen, und davon y % die Bahn nutzen und der Rest das Auto, sowie eine ganze Reihe anderer Bedingungen. Die Software berechnet dann ein Modell für eine Verbindung bestehend aus Schienen, Straßen, Brücken, Ampeln, Kreuzungen, Vekehrsleitsystemen. Die Software spuckt aber nur ein Modell der Verbindungsstruktur aus. Die steuert keine Autos darüber und schaltet keine Ampeln und Weichen. Auch wenn Du mit einer algorithmischen Beschreibung angefangen hast (x leute fahren morgens um 8:00 mit der Bahn nach B und um 18:00 zurück), so taucht dieser Algorithmus in der erzeugten Verkehrstruktur nirgendwo auf. Und häng Dich bitte nicht Konfigurierbarkeit von FPGA auf. Ein konfigurierter FPGA verhält sich wie ein ASIC, die Struktur ist vollkommen statisch (bzw wenn Sie es nicht ist, hast Du ein Problem). Der Vorgang der Zustandsänderung im Augenblick der Konfiguration ist zwar zeitgebunden, spiegelt sich aber an keiner Stelle in Deinem VHDL-Code wieder. Der VHDL- Code bescheibt nur das angestrebte Endergebnis. Auch wenn dieser Code im Simulator oder in der Synthese einmal interpretiert wird, auf der Ziel- architektur wird er es nicht, ganz im Gegensatz zu einem Softwareprogramm. > - Der Begriff "Programmieren" ist auch nicht auf Hardware wie MCUs > reduziert. Auch eine Software kann programmiert werden, wenn sie > programmierbar ist, z.B. durch Scripte. Die Xilinx-Software ist eine > solche programmierbare Software. Da herrscht eine gewisse Verwirrung, weil man umgangssprachlich mit Programmieren das Erstellen der Verhaltenbeschreibung ebenso meint wie das "Draufladen" der Verhaltensbeschreibung/Strukturinformation auf die Zielplattform. > > Wer aufgepasst hat, kann hier vier Sachen lernen: > > 1. Es ist unter mehrerlei Sichtweisen sinnvoll und zulässig von > "FPGA-Programmierung" zu sprechen. Ich habe in den letzten Jahren vor allem das gelernt: Es ist zwar allgemeiner Konsens, von "FPGA-Pogrammierung" zu sprechen, aber es dauert jedesmal einige Wochen, um meinen Studenten den Unterschied zwischen einem Softwareprogramm und einer strukturellen Beschreibung klarzumachen. In dem Moment, wo sie es verstanden haben, produzieren sie funktionsfähige FPGA-Designs. Schon aus diesem Grunde widerspreche ich Punkt 1.
@Jürgen S.: Kann es sein, dass du dir widersprichst? > Ergo ist auch das VHDL und eine reine Schaltungsstruktur eine Software, > so wie es ein Schaltplan als PDF oder als *.SCH ist. vs. > - Ein Schaltplan auf Papier ist eine Hardware, da Papier eine Hardware > ist. Das Speichermedium bestimmt nicht, ob etwas Hard- oder Software ist. Wenn ich ein Programm ausdrucke wird es nicht zu Hardware. Wenn ich eine aufgebaute Schaltung fotografiere und einscanne wird daraus keine Software. > - Die spätere reale Schaltung ist eine Hardware. Die Funktion der > Schaltung eine Software. Wenn du eine Schaltung lötest, sprichst du dann auch von programmieren? Funktion ist Funktion, und nicht Hard- oder Software. Die Funktion resultiert aus der Hard- oder Software (oder manchmal auch nicht :-) ), kann aber nicht mit dieser gleichgesetzt werden.
Vancouver schrieb: > Nein. Ein Programm ist eine Vorschrift zur Transformation von > Speicherzuständen in andere Speicherzustände. Wo hast du das denn her? Das stimmt schon innerhalb der Informatik so nicht. Ausserdem ist es ohnedies eine Verengung der Sichtweise, weil die Informatiker den Begriff gekapert haben. Als Programm wird meisten alles bezeichnet, was z.B: dazu dient die Funktion festzuelegen. Besonders auch im Ausland, in meinem Fall in Frankreich und in den USA werden FPGAs immer "programmiert". Daher heissen sie ja "programmierbare Logik". Michael K. schrieb: > Funktion ist Funktion, und nicht Hard- oder Software. Die Funktion > resultiert aus der Hard- oder Software Eine Funktion ist etwas Weiches und somit nach allgemeiner Auffassung Software. Wenigstens dann, wenn Du die Welt in diese beiden Teile aufteilen willst. Sonst bräuchtest Du eine dritte Gruppe von Objekten. Die Aufteilung nur in 2 Gruppen ist natürlich eine Grobe und Ungenaue.
Jetzt mal zu den Latches: Ich hatte den Fall auch schon, als es darum ging ein, UART-Interface zu programmieren. Der Compiler meckerte wegen eben dieser Latches. Mir ist noch nicht klar, warum er da selbständig ein Register implementiert, obwohl das nicht beschrieben ist. Wenn ein Pfad nicht definiert ist, dann muss er da doch auch nichts tun, nach meiner Vorstellung. Sind z.B. hier auch Latches im Spiel - trotz ELSE Zweig? Beitrag "Re: Multiplizierer für zwei 3 Bit-Zahlen"
:
Bearbeitet durch User
Martin K. schrieb: > Sind z.B. hier auch Latches im Spiel - trotz ELSE Zweig? Nein, weil z1 mit x*y vorbelegt wird. Trotzdem gilt natürlich, dass in der dortigen Sensitivliste das Signal z1 fehlt und deshalb die Simulation falsch ist. Das ist dort aber dem offenbar unzureichenden Wissen zum Thema "Signale und Variablen" geschuldet. Martin K. schrieb: > als es darum ging ein, UART-Interface zu programmieren. Ich tu mich da noch ein wenig schwer... :-/ Mir kam bei diesem Satz zuerst ein uC mit seiner seriellen Schnitte und dem zugehörigen Registersatz in den Sinn. Mit ein wenig Mühe gelang es mir dann, mir zu vergegenwärtigen, dass es offenbar nicht um ein Programm zur Verwendung der Schnittstelle geht, sondern dass das Programm die Schnittstelle selber ist...
:
Bearbeitet durch Moderator
Martin K. schrieb: > Wo hast du das denn her? Das stimmt schon innerhalb der Informatik so > nicht. Das ist die formale Defintion eines Programmes aus der Berechenbarkeitstheorie. Jeder Schritt eines Programmes überführt einen Vektor aus dem Zustandsraum in einen anderen Vektor ebenfalls aus dem Zustandsraum. Das ist das was jeder Prozessor macht: Er transformiert Speicherinhalte nach einer festgelegten Vorschrift. Er kann garnichts anderes. > Ausserdem ist es ohnedies eine Verengung der Sichtweise, weil die > Informatiker den Begriff gekapert haben. Die Informatiker haben sich nicht für alles ein neues Wort einfallen lassen. Wenn Du Dich daran störst, dann nenne es "App", aber da bekomme ich immer Anfälle von Fremdschämen. > Frankreich und in den USA werden FPGAs immer "programmiert". Daher > heissen sie ja "programmierbare Logik". Ich sage im täglichen Sprachgebrauch auch, dass ein FPGA programmiert wird, weil es bequem ist und alle es so sagen. Das bedeutet nicht, dass der Sourecode eines FPGA als Programm im Sinne der obigen Definition gesehen werden kann. Spätestens wenn man sich mit Hardwarebeschreibungssprachen beschäftigt, muss man sich den Unterschied bewusst machen, sonst macht man unweigerlich Fehler. > > Michael K. schrieb: >> Funktion ist Funktion, und nicht Hard- oder Software. Die Funktion >> resultiert aus der Hard- oder Software Exakt. Eine Funktion ist eine Verhaltensvorschrift, die Eingangsdaten und Ausgangdaten (und manchmal auch die Zeit) zueinander in Beziehung setzt. Das hat mit HW oder SW erstmal garnichts zu tun.
Reden wir eigentlich noch über latches oder nur noch über die Interpretation des Wortes Programmieren? Letztensendes sind es doch alles Spitzfindigkeiten. bko schrieb: > Weltbester FPGA-Pongo schrieb im Beitrag #4817420: >> Übrigens ist das Ganze ein FPGA-Problem und zwar konkret der >> Synthesesoftware. ASIC-Compiler haben da keine Probleme. Sie >> vervollständigen die Pfade sinngemäß. > > nope, zumindest die zwei welche ich kenne Synopsys+Cadence teuer > compiler > machen auch da ein "latch": >
1 | > if (en = '1') then |
2 | > a <= b; |
3 | > end if; |
4 | >
|
> > Denn dort steht: behalte den Wert von A bei solange "en" nicht '1' ist. > Das geht nur mit einem Speicherelement zu erfüllen. Das ist das, was ich meine. Es wird ein Speicherelement inferiert, welches bei ASICs nicht notwendigerweise benötigt wird. Die Frage ist doch, wird es ein synchrones latch? Wieso sollte dort der Takt ins Spiel gebracht werden?
Weltbester FPGA-Pongo schrieb im Beitrag #4818624: > Die Frage ist doch, wird es ein synchrones latch? Wie ist ein synchrones Lath definiert? > Es wird ein Speicherelement inferiert, welches bei ASICs nicht > notwendigerweise benötigt wird. Letztendlich muss das hier unabhängig von der Zielplattform und der Toolchain immer ein Latch (=pegelabhängiges Speicherelement) geben:
1 | if (en = '1') then |
2 | a <= b; |
3 | end if; |
Lothar M. schrieb: > Jürgen S. schrieb: >> Das durch VHDL "Beschriebene" ist als z.B. ein RAM-Controller, oder was >> auch immer. > Diesem Satz fehlen doch ein paar Worte, oder? Ich kaufe ein "O"! -> "das durch das VHDL "Beschriebene" ist als*o* der RAM-Controller, oder was auch immer." Darauf kam es mir an! Der Begriff "Hardware-Beschreibung" ist ja vollkommen richtig, aber er bezieht sich ja auf die Schaltung, die wir uns ausdenken, um sie in den PLD, den ASIC, den GAL, den FPGA oder demnächst den Intel-Prozessor zu bringen und nicht auf das, wo es rein soll. Könnte ja auch ein PC mit Simulator oder ein CUDA-System sein. Der FPGA selber wird nicht "beschrieben" sondern nur mit dieser "Vorschrift" (gr. Programma) beladen. Damit ist das kein Widerspruch. Die Hardware "FPGA" muss auch nicht beschrieben werden, sondern gibt es als fertiges Teil und die Beschreibung als download bei Xilinx :-) Daher spreche Ich auch immer von der "Funktion des FPGAs", wenn es um das "Beschreiben" geht. Natürlich ist es in erster Linie ein sprachliches Problem. Wenn man es aber genau nehmen und richtig darstellen will, ist es eben auch ein Logisches. > Dann werde ich in Zukunft versuchen, öfter mal ein FPGA zu > "programmieren", auch wenn das sicher einige Anfänger hübsch aus der > Kurve wirft, wenn ich sie nicht mehr explizit auf den Unterschied > zwischen C und VHDL hinweisen kann. Nein, das Einzige, was Du tun musst, ist, die Anfänger auf die Fakten hinzuweisen, nämlich: Dass das VHDL nicht vom FPGA ausgeführt wird, sondern von der Synthesesoftware. Das ist der große Unterschied. Zunächst ist das hierarchisch zwar Dasselbe, wie beim Compiler, aber: Das, was der Compiler ausgibt, ist ausführbarer Code, der nur übersetzt wird. Das, was laut C passieren soll, passiert später auf dem Controller. Es ist von der Realisation her nur etwas anders, aber funktionell identisch! Genauer: Der Ablauf ist funktionell identisch! Das, was der Synthesizer ausgibt, ist hingegen ausgeführter Code, der nicht nur übersetzt, sondern schon abgespielt wurde! Das, was laut VHDL passieren soll, ist schon im Synthesizer passiert. Was dabei rauskommt, ist daher nicht ein Ablauf, sondern eine Struktur. Genauer: Die Funktion der Struktur ist identisch zu dem Beschrieben. Systemtheoretisch gesehen bekommen wir vom Compiler eine Berechnungsformel/eine Vorgehensweise und vom Synthesizer ein komplettes Ergebnis. Das "Ergebnis" ist allerdings nicht nur ein Wert, sondern eine komplette Schaltung. Eine, die ihrerseits einen Ablauf haben kann, aber nicht muss. Der Ablauf wiederum kann im VHDL wie bei Zählern und FSMs ausdrücklich 1:1 beschrieben sein, muss es aber nicht.
:
Bearbeitet durch User
Um es mal an meinen Projekten zu verdeutlichen: Der Freescale-Compiler für meine Chameleon (56303-DSP) übersetzt ein C-Programm, mit welchem Ich eine Hardware beschreibe, nämlich die Funktion der Elektronik eines VA-Synthesizers. Das Ergebnis ist Mathematik in Assembler, angepasst auf die konkrete DSP-Struktur, die sie ausführen soll. Es gibt nur Ablauf, keine Struktur. Der Synthesizer hingegen übersetzt das VHDL-Programm, mit welchem Ich exakt dieselbe Hardware beschreibe, nämlich ebenfalls die Funktion der Elektronik eines VA-Synthesizers. Das Ergebnis ist aber jetzt der VA-Synthesizer selber, also die Mathematik, nur diesmal mit Struktur, die sie ausführen kann. C-Programm und VHDL-Programm unterscheiden sich dabei in vielen Punkten nur sehr geringfügig von einander. Es wäre durchaus möglich, das C leicht umzuarbeiten, damit es von einem Tool wie Mentor Catapult verstanden werden könnte, um es in Hardware zu gießen. Auch Xilinx HLS könnte das definitiv. Was da raus kommt, ist eine Frage der impliziten Randbedingungen. Der Knackpunkt ist dabei nicht so sehr der Unterschied in den Sprachen, hinsichtlich der Funktion, sondern die komplett andere Leistung der toolchain: Die C-Compiler übersetzen nur die Funktion des Codes - die Synthesizer führen ihn aus und bauen virtuelle Hardware! - zunächst mal nur als Netzliste, um sie dann aber auf ihre Struktur anzupassen. Das sind gleich mehrere Schritte mehr, als beim Compiler. Und es sind vor allem Schritte, die mehr Infos brauchen, als die Software. Dieses "Mehr" an Struktur-Infos macht VHDL aus. Ich bringe an der Stelle immer den Vergleich zu einem Pflichtenheft: VHDL ist ein Pflichtenheft für einen virtuellen Elektroniker+Layouter. Schaut man sich mal an, was in VHDL drin steht, ist es exakt das, was ein Systemdesigner einem Layouter mitteilen muss: - Nimm dieses Evalbaord. (FPGAs sind heute dedizierte Schaltungen, die einem fertigen PCB gleichkommen und nicht nur einfache Bausteine) - Schließe 16 Leitungen als Bus an. ("Loop"!) und synche sie auf den Takt - Baue ein Filter, das am Eingang 16 Bit und am Ausgang 24 Bit hat - Baue das Filter so, dass es per Controller umzuprogrammieren ist - Schließe einen Microblaze an und sieh zu, dass es mit 66 MHz arbeitet und die Register des Filters beschreiben kann - Baue alles so, dass es mit 200 MHz läuft So habe ich das den Studies erklärt und so erkläre ich es auch den Anfängern. Und so erkläre ich es auch meinen Kunden, damit sie sehen, welche Anteile an einer FPGA-Thematik nun Software sind und welche Hardware. Und dies noch: Bevor jetzt jemand meint, meinem Text entnehmen zu können, dass ich der Ansicht sei, man könne allein durch C eine FPGA-Entwicklung treiben: Das ist Mitnichten so! Gerade die vielen Strukturvorgaben sind es, die den Unterschied machen: Die vollkommen andere Art der Umsetzung derselben grundsätzlichen Funktion ist es, warum die Kanalzahl meines VA-Synthesizer direkt von der Taktfrequenz und der gewollten Samplefrequenz bestimmt ist und weitgehend unabhängig von der Komplexität ist, während die Zahl der Stimmen ähnlicher Projekte weitgehend von der FPGA-Größe abhängt und auch bei fetten Bausteinen um eine Zehnerpotenz geringer ist :D Beitrag "Re: Ideen für Musik-FPGA-Projekte?"
Hallo allerseits, jetzt tauchten hier mehrmals die Begriffe "asynchrones latch" und "synchrones latch" auf. Von mehreren Personen in unterschiedlichem Kontext verwendet. Was ist bitteschön der Unterschied??? Ein Latch ist ein Latch und hat 3 Anschlüsse: Daten, Takt (zur Unterscheidung besser Enable) und den Ausgang. Das kann ich natürlich in einer asynchronen Struktur oder in einer synchronen Struktur verwenden - aber es bleibt doch das gleiche Latch. Oder habe ich da was übersehen? Ähnlich ist es bei Begriffen wie "asynchroner Binärteiler". Sowas gibt es meiner Meinung nach nicht. Ein Binärteiler beibt doch ein Binärteiler - unabhängig davon, wo ich ihn einsetze. Um auf die eigentliche Frage zurückzukommen: Wenn der VHDL-Compiler ein Latch einbaut, kommt der Takteingang des Latches natürlich nicht an den Systemtakt, sondern an einen der Eingänge des Prozesses. Bei den obigen Beispielen natürlich an 'en'. Die übrigen Eingänge des Prozesses werden auf den Dateneigang und Set/Reset ggf. unter Zuhilfenahme von Logik verteilt. Meiner Meinung nach ist das so völlig ok und zulässig. Man muss sich einfach im klaren darüber sein, dass der ganze Klumpen bei Eingangssignalwechseln Verzögerungszeiten zu den Ausgängen hat und an den Ausgängen Glitches auftreten können. Also so, als ob man einen kombinatorischen Klumpen hätte. Man muss bei solchen Beschreibungen natürlich wissen, was man tut. Wenn "zufällig" und "unerwartet" Latches eingebaut werden oder gar die freundliche Meldung "...combinatorial loop detected..." auftaucht, sollte man noch mal überlegen, was man eigentlich wollte... ;-) Gruß Thomas
THS schrieb: > jetzt tauchten hier mehrmals die Begriffe "asynchrones latch" und > "synchrones latch" auf. Von mehreren Personen in unterschiedlichem > Kontext verwendet. Was ist bitteschön der Unterschied??? Ein Latch ist > ein Latch und hat 3 Anschlüsse: Ein Latch, wie du es im Beispiel anführst, das vom enable abhängt, ist kein synchrones Latch, weil es nicht synchron zum Takt ist. Wenn es das aber doch ist, ist es immer synchrones Latch. Asynchrone Latches sind in FPGAs nicht zu erzeugen. Du kannst natürlich bauen, was Du willst und wie Du es willst, nur wird die Synthese nicht das erzeugen, was Du hingeschrieben hast.
Weltbester FPGA-Pongo schrieb im Beitrag #4821497: > Ein Latch, wie du es im Beispiel anführst, das vom enable abhängt, ist > kein synchrones Latch, weil es nicht synchron zum Takt ist. So wie er es hingestellt hat, ist es durchaus synchron zum Takt. So, wie es dagegen weiter oben hingeschrieben wurde, wäre es nicht synchron zum Takt. Ich schreibe bewusst "wäre", denn: > Asynchrone Latches sind in FPGAs nicht zu erzeugen. Klar, kann man sie erzeugen, das ist ja das Problem. Die Sache ist nur die, dass gerade nicht das rauskommt, was gewollt ist, denn: > Du kannst natürlich bauen, was Du willst und wie Du es willst, nur wird > die Synthese nicht das erzeugen, was Du hingeschrieben hast. Anders herum: Man kann hinschreiben, was man will und die Synthese wird sehr wohl genau das generieren, was hingeschrieben wurde. Nur ist das, was hingeschrieben wurde unter den Randbedingungen der Synthese, also dem, was die Synthese kann (statisch denken!), was tut und wie sie es tut, nicht das, was gewünscht war! Wenn man sich es richtig überlegt, baut die Synthese nämlich durchaus das, was hingeschrieben wurde. :-) THS schrieb: > Meiner Meinung nach ist das so völlig ok und zulässig. Man muss sich > einfach im klaren darüber sein, dass der ganze Klumpen bei > Eingangssignalwechseln Verzögerungszeiten Ich stimme Dir in dem Punkt zu, dass man natürlich formulieren darf, was man möchte, sofern man sich im Klaren ist, was man erhält. Im konkreten Fall dürften aber die, die s etowas formulieren, das nicht gewollt haben, behaupte ich mal ;-) Ich möchte das Thema "asynchrone Latches" daher mal in den Bereich des grauen FPGA-Designs verschieben und zwar aus folgendem Grund: Früher, zur Zeit der GALs und ersten PLDs, waren Takte und Signale sowohl physikalisch, als auch berechnungstechnisch gleichwertig. Jedes Signal konnte aus jeder Ecke und Zeitebene hergenommen werden, um nach eifriger Verwurstung mit anderen Signalen wieder zu einem Takt zu werden, dann irgendwas zu treiben und dann wieder ein flag zu sein, das eingetaktet wird oder ausgegeben wird. Heute ist das anders: Takte werden als extra Physik geführt und auch logisch komplett anders behandelt. Daher kann man Takte weder ohne Weiteres intern einsynchronisieren, nach kann man sie gaten oder direkt ausgeben. Die Physik dafür ist im FPGA meistens nicht vorhanden. Im Falle von gegateten Clocks muss man z.B. spezielle Clockbuffer nehmen, die dann einen neuen Takt erzeugen mit all den Problemen, die eine solche Verschiebung (da weitere Zeitebene) mit sich bringt. Wenn man zudem schnelle FPGAs bauen will, dann verkürzen sich die Perioden zusehens herunter in den Bereich der Kombinatoriklaufzeiten und das Design wird immer granularer und die Laufzeiten und damit die Platzierung gewinnen an Bedeutung. Das erfordert immer mehr "Zeitscheibendenken" sowohl beim Design als auch beim Routing. Wenn dann FFs hin- und her balanciert, Elemente zeitgetrieben platziert und Pfade mikrooptimiert werden sollen, sind linear gegatete Strukturen wie "asynchrone Latches" nichts weiter als Kombinatorik mit nicht direkt vorausberechenbarem timing und schwer zu handhaben. Redundante Strukturen zur Vermeidung von Hazards, wie sie in ASICs verwendet wurden, sind praktisch überhaupt nicht zu timen, weil Kombinatorik zeitfrei optimiert wird und zusammenbröselt. Rückgekoppelte Strukturen wiederum, wie die angesprochene combinatorial loop oder die von mir mit großer Wonne verwendeten selbstschwingenden Oszillatoren entziehen sich sogar absolut jeder Berechenbarkeit beim Platzieren. Allenfalls im Nachgang kann man eine Timing Analyse veranstalten, um am fertigen Design zu ermitteln, was da rauskommt. Da muss man wirklich SEHR genau wissen, was man tut. Bei irgendwelchen sonderbaren Latches, die man benötigt (sofern überhaupt) sehe ich keinen Grund, sie durch unvollständiges VHDL zu beschreiben.
THS schrieb: > Wenn der VHDL-Compiler ein Latch einbaut, kommt der Takteingang des > Latches natürlich nicht an den Systemtakt, sondern an einen der Eingänge > des Prozesses. Mal davon abgesehen, dass ein Prozess sowas wie einen "Eingang" nicht kennt, ist ein Latch eben komplett taktlos weil es 1. Kombinatorik (im eigentlichen Sinn eine kombinatorische Schleife) und 2. pegelgesteuert ist. Solange das Enable am Latch aktiv ist, ist es sogar transparent und lässt jede Änderung am Eingang sofort auf den Ausgang durch. Und das eigentlich kritische ist ja meist dass z.B. über Kombinatorik (z.B. einen Vergleicher) gelatcht wird:
1 | Ausgang <= Eingang when Counter = 5; |
Hier kann der synchrone Counter bei jedem Zählschritt kurz glitchen und so für ein paar ps übergangsweise den Wert 5 annehmen. Und dann bleibt es dem Zufall überlassen, ob das Latch transparent wird oder eben nicht... Wenn dann gleich vom einen ganzen Vektor bei Glitches nur ein paar einzelne Speicherstellen/Latches für ein paar ps enabled werden, dann ist das gespeicherte Wort korrumpiert und unbrauchbar.
:
Bearbeitet durch Moderator
So ist es. Ein Register ist wohl die anschaulichste Erklärung für das was passiert. Wenn man sich jetzt noch in Erinnerung ruft, dass a) die Ausgänge dieses Register überall in die Schaltung gehen, weil sie zwar synchron mit dem Takt aber nicht synchron mit der ursprünglichen Änderung weitergetaktet werden, dann wird das Chaos vorstellbar.
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.