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:
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
processbegin
2
waituntilrising_edge(clk);
3
:
4
-- normale Anweisungen
5
:
6
ifReset='1'then
7
:
8
-- Resetzuweisungen
9
:
10
endif;
11
endprocess:
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... :-/
