Hallo,
ich erstelle mal einen neuen Thread, damit dieses Problem und
hoffentlich auch eine Lösung für andere leichter zu finden ist.
Ich habe bei meinem Timing Report folgende Angabe gefunden:
1
Data Path Delay: 5.843ns (Levels of Logic = 0)
Im FPGA Editor sind die Daten direkt zum IOB FF geführt.
Wie kann es sein, dass ich ein derart großes Data Path Delay habe, wo
doch das erste FF direkt im IOB sitzt (Levels of Logic = 0)?
Danke!
MfG Andi
Die Zahl ist in der Tat etwas hoch für ein IO-FF. Die Angabe "Levels of
Logic : 0" sagt aber noch nichts darüber aus, ob ein IOFF oder ein
normales FF verwendet wird.
Könntest du uns einen größeren Teil des timing reports zeigen? Ansonsten
sollte es auch noch einen *.pad Report geben (oder auch *.io*, bei den
Dateiendungen bin ich mir nicht sicher), in dem nochmal für jeden Port
die genaue Position und die Konfiguration angegeben sind. Dort findest
du dann auch die Angabe ob das IOFF benutzt wird.
Hallo,
im Anhang ein größerer Ausschnitt des betreffenden Constraints.
Ich habe jetzt alles bis zum nächsten Constraint kopiert, bezogen habe
ich mich immer auf den ersten Teil (setup path).
Das .pad File habe ich auch gefunden und für die beiden Pins, die das
differential pair bilden, ist dort folgendes angegeben:
Ist das "LOCATED" ein Hinweis darauf, dass es sich um das IOBFF handelt?
Vielen Dank!
Wenn die Angaben stimmen sollten, woher kann dann das größere Delay
kommen?
MfG Andi
>Ist das "LOCATED" ein Hinweis darauf, dass es sich um das IOBFF handelt?
Nein, located heisst, dass du den Pin im UCF-File angegeben hast. Das
"yes" unter IO-Register ist das entscheidende.
>Wenn die Angaben stimmen sollten, woher kann dann das größere Delay>kommen?
Da du anscheinend einen IP-Block fuer DDR2-Speicher benutzt tippe ich
darauf, dass automatisch ein Delay in den Datenpfad eingefuegt worden
ist, damit die Daten zum richtigen Zeitpunkt ankommen. Das kannst du
testen indem du in deinen Constraints den input Offset von 3.015 auf
z.B. 2.5 ns aenderst, dann sollte sich das angebene Path Delay auch
automatisch aendern.
Hallo,
leider nutze ich keinen IP Core für IDDR2.
IDDR2 ist nur ein Baustein zum verarbeiten eines DDR Signals und wandelt
dieses in zwei SDR Signale um... mehr nicht.
Wenn ich also das Offset IN auf weniger als 3ns setze, bekomme ich
Constraintverletzungen gemeldet.
Data Path Delay: 5.843ns (Levels of Logic = 0)(Component delays alone exceeds constraint)
7
Clock Path Delay: 2.871ns (Levels of Logic = 2)
8
Clock Uncertainty: 0.000ns
Das Data Path Delay bleibt aber konstant.
Wenn ich mir im FPGA Editor den IOB anchaue, sehe ich das Bild im
Anhang. Da sehe ich ein aufgeschaltetes "FIXED" Delay vom Pad zum FF.
Kann ich dieses Delay in irgendeiner Weise beeinflussen?
Denn ich wüßte jetzt nicht, wieso ISE mir dort ein Delay reinbauen
sollte.
MfG Andi
Jetzt passt alles zusammen.
In deiner Grafik ist gezeigt, dass IFD auf 6 programmiert ist - Tabelle
19 in DS610 schreibt fuer IFD=6 TIOPICKD = 5.09ns, plus (Tabelle 22)
0.76 ns fuer LVDS_25, das ergibt zusammen genau die 5.84ns aus dem
Timing Report.
Im wesentlichen muesstest du das IFD-Delay auf kleinere Werte einstellen
um ein geringeres Delay zu erzeugen. Das sollte entweder ein generic vom
IDDR2-Block sein, oder ein Input in diesen Block - genau kann ich das
aber gerade auch nicht sagen.
Bevor du das machst, musst du natuerlich noch darauf achten, wie dein
Timing am Input wirklich ist, damit das timing nicht auf dem Papier gut
aussieht, aber nicht mit der Realitaet zusammenpasst.
Vielen Dank für den Hinweis.
Leider weiß ich nicht, wo du die IFD=6 herausliest.
Sind das die beiden Komponenten zwischen Delay_adj und FF?
Ich kann in meiner LVDS Datenquelle die Daten und den Takt beliebig
zueinander verschieben. So kann ich das veränderte Delay auch wieder
ausgleichen. Mir ist an sich ein festes Delay in der Quelle lieber als
ein Delay im FPGA, auch wenn es an sich das gleiche ist. Denn das Delay
der Quelle kann ich jederzeit via Seriel Interface ändern. Den FPGA
müßte ich komplett neu parametrieren. Aber so kann ich im FPGA die
constraints vielleicht noch etwas straffer setzen.
Ich werde in dieser Richtung noch etwas weiter schauen, vielen Dank!
MfG Andi
Andreas B. schrieb:
> Vielen Dank für den Hinweis.> Leider weiß ich nicht, wo du die IFD=6 herausliest.> Sind das die beiden Komponenten zwischen Delay_adj und FF?
Das ist das Delay_adj selber. Wenn du genau hinschaust, siehst du da
rechts zwei Ausgaenge, einmal IFD_OUT, einmal IBUF_OUT. Fuer beide ist
das eingestellte Delay in der Grafik oben rechts dargestellt, der
tuerkise Punkt in der Liste.
Laut
http://www.xilinx.com/itp/xilinx7/books/data/docs/s3edl/s3edl0028_20.html
kannst du das IFD_DELAY als generic an die IDDR2 Instanz uebergeben.
Ah ok,
bei mir lag es am IBUFDS selber, der hatte ohne Angabe
IFD_DELAY_VALUE => "AUTO" eingestellt.
Nun habe ich es händisch auf "3" gesetzt und das Data Path Delay ist auf
4.391 ns herunter gegangen. Nun kann ich anfangen die entsprechenden
constraints zu setzen und schaue dann mal, was dabei raus kommt.
Nun kann ich auch einen Offset IN von 1.6ns angeben und es wird
eingehalten, wobei es dann bei IFD_DELAY_VALUE => "2" schon wieder
Probleme gibt. Der Slack Wert wird zwar erwartungsgemäß immer größer,
aber scheinbar macht dann der Takt Probleme, den ich ja ohne DCM in den
FPGA führe und negiere (für das IDDR2). Scheinbar macht es Probleme,
wenn der Slack größer als die Hälfte der Taktperiode überschreitet. Das
muss ich nochmal genau durchdenken, ob diese Sache dann noch ok ist und
ob ein konfugurierbares Delay in der Datenquelle dauerhaft Abhilfe
schaffen kann.
Vielen Dank!
Andi
Ich hoffe man kann daraus irgendwie eine Aussage treffen, ob es so
stimmt, oder ob es unter Umständen zu Problemen kommen kann?
Ich selber würde es jetzt so stehen lassen, nur bin ich mir unsicher, ob
das einfach nur quick & dirty ist, oder ob es etwas handfestes ist.
Vielen Dank,
Andi
Hallo,
könnte nicht jemand noch einmal einen kurzen Blick darauf werfen, ob das
so stehen bleiben kann, oder ob es noch einiger Optimierung bedarf?!
Vielen Dank!
Andi
Hatte deine letzte Frage übersehen...
Ja, das ist alles in Ordnung, natürlich vorausgesetzt dass dein externer
Baustein auch genau das in dem Constraint angegebene Timing erzeugen
kann.
Da du das Timing auf beiden Seiten verschieben kannst gibt es hier
erstmal keine Einstellung die besser wäre als eine andere.