Ich habe einen FF. Die Datenleitung und Clock Leitung ist an einem PAD angeschlossen Die Daten kommen also über ein PAD in den FPGA, gehen durch den Input Buffer und anschließend durch eine Delay Line zum D Eingang des Flip Flops. Das Clock Signal geht durch den Input Buffer über eine Delay Line, dann über einen Globalen Clock Buffer zum Clock Eingang des Flip Flops. Die Delay Lines werden mit 200MHz Referenztakt betrieben. Ich verwende einen Virtex 5 Speedgrade -1 XC5vlx30t -1ff665 FPGA. Die Delay Lines sin beide auf FIX eingestellt und der Value beträgt 0. Demnach soll keine Verzögerung durchgeführt werden, es wird also nur die Durchlaufzeit berücksichtigt. Nun habe ich mir die Timings angeschaut die ISE berechnet hat. Dabei ist mir sofort aufgefallen das die Durchlaufzeit des IDELAYS unterschiedlich ist. Bei Datensignal beträgt die Durchkaufzeit 0,527ns und beim Clock Pfad 0,917ns. DIes obwohl die IDEALY Elemente identisch konfiguriert sind. Anschließend habe ich eine Timing Simulation durchgeführt. Dort habe ich bei beiden IDELAY Elementen die gleich Durchlaufzeit gemessen. Ich dachte die Timing Simulation greift auf die Daten zu die ISE zuvor berechnet hat und stellt diese nur visuell da. Dann dürfte es ja keinen Unterschied zwischen den Ergebnissen kommen. Die alles entscheidene Frage ist natürlich was ist denn jetzt richtig?
Angehängte Dateien:
-
Bild_001.png
25 KB
Johann schrieb: > Die alles entscheidene Frage ist natürlich was ist denn jetzt richtig? Es kommt darauf an, worauf man sich bezieht. Wenn man Datenblätter von bestimmt FPGA-Komponenten ansieht, dann findet man welche, die eine negative Setupzeit haben. Die Daten könnten also nach dem Takt angelegt werden und wären /trotzdem noch rechtzeitig da/. Das ist auf den ersten Blick ein recht kurioses Verhalten. Es kommt daher, dass Xilinx die Timings quasi auf den Anschluss der Komponenten berechnet. Interne Laufzeiten (wenn der Clock länger braucht als die Daten) können dann zu einer negativen (und vor allem unterschiedlichen) Laufzeit führen. In den Dimensionsn, in denen du unterwegs bist, kann leicht so ein Fall auftreten und auffallen. Da hilft nur ausgiebigstes Datenblattstudium...
Angehängte Dateien:
-
Bild_000.png
72 KB
SOrry Miller aber es geht darum das die IDELAY Durchlaufzeiten nicht identisch sind einmal 0.527ns und das andere mal 0,917ns siehe Screenshot oben. Bei der Timing Simulation bekomme ich genau bei beiden Elementen 0,527ns raus. Was mich außerdem wundert, das die Laufzeit zwischen den Input Buffer und dem IDEALY mit 0ns angegeben wird. Ich habe das gleich Design noch mal mit Plan Ahead (ISE 13.3) untersucht. Der gibt auch eine IDELAY Durchlaufzeit von 0,527ns für beide IDELAYs an. Jetzt kommts jedoch wieder ganz DICKE. Plan Ahead gibt eine Laufzeit zwischen den Input Buffer und dem IDEALY von 1.28ns an. Dies macht werder der Simualtor noch die Timing Analyse von ISE. (siehe Screenshot) Dadurch habe ich allein 3 verschiedene Pfadelaufzeiten nur für den Datenpfade die sich deutlich voneinander unterscheiden. Die Frage ist jetzt natürlich welche der Laufzeiten ist die RICHTIGE. Vielleicht sollte man auf ISE 13.4 updaten :-)
IDELAY 0 bedeutet bei Xilinx, dass die erforderliche Setup-Zeit für das FF dahinter 0 wird, und nicht, dass es ein Delay von 0 gibt. Daher kann es durchaus sein, dass es unterschiedliche Werte gibt. Klingt allerdings wirklich etwas seltsam, die 1,x ns aus dem PlanAhead sind sicherlich zu hoch. Kannst ja die 13.4 mal parallel installieren und das Design anschauen.
Viel schlimmer finde ich das ISE 0.917ns für das IDELAY als Durchlaufzeit angibt, dadurch stimmen ja die Constraint-Berechnungen nicht mehr. Ich werde 13.4 auf meinen PC zu Hause mal installieren. Auf Arbeit will ich nicht noch ein Version :-)
Schaut Euch doch mal die ISE Berechnung (1. Screenshot ganz genau an) Die Leitungslaufzeit vom IDELAY bis zum BUFG 1.162ns während die Laufzeit bei Plan Ahead 0ns beträgt. das kann doch auch nicht stimmen. Der BUFG liegt ja auch einiges von IBUF und IDELAY entfernt. Als nächstes kommt die Verzögerung vom BUFG Buffer bis zum FF Clock Eingang. Hier gibt ISE 0.1ns an (dies kann nie stimmen). Bei Plan Ahead sind es 1.96ns (siehe Leitung W_ADC_2_DRY) Ich könnte mit dem Kopf gegen die Türrahmen klopfen. Warum ist das nur so eine Scheiße
Ist der Takt-Pin ein General-Purpose IO oder ein dedizierter Takt-Pin? Karlo
Auffällig: Der Takt wird als "Minimum", die Daten als "Maximum" angegeben.
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.