Frequenzteiler (16x) bei XILINX FPGA mit DLL

Gast #609586
Lesenswert?

Hallo zusammen,

ich möchte ein 25MHz Takt im FPGA für einen Timer auf ca. 100 KHz 
teilen.

Im Datenblatt von XILINX wird der Frequenzteiler der DLL mit folgenden 
Teilerverhältnissen beschrieben: 1.5, 2 ...8 oder 16.
Jedoch bekomme ich den Takt in der DLL nur halbiert!
Sind höhere Teilerraten eig nur über FlipFlops möglich oder wie bringe 
ich der DLL das anständige Teilen bei:)
Entwicklungsumgebung: XILINX ISE 8.2

Implementiert habe ich die DLL wie folgend:

component CLKDLL
-- synopsys translate_off
  generic(
    DUTY_CYCLE_CORRECTION : Boolean := TRUE;
    CLKDV_DIVIDE  : real := 16
    );
-- synopsys translate_on
  port(
    CLKIN    : in std_ulogic := '0';
    CLKFB    : in std_ulogic := '0';
    RST    : in std_ulogic := '0';
    CLK0    : out std_ulogic;
    CLK90    : out std_ulogic;
    CLK180  : out std_ulogic;
    CLK270  : out std_ulogic;
    CLK2X    : out std_ulogic;
    CLKDV    : out std_ulogic;
    LOCKED  : out std_ulogic
    );
end component;


Wenn ich das komplette VHDL Gerüst jedoch durch den Place&Route laufen 
lasse zeigt er mir jedoch in den TIMING Constraints an, dass der Takt 
(CLKDV) nur halbiert wurde.

Kennt sich jemand mit den Teilern aus und könnte mir nen Tip geben?

Vielen Dank Chris
Angehängte Dateien:
Gast #609596
Lesenswert?

Ich würd hald gern den Teiler nehmen in der einen DLL (Platz ect), das 
genaue Teilerverhältnis ist relativ egal (also obs 97 khz oder 100Khz 
sind). Sonst müsste ich doch den Takt über mehrere Teiler (FF´s laufen 
lassen) und die FlipFlops gehen langsam aber sicher zu gehen!

Die Angaben wie hoch der Timer zählt werden eh codiert über einen 8 bit 
code von einem MC angegeben und über nen MUX als DELAY ausgewertet.
#609598
Lesenswert?

Versuch mal "16.0" - Ich habe da etwas in Erinnerung, dass 16 als 
integer nicht einem real-Wert zugewiesen werden kann und somit der 
Default-Wert von 2 genommen wird.

Größere Teiler als 16 kann die DLL nicht - es gibt auch einen 
Mindesttakt, der am Ausgang anliegen muss, damit sie überhaupt richtig 
arbeiten kann. Weiter runter kommst du nur mit einem eigenen 
Frequenzteiler mit Counter oder  T-FlipFlops.
Gast #609616
Lesenswert?

@ Jan M.

Vielen Dank, genau die .0 hats gebracht!
Tatsächlig ignoriert er die 16 alleinstehend


@ Xenu: Das ohne "-- synopsys translate_off" hat ich davor versucht, 
aber da hat schon das Synthese Werkzeug abgelehnt!

aber jetzt funktionierts ja :)

In diesem Sinne, allen ein schönes Wochenende!

Viele Grüße
Chris
Gast #609858
Lesenswert?

@ ChrisFN (Gast)

>Ich würd hald gern den Teiler nehmen in der einen DLL (Platz ect), das

Platz? Dafür brauchst du popelige 4 FlipFlops! Die sind in JEDEM FPGA 
noch frei.
Und der Zähler hat den entschiedenden Vorteil, mit JEDER beliebigen 
Frequenz zu funktionieren, bis runter auf Null. Die DLL braucht mind. 24 
MHz Eingangstakt. Ausserdem ist die DLL sehr empfindlich auf Jitter, mit 
was anderem als nem Takt aus nem Quarzoszillator sollte man die nicht 
versorgen. Ein popeliger RC-Oszillator macht schon viel zu viel Jitter.

Ausserdem befürchte ich, dass du einen typischen Anfängerfehler machst 
und einen derived CLock verwendest.

Taktung FPGA/CPLD

MFG
Falk
Gast #610141
Lesenswert?

Hallo Falk,

"Ein popeliger RC-Oszillator macht schon viel zu viel Jitter."
- taktest Du Deine FPGAs mit RC-Oszillatoren?

Warum nicht mal eine DLL verwenden ? Ist doch kein Teufelszeug!


"Ausserdem befürchte ich, dass du einen typischen Anfängerfehler machst
und einen derived CLock verwendest."

Die Takte am Ausgang einer DLL sind alle synchron. Eine Datenübergabe
zwischen diesen Clock-Domains sollte kein Problem sein, solange
man Timing-Constraints setzt!
Gast #610156
Lesenswert?

Das Übermässige Nutzen von DLLs oder auch DCMs ist ein Übel, das weder 
einen Vorteil für die Programmierung, noch die Synthese bringt.

Verschiedene CLocks bitte immer noch, wenn wirklich unterschiedliche 
clks benötigt werden und nicht Teilfrequenzen. Die lässt man sauber als 
enable laufen.
Gast #610652
Lesenswert?

@  Mark (Gast)

>"Ein popeliger RC-Oszillator macht schon viel zu viel Jitter."
>- taktest Du Deine FPGAs mit RC-Oszillatoren?

Selten, aber es ist denkbar. Oder man taktet das FPGa mit einem 
rückgewonnenen Takt eines Datenkanals. Die sind aber nicht immer 
sonderlich jitterarm.

>Warum nicht mal eine DLL verwenden ? Ist doch kein Teufelszeug!

Sicher nicht, aber ohne echten Grund lass ich das bleiben. Nicht nur 
wegen Portierbarkeit etc. Wenn ein Problem mit einer simplen Schraube 
lösbar ist, nehm ich keinen HIGH_TEC Kleber. Schon gar nicht um popelige 
100kHz zu erzeugen.

>Die Takte am Ausgang einer DLL sind alle synchron. Eine Datenübergabe
>zwischen diesen Clock-Domains sollte kein Problem sein, solange
>man Timing-Constraints setzt!

Denkst du. Andere Leute haben da bisweilen andere Erfahrungen gemacht. 
Such mal im Archiv von comp.arch.fpga nach Ray Andraka und DLL ;-)

MfG
Falk
Gast #610848
Lesenswert?

"Solange man Timing Constraints setzt" ...

.. und seine Schaltung so designed, daß sie mit einer doppelten 
Verzögerung, die bei ungetakteten Clock Übergängen zwangsläufig 
auftritt, auch auskommt !

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren