Wie soll man mit der wait until rising_edge im RTL umgehen?
So ist es klar:
1
processbegin
2
ifrising_edge(clk)then
3
:
sollte man aber das folgende vermeiden?
1
processbegin
2
waituntilrising_edge(clk);
3
:
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?
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
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 :
1
process(clk,reset)
2
begin
3
ifreset=1then
4
...
5
elsifrising_edge(clk)then
6
...
7
endif;
8
endprocess;
oder die Varianten von
1
process
2
waituntilclk='1';
3
...
4
endprocess;
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.
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
> 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:
1
processbegin
2
waituntilrising_edge(CLK);
3
count2<=count2+1;
4
waituntilrising_edge(CLK);
5
waituntilrising_edge(CLK);
6
count2<=count2+1;
7
waituntilrising_edge(CLK);
8
count1<=count1+1;
9
endprocess;
Das geht, count1 zählt halb so schnell wie count2 :-o
> 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.
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.
>... 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
> 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 ;-)
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...
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.
> 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"
@alex:
Hier mal ein Ausschnitt aus einem Synthesereport:
1
Number of errors : 0 ( 0 filtered)
2
Number of warnings : 9485 ( 0 filtered)
3
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.
> 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.
Thread beobachten
Seitenaufteilung abschalten