Verständisfrage zum Timing von Signalen

[Dominik (Gast)]

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!

[Experte (Gast)]

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.

[Stefan W. (Gast)]

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

[J. S. (engineer)]

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.

[Dominik (Gast)]

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:

process (clk, reset_in) 
begin 
  if (reset_in = '1') then 
    sr <= (others => '1'); 
  elsif (rising_edge(clk)) then 
    sr(0) <= '0'; 
    for i in 0 to (sr_length - 2) loop 
      sr(i + 1) <= sr(i); 
    end loop; 
  end if; 
end process; 
  
reset <= sr(sr'left);

Wenn ich in einem weiteren Prozess das Reset-Signal wie folgt verwende:

process 
begin 
  wait until rising_edge(clk); 
  -- code 
  if (reset = '1') then   -- reset als letzte if-Abfrage im Prozess 
  -- code 
  end if; 
end process;

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:

process (clk, reset) 
begin 
  if (reset = '1') then 
    -- code 
  elsif (rising_edge(clk)) then 
    -- code
  end if; 
end process;

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

[S. R. (svenska)]

Meine Laienaussage lautet wie folgt...

Wenn du einen asynchronen Reset baust, also

if reset = '1' then
  ...
elsif rising_edge(clk) then
  ...
end if

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.

[J. S. (engineer)]

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.

[Stefan W. (Gast)]

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.

[Dominik (Gast)]

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

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

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

process 
begin 
  wait until rising_edge(clk); 
  if (reset = '1') then
    x <= '0'; -- zurücksetzen
  else
    x <= '1'; -- setzen
  end if; 
end process; 

process (clk, reset) 
begin 
  if (reset = '1') then 
    y <= '0'; -- zurücksetzen
  elsif (rising_edge(clk)) then 
    y <= '1'; -- setzen
  end if; 
end process;

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

[Christoph Z. (christophz)]

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