Spartan3 - DDR / DCM - Timing-Constraint-Probleme

[Michael O. (mischu)]

Hallo zusammen,

Webpack optimiert mir meine schönen Timing - Constraints für einen 
differentiellen DDR Ausgang einfach weg ....
Ich habe mich schon durch diverse "Anleitungen" und Tutorials geklickt, 
aber keine passenden Vorschlag gefunden der exakt für mein System passt.

Mein System sieht so aus:

Eingangstakt: 50MHz
Datentakt:   200MHz (0° & 180°) (intern per DCM erzeugt)
Datenströme: (16bit) jeweils für rising und falling edge
DDR - FlipFlop: FDDRCPE  (DDR-FF ohne Ausgangspad)
Ausgangsbuffer: OBUFDS (Differentieller Ausgangsbuffer)
Datentaktausgang: 200MHz werden (leider nicht anders möglich) per OBUF 
ausgegeben

Damit die externen differentiellen Datan zum Clock in einer Beziehung 
stehen habe ich folgende UCF Constraints gesetzt.
(clock_ext: 50MHz Eingang;  clock200: 200MHz Takt aus DCM)
-----------------------------------
NET "clock_ext" TNM_NET = clock_int;
TIMESPEC TS_clock_ext = PERIOD "clock_int" 20 ns HIGH 50%;

NET "clock200" TNM_NET = clock200;
TIMESPEC "TS_clock200" = PERIOD "clock200_int" 5 ns HIGH 50%;

Alle Datenausgänge (exemplarisch):
INST "Data_out_P_ext<x>" TNM = Data_Out_pads;
...

TIMEGRP "Data_Out_pads" OFFSET = OUT 2.5 ns AFTER "clock_ext" RISING;
TIMEGRP "Data_Out_pads" OFFSET = OUT 2.5 ns AFTER "clock_ext" FALLING;

-----------------------------------
Dazu bekomme ich folgende Warnings :
WARNING:Timing:3224 - The clock clock_ext associated with TIMEGRP
   "Data_Out_pads" OFFSET = OUT 1.25 ns VALID 2.5 ns AFTER COMP 
"clock_ext"
   "FALLING" does not clock any registered output components.
WARNING:Timing:3225 - Timing constraint TIMEGRP "Data_Out_pads" OFFSET =
   OUT 1.25 ns VALID 2.5 ns AFTER COMP "clock_ext" "FALLING" ignored 
during
   timing analysis


Sofern ich statt clock_ext die 200MHz Clock als Bezug angebe erhalte ich 
dieselben Warnings.

Hat jemand dieselben Probleme??
Irgend welche Vorschläge??

VIelen Dank für Eure Unterstützung!!

[Duke Scarring (Gast)]

Du kannst mal in den Clock Report schauen, wie die erkannten Takte 
aktuell benannt werden:

**************************
Generating Clock Report
**************************

+---------------------+--------------+------+------+------------+-------------+
|        Clock Net    |   Resource   |Locked|Fanout|Net Skew(ns)|Max Delay(ns)|
+---------------------+--------------+------+------+------------+-------------+
|          box_i0/clk | BUFGMUX_X2Y10| No   | 1081 |  0.073     |  0.175      |

Wenn ich mir den Takt z.B. auf ein Pin lege, ist XST der Meinung einen 
anderen Namen verwenden zu müssen. :-(

Duke

[Michael O. (mischu)]

Ich habe erstmal ein Workarround gefunden für das Problem.
Ich verwende eine DCM um den Takt Ausgangstakt relativ zum Datentakt zu 
verschieben ...   Try - and error.

Das Routing inklusive Delays habe ich mir angesehen. Er behandelt die 
zugehörigen Clocksignala via BUFG als Clocks und verwendet diese an den 
finalen DDR-FFs.

In meinem Design gebe ich ein Clocksignal mit den Daten aus.
Die Daten laufen am PAD durch ein DDR-FF mit nachgeschaltetem 
differentiellen Buffer. Da kann man an den Timings der Datenströme doch 
gar nichts mehr drehen.
Das Clocksignal habe ich schon auf diverse Arten erzeugt - final nehme 
ich ebenfalls jeweils einen DDR-FF und lasse bei z.B. steigender Flanke 
ein 1 und bei fallender Flanke eine 0 ausgeben. Somit müssten alle 
Ausgänge von Typ her sich änhlich verhalten.

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

Ich habe gerade ein ähnliches Problem und hänge mich mal hier dran:

Michael O. schrieb:
> TIMEGRP "Data_Out_pads" OFFSET = OUT 2.5 ns AFTER "clock_ext" RISING;

Ist das korrekt so?  Muss statt clock_exgt nicht der erzeugende Takt der 
DCM rein?

Michael O. schrieb:
> "FALLING" does not clock any registered output components.
Geht es bei Rising?

So ein Fehler kommt ja meistens dann, wenn man ein statisches Signal 
ausgibt. Bei DDR wird aber immer umgeschaltet, sofoern vorne wirklich 0 
und 1 an den Eingängen liegen.