Worauf beziehen sich die CLK-constraints bei Xilinx? Wenn ich von einem Quarz 100 MHz bekomme und auf 66 MHz herunter gehen will, wie muss ich das einsetzen? Ich habe jetzt z.B. NET "CLKOSC" TNM_NET = CLKOSC; TIMESPEC TS_CLKOSC = PERIOD "CLKOSC" 10 ns HIGH 50%; Vom DCM bekomme ich "CLKFPGA" 1.) Muss ich da ein extra constraint setzen? NET "CLKFPGA" TNM_NET = CLKFPGA; TIMESPEC TS_CLKFPGA = PERIOD "CLKFPGA" 16.66 ns HIGH 50%; 2.) Worauf müssen sich die Eingänge und Ausgänge beziehen? Bei ... NET "ADC_2" OFFSET = IN 11 NS VALID 12 ns BEFORE "CLKFPGA" RISING; ... findet er die "CLKFPGA" nicht - bzw es gibt keinen PFAD. Ich kann nur auf die OSC constrainen. Das nimmt er. Aber was trage ich da ein?
Unwissender schrieb: > Worauf beziehen sich die CLK-constraints bei Xilinx? du teilst ISE einfach mit, welche Leitungen bzw. Pins als Clock Signal für dein FPGA Design dienen und wie hoch die Frequenz ist, damit ISE entsprechend routen kann... Unwissender schrieb: > NET "CLKOSC" TNM_NET = CLKOSC; > TIMESPEC TS_CLKOSC = PERIOD "CLKOSC" 10 ns HIGH 50%; also weiß ISE absofort, dass der Pin CLKOSC ein Takt der Frequenz 100 Mhz mit 50% Duty Cylce hat und muss dem entsprechend routen - falls du mit dieser Frequenz ein Netzwerk taktest, welches nicht mit den spezifizierten 100 Mhz getaktet werden kann, bekommst du eine Fehlermeldung... Unwissender schrieb: > Vom DCM bekomme ich "CLKFPGA" > 1.) Muss ich da ein extra constraint setzen? ich gehe mal davon aus, dass es nicht nötig ist, da er es sich ja herleiten kann -> er weiß ja wie hoch die Frequenz ist... Unwissender schrieb: > 2.) Worauf müssen sich die Eingänge und Ausgänge beziehen? Bei ... > > NET "ADC_2" OFFSET = IN 11 NS VALID 12 ns BEFORE "CLKFPGA" RISING; > > ... findet er die "CLKFPGA" nicht - bzw es gibt keinen PFAD. Es kommt darauf an, wie du die Daten einlesen möchtest. Kommen Daten synchron mit einem Takt an dein FPGA so hast du ein Source Synchronous Input und ein Beispiel dazu findest du im "Timing Constraints User Guide" auf Seite 13. Du beschreibst mit dem OFFSET IN und VALID wieviel Zeit vor der Takt Flanke, zu der die Daten auf jeden Fall gültig sind, die Daten bereits gültig anliegen. Mit der VALID Anweisung beschreibst du die gesamte Dauer der Gültigkeit...
Das Problem ist aber doch, daß der FPGA intern mit nur 66MHz läuft und damit ganz andere Taktperioden sieht. Ausserdem ist dieser Takt ja "später dran" weil er aus einem IBUFG / DCM kommt. Wie soll das gehen, wenn es zwei Takte sind, die im FPGA verwendet werden? Ich kenne es nur von Altera, daß man die CLKs entweder per Hand spezifiziert, oder mit dem alten Timing Analyzer die Clk vorgibt und er leitet selber die internen Takte ab.
Die verschiedenen Constraints für die DCM Ausgänge werden automatisch ermittelt. Kompliziert wirds bei OFFSET IN und OUT, meines Wissens kann man die nur auf von außen kommende CLK beziehen.
Christian R. schrieb: > Kompliziert wirds bei OFFSET IN und OUT, meines Wissens kann > man die nur auf von außen kommende CLK beziehen stimmt... Unwissender schrieb: > Das Problem ist aber doch, daß der FPGA intern mit nur 66MHz läuft und > damit ganz andere Taktperioden sieht. wie sieht er ganz andere Taktperioden...??? Wenn du den Takt, der von außen kommt, durch Constraints beschreibst weiß er schonmal was in den DCM geht und kann sich mit den DCM Einstellungen auch das Ausgangssignal herleiten... Ich weiß nicht wo dein Problem ist... gibt es Timing Errors?
Naja, ich wil es einfach richtig machen. > Kompliziert wirds bei OFFSET IN und OUT, meines Wissens kann > man die nur auf von außen kommende CLK beziehen Das ist ja schon einmal eine Aussage. Was ich an Problem z.B habe, ist, daß er trotz mehrfacher Instaziierung zusätlzicher FFs für die Ausgangspfade immer noch mehr als 10ns braucht, um vom letzten FF rauszukommen. An den Eingängen funktioniert das mit 5-6ns.
Unwissender schrieb: > Was ich an Problem z.B habe, ist, daß er trotz mehrfacher Instaziierung > zusätlzicher FFs für die Ausgangspfade immer noch mehr als 10ns braucht, > um vom letzten FF rauszukommen. Mit welchem FPGA/CPLD denn? Speedgrade? Das erscheint mir relativ hoch. Du kannst mal versuchen, das IOB Packaging für die Outputs zu aktivieren. Oder speziell bei den Ausgangs-Netzen im ucf File IOB = TRUE eintragen. Oder sind da noch kombinatorische Verknüpfungen zwischen dem letzten FF und dem Pin?
Alles Probiert und angeschaltet. Die letzten FFs liegen in den IO-Zellen, davor sind jeweils 2 Register solo ohne Anschlüsse, damit er mit dem routing gut hinkommt. Trotzdem geht es nicht. Virtex 4, Design soll auf 120 MHz. Ich hätte gern 8ns. Das muss doch machbar sein. (?)
Hm, das ist seltsam. Ich hab beim Virtex 4 manchmal sogar manchmal das Problem, dass die Ausgänge zu schnell sind und Hold-Zeiten externer Chips dann nicht eingehalten werden können. Kann eigentlich nicht sein. Wenn das letzte FlipFlop das OFF im IOB ist, dann ist das Signal doch viel schneller am Pin als in 10ns. Wie kommst du eigentlich an den Wert?
Der Abschlussbericht von Xilinx sagt mir, daß er Zeiten <9ns nicht bauen kann. (?)
Unwissender schrieb: > Der Abschlussbericht von Xilinx sagt mir, daß er Zeiten <9ns nicht bauen > kann. > (?) Was sagt denn der Static Timing Report genau zu deinem Design?
Er definiert einen negativen slack und erklärt, daß er einige signale nicht im timing hat. wenn ich ihm mehr raum gebe, klappt es.
Das ist der report:
------------------------------------------------- -------------
B15.I Tiopi 0.951 CLK1
CLK1
Inst_my_dcm/CLKIN_IBUFG_INST
BUFGCTRL_X0Y31.I0 net (fanout=1) 0.835 fpga_clk1
BUFGCTRL_X0Y31.O Tbgcko_O 0.900 fpga_clk_BUFG
fpga_clk_BUFG
OLOGIC_X2Y161.CLK net (fanout=6069) 2.937 fpga_clk
------------------------------------------------- --------------
Total 5.623ns (1.851ns logic,
3.772ns route)
Langsam glaube ich, daß ich das mit den CLKs und BUFGs nicht korrekt
mache.
CLK1 ist der Pin, der auf eine DCM geht, fpga_clk der allgemeine Takt
für das gesamte FPGA
Inst_my_dcm: my_dcm PORT MAP
(
CLKIN_IN => CLK1,
CLKFX_OUT => open,
CLKIN_IBUFG_OUT => fpga_clk,
CLK0_OUT => open,
LOCKED_OUT => open
);
Wenn ich die fpga_clk auf clk0_out verschiebe, ist es dasselbe.
Vielleicht erklärst Du nochmals von vorne, was Du eigenlich erreichen willst, denn das ist noch nicht klar (mir zumindest). - Du hast einen 100 MHz Takt und machst intern 66 MHz. - Du hast einen ADC zum einlesen, dessen Ausgänge sich wahrscheinlich auf den ADC Takt beziehen. Wo kommt der Takt her, wird der vom FPGA erzeugt und an einen PIN gelegt? - Du hast Ausgänge, die innerhalb einer gewissen Zeit kommen müssen. In Bezug aber auf was? Ein Absolut-Bezug zum internen Takt ist aber irrelevant, denn davon weiss die externe Baugruppe nichts, eventuell in Bezug auf ein anderes Signal das Du generierst oder das von außen kommt.
Das mit den Constraints ist nun ok, er bezieht alles auf den IO-Pin. Das 66MHz-Problem lasse ich momentan beiseite. Ich habe nun das Problem, daß ich das Timing bei 100MHz nicht treffe, weil z.B. die Ausgänge das Setup 8ns nicht verkraften. (Ich rechne 10ns - 2ns Offset extern = 8ns maximales delay vom clk zum ausgang)
Eigentlich kommt man aus einem Virtex schnell genug raus, um 100MHz fahren zu können. Wie hast Du die constraintsaufgesetzt?
man kommt eigentlich bei jedem fpga schnell genug raus, wenn man die IO-FFs nutzt.
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.