Forum: FPGA, VHDL & Co. Reset für mehrere Komponenten


von Jörg (Gast)


Lesenswert?

Hallo zusammen,

wie gehe ich bei mehreren Komponenten mit dem Reset-Signal um?
Kann/sollte u.U. ein GlobalBuffer (bei Xilinx: BUFG) verwendet
werden?

Ich denke dabei z.B. an folgende Situation: Ein komplexer
Automat wird in mehrere einfache Teilautomaten zerlegt (als
FSM implementiert) und je Automat wird eine Komponente generiert.
Bei einem Reset müssen dann alle FSMs synchron resetet werden.
Das Problem stellt dann z.B. sich durch das Auto-P&R, falls die
Komponenten weit auseinander gelegt werden und die Laufzeiten der 
Reset-Signale zu den Komponenten zu unterschiedlich ist.


Gruss,

Jörg

von Jan M. (mueschel)


Lesenswert?

Wenn du synchrone Resets benutzt, ist das alles kein Problem, da die 
Laufzeiten automatisch berücksichtigt werden. Falls notwendig / sinnvoll 
wird auch ein globales Signalnetz verwendet.

Nur bei asynhronen Resets kann es Probleme geben; nicht nur deswegen 
sollten diese aber ohnehin vermieden werden.

von Jörg (Gast)


Lesenswert?

Sorry,

habe ich leider vergessen zu erwähnen: Das Reset-Signal kann als
Synchron angenommen werden, z.B. durch Entprellung oder durch
eine eigene (synchron zum Rest laufende) Reset-Logik.

Gruss

Jörg

von Jan M. (mueschel)


Lesenswert?

Ich meine nicht das Signal an sich, sondern wie es eingesetzt wird:

asynchron:
1
  if RESET = '1' then
2
    --RESET
3
  elsif rising_edge(CLK) then
4
    --Normal Operation
5
  end if;

synchron:
1
  if rising_edge(CLK) then
2
    if RESET = '1' then
3
      --RESET
4
    else
5
      --Normal Operation
6
    end if;
7
  end if;

von Gast (Gast)


Lesenswert?

Es gibt von Xilinx ein Paper das sich mit dem Timingverhalten von 
Resetsignalen beschäftigt. Sollte man mal gelesen haben.
http://www.xilinx.com/support/documentation/white_papers/wp272.pdf

von Jörg (Gast)


Lesenswert?

@Jan M.,

beide Designs erzeugen ja unterschiedliche Implementierungen: das Erste
generiert ein FF mit async. Reset, das Zweite ein FF mit sync. Reset.
Bei async. Design (dein zweites Beispiel) machen dann unterschiedliche
Laufzeiten Probleme, oder sehe ich das falsch?

Zu deinem ersten Beitrag: Nimmt man im Prozess ein sync. Reset
(dein Design-Stil 1), dann werden die Laufzeiten bei der Synthese bzw.
Implementierung entsprechend berücksichtigt (in Form von max Frequenz
etc.), d.h. damit ist man dann auf der sicheren Seite.

Bleibt für mich aber noch ein gravierendes Problem: Wenn die Komponenten
in unterschiedlichen Hierarchien in verschiedenen Tiefen angeordnet sind 
und zwecks Laufzeitverkürzung FFs als Zwischenpuffer einsetzte, dann
können bei unterschiedlichen Pfaden ungleiche Anzahlen von Puffer-FFs 
gegeben sein. In diesem Fall werden z.B. nicht alle FSMs gleichzeitig
resettet. Wie kann ich da vorgehen? (eine Lösung ist natürlich das
Abzählen der Puffer-FFs und ggf das Hinzufügen und Löschen, eine andere
der Einsatz einer BUFG-Komponente)

Gruss und Danke bis jetzt,

Jörg




Gruss

Jörg

von Morin (Gast)


Lesenswert?

Um den Beitrag von Jan etwas zu verdeutlichen:

- ohne weitere Vorkehrungen braucht der Reset unterschiedliche 
Laufzeiten zu den einzelnen FFs
- bei asynchronem Reset macht das Ärger
- bei asynchronem Reset machen noch ganz andere Sachen Ärger
- bei synchronem Reset machen die unterschiedlichen Laufzeiten keine 
Probleme, solange sie kürzer als die Clockperiode + Setup-Zeit sind
- bei synchronem Reset wird der Reset als Datenpfad behandelt und die 
Reset-Laufzeit in die minimale Clock-Periode (bzw. maximale 
Taktfrequenz) mit eingerechnet

Ich füge noch hinzu:

Bei den meisten Designs ist der Reset vor allem zum Testen da. Wenn die 
Fehler ausgemerzt sind, lassen sich die meisten Resets durch sinnvolle 
Initialisierungen zur Konfigurationszeit ersetzen - eine Schaltung, die 
nicht abstürzt, muss auch nicht resettet werden.

von Jan M. (mueschel)


Lesenswert?

Danke für die Ergänzung morin.

@Jörg: Wenn du nicht gerade mit den maximalen Taktfrequenzen der Chips 
arbeiten musst und du synchron resettete (hm... resetierte? 
zurückgesetzte!) FF benutzt, brauchst du dir da keine Gedanken über 
irgendwelche speziellen Konstrukte (zusätzliche FF, BUFG...) zu machen, 
bevor du nicht ein Problem beim timing-Report bekommst.

von Holger (Gast)


Lesenswert?

@Jörg
Du soltest dich mal zum Beispiel in das Thema:  PCI Bus
mit seiner spezifischen (FSM) einlesen,
bzw. ein echtes PCI Eval Board besorgen.

Mir hat das sehr geholfen, nicht nur Selbst-Befriedigung
im Speicher mit den Sim-Tools zu machen.

Du bekommst nach einiger Zeit da ein gutes Gefühl dafur
was für gute u. schlechte Code-Techniken im Netz rumgeistern
bzw. was für dedizierte I/0 oder Reset-Pinne man dem
Teil noch so aufbürden sollte und kann.

Durch ständiges spielen daran wird man immer besser.
Nun kommt man aber leider dadurch zu dem Schluss:
Je mehr man darüber weiss, desto .... weniger ....

Gruss Holger mit der Brille jetz auf.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Der eigentliche Witz beim Reset ist nicht das Eintreten in den 
Reset-Zustand. Nein, die Probleme tauchen erst auf, wenn der Reset 
wieder verlassen wird.

Und spätestens dann wird klar, dass sowohl asynchron:
1
  if RESET = '1' then
2
    --RESET
3
  elsif rising_edge(CLK) then
4
    --Normal Operation
5
  end if;

wie auch synchron:
1
  if rising_edge(CLK) then
2
    if RESET = '1' then
3
      --RESET
4
    else
5
      --Normal Operation
6
    end if;
7
  end if;

nur dann funktionieren, wenn der Reset-Eingang auf das Taktsignal 
synchronisiert ist. Denn sonst könnte ja z.B. genau zum steigenden Takt 
der Reset inaktiv werden. In der Folge haben alle angeschlossenen FFs 
mit einer Setup/Hold-Zeit-Verletzung zu kämpfen. Und dieser Kampf geht 
oft unerwartet aus.

Also:
- Reset einsynchronisieren
  (Reset ist der asynchrone Eingang schlechthin)
- Reset nur dort einbauen, wo er auch wirklich gebraucht wird
  (Defaultwerte können bei der Synthese angegeben werden)
- synchronen Reset verwenden
  (gibt effizientere Logik)
- auf Set-Reset-Priorität achten
  (gibt effizientere Logik)
- das angesprochene White-Paper lesen

von Jörg (Gast)


Lesenswert?

@Lothar Miller (lkmiller),

was ist die "Set-Reset-Priorität" und auf was muss man da achten?
Meinst du vieleicht die Reihenfolge der IF-Konstrukte?

Gruss

Jörg

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

@ Jörg
> Meinst du vieleicht die Reihenfolge der IF-Konstrukte?
Ja, genau.
Das hatten wir im Beitrag "Re: Hardware mit VHDL "richtig" beschreiben." 
schon mal.

von Jörg (Gast)


Lesenswert?

@ Lothar Miller (lkmiller),

sorry, aber den Thread habe ich leider erst jetzt gelesen, habe nur
nach "RESET" in den Betreffs anderer Threads gesucht.

Vieleicht auch interesant ist ein weiteres White Paper (wird im obigen
erwähnt):

http://www.xilinx.com/support/documentation/white_papers/wp275.pdf

(beschreibt uA das von dir angesprochene).

Mein eigentliches Problem war aber, dass ich bei hierachischem Design
mit grösserer Tiefe meine Signale zur Kommunikation oft puffere (z.B.
FFs), um uA die Pfadlaufzeit zu verkürzen (auf Kosten der Latenz),
was aber bei einem Reset sehr gefährlich ist/sein kann.
Beim Resetten habe ich eigentlich nur an einzelne Komponenten gedacht,
nie an das komplette Design. Wenn ich also nur einen kleinen Teil
resetten möchte, muss ich also nur (z.B. im Floorplaner) darauf achten,
dass die zugehörigen Logik-Elemente "nahe" beieinander sind?


Gruss und Danke,

Jörg

von Morin (Gast)


Lesenswert?

> Mein eigentliches Problem war aber, dass ich bei hierachischem Design
> mit grösserer Tiefe meine Signale zur Kommunikation oft puffere (z.B.
> FFs), um uA die Pfadlaufzeit zu verkürzen (auf Kosten der Latenz),
> was aber bei einem Reset sehr gefährlich ist/sein kann.
> Beim Resetten habe ich eigentlich nur an einzelne Komponenten gedacht,
> nie an das komplette Design. Wenn ich also nur einen kleinen Teil
> resetten möchte, muss ich also nur (z.B. im Floorplaner) darauf achten,
> dass die zugehörigen Logik-Elemente "nahe" beieinander sind?

Du must zuerst den Reset zentral einsynchronisieren (2, 3 FFs), um dich 
gegen Reset-Flanken gleichzeitig zu Clock-Flanken abzusichern.

Danach kommt die Verteilung zu den einzelnen Komponenten. Dabei spielt 
"nahe" im Floorplanner keine Rolle für die Korrektheit, sondern nur für 
die maximale Taktfrequenz (genau wie bei "langen" Datenleitungen). Was 
aber eine Rolle spielt ist die Anzahl der Pufferungs-FFs bei der 
Verteilung: Die sollte auf allen Wegen gleich sein, damit der Reset 
gleichzeitig an allen Verbrauchern ankommt.

Zuletzt wird der Reset als synchroner Reset an die Daten-FFs 
angeschlossen, also in etwa:
1
process(clk) begin
2
  if clk'event and clk='1' then
3
    if reset='1' then
4
      d <= ... (Vorbelegung) ...
5
    else
6
      d <= ... (Berechnung) ...
7
    end if;
8
  end if;
9
end process;

Wenn alles fertig ist, kannst du die Zahl der Puffer-FFs verändern (aber 
immer schön die gleiche Zahl auf allen Pfaden), um sie an die gewünschte 
Taktfrequenz anzupassen - im Prinzip sind das so eine Art 
Pipeline-Register.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.