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!!
Gast
#1833045
Du kannst mal in den Clock Report schauen, wie die erkannten Takte aktuell benannt werden:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
Wenn ich mir den Takt z.B. auf ein Pin lege, ist XST der Meinung einen anderen Namen verwenden zu müssen. :-( Duke
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.
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.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.