DLL verlangsamt Design auf 1/4

[Thomas B. (thomas1)]

Ich habe ein Spartan3A, der mit einem 25MHz Clock versorgt wird.
Das implementierte Design läuft mit ungefähr 130MHz.(Das heisst es 
zumindest am Ende des Synthesize-Reports).
Nun muss ich das Design mit 100MHz laufen lassen. Dazu will ich einen 
DCM verwenden, der den Eingangsclock vervierfacht.
Wenn ich nun diesen instanziere (ich liess ihn vom Coregenerator 
generieren), verlangsamt das das Design so massiv, dass mir die DLL 
nichts mehr bringt:  Minimum period: 29.704ns (Maximum Frequency: 
33.665MHz).

Was ist hier los?

Hier die Komponentendeklaration:

COMPONENT DLL_25_to_100MHz
PORT(
  CLKIN_IN : IN std_logic;
  RST_IN : IN std_logic;          
  CLKFX_OUT : OUT std_logic;
  CLK0_OUT : OUT std_logic;
  LOCKED_OUT : OUT std_logic
  );
END COMPONENT;

und hier die Instanzierung:

Inst_DLL_25_to_100MHz: DLL_25_to_100MHz PORT MAP(
  CLKIN_IN => CLK_25M,
  RST_IN => DLL_RST,
  CLKFX_OUT => CLK_100M,
  CLK0_OUT => DLL_CLK0out,
  LOCKED_OUT => DLL_locked 
);

Die DLL resette ich so:

-- Die DLL während 5 Clock-Zyklen resetten
reset_dll: process(CLK_25M)
begin
   if(rising_edge(CLK_25M)) then
      DLL_RST <= reset_cnt(4);
      reset_cnt <= reset_cnt(3 downto 0) & '0';
   end if;
end process reset_dll;

Das LOCKED_OUT beachte ich im Moment nicht.
Es ist mir nicht klar, was ich mit dem CLK0_OUT-Signal machen soll. Wozu 
ist das gut? Ich hänge das jetzt lediglich an ein unbenutztes Signal. 
Liegt evtl. hier das Problem?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Dein Design läuft nicht langsamer, sondern du darfst wegen des Faktors 4 
im DCM jetzt keinen 130MHz-Quarz mehr anschliessen, sondern maximal 
130MHz/4 = 32,5MHz.

> Es ist mir nicht klar, was ich mit dem CLK0_OUT-Signal machen soll. Wozu
> ist das gut?
Sieh dir die Doku zum DCM an. Zusammen mit dem CLK180_OUT & Co könnstest 
du das phasenverschobene Takte ins FGPA einschleusen...

[Thomas B. (thomas1)]

Ahaaa...
Danke, jetzt bin ich erleichtert!

Und jetzt noch gerade eine Frage:
Ist es eine schlechte Idee, das invertierte LOCKED_OUT als asynchronen 
Reset an sämtliche Prozesse zu schliessen, die mit dem 100MHz-Clock 
laufen?
Im Moment gucke ich, wie gesagt, das LOCKED_OUT gar nicht an.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Thomas B. schrieb:
> Ist es eine schlechte Idee, das invertierte LOCKED_OUT als asynchronen
> Reset an sämtliche Prozesse zu schliessen,
Ja. Es ist nzipiell eine schlechte Idee, unnötigerweise den asynchronen 
reset zu verwenden. Lies dazu mal das WP272 von Xilinx, und den
Beitrag "Xilinx und die Resets"

Setze lieber das Attribut STARTUP_WAIT, dann wartet die Konfiguration, 
bis die DCM rennt. Siehe dazu die XAPP462 (letzte Seite).

[flint (Gast)]

Aber ist es nicht eine gute Idee, das locked_out Signal der DLL bzw 
einer PLL als synchonronen Reset zu verwenden? Ich denke, sowas in die 
Richtung habe ich hier mal gelesen.

lg
flint

[Vanilla (Gast)]

Hallo flint,

es ist eine schlechte Idee einen RESET zu verwenden, wenn er nicht 
benoetigt wird.

Asynchrone Resets haben zudem den Nachteil das die Synthesetools die 
Signallaufzeit auf der Resetleitung nicht mit dem Cycleconstraint 
zusammenbringen und noch darueber hinaus keine Aussage zur Phasenlage 
des Resets mit dem Clock moeglich ist, womit deine Schaltung den Reset 
moeglicherweise in an mehreren Zeitpunkten (das letzte Mal) sieht, womit 
dein Design dann bereits zur Haelfte laeuft waehrend der Rest noch im 
Reset gehalten wird). Die daraus entstehenden Effekte koennen so manche 
kalte und dunkle Winternacht ausfuellen...

Generell gilt es Resets nur da anzuwenden an den dies auch zwingend 
notwendig ist.

Die meisten Resets werden eh nur gemacht um beim Simulationsstart 
eindeutige Verhaelltnisse zu haben.
Heutige FPGAs und Synthesetools beachten allerdings Defaultvorgaben bei 
der Signaldefinition. Entgegen der mancherorts vorhandenen 
Lehrbuchmeingung ist dies die bessere alternative zum allgegenwaertigen 
RESET.

[berndl (Gast)]

Vanilla schrieb:
> es ist eine schlechte Idee einen RESET zu verwenden, wenn er nicht
> benoetigt wird.
>
> Asynchrone Resets haben zudem den Nachteil das die Synthesetools die
> Signallaufzeit auf der Resetleitung nicht mit dem Cycleconstraint
> zusammenbringen und noch darueber hinaus keine Aussage zur Phasenlage
> des Resets mit dem Clock moeglich ist, womit deine Schaltung den Reset
> moeglicherweise in an mehreren Zeitpunkten (das letzte Mal) sieht, womit
> dein Design dann bereits zur Haelfte laeuft waehrend der Rest noch im
> Reset gehalten wird).

Im Post oben wurde explizit von synchronem Reset gesprochen!

Und was bitte machst du, wenn z.B. deine DLL/PLL mal kurz aus dem Tritt 
kommt? Einfach so weiter?

Oder wenn du an einem externen Chip haengst, dem mal kurz die 
spannungsversorgung abgedreht wird und du must beim wiedereinschalten 
mit Anfangswerten loslaufen?

Nenne es einfach nicht Reset, sondern synchronen INIT. Und da kannst du 
z.B. eine Resetbedingung einsynchronisiert mit dazu nehmen.