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
endif;
In sequentieller Logik hast du diese Problem nicht, da die direkt ein
FlipFlop erzeugt wird:
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.
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.
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
endif;
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 FPGAprogrammieren 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...
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
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"
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...
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
>endif;
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:
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.
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<=EingangwhenCounter=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.
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 abschalten