Spartan 6, dem DCM-Ausgang auf die Finger geschaut

>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.

In welcher Appnote steht das denn ?

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?

:-)))))

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

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.