Anfängerfrage: Laufzeit von Prozessbefehlen

[DJ T. (Gast)]

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.)

[Marius W. (mw1987)]

Solche Zeitangaben sind höchstens für die Simulation interessant um 
eventuell Gatterlaufzeiten etc. zu simulieren. Sowas lässt sich nicht 
synthetisieren.

MfG
Marius

[Anguel S. (anguel)]

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).

[DJ T. (Gast)]

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..."

[Anguel S. (anguel)]

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.

[DJ T. (Gast)]

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 ;)

[Anguel S. (anguel)]

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.

[Klaus F. (kfalser)]

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.

process(clk) is
begin
  if rising_edge(clk) then 
      Q <= D;
  end if;
end process;

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.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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:

Ein Design (insbesondere ein Anfängerdesign) hat genau 1 Takt, 
der immer auf dieselbe Flanke aktiv ist. 
Es gibt keinen (und schon gar keinen asynchronen) Reset.
Externe Signale werden über 2 Flipflops einsynchronisiert.
Auch (und insbesondere) der Reset ist ein asynchrones externes Signal.
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.

[M. B. (manubaum)]

Ich kenne nur folgendes Buch, aber es ist super strukturiert:
http://www.cambridge.org/gb/knowledge/isbn/item1174853/?site_locale=en_GB

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Aber der Fokus ist ganz klar ein anderer als die FPGA-Entwicklung:

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...

[Anguel S. (anguel)]

M. B. schrieb:
> Ich kenne nur folgendes Buch, aber es ist super strukturiert:
> http://www.cambridge.org/gb/knowledge/isbn/item1174853/?site_locale=en_GB

Wenn man nur oberflächliche Theorie und abstrakte Begriffe lernen will, 
scheint es gut zu sein. Leider sind FPGAs genau aufgrund solcher Bücher 
für die meisten ein Rätsel. Steht da praktisches VHDL drin? Beispiele 
für moderne FPGAs?

[DJ T. (Gast)]

Lothar Miller schrieb:
> Es gibt keinen (und schon gar keinen asynchronen) Reset.
Darf ich fragen warum?

[Anguel S. (anguel)]

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 :)

[DJ T. (Gast)]

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!

[Anguel S. (anguel)]

Hier einige FSM Beispiele:
http://www.lothar-miller.de/s9y/archives/43-Ein-oder-Zwei-Prozess-Schreibweise-fuer-FSM.html

Übrigens beschreibt Lothar einen synchronen Prozess (der reagiert also 
nur auf den Clock) gern so:

process begin
   wait until rising_edge(clk);
   ...
end process;

Gebräuchlicher ist:

process(clk)
begin
  if rising_edge(clk) then
  ...
  end if;
end process;

Ist aber Geschmackssache.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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.html

Anguel 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:

Get Smart About Reset: Think Local, Not Global

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
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... ;-)

[Anguel S. (anguel)]

Lothar Miller schrieb:
> Xilinx FPGAs das WP272:
>

> Get Smart About Reset: Think Local, Not Global
>

> 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 ;-)