Ich treibe mittels eines 150 MHZ Taktes Daten sowohl über DDR (300) als auch normal in ein externes Hardwaremodul. Die 150MHz kommen, nebst einigen anderen Takten aus einem 100 MHz quarz. 100 -> DCM -> 166 -> 150 -> 66 Bei der Vergabe der constraints bietet mir xilinx nur die 100Mhz als Bezugspunkt an. Ich habe daher die maximale IO-Delay auf 6000 ps gesetzt und zwar für die 166 MHz (noch nichts dafür designed) und die 150MHz. Nun meckert er rum: WARNING:Timing:3175 - clk_100mhz does not clock data to ddc_car_data<10> WARNING:Timing:3225 - Timing constraint COMP "ddc_car_data<10>" OFFSET = OUT 6 ns AFTER COMP "clk_100mhz" REFERENCE_PIN BEL "ddc_module1/ddc_car_out_clk" "FALLING"; ignored during timing analysis Dieselben constaints für rising werden aber genommen! Woran kann das liegen? der 150er treibt definitiv DDR-FFs und der ISE Editor liefert bei der Auswahl "DDR" auch zwei Zeilen dafür ab.
Im Prinzip hat es doch recht. Die OFFSET IN/OUT constraints beziehen sich auf ein Taktsignal an einem Eingangspin. Die Constraints die Du brauchst, beziehungsweise die Verzögerungen, die Du unter Kontrolle bringen willst, beziehen sich aber auf den generierten 150 MHz Takt, der intern erzeugt wird, und der ebenfalls an einem Pin AUSGEGEBEN wird. Es geht eigentlich darum, die Differenz zwischen den beiden Ausgangssignalen unter Kontrolle zu bringen. Soviel ich mich erinnnere, eignen sich OFFSET IN/OUT constraints dazu nicht.
also eigendl. musst du nur den inputclk, also die 100MHz in die DCM beschreiben, die generierten clks werden dann daraus abgeleitet
OFFSET klappt nur bei externen Takten: http://www.xilinx.com/support/documentation/white_papers/wp237.pdf Wenn ein DCM zwischen den FlipFlops und dem externen Takt hängt, kann ISE das in einigen Fällen auflösen, aber nicht immer.
Wie müsste man stattdessen constrainen? Im constrainat Editor wird sonst unter timing nichts angeboten.
Klaus Falser schrieb: > Im Prinzip hat es doch recht. > > Die OFFSET IN/OUT constraints beziehen sich auf ein Taktsignal an einem > > Eingangspin. Kleiner Einwand: Ich befasse mich selbst gerade mit einem solchen Problem und bin über folgende Passage gestolpert: http://www.xilinx.com/support/documentation/white_papers/wp237.pdf Seite6, unten "Figure 6: OFFSET IN Constraint with VALID Keyword" beim Bild: • TIMEGRP DATA_IN OFFSET IN = 1 VALID 3 BEFORE CLK TIMEGRP FF_RISING; • TIMEGRP DATA_IN OFFSET IN = 4 VALID 3 BEFORE CLK TIMEGRP FF_FALLING; Beides ist benannt! Sehe ich das richtig, dass man das falling nur dann benötigt, wenn man auch Gruppen/Signale benutzt, die falling edges verwenden?
Klaus schrieb: > Wie müsste man stattdessen constrainen? Gar nicht! Ich bin darueber auch mal gestolpert (allerdings kein DDR). Es laeuft im Endeffekt darauf hinaus, dass du das FF in eine I/O-Zelle legst. Bei einem DDR passiert das ja automatisch, beim normalen FF musst du das halt sicherstellen (Einstellungen der Toolchain oder Attribut im VHDL).
Michel schrieb: > berndl schrieb: >> Attribut im VHDL). > > wie? Bei Xilinx:
1 | attribute IOB : string; |
2 | attribute IOB of <signalname> : signal is "true"; |
berndl schrieb: > Gar nicht! Ich bin darueber auch mal gestolpert (allerdings kein DDR). > > Es laeuft im Endeffekt darauf hinaus, dass du das FF in eine I/O-Zelle > > legst Wie wird sichergestellt, dass das dann passt? Wir das nicht von den Tools geprüft?
Bitte 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.