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
Hallo ChrisFN, der Simulator bekommt den Teilerfaktor via Generic zugewiesen, wie bekommt das Synthesetool die /16 mitgeteilt?
@ 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 !
Thread beobachten
Seitenaufteilung abschaltenBitte 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.