www.mikrocontroller.net

Forum: FPGA, VHDL & Co. System interner Reset


Autor: Paul Jensen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich habe mir von einem Kollegen ein FPGA Board geliehen, da ich gern
etwas mit VHDL rumspielen würde. Die ersten kleinen Testprogramme
laufen schon erfolgreich. Als ich etwas mit dem 'Dignal Clock
Manager' (DCM) probiert habe, musste ich nach tausenden Fehlversuchen
feststellen, dass die von mir generierte DCM IP wirklich auch nur nach
einem Reset funktioniert und andern falls falsche oder keine Frequenzen
erzeugt. Im Moment resette ich den DCM von Hand über einen externen
Taster, den ich mit der DCM Resetleitung verbunden habe. Wenn ich jetzt
etwas an meinem Code ändere und das FPGA neu programmiere locked sich
der DCM automatisch und funktioniert erst nach dem Druck auf den
Resettaster wieder wie erwartet.
Wenn ich mich nicht irre, sollte doch nach dem Programmieren
automatisch ein Reset im FPGA ausgelöst werden, oder? Wenn das so ist,
woher bekomme  ich dieses Resetsignal? Haben FPGAs wie der Virtex-II
Pro so etwas wie einen internen Reset-Controller?

MfG Paul

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

>Wenn ich mich nicht irre, sollte doch nach dem Programmieren
>automatisch ein Reset im FPGA ausgelöst werden, oder?

Soweit ich weiss nicht, deshalb hab ich in jedem modul eine
statemaschine mit init des moduls.

Gruß,
Dirk

Autor: Paul Jensen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Dirk,
also du generierst einen systemweiten Reset mit der FSM, (das könnte
ich ja auch machen) aber durch welches Signal lässt du die FSM in den
Zusand übergehen der den Reset auslöst?

Paul

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich bin noch Anfaenger, deshalb koennte es falsch sein. In meinem
Design hab ich ein Modul welches ein Systemresetet an alle anderen
Module ausfuehrt.

Beispiel (peusdo vhdl:
process(clk)
begin
if rising_edge(clock) then
 if reset = '1' then 
  reset <= '1';
 else 
 case state is
 when INIT 
  next_state <= IDLE
  reset_out <= '1';
 when IDLE 
 reset_out <= '0';
 next_state <= IDLE;
end case
end if;

Gruß,
Dirk

Autor: Paul Jensen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mein eigentliches Problem ist ja nicht die Verteilung sondern die
Gernerierung. Mich "wundert" es halt, dass ich nach dem Programmieren
per JTAG, zusätzlich einen Reset per Knopfdruck durchführen muss. Ich
frage mich halt, ob der JTAG nicht auch einen Reset nach dem
programmieren durchführt und ob ich auf solch ein Resetsignal irgendwie
mit meinem VHDL Progrämmchen zugreifen kann?

Paul

Autor: FPGAkuechle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
#Wenn ich mich nicht irre, sollte doch nach dem Programmieren
#automatisch ein Reset im FPGA ausgelöst werden, oder? Wenn das so
#ist,
#woher bekomme  ich dieses Resetsignal? Haben FPGAs wie der Virtex-II
#Pro so etwas wie einen internen Reset-Controller?


1) Während und kurz nach der Konfiruration werden alle ff im reset
gehalten.

2) nach der eigentlichen Konfiguration startet eine StartUp-FSM. Diese
 ist fest im FPGA und von eigentlichen Design unäbhängig.

3) diese FSM gibt nach und nach die IO's und die FF frei.

4)Der Powerupwert der FF (was steht im FF nach der Konfiguration drin
ist vom anwender definierbar.

5)diese FSM kann auf ein Lock der DCM warten, heisst das design startet
garantiert mein einem stabilen takt.


6) dieses warten ist z.b: über Optionen des bitgen einstellbar.


Siehe Datenblatt chip -Functional description, abschnitt "Stabilizing
DCM Clocks before User Mode" und "Configuration sequence" stichwort
Start-Up sequence.


Bei Virtex4 könnte es einen on-board Powerreset manger geben
(vergleichbar zu den "üblichen reset-IC" die anderen haben sowas
nicht(IMHO).

gern baut man sich eine schaltung die einen systemweiten reset auslöst,
wenn das LOCK der DCM ungültig wird.

---
Früher hätte man das GSR-Netzwerk für einen PowerUp reset genutzt.
Dieses GSR (Global Set/Reset) Netzwerk ist ein extra Netzwerk, das alle
FF-SR Eingänge mit der  StartUp componente verbindet. Diese StartUp
componente muss direkt instanziert werden, genaueres im Library guide
unterm Abschnitt desing elements -> z.B. STARTUP_SPARTAN3.
da dieses Netzwerk über recht größen skew hat, kanns bei asynchronen
Reset böse probleme geben (FSM-FF nach unterschiedlichen taktanzahlen
aus dem reset)

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das FPGA führt nach dem Laden schon einen Reset durch und der DCM wird
auch zurückgesetzt.
Bei Spartan-3 hat der DCM noch einen Reset-Eingang.
Laut Handbuch muß man diesen nach dem Starten des FPGA's nochmal
pulsen, falls man ein externes Feedback Signal verwendet, also wenn des
Feedback signal über die I/O Pins geht. Vielleicht ist das bei Dir der
Fall.
Vielleicht ist beim Start des FPGA auch der Eingangstakt nicht stabil.
Wo kommt das CLKIN Signal her?
Grüße
Klaus

Autor: analoger Denker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Vielleicht ist beim Start des FPGA auch der Eingangstakt nicht stabil.
Und wenn gar kein Takt anliegt?

Ich habe probiert locked Signal auszuwerten und damit die dDCM zu 
resetten, das Ganze verhält sich sehr unstabil un klappt in 50% der 
Fälle nicht. Gibt es da was fertiges am Code?

Autor: Matthias G. (mgottke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Normalerweise, wenn die Rückführung nicht über IOs geht, läuft die DCM 
problemlos an. Es deutet viel auf einen unstabilen Takt in der 
Anlaufphase hin.

Die DCMs laufen aber bei weitem nicht so stabil wie die meisten sich das 
erhoffen. Sie reagiert z.B. sehr empfindlich auf Felder in 
vorbeiführenden Leitungen. Mit Burst- und Surge-Pulse im Prüflabor habe 
ich in Spatan 3A FPGAs die DCMs immer wieder zum aussetzen gebracht. Und 
zwar so, dass der Ausgagnstakt stehen blieb UND das Lock-Signal 
nichteinmal weg gieng. Mit einem Reset der DCM lief alles wieder los.
Meine Lösung. Eine Ausgangstaktüberwachung mit Hilfe des extern 
anliegenden Taktes. So eine Art Watchdog für den Ausgangstakt des DCM. 
Dieser Resetet einfach die DCM nach einer Zeit, wenn kein Takt am 
Ausgang des DCM kommt. Damit sollte auch jegliches Anlaufproblem gelöst 
sein.

Im Übrigen: Für ein FPGA-Internes Reset beziehe ich immer all 
Locked-Signale mit ein. Das Reset-Signal wird immer asynchron generiert, 
ist mindestens ein ganzer Takt lang und wird immer Synchron wieder 
aufgehoben. Dann gibt es keine Probleme im Design. Das Resetsignal kann 
und sollte dann in jedem Prozess asynchron verwendet werden.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
analoger Denker wrote:

> Ich habe probiert locked Signal auszuwerten und damit die dDCM zu
> resetten, das Ganze verhält sich sehr unstabil un klappt in 50% der
> Fälle nicht. Gibt es da was fertiges am Code?

Hast du dir das noch mal durchgelesen und langsam durch den Kopf sickern 
lassen? :)

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Vielleicht ist beim Start des FPGA auch der Eingangstakt nicht stabil.
> Und wenn gar kein Takt anliegt?
Lies die Doku zum DCM durch. Dort sind recht zwingende Vorgaben für die 
Qualität des Taktsignals in den DCM angegeben. Wenn du z.B. keinen 
Takt oder einen mit starken Jitter einleitest, wird das Ding nicht 
einrasten oder zwischendurch die Rastung verlieren.

Autor: SuperWilly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Matthias G. schrieb
>Dann gibt es keine Probleme im Design. Das Resetsignal kann
>und sollte dann in jedem Prozess asynchron verwendet werden.

Wieso sollte das Resetsignal ASYNCHRON weiter verwendet werden ?

Gruß,
SuperWilly

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das Resetsignal kann
> und sollte dann in jedem Prozess asynchron verwendet werden.
Das Reset-Signal sollte überhaupt nicht verwendet werden, weil dann 
einige Optimierungs-Tricks der Toolchain nicht funktionieren. Bei Xilinx 
gibts dazu ein schönes Whitepaper:
http://www.xilinx.com/support/documentation/white_...

Autor: Matthias G. (mgottke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wieso sollte das Resetsignal ASYNCHRON weiter verwendet werden ?

Ein FF in FPGAs und CPLDs hat im wesentlichen drei nutzbare Eingänge: 
Daten, Clock und Reset. In der Regel kommen die Daten aus einer LUT mit 
4 Eingängen. Je nach Komplexität der Kombinatorik sind es euch mehrere 
LUTs hintereinander. Bei einer synchronen Verwendung des Resets, muss 
dieses in die Kombinatorik einbezogen werden. Es fließt ein zusätzliches 
Signal ein. Daher werden unter Umständen zusätliche LUTs benötigt, bzw. 
die Stufenzahl der LUTs hintereinander erhöht.
Deshalb benötigt ein synchrones Reset mehr Resourcen und das Design wird 
langsamer.
Der FF-Reseteingang kann also genutzt werden und bedarf keinerlei 
zusätlicher Resourcen. Das Reset selbst sollte aber eine Mindestlänge 
von einem Takt haben und vor allem sollte es synchron zum Takt wieder 
aufgelöst werden. Sonst geschehen die absonderlichsten Dinge.

> Das Reset-Signal sollte überhaupt nicht verwendet werden, ...

Das ist nur sehr hypothetisch. In vielen Designs gibt es klare 
Anforderungen die ein Reset unabdingsbar machen.

Viele Grüße Matthias

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Bei einer synchronen Verwendung des Resets, muss dieses in die
> Kombinatorik einbezogen werden.
Falsch. Die FFs von Xilinx haben einen D-Eingang und entweder 
synchrone Set/Reset-Eingänge oder asynchrone Preset/Clear-Eingänge. 
Siehe dazu den Beitrag "Re: Hardware mit VHDL "richtig" beschreiben."

Am schlimmsten ist es, ein FF asynchron zurückzusetzen und synchron zu 
setzen (so wie in fast jedem VHDL-Beispiel beschrieben). Das braucht 
zusätzliche Logik  :-/

> In vielen Designs gibt es klare Anforderungen die ein Reset unabdingsbar
> machen.
Yeah, der Reset-Taster...

Autor: Matthias G. (mgottke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Bei einer synchronen Verwendung des Resets, muss dieses in die
>> Kombinatorik einbezogen werden.
> Falsch. Die FFs von Xilinx haben einen D-Eingang und /entweder/
> synchrone Set/Reset-Eingänge oder asynchrone Preset/Clear-Eingänge.

Da gebe ich Dir nur bedingt recht. In dem von Dir gezeigten Link stellt 
sich auch die Frage wie mit dem EN der FFs umgegangen wird. Da läßt sich 
auch eine menge Resourcen Sparen. Das viel schlimmere daran ist, dass 
die FF nicht in jeder Zielhardware identisch sind.
Ich selbst musste leider schon mit Lattice, Actel, Xilinx und Altere 
arbeiten. Die geschriebenen Module sollten aber möglichst Platform 
unabhängig funktionieren. Daher die Wiederverwendbarkeit sollte gewährt 
belieben. Deshalb ist für mich die beste Reset-Lösung immer noch die 
asynchrone Verwendung "eines" Resets mit synchroner Auflösung.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das viel schlimmere daran ist, dass
> die FF nicht in jeder Zielhardware identisch sind.
Das schon, aber hier im Thread geht es um Xilinx FPGAs  :-/

Lattice-FPGAs z.B. bringen mit einer anderen Reset-Beschreibung mehr 
Performance.


> Die geschriebenen Module sollten aber möglichst Platform unabhängig
> funktionieren.
Von dieser Idee bin ich mittlerweile abgekommen. Damit ergibt sich fast 
immer ein Kompromiss (und diese Idee hat in der Software-Programmierung 
schon nicht funktioniert)...

Autor: Arndt Bußmann (Firma: Helion GmbH) (bussmann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei der Benutzung eines Resetsignals und den dazugehörigen Implikationen 
kann ich nur auf das Paper von Xilinx (s. Lothar) verweisen. Es ist auch 
für alle anderen FPGA Hersteller, wie auch ASIC Logikdesigner gültig.

Kernaussage:
Bei Verwendung eines globalen Resets besteht die Gefahr, das unter 
Umständen teile der Schaltung erst einen Takt später den Reset 
verlassen. Damit hat man seine Statemachines und andere Zustandsregister 
so richtig durcheinander gebracht. Das Auffinden dieses Fehlers ist sehr 
schwierig (wenn man ihn z.B. nicht kennt), da er nur sporadisch und in 
unterschiedlichen Schaltungsteilen auftritt.

Da wir diese Fehlerverhalten tatsächlich bei Xilinx wie auch Lattice 
Designs beobachten konnten, haben wir das obige Paper als 
Designrichtlinie übernommen. Wir haben in den Design einen zentralen 
Block, der ein synchrones Reset für alle anderen Blöcke erzeugt. Seitdem 
ist das Designerleben deutlich einfacher geworden, man zahlt natürlich 
mit zusätzlicher Logik...

Viele Grüße
Arndt

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wir haben in den Design einen zentralen Block, der ein synchrones Reset
> für alle anderen Blöcke erzeugt.
Einfachste Regel:
Niemals darf ein externes Reset-Signal ohne Synchronisation (und am 
besten Verlängerung) direkt auf die FFs losgelassen werden.

Ich hatte z.B. den Fall, dass kurze EMV-Spikes auf der Resetleitung
nur einen Teil des FPGAs zurückgesetzt haben. Damit waren dann etliche 
der SM ausser Takt geraten und das Gerät zeigte absolut nicht 
reproduzierbare Fehlerbilder. Und das passiert z.B. einmal am Tag, jede 
Stunde oder auch nur dann und wann :-/

Autor: SuperWilly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Arndt,

>Wir haben in den Design einen zentralen
>Block, der ein synchrones Reset für alle anderen Blöcke erzeugt. Seitdem
>ist das Designerleben deutlich einfacher geworden, man zahlt natürlich
>mit zusätzlicher Logik...

Und wie verwendet Ihr das synchronisierte Reset-Signal in den Prozessen 
?

a) process(Reset, Clk)
   begin
       if Reset='1' then

       elsif rising_edge(Clk) then

       end if;
   end process;

     ODER

b) process(Clk)
   begin
       if rising_edge(Clk) then
          if Reset='1' then

          else

          end if;
       end if;
   end process:

Gruß,
SuperWilly

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Und wie verwendet Ihr das synchronisierte Reset-Signal in den Prozessen?
Bei Xilinx:
Wegen der Set/Reset-Eingänge wie in Beispiel B (wegen WP272).

Ich würde das sogar noch eher so schreiben:
 process begin
    wait until rising_edge(clk);
    :
    -- normale Anweisungen
    :
    if Reset='1' then
       :
       -- Resetzuweisungen
       :
    end if;
   end process:


EDIT:
> Und wie verwendet Ihr das synchronisierte Reset-Signal in den Prozessen?
Du wirst in beiden Fällen mit dem synchronisierten Reset-Signal 
definiert aus dem Reset herauskommen.

Autor: Matthias G. (mgottke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich empfehle jedenfalls immer die Variante a) zu nehmen.

Im übrigen im RTL hat "wait" nichts zu suchen, auch wenn viele 
Synthesetools das wie gewünscht umsetzen.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich empfehle jedenfalls immer die Variante a) zu nehmen.
Wie schon gesagt: Für Xilinx idR. ungünstig.

> Im übrigen im RTL hat "wait" nichts zu suchen ...
Es gibt ein paar schlagende Vorteile:
- schreibt und liest sich schöner, weil weniger Einrückungen nötig sind
  und eine Klammerebene gespart wird
- die Simulation und die Synthese stimmen immer überein,
  weil es keine unvollständigen Sensitivity-Listen mehr gibt
- der Prozess ist garantiert getaktet,
  und hat nicht irgendwo einen asynchronen Teil

Und wieso sollte man etwas nicht verwenden, wenn es Vorteile bringt?
Nur, weil es in keinem Buch steht?

Autor: Matthias G. (mgottke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Und wieso sollte man etwas nicht verwenden, wenn es Vorteile bringt?
> Nur, weil es in keinem Buch steht?

Ich bin nun einige Tage auser gefecht gesetzt und komme nicht an alles 
dran. So viel ich immer gelesen habe, wird in den den Style-Guides immer 
dringlichst davon abgeraten. Da das mit dem Thema aber nichts zu tun hat 
werde ich mal einen neuen Beitrag eröffnen.

Gruß Matthias

Autor: SuperWilly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frage an Lothar:

Du bist (so scheint mir) ein Fan von synchronen Resets.
Würde mich mal interessieren, wie Du Dual-Clock-Fifos resettest ?
Auf welchen Takt synchronisierst du das Reset-Signal ein ?

Gruß,
SuperWilly

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Du bist (so scheint mir) ein Fan von synchronen Resets.
Nein, ich bin ein Fan von keinen Resets  ;-)
Aber wenn schon ein Reset, dann synchron.
Das ideale Design hat 1 Takt und 0 Resets (allerdings sind Ideale so 
selten zu erreichen).

> Würde mich mal interessieren, wie Du Dual-Clock-Fifos resettest ?
> Auf welchen Takt synchronisierst du das Reset-Signal ein ?
Was gibt es an so einem Fifo zurückzusetzen?
Eigentlich "nur" den Schreib- und Lesezeiger.
Da würde ich mal ganz einfach der übergeordneten Steuereinheit (also 
meinem Code) die Schuld geben, wenn was schiefgeht. Und somit den Reset 
(und damit meinen Teil des Designs) auf beiden Seiten des Fifos auf den 
jeweiligen Takt synchronisieren. Auf der Seite, die asynchron zum Reset 
ist, wird das Resetsignal verzögert deaktiviert.

Die schlechteste Lösung dürfte sein, zu sagen:
Da kann man sowieso nichts machen. Also gleich alles asynchron... :-/

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.