Hallo! Kann mir bitte jemand erklären, wozu genau die IFD Delay Einstellung (Spartan 3A) gut sein soll? Werde aus dem UG nicht wirklich schlau, in welchen Fällen man das Delay nutzt. Danke! Grüße, Anguel
Das IFD Delay wirkt, wenn du ein IFF am Eingang hast, und ist da, um die Verzögerung zwischen Datenleitungen und der Taktleitung im FPGA auszugleichen. Bei einem Source-Synchronen Design mit Nutzung des DCM kann man das IFD_DELAY_VALUE auf Null setzen, weil der DCM so gemacht ist, dass er diese internen Verzögerungen schon ausgleicht. Ansonsten setzt ISE das meistens automatisch. Problematisch wird das bei knappen Constraints, da kann es schon mal sein, dass das zuviel Delay ist. Daher am besten DCM verwenden und IFD Delay auf 0 setzen.
Christian R. schrieb: > Das IFD Delay wirkt, wenn du ein IFF am Eingang hast, und ist da, um die > Verzögerung zwischen Datenleitungen und der Taktleitung im FPGA > auszugleichen. Danke für die Erklärung Christian! Ich versuche einen externen A/D Wandler anzusteuern. Ich habe ein IFF am seriellen Dateneingang zum FPGA. Ich erzeuge außerdem in meinem FPGA alle SPI Signale für den A/D-Wandler (alle in IOB FFs), auch SCLK, der meinem FPGA Clock von 56 MHz entspricht. Nun ist das jedoch so, dass die über SDO vom ADC zum FPGA zurückkommenden seriellen Daten nur noch 3 ns nach der SCLK Flanke bei der ich sample mit Sicherheit valide sind. Jetzt sehe ich aber, dass mir die Tools meinem Eingangs-IOB ein IFD Delay von 5 zugewiesen haben. Deshalb frage ich mich, ob ich das Delay auf 0 ändern soll oder nicht? DCM nutze ich nicht.
Also eine Hold-Time von 3ns? Das reicht doch dicke. Die internen FF haben meist kleiner 1ns erforderliche Hold-Time. Kannst das Delay auch auf 0 setzen, denn bei der Anwendung muss ja zwischen dem Takt und den Daten nix ausgeglichen werden, denn den Takt stellst du ja selbst zur Verfügung. Aber wenn du das Delay auf 0 setzt, wird die Hold-Time ja eher kleiner. Also wenn alles funktioniert, würd ich das erst mal so lassen. Dummerweise lassen sich da keine OFFSET IN Constraints angeben, die brauchen immer einen externen CLK.
Christian R. schrieb: > Also eine Hold-Time von 3ns? Das reicht doch dicke. Die internen FF > haben meist kleiner 1ns erforderliche Hold-Time. Kannst das Delay auch > auf 0 setzen, denn bei der Anwendung muss ja zwischen dem Takt und den > Daten nix ausgeglichen werden, denn den Takt stellst du ja selbst zur > Verfügung. Aber wenn du das Delay auf 0 setzt, wird die Hold-Time ja > eher kleiner. Also wenn alles funktioniert, würd ich das erst mal so > lassen. Dummerweise lassen sich da keine OFFSET IN Constraints angeben, > die brauchen immer einen externen CLK. Ich hatte nur befürchtet, dass dieses IFD Delay von 5 irgendwie dazu führen könnte, dass meine Daten dann vom Sampling-Zeitpunkt aus gesehen etwas mehr als 4 ns später am Eingangs-FF ankommen (da IFD von 5 laut http://forums.xilinx.com/t5/Spartan-Family-FPGAs/Demystifying-the-IBUF-DLY-ADJ/m-p/26579#M1999 zu einer Verzögerung von über 4 ns führt). Und somit dachte ich, dass ich dann die 3 ns Hold Zeit des Wandlers um ca. 1 ns verpasse. Oder mache ich einen Denkfehler?
Du hast ja nur ein Problem, wenn sich Daten und Clock gleichzeitig ändern (bzw. die Daten zu kurz vor dem Takt). Wenn Du ein Delay brauchst, dann am ehesten auf der Taktleitung, damit die Daten schon stabil sind, wenn der Takt kommt. Duke
Duke Scarring schrieb: > Du hast ja nur ein Problem, wenn sich Daten und Clock gleichzeitig > ändern (bzw. die Daten zu kurz vor dem Takt). Wenn Du ein Delay > brauchst, dann am ehesten auf der Taktleitung, damit die Daten schon > stabil sind, wenn der Takt kommt. Also sollte ich das IFD Delay doch manuell auf 0 setzen? Ich versuche meine Gedanken nochmal zu präzisieren: Ich benutze ja den gleichen FPGA Clock einmal für die Erzeugung des SCLK zum ADC und dann wieder zum Samplen der ADC Daten im FPGA. Das SCLK Signal zum ADC erzeuge ich über ein ODDR2 FF. Über SCLK bestimmt der FPGA Clock indirekt, wann mir der ADC die Daten zur Verfügung stellt. Diese ADC Daten muss ich dann innerhalb von 3 ns nach der SCLK Flanke im FPGA gesamplet haben, da sie danach nicht mehr valide sind. Dieses Samplen im Eingangs-IOB-FF geschieht wieder mit dem selben FPGA Clock. Nur dass mir die Tools am Dateneingang des IOB FFs per Default dieses Delay von 5 vorgeben. Irgendwie bin ich mir jetzt nicht sicher, ob mir dieses Delay eher hilft, die 3 ns Hold-Zeit des ADC einzuhalten oder eher dazu führt, dass ich die validen Daten verpasse.
In dem Fall hilft dir ja das zusätzliche Delay, weil die Daten dann länger nach der (internen) Flanke des Taktes anliegen. Solange es keine Probleme gibt, lass sie lieber drin. Du kannst ja auch mal eine post Route Simulation machen, dann sagt dir der Simulator, ob es eine Verletzung der Hold-Zeit gibt (musst du aber einstellen, default steht der Simulator auf Setup-Zeit).
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.