Nachdem ich Probleme beim Start meines Designs hatte, wenn es aus dem Config-Flash geladen wurde (siehe Beitrag "Re: Spartan6 Firmware mit Microcontroller updaten"), habe ich mir das Ganze noch einmal mit dem Oszi angeschaut. Das obere Signal auf dem Oszilloskop-Screenshot ist jeweils der LOCKED-Ausgang. Unten ist das CLKFX-Signal. Im ersten Bild sieht man alles vom Ende der Konfiguration (LOCKED ist hochohmig) bis zum Erreichen des DCM-lock. Wenn man sich das genau anschaut (zweites Bild) so kommt für ca. 3.5µs erstmal der Eingangstakt aus der DCM raus (hier 200 MHz). Dann wird relativ glitchfrei auf den gewünschten Takt umgestellt. Nach weiteren 500ns wird das LOCKED-Signal aktiviert. Ergo: Wenn man von der DCM generierte Takte verwenden möchte, sollte man sein Design erst starten, wenn LOCKED gesetzt ist. Sonst läuft das Design u.U. mit einem Takt, der viel zu schnell ist... Duke P.S.: Der Parameter STARTUP_WAIT = TRUE hat bei mir (ISE 13.3) nicht funktioniert. (Und ja, ich hatte auch den LCK_cycle angepasst.) P.P.S.: Außerdem kann ich anhand der Oszibilder keinen Unterschied zwichen ConfigRate 2 (da geht es fast immer) und ConfigRate 26 (da geht es nicht) erkennen.
>Ergo: Wenn man von der DCM generierte Takte verwenden möchte, sollte man >sein Design erst starten, wenn LOCKED gesetzt ist. Das ist nichts Neues, steht auch in der AppNote. Dazu ist der LOCKED Ausgang da.
Sauron schrieb: > In welcher Appnote steht das denn ? UG382:
1 | Until LOCKED is High, the stability of the DCM clock outputs is questionable. The DCM |
2 | output clocks are not valid until LOCKED is High. Before that time, the DCM clock |
3 | outputs can exhibit glitches, spikes, or other spurious behavior. |
Übrigens, das Einzige, was man mit LCK_cycle und STARTUP_WAIT verändern kann, ist der Zeitpunkt, an dem das Signal STARTUP_SPARTAN6 -> EOS auf '1' geht. Der DONE-Pin ist davon völlig unbeeindruckt. Duke
Duke Scarring schrieb: > Übrigens, das Einzige, was man mit LCK_cycle und STARTUP_WAIT verändern > kann, ist der Zeitpunkt, an dem das Signal STARTUP_SPARTAN6 -> EOS auf > '1' geht. Der DONE-Pin ist davon völlig unbeeindruckt. klar, dafür ist ja auch der "DONE_cycle" zuständig: "-g DONE_cycle" > "-g LCK-cycle" sollte den Unterschied machen
Soweit ich weiss wird als STARTUP-Parameter die Phase während der Setup-Sequence angegeben, zu der das entspr. Event ausgelöst wird (oder auch nicht, wie z.B. das Warten auf DCM/PLL). Soll also DONE nach DCM-Locked ausgelöst werden, dann muss z.B. LCK_cycle z.B. auf "1" und DONE auf "6" gesetzt werden. (kann jedenfalls ab ISE 14.x angegeben werden) P.S.1: ich habe der DCM bis jetzt nur in der SIM zugeschaut, nie per Oszi. Dass die CLK-Freq vorm Einlocken teilweise doppelt so hoch wie die Zielfreq. ist macht schon sehr deutlich, wie wichtig das LOCKED-Signal ist. P.S.2: Man kann zwar angeben, dass auf die DCM gewartet wird, bei hintereinander geschaltenen DCMs kann's aber kritisch werden, insbes. wenn FFs involviert sind! Von daher ist das Warten auf die DCM für mich keine Option.
Dude schrieb: > klar, dafür ist ja auch der "DONE_cycle" zuständig: > "-g DONE_cycle" > "-g LCK-cycle" Es ist ja nicht so, das ich das nicht probiert hätte... Sigi schrieb: > Soll also DONE nach DCM-Locked ausgelöst werden, dann muss z.B. > LCK_cycle z.B. auf "1" und DONE auf "6" gesetzt werden. Achtung, vor dem LCK_cycle muß noch der GTS_cycle kommen. Mit den folgenden Einstellungen sieht es am DONE-Pin aber auch nicht anders aus, als oben:
1 | -g DONE_cycle:6 |
2 | -g GTS_cycle:4 |
3 | -g GWE_cycle:5 |
4 | -g LCK_cycle:5 |
Hier die Einstellungen vom zweiten Screenshot:
1 | -g DONE_cycle:6 |
2 | -g GTS_cycle:3 |
3 | -g GWE_cycle:5 |
4 | -g LCK_cycle:4 |
Duke
komisch - sah bei uns (damals vor einigen Jahren beim Spartan3E) anders aus... auch (bestimmt - aber ich frag ja nur) das Attribut "STARTUP_WAIT" der DCM auf "TRUE" gesetzt ?
>Wenn man von der DCM generierte Takte verwenden möchte, sollte man >sein Design erst starten, wenn LOCKED gesetzt ist. Sonst läuft das >Design u.U. mit einem Takt, der viel zu schnell ist... Aaaah, hörte ich in diesem Forum nicht mal sagen, dass man bei Xilinx kein asynchronen Reset braucht? :-)))))
Dr. Schnaggels schrieb: > Aaaah, hörte ich in diesem Forum nicht mal sagen, dass man bei Xilinx > kein asynchronen Reset braucht? Braucht man auch nicht zwingend. Wenn man das LOCKED einsynchronisiert, läuft die Sync Stufe zwar erst mal mit schnellerem Takt, da aber LOCKED sowieso auf 0 ist macht das ja nix.
Dude schrieb: > komisch - sah bei uns (damals vor einigen Jahren beim Spartan3E) > anders > aus... Da schau ich doch gleich mal nach... ... da funktioniert es (siehe Anhang). Allerdings kommt beim Spartan 3e erst das LOCKED und nach 1.5 µs der Takt (gilt für CLK_FX und CLK_DV). > auch (bestimmt - aber ich frag ja nur) das Attribut "STARTUP_WAIT" der > DCM auf "TRUE" gesetzt ? Ich hätte schwören können, es auch mit STARTUP_WAIT = TRUE probiert zu haben. Im UG380 steht:
1 | When the |
2 | LCK_CYCLE is set to a startup phase, the FPGA waits for all DCMs and PLLs to lock prior |
3 | to moving to the next phase of startup. To only wait for specific DCMs to lock, assign the |
4 | STARTUP_WAIT attribute to those instances. |
Das würde ich so übersetzen: Wenn LCK_CYCLE auf einem Wert steht, wartet der FPGA auf alle DCMs (und PLLs). Also auch wenn STARTUP_WAIT nicht explizit gesetzt ist. Allerdings hat das trotzdem nur Auswirkungen auf den DONE-Pin (Bild 3). Kritische FSM müssen trotzdem auf LOCKED warten :-( Ich hatte gehofft auf einen Reset komplett verzichten zu können. Duke
>Ich hatte gehofft auf einen Reset komplett verzichten zu können.
Warum brauchst du RESET, LOCKED als Enable-Signal für entsprechende
FFs/RAMs reicht doch aus?
Sigi schrieb: > Warum brauchst du RESET, LOCKED als Enable-Signal für entsprechende > FFs/RAMs reicht doch aus? Ob ich das Signal als enable oder als sync_reset verwende, sollte für den Logikverbrauch eigentlich keine Rolle mehr spielen. Duke
Duke Scarring schrieb: > Im UG380 steht:When the > LCK_CYCLE is set to a startup phase, the FPGA waits for all DCMs and > PLLs to lock prior > to moving to the next phase of startup. To only wait for specific DCMs > to lock, assign the > STARTUP_WAIT attribute to those instances. > Das würde ich so übersetzen: Wenn LCK_CYCLE auf einem Wert steht, wartet > der FPGA auf alle DCMs (und PLLs). Also auch wenn STARTUP_WAIT nicht > explizit gesetzt ist. Xilinx hat uns erklärt: LCK_cycle sagt: warte auf alle DCMs, deren WAIT-Attribut auf TRUE gesetzt ist. Wir hatten 'damals' mehrere DCMs; aber nur EINE davon war verantwortlich für das Interface zu einer externen MCU (über die auch der FPGA im SelectMap konfiguriert wurde). Diese verwendete soweit ich mich erinnere den CLK0- und den CLK2X-Ausgang. Über CLKDV und CLKFX kann ich daher nix sagen... => wir haben den DONE-Pin solange verzögert haben (wie oben beschrieben) bis wir sicher sein konnten, dass das Interface im FPGA 'funktional' ist - stabiler, garantierter Takt und 'losgelassener' Reset. Erst mit DONE=1 war es der MCU erlaubt, auf den FPGA zuzugreifen. Alle anderen DCMs waren uns 'egal', weshalb deren Attribut auf 'FALSE' gesetzt wurde, um eine möglichst frühzeitige Verbindung MCU<->FPGA zu erreichen.
Duke Scarring schrieb: > Nachdem ich Probleme beim Start meines Designs hatte, wenn es aus dem > Config-Flash geladen wurde (siehe > Beitrag "Re: Spartan6 Firmware mit Microcontroller updaten"), habe ich > mir das > Ganze noch einmal mit dem Oszi angeschaut. Hi Duke, wie hast du denn den DCM eingebaut? Per Template einfach den DCM_SP instanziert oder Core-Gen?
berndl schrieb: > wie hast du denn den DCM eingebaut? Per Template einfach den DCM_SP > instanziert oder Core-Gen? Ersteres. Den Coregen versuche ich zu vermeiden, wo es geht. Duke
Duke Scarring schrieb: >> wie hast du denn den DCM eingebaut? Per Template einfach den DCM_SP >> instanziert oder Core-Gen? > Ersteres. Den Coregen versuche ich zu vermeiden, wo es geht. ah, me too... Hast du mal untersucht, ob clk1x/2x im Feedback einen Unterschied macht? Hintergrund der Frage: Ich koennte mir vorstellen, dass clk2x 'mehr trouble' beim einschwingen macht...
berndl schrieb: > Hast du mal untersucht, ob clk1x/2x im Feedback einen > Unterschied macht? Hintergrund der Frage: Ich koennte mir vorstellen, > dass clk2x 'mehr trouble' beim einschwingen macht... Bisher nicht, ich hab das aber mal schnell nachgeholt. clk2x bringt allerdings timing-Fehler. Offenbar sind 2x 200 MHz für CLKFB zu schnell. Der eigentliche Unterschied besteht zwischen FEEDBACK=NONE und FEEDBACK=1X. Bei FEEDBACK=2X habe ich nochmal einen Zoom gemacht. Auch hier läuft CLK_FX erstmal für ein paar Takte zu schnell. Duke
hi, anstelle das LOCKED als (a)synchronen reset oder als direktes enable zu verwenden, nutze ich das LOCKED Signal für den CE des BUFGs. D.h. der korrekte Takt wird erst dann glitchfrei auf clock-Netzwerk gegeben, wenn alles ok ist. Nachteil bei Spartan6: nur die BUFG haben einen CE, die BUFH nicht. Grüße
...und man braucht noch einen zusätzlichen BUFG für das Feedback, der nicht abgeschaltet wird.
Christian R. schrieb: > zusätzlichen BUFG für das Feedback meines Wissens aber auch nur dann, wenn man genaue Phasenbezüge zwischen DCM-Ausgang und -Eingang benötigt, z. B. für source- oder systemsynchronen Betrieb. Will man nur einen vorhandenen Takt z. B. für einen Microblaze auf eine andere Frequenz bringen, kann der Feedbackausgang direkt mit dem Feedbackeingang verbunden werden, ohne einen Clockbuffer.
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.