Hallo zusammen,
ich hab jetzt viele, viele Jahre C und Assembler auf Microcontrollern
programmiert und versuche mich jetzt in VHDL.
Jetzt hab ich mal eine grundsätzliche Frage zum Verständnis. Nehmen wir
dieses Beispiel:
mux: process (a,b,sel) is
begin
case sel is
when '0' =>
z <= a after 20 ns;
when '1' =>
z <= b after 20 ns;
end case;
end process mux;
Wenn ich es richtig verstehe, folgt der Ausgang "z" dem Eingang "a" bzw.
"b" in jedem Fall immer mit exakt 20ns Verzögerung, und zwar unabhängig
davon, ob ich durch den ersten Case (sel = '0') oder den zweiten Case
(sel = '1') gehe. D.h. die Laufzeit des Signals wird allein über die
"after 20 ns" bestimmt und ist unabhängig von dem Code-Pfad.
Ist das korrekt?
Heißt das, daß die einzelnen Befehle innerhalb des Prozesses quasi keine
Laufzeiten haben?
Oder muß man sich einen Prozess nur als "Programmierkrücke" vorstellen
und im CPLD/FPGA läuft letztendlich eh etwas völlig anderes ab?
(Ich frag so blöd, weil man in Assembler ja ganz genau abzählen müßte,
wieviele Befehlstakte die einzelnen Zweige habe, damit das Timing exakt
stimmt.)
Solche Zeitangaben sind höchstens für die Simulation interessant um
eventuell Gatterlaufzeiten etc. zu simulieren. Sowas lässt sich nicht
synthetisieren.
MfG
Marius
Sebastian F. schrieb:> ich hab jetzt viele, viele Jahre C und Assembler auf Microcontrollern> programmiert und versuche mich jetzt in VHDL.
Dann solltest Du ganz schnell C und Assembler vergessen :) Durch VHDL
definierst du Hardware. Im FPGA/CPLD gibt es unzählige kleine
Speicherelemente (Flip-Flops) und logische Verbindungen (kombinatorische
Logik) zwischen ihnen. Durch VHDL beschreibst Du (indirekt) wie diese
genau miteinander verbunden werden und Daten bei jedem Takt austauschen.
Es gibt dort keine CPU, die Befehle sequentiell abarbeitet (es sei denn
man implementiert eine Soft-CPU als Modul aber das ist ein ganz anderes
Thema).
> Jetzt hab ich mal eine grundsätzliche Frage zum Verständnis. Nehmen wir> dieses Beispiel:>> mux: process (a,b,sel) is> begin> case sel is> when '0' =>> z <= a after 20 ns;> when '1' =>> z <= b after 20 ns;> end case;> end process mux;
Das ist wie bereits gesagt nur für die Simulation gültig, die
Zeitangaben sind für die Synthese (also für die spätere Hardware im
FPGA) irrelevant. Für die echte Hardware spielen nur die Laufzeiten, die
durch die Eigenschaften der Hardwareelemente im FPGA definiert sind,
eine Rolle. Die tatsächlichen Verzögerungen sind erst nach
"Fertigstellung" der Zusammenhänge aller durch VHDL beschriebenen
HW-Elemente klar. Dich interessiert aber meistens nur, ob die Zeit für
die Überbrückung der kombinatorischen Logik zwischen den
Speicherelementen (Flip-Flops) ausreicht, bevor der nächste Takt (Clock)
kommt. Das analysieren die Tools aber für dich und sagen dir, ob das
hinkommt oder nicht.
> Wenn ich es richtig verstehe, folgt der Ausgang "z" dem Eingang "a" bzw.> "b" in jedem Fall immer mit exakt 20ns Verzögerung, und zwar unabhängig> davon, ob ich durch den ersten Case (sel = '0') oder den zweiten Case> (sel = '1') gehe. D.h. die Laufzeit des Signals wird allein über die> "after 20 ns" bestimmt und ist unabhängig von dem Code-Pfad.> Ist das korrekt?
Dein Beispiel-Prozess verwendet keinen Takt, ist also rein
kombinatorische Logik (z.B. zwischen 2 Flip-Flops). Diese 20 ns sollen
nur in der Simulation demonstrieren, dass diese kombinatorischen
Logikverbindungen auch eine gewisse Zeit benötigen, die tatsächlichen
Laufzeiten in der HW sind aber ganz anders und viel kürzer. Wenn man
mehrere solche Prozesse nebeneinander hat, laufen diese parallel ab und
nicht nacheinander.
> Oder muß man sich einen Prozess nur als "Programmierkrücke" vorstellen> und im CPLD/FPGA läuft letztendlich eh etwas völlig anderes ab?
Ja, als Simulations- und Anfängerkrücke :) Wobei das ganze IMHO eher
verwirrt. VHDL für Simulation verwendet Funktionen, die VHDL für
Synthese nicht unterstützt!
> (Ich frag so blöd, weil man in Assembler ja ganz genau abzählen müßte,> wieviele Befehlstakte die einzelnen Zweige habe, damit das Timing exakt> stimmt.)
Im FPGA muss man auch Takte abzählen. Dein Beispiel ist jedoch etwas,
was zwischen zwei Takten passiert. Die durch diesen Prozess
beschriebene Logik darf dann nicht zu komplex werden, da diese sonst
mehr Zeit benötigen würde, als zwischen zwei Takten zur Verfügung steht
(abhängig von der Taktrate).
Danke!
Mir ist dieser Unterschied zwischen Simulieren und Synthetisieren nicht
klar gewesen.
Und ich hab mir noch gedacht: "Wow, da kann man aber einfach Timer
realisieren..."
Sebastian F. schrieb:> Danke!> Mir ist dieser Unterschied zwischen Simulieren und Synthetisieren nicht> klar gewesen.> Und ich hab mir noch gedacht: "Wow, da kann man aber einfach Timer> realisieren..."
Ich war am Anfang genauso verwirrt, leider ist die ganze Literatur zum
Thema ziemlich blöd aufgebaut. Welches Buch hast Du?
Wenn Du in einem VHDL-Projekt ein FPGA als Target hast, wird der
Compiler meckern, weil die 20 ns gar nicht erlaubt sind. Im Simulator
ist es aber ok.
Ich acker mich gerade durch den "Designer'S Guide to VHDL" von Peter
Ashenden. Ist eigentlich extrem ausführlich, insofern wundert es mich
umsomehr, daß dieser fundamentale Unterschied nicht so richtig
rauskommt...
Ich hab jetzt auch mal versucht, ein paar Signal-Timing-Beispiele aus
dem Buch auf meinem FPGA-Board (Digilent Spartan 3E) laufen lassen und
siehe da: entweder es läßt sich erst gar nicht synthetisieren (z.B.
ergibt "wait for" einen Abbruch) oder es tut sich einfach nichts.
Na gut, wieder was gelernt ;)
Sebastian F. schrieb:> Ich acker mich gerade durch den "Designer'S Guide to VHDL" von Peter> Ashenden. Ist eigentlich extrem ausführlich, insofern wundert es mich> umsomehr, daß dieser fundamentale Unterschied nicht so richtig> rauskommt...
Das Buch ist nicht für Anfänger. Eher als Referenz, aber wenn man die
Grundlagen hat. Viele Bücher sind außerdem eher für Simulation. Ich
finde die Bücher von Pong Chu ganz gut als Einstieg für Hardware, auch
wenn hier einige Gurus widersprechen werden.
Anguel S. schrieb:>> Oder muß man sich einen Prozess nur als "Programmierkrücke" vorstellen>> und im CPLD/FPGA läuft letztendlich eh etwas völlig anderes ab?> Ja, als Simulations- und Anfängerkrücke :) Wobei das ganze IMHO eher> verwirrt. VHDL für Simulation verwendet Funktionen, die VHDL für> Synthese nicht unterstützt!
Im Grunde ist es ganz anders:
VHDL ist eine Simulationssprache, mit der man Hardware simuliert und
verifiziert, wobei die Sprache verschieden Möglichkeiten bietet, die
Eigenschaften realer Hardware zu modellieren.
Deshalb z.B. Sprachkonstrukte wie
A <= B after 20 ns.
Das modelliert einfach ein Durchlaufzeit von 20 ns von einen
Eingangsignal zum Ausgangssignal.
Aber es ist ein Modell.
Diese Simulationssprache hat man schon vor den FPGA's verwendet, um z.B.
zu testen, ob man ASICs richtig geplant hat.
Als die FPGA's aufkamen, hat man eine Möglichkeit (Sprache) gesucht, die
Logik, die im FPGA drinnen sein soll zu definieren und zu beschreiben
und hat angefangen VHDL zu verwenden.
Der Compiler macht nun die Sache rückwärts. Er erkennt bestimmte Pattern
und macht daraus Hardware, z.B.
1
process(clk)is
2
begin
3
ifrising_edge(clk)then
4
Q<=D;
5
endif;
6
endprocess;
Das ist in VHDL ein Modell für ein verzögerungsfreies FF. Der Syntesizer
erkennt das MUSTER, und generiert damit ein FF im FPGA.
Dieses FF ist dann in Wirklichkeit nicht mehr verzögerungsfrei.
Sebastian F. schrieb:> Ich acker mich gerade durch den "Designer'S Guide to VHDL" von Peter> Ashenden.
Lies dir mal VHDL-Synthese von Reichhardt&Schwarz durch. Dort ist die
Synthese für FPGAs mit Beispielen erklärt. Auf meiner HP sind solche
Beispiele auch zu finden. Der wichtigste Tipp für Anfänger:
Externe asynchrone Signale müssen einsynchronisiert werden.
http://www.lothar-miller.de/s9y/categories/35-Einsynchronisieren
Ansonsten gelten nach wie vor meine Postulate:
1
Ein Design (insbesondere ein Anfängerdesign) hat genau 1 Takt,
2
der immer auf dieselbe Flanke aktiv ist.
3
Es gibt keinen (und schon gar keinen asynchronen) Reset.
4
Externe Signale werden über 2 Flipflops einsynchronisiert.
5
Auch (und insbesondere) der Reset ist ein asynchrones externes Signal.
6
Jede Abweichung von diesen Regeln muß fundiert begründet werden können.
Blöderweise wird der 2. Punkt (kein Reset) von den allermeisten Büchern
schlicht ignoriert... :-/
Von Xilinx gibt es dazu aber das sehr lesenswerte WP272.
Sebastian F. schrieb:> Und ich hab mir noch gedacht: "Wow, da kann man aber einfach Timer> realisieren..."
Ja, das hat sich wohl jeder VHDL-Anfänger schon mal gedacht. Aber in
Hardware wird jede Zeit (abgesehen von ein paar Sonderkomponenten wie
IO-Pins zur Laufzeitkorrektur) mit Zählern realisiert.
http://www.lothar-miller.de/s9y/categories/34-Getakteter-Prozess> Ich hab jetzt auch mal versucht, ein paar Signal-Timing-Beispiele aus> dem Buch auf meinem FPGA-Board (Digilent Spartan 3E) laufen lassen und> siehe da: entweder es läßt sich erst gar nicht synthetisieren (z.B.> ergibt "wait for" einen Abbruch) oder es tut sich einfach nichts.
Richtig: du mußt mit den Tools ein wenig herumspielen und insbesondere
mal den RTL-Schaltplan ansehen.
VHDL kann viel, viel, viel mehr, als du auf ein FPGA tatsächlich
abbilden kannst. Auf einem FPGA hast du nur Flipflops und Logik (das ist
quasi die "Assmblerprache" des FPGAs). In diesen Komponenten mußt du
denken können (quasi ein "Assemblerlisting" lesen und verstehen können),
sonst kannst du nie nachvollziehen, was der Synthesizer aus deiner
VHDL-Beschreibung gemacht hat.
Aber der Fokus ist ganz klar ein anderer als die FPGA-Entwicklung:
1
From VLSI Architectures to CMOS Fabrication
Darin geht es nur sehr sehr beiläufig um VHDL. Im ganzen Buch mit 866
Seiten taucht das Wort gerade 100 mal auf. Für FPGAs siehts noch
schlechter aus: nur 29 Treffer...
Sebastian F. schrieb:> Lothar Miller schrieb:>> Es gibt keinen (und schon gar keinen asynchronen) Reset.> Darf ich fragen warum?
Ein Reset ist in einem Design eigentlich nicht nötig, denn gut
funktionierende Hardware sollte keinen externen Reset-Knopf brauchen. Im
FPGA können alle Speicherzellen auf '1' oder '0' im VHDL-Code durch :=
'1' oder := '0' vorkonfiguriert werden und haben damit keinen
undefinierten Anfangszustand, brauchen also auch keinen Reset. Bei der
Implementierung eines globalen Resets müsste dieser Reset zu allen
Flip-Flops geroutet werden und verbraucht damit unnötig sehr viele
kostbare Ressourcen. Asynchrone Resets sind gefährlich, weil man keine
Garantie hat, dass sie rechtzeitig alle Flip-Flops resetten werden - sie
kommen nämlich unabhängig vom Takt an und deren Laufzeiten werden von
den Tools nicht berücksichtigt. Wenn man also Resets nutzt, muss man
diese einsynchronisieren. Lokale synchrone Resets (also solche die nur
einen kleinen Teil der Schaltung resetten - z.B. eine FSM) sind soweit
ich weiß nicht völlig verboten. Falls ich etwas falsches geschrieben
habe, möge mich bitte Lothar korrigieren oder ergänzen :)
Hallo zusammen,
ich hab den ganzen Nachmittag versucht, eine ganz einfache
Statusmaschine auf meinen FPGA-Board zum Laufen zu bekommen. Auf dem
CPLD-Board lief es, auf dem FPGA-Board nicht. Schlimmer noch, die
Statusmaschine nimmt auch noch Zustände an, die sie laut Programmcode
eigentlich gar nicht annehmen dürfte.
Zum Verzweifeln!
Dann hab ich mir die Einsynchronisierung auf Lothars Homepage
durchgelesen und die Statusmaschine entsprechend erweitert. Und jetzt
tut's! (Und auch ohne Reset)
Ich bin begeistert!
Danke Euch allen!
Sebastian F. schrieb:>> Es gibt keinen (und schon gar keinen asynchronen) Reset.> Darf ich fragen warum?
Ja, klar... ;-)
Als kleine Ergänzung zu dem von Anguel bereits gesagten:
http://www.lothar-miller.de/s9y/archives/70-Asynchroner-Reset.htmlAnguel S. schrieb:> Falls ich etwas falsches geschrieben> habe, möge mich bitte Lothar korrigieren oder ergänzen :)
Gut, bitteschön: ;-)
> Lokale synchrone Resets (also solche die nur einen kleinen Teil der> Schaltung resetten - z.B. eine FSM) sind soweit ich weiß nicht> völlig verboten.
Es ist prinzipiell nichts verboten, jeder kann mit seinem FPGA machen
was er will (so er es bezahlt hat). Nur: wer ein funktionierendes Design
will, der sollte die entsprechenden AppNotes und WhitePapers des
entsprechenden Herstellers lesen. Und eines davon ist wie gesagt für
Xilinx FPGAs das WP272:
> http://www.xilinx.com/support/documentation/white_papers/wp272.pdf> Und das darin verlinkte WP275:> http://www.xilinx.com/support/documentation/white_papers/wp275.pdf
Entweder bin ich zu blöd, oder diese Xilinx-WPs sind verdammt
unverständlich geschrieben (genauso wie der Rest der Doku). Man muss die
100 mal durchlesen und versteht trotzdem nicht, was mit dem ganzen hin
und her am Ende eigentlich gemeint ist. Dabei sind die Sachen nicht
wirklich so komplex.
> Fazit daraus:>> Lokale synchrone Resets (also solche die nur einen kleinen Teil der>> Schaltung resetten - z.B. eine FSM) sind soweit ich weiß nicht>> völlig verboten.> Sie sind nicht verboten, sondern zu bevorzugen... ;-)
Ok, aber nur falls man sie wirklich braucht ;-)