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
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.
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.
Mach mal das "-- synopsys translate_off" und "-- synopsys translate_on"
raus. Ein VHDL-Synthesizer wertet das nämlich aus und ignoriert alles
dazwischen.
@ 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
@ 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
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!
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.
@ 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
"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 !
