Hallo zusammen,
ich habe eine Verständnisfrage zum Thema Timing. Ich hoffe, jemand kann
mir hier weiterhelfen:
Vorweg: in meinem Beispiel geht es zwar um einen Reset, ich will aber
keine neue Diskussion über synchrone/asynchronen/Sinn des Resets führen.
Mir geht es um das Verständnis der Synthese-/Implementierungstools.
Ich synchronisiere ein externes Reset-Signal ein, d.h. ich habe einen
Prozess, in welchem ich das Signal synchron zu meinem Taktsignal mache.
Wenn ich nun an anderen Stellen asynchron auf dieses Signal zugreife,
stellt das Synthese-/Implementierungstool sicher, dass bis zu diesem
Punkt das Timing im Hinblick auf meinen Takt nicht „verletzt“ wird? Oder
erkennt das Tool, dass zwar von einem synchronen Signal ausgegangen
wird, der asynchrone Zugriff aber die Timing-Anforderungen „aufhebt“?
Mit Ausnahme des Zugriffs auf das Reset-Signal ist der Code immer
synchron.
Anders ausgedrückt: wenn ich mein einsynchronisiertes Reset aufhebe,
kann ich dann davon ausgehen, dass bei der nächsten steigenden
Taktflanke alle Prozesse sehen, dass das Reset-Signal aufgehoben wurde?
Oder wäre es möglich, dass die Signal-Laufzeiten des Reset-Signals zur
Hardware von dem einen oder anderen Prozess so lange dauern, dass (durch
die asynchronen Abfrage des Resets) hier auch erst ein Taktzyklus
verspätet dieser Zustand erkannt wird?
Ich möchte mich bereits im Voraus für die Hilfe bedanken!
Dominik schrieb:> Ich synchronisiere ein externes Reset-Signal ein, d.h. ich habe einen> Prozess, in welchem ich das Signal synchron zu meinem Taktsignal mache.
Nein, du erzeugst ein neues Signal, welches getaktet ist.
> Wenn ich nun an anderen Stellen asynchron auf dieses Signal zugreife,
Auf welches?
Wie und mit welchen Mitteln willst du "asynchron zugreifen"?
Ich glaube, du hast ein grundsätzliches Verständnisproblem von Hardware.
> Anders ausgedrückt: wenn ich mein einsynchronisiertes Reset aufhebe,
Wie und mit welchen Mitteln willst du ein Signal "aufheben"?
> kann ich dann davon ausgehen, dass bei der nächsten steigenden> Taktflanke alle Prozesse sehen, dass das Reset-Signal aufgehoben wurde?
wie gesagt, du hast ein grundsätzliches Problem.
Prozesse können nicht "sehen" und wenn, dann sehen sie alles zur
gleichen Zeit. Der Zustand eines Signals ist immer nur einer und der
gilt an allen Stellen im FPGA> Ich möchte mich bereits im Voraus für die Hilfe bedanken!
Nicht sicher, ob dir hier jemand helfen kann.
> Wenn ich nun an anderen Stellen asynchron auf dieses Signal zugreife,
Was ist damit gemeint?
Allgemein:
Wenn du in deinem Design nur einen Takt hast und diesen per Constraint
deklariert hast, kümmert sich die Timinganalyse um jeden Signalpfad
zwischen zwei getakteten Elementen, egal wie viel Logik oder Wegstrecken
dazwischen liegen. Wenn eine Signallaufzeit so lange ist, dass eine
Taktflanke übersprungen wird, ist das Timing fehlgeschlagen (und das
wird dir auch gemeldet).
Was anderes ist es mit dem Signal von außerhalb des FPGAs bis zum ersten
getakteten Element. Beim asynchronen Reset gibt es ohnehin nicht "die"
richtige Flanke. Wenn der Reset aber zufällig zeitlich sehr nahe zur
Flanke kommt, kann es passieren, dass das Flip-Flop in einen
metastabilen Zustand gerät (googlen). Deshalb würde ich mir unter
"Einsynchronisieren" eine Kette von (z.B. 3) Flip-Flops vorstellen,
bevor das Signal verteilt wird. Das verringert das Risiko auf ein für
übliche Zwecke akzeptables Maß. Ich weiß aber nicht, ob das immer so
gemacht wird.
Dominik schrieb:> ich will aber> keine neue Diskussion über synchrone/asynchronen/Sinn des Resets führen.
Die Diskussion solltest Du dir aber ansehen und die einschlägigen
Beiträge sowie Artikel lesen, weil ich und andere dort genau diese
Thematik schon oft abgehandelt haben.
Dein Problem ist das vieler Designer: Du vermischst Logikdesign und
Schaltungsumsetzung und willst mit Prozessen Hardware managen. Dem
stehen aber nicht nur die Logik sondern auch die heutigen
Designprinzipien von FPGAs entgegen, die funktionsorientiert gebaut
werden und bei denen man nur selten aktiv auf das timing der Hardware
hinsieht.
Ich kann auch hier nur wieder deutlich darauf hinweisen, dass ein Signal
etwas Abstraktes ist, also eine Information und nicht etwa eine Leitung,
auch wenn sie in Verilog dummerweise so genannt wird. Deshalb gibt es
bei Signalen weder Pegel (loaktiv) noch Timing.
Es gibt nur einen Signalzustand und das dessen Wert, also z.B. 0 und 1
oder eben einen INT oder was auch immer. Diese Information wandert von
einer einzigen Quelle zu einem oder mehren Zielen. Daher gibt es z.B.
kein wired OR oder AND. Im Logikdesign grundsätzlich nicht und auch in
FPGAs nicht (mehr).
Was konkret dein Reset angeht, ist das nur in speziellen Fällen und
FPGAs bei aysnchronen FlipFlops wirklich eine dedizierte Leitung. In
einem synchronen Design ist das nichts anderes als eine Funktion, die
mit in die Gleichungen eingebacken wird, welche die Funktionen vor den
Registern speisen.
Du musst dich von der Vorstellung lösen, dass du Hardware definierst. Du
definierst nur die Funktion einer Hardware. Wie das hinterher aussieht,
ist nicht in determiniert:
Dominik schrieb:> Oder wäre es möglich, dass die Signal-Laufzeiten des Reset-Signals zur> Hardware von dem einen oder anderen Prozess so lange dauern,
Wir bewegen uns in einem Logikdesign. Dort gibt es keine
Signallaufzeiten zwischen Sender und Empfänger. Alle Informationen sind
synchron = gleichzeitig. Das ist ja der eigentliche Sinn der
Schaltungslogik im Gegensatz zur Schaltungsrealisation und der
Schaltungsfunktion. Durch das Einsynchen wird ja gerade sichergestellt,
dass man ein solches synchrones Signal = Resetinformation hat und dann
damit so einfach agieren kann.
Wenn das Logikdesign mal läuft, ist das in sich konsistent.
Wenn es dann später in eine TTL-Schaltung, einen ASIC oder in einen FPGA
wandert, entstehen natürlich unterschiedliche Laufzeiten. Die zu managen
ist Aufgabe des realen Designers oder eines virtuellen Designers,
nämlich dem ASIC-Compilers oder des FPGA-Synthesetools.
Bei der Umsetzung in einen FPGA formulierst du nur noch die
Timing-Anforderungen und dein tool wird dir dann sagen, wenn was nicht
passt. Genau dafür sind die im Übrigen da. Solange das timing passt,
läuft innen alles synchron, d.h. in der Betrachtungs des Taktens "ideal
gleichzeitig".
Mehr kann man da nicht steuern und ist nicht zu berücksichtigen.
Praktisch sieht das innen nämlich nochmal vollkommen anders aus, weil
die Logik zerstückelt- und auf LUTs verteilt wurde, Register aufgelöst,
verschoben oder dupliziert wurden, um die reale Information rechtzeitig
an die LUTs und die Folgeregister heranzuführen. Das muss dich aber
nicht interessieren.
Du baust in VHDL nur entweder Schaltungslogik in UND, ODER, AND sowie
Verwendung von Cores und Zellen, oder Schaltungsfunktion mit Addition,
Multiplikation, FSM etc. und zwar beides vermischt auf einer Ebene egal,
ob man es behaviour, structure oder HumptiDumpti nennt. Es ist alles die
Formulierung einer Wunschfunktion und zwar einer getakteten.
Den Rest macht das tool.
Hallo zusammen,
zunächst einmal vielen Dank für die Antworten und Erklärungen!! Des
Weiteren möchte ich mich gleich noch dafür entschuldigen, dass meine
Frage schlecht formuliert und damit nicht eindeutig war.
Die vielen Hinweise und Tipps werde ich mir natürlich zu Herzen nehmen
und versuchen, mich da weiter einzulesen und -arbeiten.
Im Hinblick auf die Rückfragen bzw. die Unklarheiten. Ich versuche meine
Frage nochmals etwas klarer zu beschreiben:
Ich habe ein externes high-aktives Reset-Signal. In der Literatur (White
Paper von Xilinx WP272) habe ich folgende Schaltung gefunden, welches
den Wechsel des Reset-Signals von low auf high (das meinte ich mit Reset
wird „gesetzt“) asynchron erfasst. Der Wechsel von high auf low, also
das Aufheben des Reset-Zustands, erfolgt synchron zum Takt:
1
process(clk,reset_in)
2
begin
3
if(reset_in='1')then
4
sr<=(others=>'1');
5
elsif(rising_edge(clk))then
6
sr(0)<='0';
7
foriin0to(sr_length-2)loop
8
sr(i+1)<=sr(i);
9
endloop;
10
endif;
11
endprocess;
12
13
reset<=sr(sr'left);
Wenn ich in einem weiteren Prozess das Reset-Signal wie folgt verwende:
1
process
2
begin
3
waituntilrising_edge(clk);
4
-- code
5
if(reset='1')then-- reset als letzte if-Abfrage im Prozess
6
-- code
7
endif;
8
endprocess;
dann sollte das Synthese-Tool erkennen, dass alles taktsynchron erfolgt.
Damit versucht es die beschriebene Funktion derart umzusetzen, dass das
Timing bei der definierten Frequenz eingehalten wird und gibt eine
Warnung aus, wenn dies nicht möglich ist.
Wenn ich in anderen Prozessen das Reset-Signal wie folgt verwende:
1
process(clk,reset)
2
begin
3
if(reset='1')then
4
-- code
5
elsif(rising_edge(clk))then
6
-- code
7
endif;
8
endprocess;
dann würde dieser Teil der Schaltung einen asynchronen Reset für die
Flipflops verwenden.
Nach einem Wechsel des Reset-Signals von high auf low arbeitet in beiden
Fällen die Schaltung wieder taktsynchron, d.h. bei der nächsten
Taktflanke wird die beschriebene Funktion ausgeführt.
Ich hatte mir nun vorgestellt, dass es durchaus passieren kann, dass
beim Place and Route zwei Schaltungsteile, welche den beschriebenen
asynchronen Reset verwenden, innerhalb des FPGA weit entfernt von
einander platziert werden könnten. Die Laufzeit des Reset-Signals zu
diesen Schaltungsteilen ist dann sehr verschieden.
Meine Frage war nun die folgende: würde ein Tool hier eine Warnung
ausgeben, wenn die Laufzeit des Reset-Signals zu einem dieser Teile der
Schaltung länger dauert als bei einem „synchronen“ Schaltungsteil durch
die definierte Frequenz zulässig wäre? D.h. dass die Schaltung einen
Pegelwechsel des Reset-Signal von high auf low nicht innerhalb einer
Taktperiode mitbekommen würde, weil die Signallaufzeit des Reset-Signals
zu diesem Teil der Schaltung zu lange dauert?
Ich habe einfach einen Knoten im Hirn wie ein Tool damit umgehen würde,
dass ein Takt verwendet wird um den Pegelwechsel des Resets von high auf
low zu übernehmen, der Zugriff auf dieses Signal aber mit einer
asynchronen Beschreibung erfolgt.
Ich weiß natürlich, dass ich mir die Frage hätte sparen können, wenn ich
immer die synchrone Beschreibung verwende. Aber ich versuche die
Funktionsweise zu verstehen und habe da ja offensichtlich auch noch
einige größere Wissenslücken.
Nochmals vielen Dank für die Antworten und ausführlichen Erklärungen!!
Meine Laienaussage lautet wie folgt...
Wenn du einen asynchronen Reset baust, also
1
ifreset='1'then
2
...
3
elsifrising_edge(clk)then
4
...
5
endif
dann wird die Reset-Leitung an den asynchronen Reset-Eingang des
Flipflops angeschlossen und triggert damit asynchron zum Takt.
Es spielt keine Rolle, ob das Reset-Signal theoretisch synchron zum Takt
ist, denn es durch die Laufzeitunterschiede gibt es immer einen
Zeitunterschied zwischen beiden Signalen (insbesondere, weil der Takt
sein eigenes Netzwerk benutzt).
Zumal Xilinx m.W. dafür wirbt, keinen Reset einzusetzen.
Dominik schrieb:> Nach einem Wechsel des Reset-Signals von high auf low arbeitet in beiden> Fällen die Schaltung wieder taktsynchron,
"Die Schaltung" arbeitet IMMER synchron zum Takt oder nie, je nach
Interpretation. Du musst
a) Die Signale von einander trennen, nur die können gegeneinander
synchron sein
b) Logik von Physik trennen. Nur in der Logik ist alles synchron bei
einem idealen Zeitpunkt, in der Realität faktisch nie.
Wie ich schon erklärt habe, macht es bei der Formulierung eines
Logigdesigns keinen Sinn, ein Timing anzunehmen. Umgekehrt musst du Dir
bei einem physischen design, wenn du Elemente platzierst und Leitungen
ziehst, wenn schon dann aber über alle timings im Klaren sein. Das aber
kannst du nicht, weil du die Struktur nicht in der Hand hast.
> Ich hatte mir nun vorgestellt, dass es durchaus passieren kann, dass> beim Place and Route zwei Schaltungsteile, welche den beschriebenen> asynchronen Reset verwenden, innerhalb des FPGA weit entfernt von> einander platziert werden könnten. Die Laufzeit des Reset-Signals zu> diesen Schaltungsteilen ist dann sehr verschieden.
Das ist, wie gesagt, IMMER der Fall. Es gibt auch bei minimalen
Distanzen nie ein ideale Flankenmatching. Es ist auch von dem tool nicht
herstellbar wegen z.B. der Störungen. Auch beim Takt geht das nicht.
Das ist aber auch nicht nötig, denn:
> Meine Frage war nun die folgende: würde ein Tool hier eine Warnung> ausgeben, wenn die Laufzeit des Reset-Signals zu einem dieser Teile der> Schaltung länger dauert als bei einem „synchronen“ Schaltungsteil durch> die definierte Frequenz zulässig wäre?
Diese Betrachtung macht keinen Sinn, weil man jederzeit eine
Taktkonstellation annehmen kann, bei der eine gerade auftauchende 1
direkt durch den Takt geschnappt wird, während das Signal selber weiter
hinten im Chip nicht nichts hat veranstalten können.
Sobald du auf die Picosekunden schaust, gibt es zahlreiche solcher
Fälle.
> Pegelwechsel des Reset-Signal von high auf low nicht innerhalb einer> Taktperiode mitbekommen würde, weil die Signallaufzeit des Reset-Signals> zu diesem Teil der Schaltung zu lange dauert?
Dein high/low gibt es nur Außen am Pin und nicht innen im design und
dort wiederum gibt es keine Laufzeit, zumindest nicht für dich in der
Designphase. Was dann hinterher real passiert, hängt allein von der
Konstellation ab, wann das Signal und wann der Takt kommt. Kann alles
sein.
> Ich habe einfach einen Knoten im Hirn wie ein Tool damit umgehen würde,> dass ein Takt verwendet wird um den Pegelwechsel des Resets von high auf> low zu übernehmen, der Zugriff auf dieses Signal aber mit einer> asynchronen Beschreibung erfolgt.
Die tools gehen täglich damit um, indem sie dieses Verhalten ignorieren.
Es erfolgt keine Annahme, wann ein asynchrones Signal kommt. Nur bei
zueinander synchronen Signalen, Busbits gegen strobe ist das wichtig.
Nochmal: Ein Signal, welches ohne Einsynchronisation in eine Schaltung
fließt, kommt zu nicht exakt deterministischen Zeiten an. Das gilt auch
für FPGAs. In manchen FFs ist es eben in einem anderen Takt evident als
in anderen, je nachdem welche Kombinatorik noch damit verbunden ist.
Genau deshalb vereinfacht man sich die Sache durch das Synchronisieren.
Die Verwendung eines externen Signals einmal am asynchronen FF-Port und
einmal am synchronen führt dann genau zu dem Paradoxon, dass sich die
Informationen widersprechen können. Deshalb baut das kein vernünftiger
Mensch ein und auch Altera, die diese Option des asynch resets als
exklusive Funktion anbieten, wirft hier eine entsprechende Warnung aus.
Ein und dieselbe Information in einem design mehrfach in abweichender
Form zu verwenden, ist einfach Käse und erzeugt Probleme, die komplett
unnötig sind. Daher macht es auch keinen Sinn, einen negierten und einen
nicht negierten Reset in VHDL-Module zu schicken.
> Ich weiß natürlich, dass ich mir die Frage hätte sparen können, wenn ich> immer die synchrone Beschreibung verwende. Aber ich versuche die> Funktionsweise zu verstehen
Du musst dich entscheiden, ob du ein physisches design bauen willst, wie
man früher ASICs gebaut hat, mit Signallaufzeitbetrachtung, balancieren
des Clock-Baums, partiell intertierten Takten, partiell invertierten
Logiken ...
oder ob du ein Logikdesign bauen möchtest, dass vom Synthesetool gebaut
wird, nachdem es deine Randbedingungen kennt. In diesem Fall kannst du
High/Low, Schaltzeiten, Laufzeiten, Signalinvertierungen direkt
streichen und dich darauf konzentrieren, dem tool mitzuteilen, welche
Signale zusammengehören und bitte binnen eines Taktes von einer Domäne
(als auch von und nach Draußen) nach drinnen in die Register zu wandern
haben.
Wenn ich deine Frage richtig verstehe, erwartest du, dass sich die
Schaltung bei Wegnehmen des Resets wie beim Wegnehmen eines synchronen
Resets (einen Takt früher?) verhält, auch wenn bei manchen Flip-Flops
der Reseteingang asynchron ist, und fragst dich, ob das Tool das
überprüft.
Ich weiß es nicht und ich weiß nicht, ob es eine sinnvolle Frage ist.
Aber Vivado führt für asynchrone Resets eine Recovery/Removal Analyse
durch. Ich weiß nicht, was das ist, aber vielleicht hat es was damit zu
tun.
Hallo zusammen,
ein RIESENGROSSES Dankeschön für die ausführlichen Antworten und
Erklärungen. Ich habe einiges verstanden und neu dazugelernt und viele
andere Punkte erfahren, bei denen ich mich noch gezielt einlesen kann.
DANKE!!
Dominik schrieb:> Ich synchronisiere ein externes Reset-Signal ein, d.h. ich habe einen> Prozess, in welchem ich das Signal synchron zu meinem Taktsignal mache.> Wenn ich nun an anderen Stellen asynchron auf dieses Signal zugreife,> stellt das Synthese-/Implementierungstool sicher, dass bis zu diesem> Punkt das Timing im Hinblick auf meinen Takt nicht „verletzt“ wird?
Ja.
Der Witz ist ja, dass ein "Verletzen" des Timings nur dann passieren
kann, wenn dieses Signal ausgewertet und dann wieder in ein Flipflop
geht.
> Anders ausgedrückt: wenn ich mein einsynchronisiertes Reset aufhebe,> kann ich dann davon ausgehen, dass bei der nächsten steigenden> Taktflanke alle Prozesse sehen, dass das Reset-Signal aufgehoben wurde?
Es ist egal, was irgendwelche Prozesse "sehen". Letztlich kommt es nur
darauf an, dass rechtzeitig vor dem nächsten Takt die Signale am
Flipflopeingang stabil sind.
Dominik schrieb:> Ich hatte mir nun vorgestellt, dass es durchaus passieren kann, dass> beim Place and Route zwei Schaltungsteile, welche den beschriebenen> asynchronen Reset verwenden, innerhalb des FPGA weit entfernt von> einander platziert werden könnten. Die Laufzeit des Reset-Signals zu> diesen Schaltungsteilen ist dann sehr verschieden.
Die Toolchain stellt sicher, dass die Laufzeit eingehalten wird. Kann
sie das nicht, dann bekommst du einen Fehler (vorausgesetzt, du hast in
einem Clock-Constraint mitgeteilt, wie viel Zeit dafür zur Verfügung
steht.
> Ich habe einfach einen Knoten im Hirn wie ein Tool damit umgehen würde,> dass ein Takt verwendet wird um den Pegelwechsel des Resets von high auf> low zu übernehmen, der Zugriff auf dieses Signal aber mit einer> asynchronen Beschreibung erfolgt.
Du bezahlst den FPGA-Hersteller dafür, dass er seinen Baustein so baut,
dass solche "Race-Conditions" durch das Taktsignal und daraus folgenden
Raktionen nicht auftreten und somit das Verhalten determinstisch ist und
aus dem Datenblatt abgelesen werden können.
Mal deine Beispiele genommen und zur leichteren Vergleichbarkeit ein
wenig egalisiert (im Prinzip ist das aber trotzdem dein Code):
1
process
2
begin
3
waituntilrising_edge(clk);
4
if(reset='1')then
5
x<='0';-- zurücksetzen
6
else
7
x<='1';-- setzen
8
endif;
9
endprocess;
10
11
process(clk,reset)
12
begin
13
if(reset='1')then
14
y<='0';-- zurücksetzen
15
elsif(rising_edge(clk))then
16
y<='1';-- setzen
17
endif;
18
endprocess;
Dann ist leicht zu erkennen, dass der synchrone Reset, der z.B. bei der
Taktflanke t=-1 noch aktiv ist und durch die Taktflanke t=0 (also im
Desgin ein paar ps nach dieser Flanke t=0) inaktiv wird, in beiden
Fällen zwar unterschiedlich "wirkt", dies aber keine Auswirkungen auf
das Ergebnis hat.
Denn sowohl in der synchronen wie in der asynchronen Beschreibung wirkt
sich das Deaktivieren des Resets zum gleichen Zeitpunkt aus, nämlich
nach der Flanke t=+1 durch das Setzen von x und y auf '1'. Dass das
asynchrone Flipflop den Reset schon kurz nach der Flanke t=0 "verlassen"
hat, wird ebenso wie beim synchronen Flipflop erst mit der (bzw. durch
die) Taktflanke t=+1 sichtbar.
S. R. schrieb:> Zumal Xilinx m.W. dafür wirbt, keinen Reset einzusetzen.
Nicht ganz. Man soll nicht einen synchronen Zähler asynchron
zurücksetzen. Denn Xilinx kennt zwei Modi (oder gar 3) für die
Flipflops:
1. als synchrones Flipflop mit Set und Reset Eingängen,
2. als asynchrones Flipflop mit Clear und Preset oder gar
3. als Latch mit diversen Varianten.
Und wenn ein Flipflop asynchron beschrieben wurde, dann kann z.B. ein
synchroner Zähler nur ungünstig mit Mehraufwand in der Logik
implementiert werden.
Siehe auch dort in
https://www.mikrocontroller.net/articles/Reset_f%C3%BCr_FPGA/CPLD die
unteren drei Zeilen...
EDIT: Hoppla, zu spät, der Groschen ist offenbar schon gefallen... ;-)
Lothar M. schrieb:> EDIT: Hoppla, zu spät, der Groschen ist offenbar schon gefallen... ;-)
Danke trotzdem vielmals für diese sehr saubere Ausführung.
Hatte mir die Frage nämlich auch schon gestellt, ob ich mir irgendetwas
einhandle, wenn ich unterschiedliche Reset Beschreibungen mische (Was ja
sehr schnell passiert beim wiederverwenden von Code aus
unterschiedlichen Quellen).
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