Benötige Hilfe beim DDR Constraints

Hier ist eine Timing Analyse von einem Datenpfad: Ich habe den CLK um 
14*78ps verzögert.



Timing constraint: OFFSET = IN 2 ns VALID 1.5 ns BEFORE COMP 
"ADC_1_DRY_P" TIMEGRP         GROUP_IDDR_ADC_1_DATA "RISING";
 28 paths analyzed, 14 endpoints analyzed, 14 failing endpoints
 14 timing errors detected. (0 setup errors, 14 hold errors)
 Minimum allowable offset is   0.985ns.
------------------------------------------------------------------------ 
--------
Slack (setup path):     1.015ns (requirement - (data path - clock path - 
clock arrival + uncertainty))
  Source:               ADC_1_DATA_12_N (PAD)
  Destination:          IDDR_ADC_1_DATA_12 (FF)
  Destination Clock:    W_ADC_1_DRY rising at 0.000ns
  Requirement:          2.000ns
  Data Path Delay:      5.478ns (Levels of Logic = 2)
  Clock Path Delay:     4.518ns (Levels of Logic = 3)
  Clock Uncertainty:    0.025ns

  Clock Uncertainty:          0.025ns  ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + 
PE
    Total System Jitter (TSJ):  0.050ns
    Total Input Jitter (TIJ):   0.000ns
    Discrete Jitter (DJ):       0.000ns
    Phase Error (PE):           0.000ns

  Maximum Data Path: ADC_1_DATA_12_N to IDDR_ADC_1_DATA_12
    Location             Delay type         Delay(ns)  Physical Resource
                                                       Logical 
Resource(s)
    ------------------------------------------------- 
-------------------
    AE23.PADOUT          Tiopp                 0.000   ADC_1_DATA_12_N
                                                       ADC_1_DATA_12_N
    AF23.DIFFI_IN        net (fanout=1)        0.000 
IBUFDS_ADC_1_DATA_12/SLAVEBUF.DIFFIN
    AF23.I               Tiodi                 1.164   ADC_1_DATA_12_P
                                                       IBUFDS_ADC_1_DATA_12/IBUFDS
    ILOGIC_X0Y31.DDLY    net (fanout=1)        3.962   W_ADC_1_DATA_12
    ILOGIC_X0Y31.CLK     Tidockd               0.352   B_ADC_1_DATA<12>
                                                       IDDR_ADC_1_DATA_12
    ------------------------------------------------- 
---------------------------
    Total                                      5.478ns (1.516ns logic, 
3.962ns route)
                                                       (27.7% logic, 
72.3% route)

  Minimum Clock Path: ADC_1_DRY_P to IDDR_ADC_1_DATA_12
    Location             Delay type         Delay(ns)  Physical Resource
                                                       Logical 
Resource(s)
    ------------------------------------------------- 
-------------------
    AC17.I               Tiopi                 1.074   ADC_1_DRY_P
                                                       ADC_1_DRY_P
                                                       IBUFGDS_ADC_1_DRY/IBUFDS
    IODELAY_X1Y23.IDATAINnet (fanout=1)        0.000 
W_ADC_1_DRY_IBUFGDS
    IODELAY_X1Y23.DATAOUTTioddo_IDATAIN        1.945   IDELAY_ADC_1_DRY
                                                       IDELAY_ADC_1_DRY
    BUFGCTRL_X0Y6.I0     net (fanout=2)        1.162   W_ADC_1_DRY1
    BUFGCTRL_X0Y6.O      Tbgcko_O              0.230   W_ADC_1_DRY_BUFG
                                                       W_ADC_1_DRY_BUFG
    ILOGIC_X0Y31.CLK     net (fanout=64)       0.107   W_ADC_1_DRY
    ------------------------------------------------- 
---------------------------
    Total                                      4.518ns (3.249ns logic, 
1.269ns route)
                                                       (71.9% logic, 
28.1% route)

Deine Daten kommen mit 200 MHz im DDR-Mode rein?
D.h. 200 MHz, DDR = alle 2.5 ns eine Flanke.

Johann schrieb:
> den CLK um 14*78ps verzögert
Das entspricht 1.01 ns.

> Data Path Delay:      5.478ns (Levels of Logic = 2)
> Clock Path Delay:     4.518ns (Levels of Logic = 3)
Die scheint er ja auch zu berücksichtigen.


Johann schrieb:
> Jedoch habe ich ein Beispiel Constraint im Internet gefunden was den
> Offset-In-Parameter auf 2ns setzt und den Data Valid Parameter auf
> 1.5ns. Diese Variante halte ich auch für logisch richtig jedoch bin ich
> verunsichert und wollte Euren Rat einholen.
Das ist möglicherweise für ein anderes Beispiel? Anderer Takt, anderer 
ADC?

Da steht, das es hold-Zeit Verletzungen sind.
Johann schrieb:
>  ... 14 hold errors)
>  Minimum allowable offset is   0.985ns.
Also liegen die Daten nicht lange genug an. Versuch doch mal eine 
Taktverzögerung von 12 * 78 ps = 935 ps. Damit solltest Du unter die 
geforderten 0.985 ns kommen.

Kann Dein ADC Testpattern generieren? Damit läßt sich die Übertragung 
prüfen.

Duke

Leider kann der keine Testsignale erzeuge. Ich muss einen 
Funtinsgenerator nehmen und einen Sinus erzeugen.

Den schaue ich mir an auerßdem ezeuge ich die FFT von dem Signal. Ich 
werde es mal mit 12 ausprobieren.

Muss ich denn nur 2ns als Offset-In-Parameter verwenden oder 0.5ns?

Weis denn keiner wie ich diese Constraint richtig setzen muss?

0.5ns oder 2ns für den Offset-IN-Parameter

Ich knapper schon die Tischkante. :-)

Und das wieder so kurz vor Weihnachten

Johann schrieb:
> Muss ich denn nur 2ns als Offset-In-Parameter verwenden oder 0.5ns?
Wenn ich mir Deine Grafiken im ersten Beitrag anschaue, dann würde ich 
sagen 0.5 ns.

Duke

0.5ns empfielt der Wizard. Aber rein logisch würde ich 2ns sagen, daher 
bin ich sehr unsicher. Ich denke jedoch das bereits einige mit DDR 
Signalen zu tun hatten siehe DDR RAM

Hier ist leider kein Beispiel für DDR constraints vorhanden. Außerdem 
wird das Valid constraint nicht benutzt.

Wenn ich das richtig verstehe dann stellt das Offset In Constraint 
folgendes da:

Das Offset In Constraint gibt an wie der Zusammenhang zwischen dem CLK 
und den Datenleitungen ist. Der Zusammenhang bezieht sich auf die Pads.

OFFSET = IN 2.0 ns VALID 1.5 ns BEFORE "ADC_1_DRY_P" TIMEGR 
"GROUP_IDDR_ADC_1_DATA" RISING;

bedeutet das die Daten 2ns vor der ansteigenden CLK Flanke satbil 
anliegen. Die Daten bleiben für 1.5ns  stabil. Demnach kann mit Hilfe 
des Constraint geprüft werden, ob die Setup and Hold Zeit am ersten 
FlipFlop eingehalten wird.

Im FPGA werden die Datenleitungeu und CLK Leitung bis zum ersten FF 
unterschiedlich verzögert.

Muss jetzt am Flip Flop immer die Datenleitung zuerst ankommen oder ist 
es besser wenn der Clock voher da ist? (Dadurch würde ja das Signal nur 
1 Takt später übernommen werden)


ICH VERSTEHE NUR NICHT WARUM DER WIAZRD IN DEN SCREENSHOTS ES ANDERS 
BESCHREIBT. HIER MUSS ICH JA EINE SEHR GERINGE OFFSET IN ZEIT VON 0.5ns 
ANGEBEN.

Ich hatte auch den Wizard benutzt. Er erzeugt ein Constraint für rising 
und eins für falling edge. Nur leider werden die Timing nicht 
eingehalten, obwohl die Daten nach dem IBUFDS direkt auf ein IDDR geht. 
Dies habe ich auch mit dem Plan Ahead geprüft.

Bei einer Periode von 5ns ergibt das 2.5ns für die High-Phase und 2.5ns 
für die Low-Phase.

Im idealen Fall ändern die Daten zusammen mit dem Clock ihren Zustand. 
Jedoch steht im Datenblatt das die Daten SPÄTESTENS 0.5 ns nach jeden 
CLK-Flankenwechseln gültig anliegen.

Außerdem ist auch 0.5ns vor jedem Flankenwechsel kein stabiles 
Datensignal zu erwarten.

Darauchs  bin ich zu folgende Constraints gekommen:

OFFSET IN = (Periodendauer / 2) - 0.5ns --> 2.0ns
VALID = (Periodendauer / 2) - (2 x 0.5ns) --> 1.5ns

OFFSET = IN 2.0 ns VALID 1.5 ns BEFORE "ADC_1_DRY_P" TIMEGRP
"GROUP_IDDR_ADC_1_DATA" RISING;
OFFSET = IN 2.0 ns VALID 1.5 ns BEFORE "ADC_1_DRY_P" TIMEGRP
"GROUP_IDDR_ADC_1_DATA" FALLING

Jetzt hatte ich den Einfall einfach den CLK mit Hilfe eines IDELAYS um 
1.8 ns zu verzögern. Dadurch liegen die Daten mehr als 1.3ns (1.8ns 
-0.5ns = 1.3ns) stabil an wenn eine Clock-Flanke eintritt.

Also habe ich die Verzögerung eingebaut und mit Hilfe von Plan Ahead das 
ganze untersucht. Ich habe die Laufzeit des Datenpfads vom Input Pad bis 
zum IDDR Element ermittelt und die Laufzeit vom CLK (PAD bis IDDR). 
Anschließend habe ich die Differenz beider Datenpfade gebildet. Die 
Daten liegen aus meiner sich lange genug stabil an. Leider habe ich 
nichts gefunden wie lange die Setup Time von einem IDDR bei einem Virtex 
5 ist.

Ich kann durch das Verschieben des CLKs die Setup-Time einhalten jedoch 
erhalte ich dann einen negativen Slack beim Hold-Timing.


Die genauen Zeiten der Pfade kann ich beim nächsten mal posten. Und das 
Ergebnis der Timing Analyse.

Die Daten kommen werden schon richtig in den FIFO geschrieben. Nur ab 
und zu ledier nicht. Ich denke das ist ein Timing Problem das bei 
unterschiedlich Temperaturen auftritt.

Was mich halt wundert ist wenn ich dein IDEALY verwende dann steht im 
Datenblatt das pro Stuffe ein Delay von 78ps hinzukommt. Laut Plan Ahead 
sind die 78ps leider nicht konstant. Wenn ich zum Beispiel als festen 
Wert 14 beim Idealy einstelle, dann gehe ich von einer Verzögerung von 
78ps*14 aus --> 1092ps. Dies stimmt jedoch nicht. Wenn ich den Wert um 2 
erhöhe (also 16) dann erwarte ich eine Verzögerung von 1248ps (1248ps 
-1092ps = 156ps --> 2*78ps)

Jedoch zeigt mir Plan Ahead nicht diese Verzögerung an. Manchmal wird 
von 70ps ausgegangen manchmal von mehr.

Ich werde am Montag mal die genauen Ergebnisse der Pfadanalyse von Play 
Ahead posten. Ich habe es mit der Version 11.4 und 13.3 untersucht. Es 
sind keine Unterschiede feststellbar.

Frohes und vor allem gesundes neues Jahr an alle