Reset für mehrere Komponenten

[Jörg (Gast)]

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

[Jan M. (mueschel)]

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.

[Jörg (Gast)]

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

[Jan M. (mueschel)]

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

asynchron:

  if RESET = '1' then
    --RESET
  elsif rising_edge(CLK) then
    --Normal Operation
  end if;

synchron:

  if rising_edge(CLK) then
    if RESET = '1' then
      --RESET
    else
      --Normal Operation
    end if;
  end if;

[Gast (Gast)]

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

[Jörg (Gast)]

@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

[Morin (Gast)]

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.

[Jan M. (mueschel)]

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.

[Holger (Gast)]

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

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

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:

  if RESET = '1' then
    --RESET
  elsif rising_edge(CLK) then
    --Normal Operation
  end if;

wie auch synchron:

  if rising_edge(CLK) then
    if RESET = '1' then
      --RESET
    else
      --Normal Operation
    end if;
  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

[Jörg (Gast)]

@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

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

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

[Jörg (Gast)]

@ 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

[Morin (Gast)]

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

process(clk) begin
  if clk'event and clk='1' then
    if reset='1' then
      d <= ... (Vorbelegung) ...
    else
      d <= ... (Berechnung) ...
    end if;
  end if;
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.