Forum: FPGA, VHDL & Co. Data Path Delay zum IOB FF 5,8ns


von Andreas B. (loopy83)


Lesenswert?

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

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Welches FPGA?

von Andreas B. (loopy83)


Lesenswert?

Oh Verzeihung, die Angabe habe ich vergessen:
Es ist ein Spartan 3A DSP

Danke!

von Jan M. (mueschel)


Lesenswert?

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.

von Andreas B. (loopy83)


Angehängte Dateien:

Lesenswert?

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:
1
Pin Number|Signal Name|Pin Usage|Pin Name|Direction|IO Standard|IO Bank Number|Drive (mA)|Slew Rate|Termination|IOB Delay|Voltage|Constraint|IO Register|Signal Integrity|
2
3
H3|DOUT0A_P|DIFFMI_NDT|IO_L05P_3||LVDS_25|3||||||LOCATED|YES||
4
H4|DOUT0A_N|DIFFSI_NDT|IO_L05N_3||LVDS_25|3||||||LOCATED|YES||
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

von Jan M. (mueschel)


Lesenswert?

>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.

von Andreas B. (loopy83)


Angehängte Dateien:

Lesenswert?

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.
1
Slack (setup path):     -0.472ns (requirement - (data path - clock path - clock arrival + uncertainty))
2
  Source:               DOUT0A_P (PAD)
3
  Destination:          A0_S2P_1laneDATA/IDDR2_inst/A0_S2P_1laneDATA/IDDR2_inst/IDDR2.C0Q0/FF0 (FF)
4
  Destination Clock:    CLOCK_IN_0 rising at 0.000ns
5
  Requirement:          2.500ns
6
  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

von Jan M. (mueschel)


Lesenswert?

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.

von Andreas B. (loopy83)


Lesenswert?

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

von Jan M. (mueschel)


Lesenswert?

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.

von Andreas B. (loopy83)


Lesenswert?

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

von Andreas B. (loopy83)


Lesenswert?

Ich stelle nun nochmal meine Ergebnisse zusammen:

den IBUFDS habe ich nun wie folgt verwendet:
1
IBUFDS_inst : IBUFDS
2
generic map ( IFD_DELAY_VALUE => "1" )
3
port map ( O => DATA_IN, I => DOUT_P, IB => DOUT_N );

Dazu verwende ich folgendes constraint:
1
NET "DOUT0A_P" OFFSET = IN 1.5625 ns VALID 3.125 ns BEFORE "TCLK_P" RISING;

Und dieser Timingreport wird mir dazu ausgegeben:
1
================================================================================
2
Timing constraint: COMP "DOUT0A_P" OFFSET = IN 1.5625 ns VALID 3.125 ns BEFORE COMP "TCLK_P"         "RISING";
3
 1 path analyzed, 1 endpoint analyzed, 0 failing endpoints
4
 0 timing errors detected. (0 setup errors, 0 hold errors)
5
 Minimum allowable offset is   0.167ns.
6
--------------------------------------------------------------------------------
7
Slack (setup path):     1.395ns (requirement - (data path - clock path - clock arrival + uncertainty))
8
  Source:               DOUT0A_P (PAD)
9
  Destination:          A0_S2P_1laneDATA/IDDR2_inst/A0_S2P_1laneDATA/IDDR2_inst/IDDR2.C0Q0/FF0 (FF)
10
  Destination Clock:    CLOCK_IN_0 rising at 0.000ns
11
  Requirement:          1.562ns
12
  Data Path Delay:      3.000ns (Levels of Logic = 0)
13
  Clock Path Delay:     2.833ns (Levels of Logic = 2)
14
  Clock Uncertainty:    0.000ns
15
16
  Maximum Data Path: DOUT0A_P to A0_S2P_1laneDATA/IDDR2_inst/A0_S2P_1laneDATA/IDDR2_inst/IDDR2.C0Q0/FF0
17
    Location             Delay type         Delay(ns)  Physical Resource
18
                                                       Logical Resource(s)
19
    -------------------------------------------------  -------------------
20
    H3.ICLK1             Tiopickd              3.000   DOUT0A_P
21
                                                       DOUT0A_P
22
                                                       A0_S2P_1laneDATA/IBUFDS_inst/IBUFDS
23
                                                       DOUT0A_P.DELAY_ADJ
24
                                                       A0_S2P_1laneDATA/IDDR2_inst/A0_S2P_1laneDATA/IDDR2_inst/IDDR2.C0Q0/FF0
25
    -------------------------------------------------  ---------------------------
26
    Total                                      3.000ns (3.000ns logic, 0.000ns route)
27
                                                       (100.0% logic, 0.0% route)
28
29
  Minimum Clock Path: TCLK_P to A0_S2P_1laneDATA/IDDR2_inst/A0_S2P_1laneDATA/IDDR2_inst/IDDR2.C0Q0/FF0
30
    Location             Delay type         Delay(ns)  Physical Resource
31
                                                       Logical Resource(s)
32
    -------------------------------------------------  -------------------
33
    A8.I                 Tiopi                 1.179   TCLK_P
34
                                                       TCLK_P
35
                                                       CLKIN_IBUFGDS_INST/IBUFDS
36
                                                       TCLK_P.DELAY_ADJ
37
    BUFGMUX_X1Y10.I0     net (fanout=1)        0.027   CLOCK_IN_01
38
    BUFGMUX_X1Y10.O      Tgi0o                 0.199   CLOCK_IN_0_BUFG
39
                                                       CLOCK_IN_0_BUFG
40
    H3.ICLK1             net (fanout=124)      1.428   CLOCK_IN_0
41
    -------------------------------------------------  ---------------------------
42
    Total                                      2.833ns (1.378ns logic, 1.455ns route)
43
                                                       (48.6% logic, 51.4% route)
44
45
--------------------------------------------------------------------------------
46
47
Hold Paths: COMP "DOUT0A_P" OFFSET = IN 1.5625 ns VALID 3.125 ns BEFORE COMP "TCLK_P"
48
        "RISING";
49
--------------------------------------------------------------------------------
50
Slack (hold path):      0.527ns (requirement - (clock path + clock arrival + uncertainty - data path))
51
  Source:               DOUT0A_P (PAD)
52
  Destination:          A0_S2P_1laneDATA/IDDR2_inst/A0_S2P_1laneDATA/IDDR2_inst/IDDR2.C0Q0/FF0 (FF)
53
  Destination Clock:    CLOCK_IN_0 rising at 0.000ns
54
  Requirement:          1.563ns
55
  Data Path Delay:      2.182ns (Levels of Logic = 0)
56
  Clock Path Delay:     3.218ns (Levels of Logic = 2)
57
  Clock Uncertainty:    0.000ns
58
59
  Minimum Data Path: DOUT0A_P to A0_S2P_1laneDATA/IDDR2_inst/A0_S2P_1laneDATA/IDDR2_inst/IDDR2.C0Q0/FF0
60
    Location             Delay type         Delay(ns)  Physical Resource
61
                                                       Logical Resource(s)
62
    -------------------------------------------------  -------------------
63
    H3.ICLK1             Tioickpd    (-Th)    -2.182   DOUT0A_P
64
                                                       DOUT0A_P
65
                                                       A0_S2P_1laneDATA/IBUFDS_inst/IBUFDS
66
                                                       DOUT0A_P.DELAY_ADJ
67
                                                       A0_S2P_1laneDATA/IDDR2_inst/A0_S2P_1laneDATA/IDDR2_inst/IDDR2.C0Q0/FF0
68
    -------------------------------------------------  ---------------------------
69
    Total                                      2.182ns (2.182ns logic, 0.000ns route)
70
                                                       (100.0% logic, 0.0% route)
71
72
  Maximum Clock Path: TCLK_P to A0_S2P_1laneDATA/IDDR2_inst/A0_S2P_1laneDATA/IDDR2_inst/IDDR2.C0Q0/FF0
73
    Location             Delay type         Delay(ns)  Physical Resource
74
                                                       Logical Resource(s)
75
    -------------------------------------------------  -------------------
76
    A8.I                 Tiopi                 1.284   TCLK_P
77
                                                       TCLK_P
78
                                                       CLKIN_IBUFGDS_INST/IBUFDS
79
                                                       TCLK_P.DELAY_ADJ
80
    BUFGMUX_X1Y10.I0     net (fanout=1)        0.033   CLOCK_IN_01
81
    BUFGMUX_X1Y10.O      Tgi0o                 0.221   CLOCK_IN_0_BUFG
82
                                                       CLOCK_IN_0_BUFG
83
    H3.ICLK1             net (fanout=124)      1.680   CLOCK_IN_0
84
    -------------------------------------------------  ---------------------------
85
    Total                                      3.218ns (1.505ns logic, 1.713ns route)
86
                                                       (46.8% logic, 53.2% route)
87
88
--------------------------------------------------------------------------------

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

von Andreas B. (loopy83)


Lesenswert?

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

von Jan M. (mueschel)


Lesenswert?

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.

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
Noch kein Account? Hier anmelden.