Nun mal Tacheles mit den Resets

[Christian P. (kron)]

Hallo,

ich habe viel viel viel über Resets gelesen,
ich Büchern, in PDFs, hier auf der Seite und im Forum.
Aber eine richtig glasklare Meinung konnte ich mir
bisher trotzdem nicht bilden.
Deswegen möchte ich hier nochmal höchst sachlich
(weil das ja teilweise schon religiöse Züge annimmt bei manchen)
darüber diskutieren.
Ich schreibe jetzt mal alles so, wie ich es bisher verstanden habe.

Ich meine hier jetzt mit Reset übrigens allgemein das Setzen
der Signale auf einen gewünschten (irgendwo angegebenen) Wert.

Aalso, zunächst muss man doch unterscheiden zwischen
Simulation und Synthese.

Bei der Sim hat ein Signal, wenn es mit := '1' nicht bei
der Deklaration einen Wert zugewiesen bekommen hat, ein 'U'.
Und damit kann man natürlich nicht immer sinnvoll simulieren,
wenn man das Signal z.B. mit "s1 <= NOT s1" nutzen will.
Hier benötigt man also einen Resetzweig, der alle sich im jeweiligen
Prozess ändernden Signalen einen Startwert gibt. Right?

Bei der Synthese sieht das ja dann schon anders aus.
Im FPGA sind kleine Flipflops, und die kennen kein 'U',
die sind entweder 1 oder 0, stimmts?
D.h., irgendeinen Wert hat jedes Signal nach dem Einschalten,
man weiß halt nur nicht genau, welchen. Oder?
Außerdem wird doch ein Reset im FPGA nicht so schön einfach
wie in der Sim ausgelöst, wo ich ja in 'nem Prozess halt
einfach für ein paar Nanosekunden "Reset <= '1'" o.ä. schreibe.
Da gibt es doch nur die Möglichkeiten, dass irgendwo ein Reset-Knöpfchen
ist, welches jemand drückt, oder dass es intern durch etwas ausgelöst 
wird.
Aber manchmal möchte man halt, dass bestimmte Signale eben genau
mit 1 oder 0 starten, und nicht mit egalwas. Und wie ich schon
gemerkt habe, ist die Aussage, dass Signale auch bei der Synthese
mit := vorbestimmt werden, eher umstritten. Zumindest ältere 
ISE-Versionen
ignorieren solche Konstrukte.

Egal, jedenfalls sind wir ja damit beim Thema schlechthin,
synchron oder asynchron. (Bitte hier dramatische Musik denken ;) )
Also, synchroner Reset sieht ja (ganz vereinfacht) so aus:

if rising_edge(clk) then
 if reset = '1' then
  --hier allen signalen gewünschte Werte zuweisen
 else
  --hier der eigentliche Code
 end if;
end if;

Das einzige Problem dabei, was ich so erlesen habe, ist die Tatsache,
dass ein funktionierendes Clock-Signal anliegen muss, damit der Reset
überhaupt ausgelöst werden kann. Kein clk -> kein Reset.
Demgegenüber der asynchrone Reset:

if reset = '1' then
 --hier allen signalen gewünschte Werte zuweisen
elsif rising_edge(clk) then
 --hier der eigentliche Code
end if;

So, hier knallt der Reset auch ohne clk, aber deswegen auch nicht
synchron dazu, was wohl bei bestimmten Schaltungen und Situationen
zu Problemem führen kann (an der Stelle A ist das FlipFlop Resettet,
an Stelle B nicht). Außerdem soll wohl der asynchrone Reset auch
mehr Resourcen verbrauchen, aber da bin ich mir nicht so sicher.

Und dann gibt es quasi noch "Mischformen", also z.B. ein Asynchroner
Reset, der nur an einer Stelle verwendet wird und dort wird dann
ein synchrones Reset-Signal erzeugt, welches alles andere resettet.

Ok, das war so ungefähr das, was ich mir zusammengereimt habe.
Wie gesagt, ich will keinen Streit, sondern möglichst klare
Aussagen, warum was verwendet werden sollte oder könnte.
(Schon klar, dass das auch von Situation
zu Situation verschieden sein kann)
Aber wir wollen ja alle Lernen (voneinander), und es gibt
sicher viele, die auch nicht sicher sind, warum nun wie
zurückgesetzt werden soll.
Danke fürs Lesen und evtl. Antworten.

[Fried V. (tich)]

Hallo,
die Fragestellung interessiert mich auch sehr (Ich komme von der uP 
Programmierung und habe durchaus noch Probleme damit diese ganze 
nebenläufige Digitaltechnik voll zu durchdringen). Weiter unten habe ich 
eine Minianwendung (Schreibmaschine) für ein Altera DE2 Board 
hochgeladen, nach dem downloaden wird automatisch der Reset durchlaufen, 
ganz so als ob ich den gleichfalls implementierten synchronen 
Reset-Button gedrückt hätte. Ganz klar ist mir der Ablauf da auch nicht?

[ChrisV (Gast)]

@Christian:

Zu deiner Zusammenfassung lässt sich nicht viel hinzufügen. Du hast alle 
Probleme diesbezüglich aufgezählt.

Man sollte sich eben immer die Frage stellen ob ein Reset nötig ist. Für 
die allermeisten Schaltungen ist er eben nur nötig um nach dem 
Einschalten einen definierten Zustand zu haben, und genau dass lässt 
sich bei der Deklaration schon zuweisen. Da das ganze ab etwa V7 der 
Xilinx ISE auch für die Simulation tut gibt es für mich meist keinen 
Grund mehr ein Reset Signal zu verwenden.
Falls ich dann doch mal Signale während des Betriebes auf irgendeinen 
Wert setzen muss, versuch ich zumindest um einen asynchronen Reset 
herumzukommen. Die Fehler die durch Asynchrone Signale auftauchen können 
wie z.B. teilweise zurückgesetzte Register sind SEHR schwer zu finden 
und verursachen mitunter Effekte die einen dazu bringen können an sich 
selber zu zweifeln :-)

Das Argument, dass sich die Schaltung dann nur zurücksetzen lässt wenn 
ein Takt anliegt ist sicher richtig. Allerdings ist es auch meistens so, 
dass wenn kein Takt anliegt, die Schaltung keine sinnvollen Dinge tut, 
weshalb dann auch ein Reset mir nicht weiterhilft.

Zum Thema Ressourcenverbrauch bei Mixturen aus synchronen und 
asynchronen signalen kann ich nur immer wieder das TechXclusive [1] von 
Ken Chapman von Xilinx empfehlen. Da werden die zusammenhänge auf klare 
und erfrischende Art erklärt.

So, Dass ist meine Meinung dazu, und die habe ich mir durch leidvolle 
Debugsitzungen am Logikanalyzer gebildet.

Beste Grüße,
Christof

[1]:
http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?iLanguageID=1&category=&sGlobalNavPick=&sSecondaryNavPick=&multPartNum=1&sTechX_ID=kc_priorities

[Axel (Gast)]

Ich habe in solchen Fällen einen asynchronen Reset an den FF verwendet, 
der aber in einem zentralen Block so erzeugt wird, dass er zwar 
asnychron (also auch ohne Takt) den RESET erzeugt, aber nur synchron bei 
funktionierendem Takt weggeht, so dass die FF in einem sauberen Zustand 
sind.

Gruss
Axel

[Xenu (Gast)]

@Christian Peters

Zum Thema Signalinitialisierung:

Wenn Du ein Signal, welches ein Flip-Flop darstellt, initialisierst,
dann ist das der Anfangszustand dieses Flip-Flops nach dem Einschalten, 
bzw. Konfiguration.
Das funktioniert mit der aktuellen Xilinx- und Altera-Software.
Bei Xilinx funktioniert das mindestens schon seit Version 6.1 (4 Jahre 
alt), von der Version habe ich gerade das XST-Handbuch auf einer Website 
gefunden.

>Und wie ich schon gemerkt habe, ist die Aussage, dass Signale auch bei der 
>Synthese mit := vorbestimmt werden, eher umstritten.

Kein Ahnung wie Du darauf kommst.

Wenn ich mal das aktuelle XST-Handbuch zitieren darf:

"When you give a register an initial value in a declaration, XST sets 
this value on the output of the register at global reset, or at power 
up. A value assigned this way is carried in the NGC file as an INIT 
attribute on the register, and is independent of any local reset."

Viel eindeutiger geht's ja wohl nicht.

Noch was zum Thema Reset hier:

http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?iLanguageID=1&category=Devices%2FVirtex-II+Pro&sGlobalNavPick=SUPPORT&sSecondaryNavPick=&multPartNum=1&sTechX_ID=kc_smart_reset&languageID=1

[Christian P. (kron)]

@Xenu: Ich arbeite hier teilweise mit V 4.x, und da
kommt bei jedem Initialwert die Warnung, dass das ignoriert wird.
Und im Forum hier gab es auch schon die Diskussion, ob das
so ist, wie du sagst, oder doch nicht.

Aber mein Text soll ja auch nicht die Wahrheit darstellen,
sondern nur meinen Stand und damit Auftakt zur Diskussion bzw.
Richtigstellung. :)

[Dennis (Gast)]

Hi,

also ich kann dazu nur sagen Initialwerte von Signalen mit ":= value"
werden von der Synthese nicht berücksichtigt, dies ist rein für 
Simulationszwecke.

ich arbeite seit Jahren mit FPGA's(XILINX) da stellte sich die Frage 
Reset ja nein bzw synchron/asynchron. Laut XILINX ist für FPGA's ein 
synchroner Reset besser, da die Synthese mehr Möglichkeiten der 
Optimierung hat. Allerdings muss dann das RESET-Signal auch aus der 
Clockdomain kommen. Reine Datenregister sollten ohne ein Reset generiert 
werden, das spart Ressourcen und man erhält ein besseren TimingScore. 
Alle anderen Signale sollten wohl definiert sein ...

Gruss
Dennis

[Klaus F. (kfalser)]

Dennis,
wenn Du den Thread gelesen hättest, wüsstest Du daß Initialwerte für 
neuere Versionen von ISE schon funktionieren.
Das können in der Zwischenzeit mehrere Leute bestätigen.

Klaus

[Dennis (Gast)]

Hi Klaus,

da war ich wohl zu schnell Du hast recht für XST sind Initialwerte, 
allerdings nur für Memory-Elemente möglich...

http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=9917

man lernt nie aus :-)

ich benutze allerdings Mentor-Precision, da wird es noch ignoriert.

Gruß Dennis

[Bla (Gast)]

>allerdings nur für Memory-Elemente möglich

Für was anderes ist ja wohl auch ziemlich nutzlos...

[alex (Gast)]

Hallo,

wieder mal aus reiner Neugier, wie ist das eigentlich bei den FPGAs, 
gibt es da nicht spezielle Pins, die irgendwie "Global Reset" heißen? 
Das kenne ich von einigen CPLDs, hatte leider mit FPGAs wenig zu tun. 
Aber wie dem auch sei, wenn ich mich recht erinnere, wurde an den Pins 
immer ein Reset-Baustein angeschlossen und im VHDL Code ein Reset-Signal 
mit dem Pin verknüpft. Verstehe die ganze Diskussion mit 
Initialisierungswerten u.ä. nicht. Gibt es bei den FPGAs keine 
Möglichkeit, von außen sicher und ohne Probleme ein Reset-Signal 
zuzuführen, mit dem die interne Logik sowohl beim Einschalten als auch 
im laufenden Betrieb sicher in definierten Zustand zurückgesetzt werden 
kann? Oder werden die Reset-Bausteine heutzutage aus Kostengründen 
wegoptimiert...

[Lothar (Gast)]

@alex: So ein FPGA (SRAM-basierte wie z.B. Xilinx, Altera...) ist erst 
mal nichts mehr als ein Statisches RAM. Zum Laden der Konfiguration, 
also des SRAM-Inhalts, braucht so ein FPGA also so was wie einen 
Prozessor. Und ein anständiger Prozessor hat auch einen anständigen 
Reset.

Dieser Power-Up-Prozessor incl. Power-Up-Reset ist im FPGA schon fest 
eingebaut. Und weil in dem FPGA sowieso jedes Flip-Flop beim Power-Up 
per Handschlag begrüsst wird, bekommt es da auch seinen 
Initialisierungswert.

Fazit bis hier: Nach einem Power-UP ist in einem FPGA jedes Flip-Flop 
auf einem definierten Zustand (per Default '0', änderbar wie oben 
beschrieben im VHDL-Sourcecode).

Wenn jetzt allerdings der nicht Aussterben wollende rote Reset-Knopf in 
Aktion tritt, bekommt die Reset-Logik des FPGAs davon nichts mit und 
macht erst mal unbeirrt weiter (es sei denn, man löst z.B. bei Xilinx 
über den Pin PROGRAM# den Ladeprozess nochmal aus).
Um diesen besagten Reset-Knopf im FPGA zu bearbeiten, ist erst mal, wie 
für jedes andere asynchrone Signal, eine Synchronisierung zum internen 
Takt nötig. Dann kann das Reset-Signal im FPGA an die betreffenden 
Stellen durchgereicht und dort synchron bearbeitet werden.

[alex (Gast)]

D.h. es wäre einfacher und vielleicht sicherer, bei einem Reset einen 
FPGA einfach neu zu laden, weil danach alle Flipflops default 0 sind 
oder mit Initialisierungswerten geladen werden?
Ist es möglich, dass ein Ladevorgang irgendwie durch irgendwas gestört 
wird?

[Joerg W. (joergwolfram)]

Ich habe bis jetzt eigentlich fast immer auf Reset verzichtet und die 
Designs so "gestaltet", dass sie sich selbst nach ein paar Takten in 
einen definierten Zustand bringen. Ist doch ein Reset nötig, sollte 
dieser als normales Signal behandelt werden, da zum Beispiel bei 
Memory-Controllern eventuell noch Schreibzugriffe abgeschlossen werden 
müssen. Bei CPLD's kann man auch einfach den globalen Tristate als Reset 
nehmen, und während des Resets (der ja meistens eine Zeitlang anliegt) 
die interne Struktur in einen definierten Zustand bringen.

Gruß Jörg

[Breti (Gast)]

Ich hatte gerade in der letzten Woche einiges über ISE und Resets 
gelernt. Nach einem mir unerklärlichen Problem erklärte mir Xilinx, dass 
es wohl so ist, dass ältere versionen von ISE (also vor der 9er) mit dem 
asynchronen Reset nicht so richtig klar kommen und unsinnig viel und 
teilweise prolbematische Logik erstellen. Daher sollte man unbedingt 
einen synchronen Reset nutzen, wenn nötig.
Der Supporter sprach sogar davon, dass ein asynchroner reset das design 
dadurch um bis zu 30% aufblähen kann.

In meinem spziellen Fall war es so, dass Werte bei der Übergabe an ein 
Fifo manchmal einfach verloren gingen. Nach Umstellung auf synchronen 
Reset funktioniert es nun problemlos - obowohl in diesem Fall das Design 
noch um ca. 10 Slices gewachsen ist.

Gruß,
Thomas