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
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
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
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:
1 | process(clk) |
2 | begin
|
3 | if rising_edge(clock) then |
4 | if reset = '1' then |
5 | reset <= '1'; |
6 | else
|
7 | case state is |
8 | when INIT |
9 | next_state <= IDLE |
10 | reset_out <= '1'; |
11 | when IDLE |
12 | reset_out <= '0'; |
13 | next_state <= IDLE; |
14 | end case |
15 | end if; |
Gruß, Dirk
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
#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)
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
> 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?
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.
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? :)
>> 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.
>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
> 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_papers/wp272.pdf
> 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
> 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...
>> 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.
> 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)...
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
> 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 :-/
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
> 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:
1 | process begin |
2 | wait until rising_edge(clk); |
3 | :
|
4 | -- normale Anweisungen
|
5 | :
|
6 | if Reset='1' then |
7 | :
|
8 | -- Resetzuweisungen
|
9 | :
|
10 | end if; |
11 | 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.
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.
> 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?
> 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
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
> 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... :-/
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.