(asynchronen) Reset vermeiden. oder nicht?

Sym schrieb:
> Reset wird bei den FPGAs über ein Taktnetz verteilt.
Aber garantiert nicht bei allen!

> Reset wird bei den FPGAs über ein Taktnetz verteilt. Das heißt aber
> noch lange nicht, dass der Reset alle Register zeitgleich erreicht.
Genau das muss ein Taktnetz aber garantieren.

> Dadurch wird der Reset eingetakt und Probleme mit
> der Metastabilität umgangen.
Bleib mit der Metastabilität aus diesem Thema raus. Es ist zum 
überwiegendsten Teil ein Problem von simplen Laufzeiten.
http://www.lothar-miller.de/s9y/categories/35-Einsynchronisieren
Ich würde wetten, du hast bei Taktfrequenzen kleiner 200MHz bei 
aktuellen FPGAs noch nie ein Problem mit einem metastabilen FF gehabt. 
Sehr wohl aber mit unterschiedlichen Laufzeiten wegen eines nicht 
artgerecht einsynchronisierten Eingangs.
Und ich hätte sehr gute Chancen auf einen Gewinn...  ;-)

Kurz: ob ein asynchroner Reset beschrieben werden darf oder sogar 
sollte, hängt von der Zielarchitektur ab.
Siehe auch den Beitrag "Xilinx und die Resets"

Konstantin L. schrieb:
> Reset würde von den Tools intern über ein reset Netz verteilt.
Es gibt ein globales Resetnetzwerk, an das alle FFs angeschlossen 
sind. Aber weil in deinem Design garantiert (!) nicht für alle Elemente 
ein Reset beschreiben ist, kann dieses Netz nicht verwendet werden.
Fazit: Der Reset wird händisch gereoutet...
Nicht mehr...

> Und einen noch so kurzen Puls bekommen doch
> trotzdem alle angeschlossenen FF irgendwann mit.
Nein.
Das gibt dann auch lustige Fehler, wenn dir das halbe Design 
zurückgesetzt wird. Und jedesmal eine andere Hälfte...  :-o

> Bei Herrn Miller ist ja eine Schaltung vorgestellt,
> die einen (nahezu) beliebig kurzen Puls auf Taktlänge bringt.
Das schnelle Reagieren macht für einen Reset keinen Sinn.
Ich gehe (wenn ich mal unbedingt muß) eher den anderen Weg: das externe 
Resetsignal muß mindestens 100 Taktzyklen stabil anliegen, sonst wars 
evtl. nur ein EMV-Spike...

Sym schrieb:
> Allerdings darf man das Resetsignal nicht knapp nach der Taktflanke der
> FFs zurücksetzen, weil man sonst die Removal Time verletzt.
Die Haltezeit von FFs in aktuellen FPGAs ist 0ns. Es gibt nur noch eine 
Setup-Zeit zu beachten.

> Ein möglicher Weg ist es daher, das Reset auf die andere Flanke
> zurückzusetzen. (d.h. FFs auf rising edge, reset wird bei falling
> edge deaktiviert).
Damit verdoppelst du virtuell die Taktfrequenz. Denn im ersten 
Taktzyklus nach dem Reset steht nur die Hälfte der Zeit bereit, damit 
für die FFs bei der nächsten Flanke die Setup-Zeit eingehalten wird...

Sym schrieb:
> Wenn du 2x einsynchronisieren als ordnungsgemäß betrachtet, dann hast du
> verloren. Manchmal bringt tatsächlich eine 1-2 weitere Stufen die
> erhoffte Stabilität.
Dann hast du ein anderes Problem. Bei Taktfrequenzen kleiner 200MHz ist 
Metastabilität auf jeden Fall kein Thema. Siehe dazu den 
Beitrag "Detailbetrachtungen zur Metastabilität"

Hans schrieb:
>> Damit verdoppelst du virtuell die Taktfrequenz. Denn im ersten
>> Taktzyklus nach dem Reset steht nur die Hälfte der Zeit bereit, damit
>> für die FFs bei der nächsten Flanke die Setup-Zeit eingehalten wird...
> Das verstehe ich nicht. Wenn ich im Resetzustand bin, dann sollte die
> Schaltung (auch alle Flip Flops) irgendwann einen stabilen Reset-Zustand
> eingenommen haben.
Richtig: Alle Flipflops!!!
Aber wenn du einen kombinatiroschen Pfad (evtl. auch irrtümlicherweise) 
mit einem Reset versiehst, dann kommt mit oder ohne Reset was anderes 
raus. Und um diese Änderung zu berechnen hast du nur die halbe SetupZeit 
zur Verfügung.

Nimm nur mal das:

1

:

2

:

3

   mux_select <= externer_select when reset='0' else "111"; --- von hier

4

5

   process (reset, clk) begin

6

      if reset='1' then

7

         a <= "00";

8

      elsif rising_edge(clk) then

9

         if mux_select = "110" then                         --- bis hier nur halbe Setuptzeit

10

            a <= "01";                                      --- wenn Reset mit fallender Flanke inaktiv wird

11

         elsif mux_select = "010" then

12

            a <= b;

13

         :

14

         :

15

         end if; 

16

      end if;

17

   end process;

Mathi schrieb:
> Dafür hätte ich gerne einen Beleg. Hast Du eine Quelle?
Hier ein Spartan 3 (ds099):

1

Hold Times

2

TAH Time from the active transition at the CLK input 

3

to the point where data is last held at the F or G input         0 ns

Beim Virtex 5 ist es wegen der vielfältigen Möglichkeiten ein wenig 
schwieriger, aber dort finden sich sogar negative Hold-Zeiten :-o
Und dazu passend der Kommentar:

1

A Zero “0” Hold Time listing indicates no hold time or a negative hold 

2

time. Negative values cannot be guaranteed “best-case”, but if a “0” is 

3

listed, there is no positive hold time.

Es ist mir übrigens schon klar, dass es ein FF ohne oder sogar mit 
negativer Hold-Zeit nicht gibt. Solche Zeiten lassen sich mit 
Laufzeitunterschieden von den angegebenen Messpunkten bis zum 
eigentlichen Flipflop erklären. Wenn der Datenpfad länger ist, 
verschiebt sich das Validierungsfenster immer mehr in Richtung vor dem 
Takt.

Hallo Konstantin,

wenn Du schon einige Threds gelesen hast, dann hast Du sicher auch 
gemerkt, dass es in vielen Fällen die "one and only"-Lösung nicht gibt. 
So wohl auch bei der Frage nach dem Reset. Zunächst möchte ich Dir aber 
gerne, mit Verlaub, widersprechen:

Konstantin L. schrieb:
> Wie gesagt, ich habe riesige Verständnislücken das ist mir bewusst.

Das seh ich nicht so. Alleine die Formulierung deiner Frage zeigt, dass 
Dir vielleicht Erfahrung fehlt, aber nicht das nötige Verständnis. Und 
die Problematik des Reset wird nunmal von einigen Leuten unterschiedlich 
bewertet. Ich stimme Dir jedenfalls zu, wenn du meinst:

Konstantin L. schrieb:
> Dann wäre nach einem Reset alles im fpga wenigstens auf default
> Werten was für mein Gefühl irgendwie wünschenswert ist. Ich denke an
> Automaten, default Registerwerte usw. die doch zum Rest des
> zurückgesetzten Systems passen müssen.

Die Bedenken der meisten Antwortschreiber gehen in die gleich Richtung: 
Es darf nicht sein, dass durch ein irgendwie geartetes Signal an einem 
Reset-PIN des FPGAs dieses aus dem Tritt kommt. Und was ein prellender 
Taster für ein Signal abgibt, oder ein RC-Glied beim langsamen 
Durchlaufen der Schaltschwelle, das sieht oftmals gräulich aus. Ich habe 
mir daher meistens Filter in das Reset-Signal eingebaut. Etwa in der 
Art: Das Signal vom Reset-Taster (oder sonstwo her) muss mindestens n 
Takte lange aktiv sein, bevor es an die interne Logik gegeben wird. 
Gleiches für das Ende von Reset. Und das dann Ganze immer synchron.

Zuletzt noch meine Einschätzung zu deinem konkreten Fragen:

Reset würde von den Tools intern über ein reset Netz verteilt. ist das 
richtig? Die Tools denken inzwischen mit und verteilen Clocks, Resets, 
und weitere Signale mit hohem fan-out (= viele Benutzer) über spezielle 
Routing-Ressourcen.

Wenn das so ist sollte doch das Problem, daß die FF reset zeitlich 
extrem versetzt bekommen entschärft sein? Entschärft ja, weg nein.

Und einen noch so kurzen Puls bekommen doch trotzdem alle 
angeschlossenen FF irgendwann mit. Nee, leider nicht. Innerhalb des FPGA 
könnten tatsächlich einige Flipflops einen kurzen Reset übersehen. Die 
Welt ist leider nicht digital.

Wenn nach einem reset eine gewisse Zeit kein clk anliegt, gibt es dann 
Probleme mit nicht zurückgesetzten FF? Ein extrem kurzer Reset könnte 
eine Statemachine in einen Zustand bringen, aus dem es keinen Ausweg 
gibt.

Als gefährlich war ja auch das Szenario beschrieben wenn reset eben 
unmittelbar vor clk eintritt. Stoppt der reset Knopf den Takt - keine 
Probleme? Bis auf eben den Fall dass nicht alle Flipflops den Reset 
gesehen haben.

Sollte man dann ein reset Signal eintakten und im ganzen Design 
taktsynchron verwenden? Klares Ja.

Grüße, und viel Erfolg
Harald

Harald Flügel schrieb:
> Sollte man dann ein reset Signal eintakten und im ganzen Design
> taktsynchron verwenden? Klares Ja.
Ein klares ja deshalb, weil jedes asynchrone Signal irgendeine 
Einsynchronisierung (oder Validierung) braucht. Und der Reset ist ja 
wohl das asynchronste Signal schlechthin.

> Als gefährlich war ja auch das Szenario beschrieben wenn reset eben
> unmittelbar vor clk eintritt.
Dieser Fall ist eigentlich ziemlich unkritisch. Wenn der lang genug 
anliegt, werden früher oder später alle FF den Reset gesehen haben (und 
bestenfalls währen der paar ps eine FSM den falschen Zustand 
dargestellen).
Kritischer ist das Verlassen des Reset-Zustandes. Denn wenn hier ein 
paar FFs einer FSM schon mit den von aussen anliegenden Signalen 
arbeiten, und andere noch für einen Takt im Reset-Zustand sind, dann 
läuft das Design nicht richtig an...
Das hört man dann auch immer wieder: "Mein Design startet manchmal nicht 
richtig. Aber wenn es läuft, dann tagelang problemlos."   :-o

Hans schrieb:
> Lothar Miller schrieb:
>> Aber wenn du einen kombinatorischen Pfad (evtl. auch irrtümlicherweise)
>> mit einem Reset versiehst
> Das ist aber nun allerschlechteste Designpraxis. Wer ein asynchrones
> Signal in dem kombinatorischen Signalpfad abfragt gehört geschlagen.
Richtig, ich schrieb: irrtümlicherweise. Das kann auch so entstehen, 
dass da mal ein registriertes Signal war, das aber nach Umschreiben 
irgendeiner Zeile auf einmal nur noch kombinatorisch ist.

Ge- und erschlagen wird er dann von der Realität... ;-)

NeunmalKlug schrieb:
> (Hinweis: ,dass)
Das müsste eher ", dass" heißen, denn sonst gehts Richtung Plenken... 
;-)