mikrocontroller.net

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


Autor: Andreas B. (loopy83)
Datum:

Bewertung
0 lesenswert
nicht 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:
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

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welches FPGA?

Autor: Andreas B. (loopy83)
Datum:

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

Danke!

Autor: Jan M. (mueschel)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Andreas B. (loopy83)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht 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:
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|

H3|DOUT0A_P|DIFFMI_NDT|IO_L05P_3||LVDS_25|3||||||LOCATED|YES||
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

Autor: Jan M. (mueschel)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Andreas B. (loopy83)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht 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.
Slack (setup path):     -0.472ns (requirement - (data path - clock path - clock arrival + uncertainty))
  Source:               DOUT0A_P (PAD)
  Destination:          A0_S2P_1laneDATA/IDDR2_inst/A0_S2P_1laneDATA/IDDR2_inst/IDDR2.C0Q0/FF0 (FF)
  Destination Clock:    CLOCK_IN_0 rising at 0.000ns
  Requirement:          2.500ns
  Data Path Delay:      5.843ns (Levels of Logic = 0)(Component delays alone exceeds constraint)
  Clock Path Delay:     2.871ns (Levels of Logic = 2)
  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

Autor: Jan M. (mueschel)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Andreas B. (loopy83)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Jan M. (mueschel)
Datum:

Bewertung
0 lesenswert
nicht 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/... 
kannst du das IFD_DELAY als generic an die IDDR2 Instanz uebergeben.

Autor: Andreas B. (loopy83)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Andreas B. (loopy83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich stelle nun nochmal meine Ergebnisse zusammen:

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

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

Und dieser Timingreport wird mir dazu ausgegeben:
================================================================================
Timing constraint: COMP "DOUT0A_P" OFFSET = IN 1.5625 ns VALID 3.125 ns BEFORE COMP "TCLK_P"         "RISING";
 1 path analyzed, 1 endpoint analyzed, 0 failing endpoints
 0 timing errors detected. (0 setup errors, 0 hold errors)
 Minimum allowable offset is   0.167ns.
--------------------------------------------------------------------------------
Slack (setup path):     1.395ns (requirement - (data path - clock path - clock arrival + uncertainty))
  Source:               DOUT0A_P (PAD)
  Destination:          A0_S2P_1laneDATA/IDDR2_inst/A0_S2P_1laneDATA/IDDR2_inst/IDDR2.C0Q0/FF0 (FF)
  Destination Clock:    CLOCK_IN_0 rising at 0.000ns
  Requirement:          1.562ns
  Data Path Delay:      3.000ns (Levels of Logic = 0)
  Clock Path Delay:     2.833ns (Levels of Logic = 2)
  Clock Uncertainty:    0.000ns

  Maximum Data Path: DOUT0A_P to A0_S2P_1laneDATA/IDDR2_inst/A0_S2P_1laneDATA/IDDR2_inst/IDDR2.C0Q0/FF0
    Location             Delay type         Delay(ns)  Physical Resource
                                                       Logical Resource(s)
    -------------------------------------------------  -------------------
    H3.ICLK1             Tiopickd              3.000   DOUT0A_P
                                                       DOUT0A_P
                                                       A0_S2P_1laneDATA/IBUFDS_inst/IBUFDS
                                                       DOUT0A_P.DELAY_ADJ
                                                       A0_S2P_1laneDATA/IDDR2_inst/A0_S2P_1laneDATA/IDDR2_inst/IDDR2.C0Q0/FF0
    -------------------------------------------------  ---------------------------
    Total                                      3.000ns (3.000ns logic, 0.000ns route)
                                                       (100.0% logic, 0.0% route)

  Minimum Clock Path: TCLK_P to A0_S2P_1laneDATA/IDDR2_inst/A0_S2P_1laneDATA/IDDR2_inst/IDDR2.C0Q0/FF0
    Location             Delay type         Delay(ns)  Physical Resource
                                                       Logical Resource(s)
    -------------------------------------------------  -------------------
    A8.I                 Tiopi                 1.179   TCLK_P
                                                       TCLK_P
                                                       CLKIN_IBUFGDS_INST/IBUFDS
                                                       TCLK_P.DELAY_ADJ
    BUFGMUX_X1Y10.I0     net (fanout=1)        0.027   CLOCK_IN_01
    BUFGMUX_X1Y10.O      Tgi0o                 0.199   CLOCK_IN_0_BUFG
                                                       CLOCK_IN_0_BUFG
    H3.ICLK1             net (fanout=124)      1.428   CLOCK_IN_0
    -------------------------------------------------  ---------------------------
    Total                                      2.833ns (1.378ns logic, 1.455ns route)
                                                       (48.6% logic, 51.4% route)

--------------------------------------------------------------------------------

Hold Paths: COMP "DOUT0A_P" OFFSET = IN 1.5625 ns VALID 3.125 ns BEFORE COMP "TCLK_P"
        "RISING";
--------------------------------------------------------------------------------
Slack (hold path):      0.527ns (requirement - (clock path + clock arrival + uncertainty - data path))
  Source:               DOUT0A_P (PAD)
  Destination:          A0_S2P_1laneDATA/IDDR2_inst/A0_S2P_1laneDATA/IDDR2_inst/IDDR2.C0Q0/FF0 (FF)
  Destination Clock:    CLOCK_IN_0 rising at 0.000ns
  Requirement:          1.563ns
  Data Path Delay:      2.182ns (Levels of Logic = 0)
  Clock Path Delay:     3.218ns (Levels of Logic = 2)
  Clock Uncertainty:    0.000ns

  Minimum Data Path: DOUT0A_P to A0_S2P_1laneDATA/IDDR2_inst/A0_S2P_1laneDATA/IDDR2_inst/IDDR2.C0Q0/FF0
    Location             Delay type         Delay(ns)  Physical Resource
                                                       Logical Resource(s)
    -------------------------------------------------  -------------------
    H3.ICLK1             Tioickpd    (-Th)    -2.182   DOUT0A_P
                                                       DOUT0A_P
                                                       A0_S2P_1laneDATA/IBUFDS_inst/IBUFDS
                                                       DOUT0A_P.DELAY_ADJ
                                                       A0_S2P_1laneDATA/IDDR2_inst/A0_S2P_1laneDATA/IDDR2_inst/IDDR2.C0Q0/FF0
    -------------------------------------------------  ---------------------------
    Total                                      2.182ns (2.182ns logic, 0.000ns route)
                                                       (100.0% logic, 0.0% route)

  Maximum Clock Path: TCLK_P to A0_S2P_1laneDATA/IDDR2_inst/A0_S2P_1laneDATA/IDDR2_inst/IDDR2.C0Q0/FF0
    Location             Delay type         Delay(ns)  Physical Resource
                                                       Logical Resource(s)
    -------------------------------------------------  -------------------
    A8.I                 Tiopi                 1.284   TCLK_P
                                                       TCLK_P
                                                       CLKIN_IBUFGDS_INST/IBUFDS
                                                       TCLK_P.DELAY_ADJ
    BUFGMUX_X1Y10.I0     net (fanout=1)        0.033   CLOCK_IN_01
    BUFGMUX_X1Y10.O      Tgi0o                 0.221   CLOCK_IN_0_BUFG
                                                       CLOCK_IN_0_BUFG
    H3.ICLK1             net (fanout=124)      1.680   CLOCK_IN_0
    -------------------------------------------------  ---------------------------
    Total                                      3.218ns (1.505ns logic, 1.713ns route)
                                                       (46.8% logic, 53.2% route)

--------------------------------------------------------------------------------

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

Autor: Andreas B. (loopy83)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Jan M. (mueschel)
Datum:

Bewertung
0 lesenswert
nicht 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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.