Xilinx IO constraints werden ignoriert

[Klaus U. (Gast)]

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.

[Klaus F. (kfalser)]

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.

[user (Gast)]

also eigendl. musst du nur den inputclk, also die 100MHz in die DCM 
beschreiben, die generierten clks werden dann daraus abgeleitet

[Christian R. (supachris)]

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.

[Klaus (Gast)]

Wie müsste man stattdessen constrainen?
Im constrainat Editor wird sonst unter timing nichts angeboten.

[Robert K. (Firma: Medizintechnik) (robident)]

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?

[berndl (Gast)]

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 (Gast)]

berndl schrieb:
> Attribut im VHDL).

wie?

[Christian R. (supachris)]

Michel schrieb:
> berndl schrieb:
>> Attribut im VHDL).
>
> wie?

Bei Xilinx:

attribute IOB : string;
attribute IOB of <signalname> : signal is "true";

[CZM (Gast)]

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?