www.mikrocontroller.net

Forum: FPGA, VHDL & Co. RTL: "wait until rising_edge" oder "if rising_edge"


Autor: Matthias G. (mgottke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie soll man mit der wait until rising_edge im RTL umgehen?
So ist es klar:
process begin
    if rising_edge(clk) then
    :
sollte man aber das folgende vermeiden?
process begin
    wait until rising_edge(clk);
    :
Lothar Miller schreib dazu in einem anderen Beitrag:
> Es gibt ein paar schlagende Vorteile:
> - schreibt und liest sich schöner, weil weniger Einrückungen nötig sind
>   und eine Klammerebene gespart wird
> - die Simulation und die Synthese stimmen immer überein,
>   weil es keine unvollständigen Sensitivity-Listen mehr gibt
> - der Prozess ist garantiert getaktet,
>   und hat nicht irgendwo einen asynchronen Teil
> Und wieso sollte man etwas nicht verwenden, wenn es Vorteile bringt?
> Nur, weil es in keinem Buch steht?

In den "vhdl style sheets" die ich kenn wird meist dringend davon 
abgeraten wait im RTL zu verwenden. Gleichzeitig wird aber darauf 
hingewiesen, dass waits im Zusammenhang mit Takten möglichst immer zu 
verwenden ist.

Wo gibt es mit dem wait mögliche Probleme? Oder auch nicht?

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im XST User Guide (-> VHDL Language Support -> VHDL Sequential Circuits 
-> VHDL Sequntial Process Without a Sensitivity List) ist die von Lothar 
Miller vorgeschlagene Syntax beschrieben.
Die Vorteile sehe ich auch. Es ist schon oft genug vorgekommen, dass es 
in der Hardware läuft und in der Simulation nicht, weil die Sensitivty 
List fehlerhaft war.

Duke

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beide Formen sind für die Synthese möglich.

Letztendlich läuft es immer darauf hinaus, dass der VHDL Text die 
Beschreibung von FFs ergibt.
Das sind also die Varianten mit :
process(clk, reset)
begin
  if reset = 1 then 
    ... 
  elsif rising_edge(clk) then  
    ... 
  end if;
end process;

oder die Varianten von
process
  wait until clk = '1';
  ...
end process;

Bei der Beschreibung mit if rising_edge() kann man den asynchronen Reset 
beschreiben, etwas das in Form 2 nicht geht.
Bei der Beschreibungsform 2 hat man den (fragwürdigen) Vorteil, dass man 
die sensitivity list nicht zu schreiben braucht. Außerdem unterstützt 
XST anscheinend auch mehrere waits (immer für das gleiche clk Signal) 
hintereinander, sodass man eine Art Sequenz programmieren kann. Ich habe 
das jedenfall noch nie verwendet und ich denke die meisten verwenden 
Form 1 wegen dem Vorteil mit dem asynchronen Reset.

Diese Einschränkungen gelten natürlich nur für die Synthese, in 
Testbenches kann man beschreiben was man will.

Autor: SuperWilly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ist denn mit folgender Variante ?

process
begin
   wait until Clk='1';
...
end process;

Hat meines Erachtens die gleiche Funktion wie der Vorschlag
von Lothar M.

Kommentare ?

Gruß,
SuperWilly

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der betreffende Standard ist IEEE 1076.6.
Eine Suche im weltweiten Web ergibt einige Treffer, wobei sogar noch 
wesentlich "wildere" Konstruktionen definiert (z.B. Enable und Clk in 
einer Abfrage) und von den Synthesetools unterstützt werden.
http://www.synthworks.com/papers/vhdl_rtl_synthesi...
http://hotelhilbert.net/ETH/digitech/vorlesungssli...
Offenbar wird an der TU Delft auch diese "neue" Beschreibung 
verwendet...

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Bei der Beschreibungsform 2 hat man den (fragwürdigen) Vorteil,
> dass man die sensitivity list nicht zu schreiben braucht.
Ich würde gerade diesen Vorteil nicht in Frage stellen. Man muß sich nur 
mal in den hier (im Forum) geposteten Quellen die überdefinierten oder 
unvollständigen Sensitivity-Listen ansehen, um zu erkennen, dass da 
etliche Simulationen nicht das machen werden, was das Design auf dem 
FPGA tun wird...   :-/

> XST anscheinend auch mehrere waits (immer für das gleiche clk Signal)
> hintereinander, sodass man eine Art Sequenz programmieren kann.
Das ist vom IEEE aber nicht mehr abgedeckt.
Dort steht, dass das wait an erster Stelle im Prozess zu stehen hat.
Spätestens das zweite wait until würde diese Forderung verletzen.
Aber, ich habe es gerade ausprobiert:
   process begin
      wait until rising_edge(CLK);
      count2 <= count2+1;
      wait until rising_edge(CLK);
      wait until rising_edge(CLK);
      count2 <= count2+1;
      wait until rising_edge(CLK);
      count1 <= count1+1;
   end process;
Das geht, count1 zählt halb so schnell wie count2    :-o

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@SuperWilly:

Ich hab mal den Namen ausgetausch:
process
begin
   wait until En='1';
...
end process;
Für mich sieht das aus wie ein Latch.

Duke

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Für mich sieht das aus wie ein Latch.
Das schon (deshalb schreibe ich lieber wait until rising_edge), aber 
diese Beschreibung ist nach IEEE korrekt und ergibt ein getaktetes FF.

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Duke
> Für mich sieht das aus wie ein Latch.

Die Zeile
Wait until EN='1';
ist laut VHDL Standard equivalent zu
Wait on EN until EN='1'" 

Wait on EN wartet auf ein Event am EN signal, das EN'event ist also 
überflüssig, wenn es auch die Lesbarkeit erhöht.

@Lothar
>> Bei der Beschreibungsform 2 hat man den (fragwürdigen) Vorteil,
>> dass man die sensitivity list nicht zu schreiben braucht.
>Ich würde gerade diesen Vorteil nicht in Frage stellen.

Bei einem kombinatorischen Prozess würde ich Dir recht geben, aber bei 
einem getakteten Prozess sind es nur der Takt (und ev. der Reset) der in 
die sensitivity list gehört. Wer dieses Grundprinzip nicht verstanden 
hat, der hat früher oder später mit dem Rest seines VHDL Codes auch 
Schwierigkeiten.

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>... bei einem getakteten Prozess sind es nur der Takt (und ev. der Reset) >der in 
die sensitivity list gehört.

Richtig und dann ändert man mal schnell auf eine andere Taktdomäne und 
vergisst die sensitivity list...
...und die Simulation geht nicht mehr. Nur so als Beispiel aus der 
Praxis.

Duke

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Bei einem kombinatorischen Prozess würde ich Dir recht geben...
Bei kombinatorischen Prozessen geht das mit wait sowieso nicht, weil 
aus einer solchen Beschreibung ein getakteter Prozess wird.

Ich versuche, kombinatorische Prozesse in concurrent-Beschreibungen 
abzuhandeln. Das geht erstaunlich oft  ;-)

> Wer dieses Grundprinzip nicht verstanden hat, der hat früher
> oder später mit dem Rest seines VHDL Codes auch Schwierigkeiten.
FULLstes ACK  ;-)

Autor: alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Verstehe nicht, warum ihr so auf Sensitivity Listen rumhackt. Bei der 
Synthese gibt es diesbezüglich sowieso eine Warnung, wenn in der Liste 
Signale fehlen sollten (bei ISE zumindest), und diesen Fehler kann man 
doch, so gesehen, gar nicht übersehen. Ist das bei anderen Synthesetools 
etwa anders? Oder ist es jetzt etwa in Mode, ein Design mit Warnungen 
abzugeben...

Autor: Matthias G. (mgottke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei der Synthese schon, da arbeiten die Tools sehr unsauber. Aber bei 
der Simulation kommt keine Warnung. Laut VHDL ist es mämlich zulässig 
Singale in der Sensitivity-Liste weg zu lassen. Dies sollte dann auch zu 
anderen Ergebnissen führen. Dies ist aber meist nur in der Simulation 
der Fall.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Dies sollte dann auch zu anderen Ergebnissen führen.
Tut es auch :-/
> Dies ist aber meist nur in der Simulation der Fall.
Ausschließlich in des Simulation.
Die (vollständige) Sens-Liste ist nur für die Simulation nötig.

>> Verstehe nicht, warum ihr so auf Sensitivity Listen rumhackt.
Beispiele im Beitrag "Re: Vergleich von 2 code Varianten" und im 
Beitrag "Re: State Machine Zähler-Problem"

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@alex:
Hier mal ein Ausschnitt aus einem Synthesereport:
Number of errors   :    0 (   0 filtered)
Number of warnings : 9485 (   0 filtered)
Number of infos    : 2088 (   0 filtered)

Das Design läuft. Und man möchte den Code gar nicht ändern, um die 
Warnungen wegzubekommen...
Der Warnmechanismus von XST ist alles, nur nicht produktiv brauchbar.

Duke

P.S.: Simulieren läßt es sich natürlich auch.

Autor: Morin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> und diesen Fehler kann man doch, so gesehen, gar nicht übersehen.

Würde gerne mal sehen, wie du diesen Fehler in den 9485 Warnungen in 
Dukes Projekt erspähst.

> Ist das bei anderen Synthesetools etwa anders?
> Oder ist es jetzt etwa in Mode, ein Design mit Warnungen abzugeben

Um im Xilinx ISE ein Design ohne Warnungen synthetisiert zu bekommen, 
musst du diverse Änderungen vornehmen, die den Code extrem unlesbar und 
unstrukturiert machen.

Schönes Beispiel: Ein einfacher SoC-Bus, Single-Master, 32 
Adressleitungen, 32 Datenleitungen. Gedacht war es so: 12 A-Leitungen 
wählen ein Device, 20 A-Leitungen gehen an das Device. Alle Schreibdaten 
gehen an alle Devices, die Lesedaten aller Devices werden je nach 
Adresse gemultiplexed. Nichts besonderes also. Ergebnis: Eine Flut von 
Warnungen über unbenutzte Adress- und Schreibdaten-Signale in den 
Devices. Und das ist sogar noch relativ einfach zu beheben, es gibt noch 
weitaus schlimmeres.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>> Verstehe nicht, warum ihr so auf Sensitivity Listen rumhackt.
Ein aktuelles Beispiel findet sich im 
Beitrag "MUX mit bidirektionalem Pin"  ;-)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.