Hallo Ich verwende einen Virtex 5 FPGA und einen externen AD-Wandler. Die Digitalisierung funktioniert auch schon ganz gut nur manchmal kommen fehlerhafte Werte zustande. Ich vermute mal dies liegt am Timing. Bis jetzt habe ich leider noch nicht so viele Erfahrung mit den Constraints. Ich habe einen Takt von max. 200MHz. Die Daten werden per DDR-Verfahren an den FPGA übertragen. Laut Datenblatt des AD-Wandlers kommen die Daten typischer Weise immer genau bei einer ansteigenden und fallenden Flanke. Im Worst Case können aber die Daten 0.5ns vor oder hinter der CLK-Flanke noch nicht stabil sein. Daher sollte man diesen Bereich meiden. Ich habe es wie folgt programmiert. Die CLK geht auf einen CLK-BUFGDS und von dort auf einen internen BUFG. Die Daten werden auf einen IBUDS gelget. Danach werden diese direkt mit einem IDDR verbunden. Der IDDR-Datenausgang ist dann direkt mit einem BLOCK-RAM verbunden. Demnach habe ich meine Constraints wie folgt erzeugt: Alle Datenleitungen zu einer Gruppe zusammenfassen: INST "IDDR_ADC_1_DATA_0" TNM = GROUP_IDDR_ADC_1_DATA; INST "IDDR_ADC_1_DATA_1" TNM = GROUP_IDDR_ADC_1_DATA; ... Die Clockfrequenz festlegen NET "ADC_1_DRY_P" TNM_NET = ADC_1_DRY_P; TIMESPEC TS_ADC_1_DRY_P = PERIOD "ADC_1_DRY_P" 5 ns HIGH 50%; Die Daten sollen 2ns vor der ansteigenden Flanke für 1,5ns stabil anliegen. 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 Und genau bei diesem OFFSET-IN-Constarint habe ich so meine Probleme. In Anhang habe ich 2 Screenshits hinzugefügt. Hier kann man sehen das vor und hinter jeder Flanke die Daten noch nicht stabil anliegen. Genau dies will ich verwenden. Laut diesem Bild muss der OFFSET-IN-Parameter siehe 2. Screenshot 0.5ns groß sein. Da bei 200MHz die High Phase 2.5ns entspricht muss Data Valid Parameter 1.5ns sein. (Sorry fehler auf dem Screenshot hier steht 2) 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. Da die Datenleitungen ja direkt mit IDDR verbunden werde habe ich kein IDELAY für die Datenleitungen vorgesehen. Ich verwende nur ein IDELAY für die CLOCK-Leitung. Hierzu habe ich mit einem DCM aus 50MHz 200MHz erzeugt. Diese 200MHz habe ich mit dem IDELAYCNTRL verbunden. Den IDELAY habe ich auf FIX eingestellt. Was mich nur wundert ist das pro Stuffe ein Delay von 78ps erzeugt wird. Veränder ich jedoch den Wert und mache erneut eine Timing Analyse sehe aich das dies nicht konstant ist. Ich verwende ISE 11.4 und einen Virtex 5 mit dem langsamsten Speedgrade.
Angehängte Dateien:
-
Offset_IN_DDR_Timing.png
32 KB -
Offset_IN_DDR_Timing_2.png
38 KB
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
Hast du dir das WP 237 von Xilinx mal reingezogen? http://www.xilinx.com/support/documentation/white_papers/wp237.pdf
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.
Ja, der Wizzard ist echt bissl komisch. Ich hab das immer so verstanden, dass das OFFSET IN die Zeit vor der Flanke angibt, in der die Daten stabil sind. Also Periodendauer - maximale Setup-Zeit des externen Bausteins. Und das VALID gibt die Zeit an, wie lange die Daten gültig sind, ungeachtet der Flanke. Also Periodendauer - Differenz aus maximaler und minimaler Setup-Zeit. Wenn der ADC also 1 bis 2 ns für das Setup der Daten nach der Flanke braucht, wäre das OFFSET IN 8ns und das VALID 9 ns. Die Daten könnten sich ja 1ns nach der Flanke schon ändern. Bei DDR bin ich mir aber auch immer etwas unsicher. Im Whitepaper steht, man solle das manuell ausrechnen für den FALLING Zweig, der Wizzard erzeugt aber auch DDR Constraints mit FALLING drin.
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.
Stimmen denn die Daten vom ADC nicht oder sagt das nur die statische Timing-Analyse? Du könntest auch alle Daten mit dem IDELAY einstellbar verzögern und durch inkrementieren - Daten lesen - inkrementieren die Breite des Daten-Auges ermitteln. Oder du machst in diesem Fall mal ausnahmsweise eine Timing-Simulation, die sagt dir an, wie weit die Timings verletzt sind.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.