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:
1
ifrising_edge(clk)then
2
ifreset='1'then
3
--hier allen signalen gewünschte Werte zuweisen
4
else
5
--hier der eigentliche Code
6
endif;
7
endif;
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:
1
ifreset='1'then
2
--hier allen signalen gewünschte Werte zuweisen
3
elsifrising_edge(clk)then
4
--hier der eigentliche Code
5
endif;
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.
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?
@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
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
@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
@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. :)
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
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
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...
@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 FPGAjedes 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.
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?
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
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