mikrocontroller.net

Forum: FPGA, VHDL & Co. Timing constraints für LVDS


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

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich habe einige Probleme in meinem Spartan-3A DSP (Speedgrade 4) Design.

Ich verwende serielle LVDS Signale, also Takt und Data.

Nun habe ich in meinem Design das Problem, dass scheinbar die 
Timingcontraints nicht richtig von mir gesetzt wurden und deswegen nicht 
eingehalten werden können.

Der Takt hat 160MHz (6.25 ns) und die Daten sind Double-Data-rate. Also 
effektive 320MHz (3.125 ns)...

Nun muss ich ja bedenken, dass die Daten spätestens (!) nach 3.125 ns am 
ersten Register/FF anliegen, damit auch auf die fallende Flanke des 
Taktes genau abgetastet werden kann.

Ich habe also meine COnstraints folgendermaßen gesetzt:
#Clock -
NET "TCLK_N" TNM_NET = TCLK_N;
TIMESPEC TS_TCLK_N = PERIOD "TCLK_N" 160 MHz HIGH 50%;
#Clock +
NET "TCLK_P" TNM_NET = TCLK_P;
TIMESPEC TS_TCLK_P = PERIOD "TCLK_P" 160 MHz HIGH 50%;
#Daten -
NET "DOUT0A_N" OFFSET = IN 3.125 ns VALID 3.125 ns BEFORE "TCLK_N" RISING; 
NET "DOUT0A_N" OFFSET = IN 3.125 ns VALID 3.125 ns BEFORE "TCLK_N" FALLING;
#Daten +
NET "DOUT0A_P" OFFSET = IN 3.125 ns VALID 3.125 ns BEFORE "TCLK_P" RISING; 
NET "DOUT0A_P" OFFSET = IN 3.125 ns VALID 3.125 ns BEFORE "TCLK_P" FALLING;

Nun gibt ISE mir beim Implementieren an, dass die Daten aber erst nach 
6.325 ns anliegen und somit diese Bedingung nicht erfüllt werden kann. 
(siehe Bild im Anhang). Der Clock hingegen ist schon nach spätestens 
1.649 ns am ersten Register/FF. Also gibt es dort ein Delay, was mir 
Probleme bereitet.

Habe ich die Contraints für mein Problem richtig gesetzt?
Muss ich je eine Bedingung für + und - Signal erstellen?
Gibt es ein Contraint das mir sicherstellt, dass meinetwegen die Daten 
ein minimales Delay haben und damit dann einen Takt später abgetastet 
werden können? (das ich die Daten bewußt um X ns verzögere, dass es dann 
beim nächsten Takt passt).

Ich wäre für Hinweise sehr sehr dankbar!

MfG Andi

PS: Folgende Fehlermeldungen bekomme ich gemeldet, die was mit dem 
Timing zu tun haben könnten:
WARNING:Timing:3225 - Timing constraint COMP "DOUT0A_N" OFFSET = IN 3.125 ns
   VALID 3.125 ns BEFORE COMP "TCLK_N" "FALLING" ignored during timing analysis
WARNING:Timing:3175 - TCLK_P does not clock data from DOUT0A_P
WARNING:Timing:3225 - Timing constraint COMP "DOUT0A_P" OFFSET = IN 3.125 ns
   VALID 3.125 ns BEFORE COMP "TCLK_P" "FALLING" ignored during timing analysis
WARNING:Timing:3175 - TCLK_N does not clock data from DOUT0A_N
WARNING:Timing:3225 - Timing constraint COMP "DOUT0A_N" OFFSET = IN 3.125 ns VALID 3.125 ns BEFORE COMP "TCLK_N"       
   "FALLING"; ignored during timing analysis
WARNING:Timing:3175 - TCLK_P does not clock data from DOUT0A_P
WARNING:Timing:3225 - Timing constraint COMP "DOUT0A_P" OFFSET = IN 3.125 ns VALID 3.125 ns BEFORE COMP "TCLK_P"       
   "FALLING"; ignored during timing analysis

Autor: Andreas B. (loopy83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ich habe es nochmal mit den globalen Constraints versucht:
OFFSET = IN 1.5625 ns VALID 3.125 ns BEFORE "TCLK_P" RISING;
OFFSET = IN 1.5625 ns VALID 3.125 ns BEFORE "TCLK_P" FALLING;
OFFSET = IN 1.5625 ns VALID 3.125 ns BEFORE "TCLK_N" RISING;
OFFSET = IN 1.5625 ns VALID 3.125 ns BEFORE "TCLK_N" FALLING;

3.125 ns gültige Daten und die sollen 1.5625 na vor der jeweiligen 
Taktflanke anliegen.

Kann mir jemand dazu noch einen Hinweis geben?
Wieso werden beim Implementieren die FALLING Constraints rausgeschmissen 
bzw. ignoriert?

MfG Andi

Autor: Thomas Reinemann (Firma: abaxor engineering) (abaxor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas B. schrieb:
> Gibt es ein Contraint das mir sicherstellt, dass meinetwegen die Daten
> ein minimales Delay haben und damit dann einen Takt später abgetastet
> werden können? (das ich die Daten bewußt um X ns verzögere, dass es dann
> beim nächsten Takt passt).

Hallo,

160 MHz sind die Grenze bei einem Spartan 3. Das macht schon keinen Spaß 
mehr. Du kannst die Daten mit einem IBUF_DLY_ADJ oder IBUFDS_DLY_ADJ 
verzögern um sie mit dem nächsten Takt zu verarbeiten. Üblicherweise 
arbeitet man mit Trainigsdaten, um das Delay auszurichten.

Tom

Autor: Andreas B. (loopy83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

diese Möglichkeit habe ich mir auch schon angeschaut, leider fehlt mir 
noch die Erfahrung, um den Timingreport 100%ig korrekt zu 
interpretieren.
Ich kann auch in der Quelle der LVDS Daten ein Delay zwischen Takt und 
Daten erzeugen, wobei mir die Möglichkeit des IBUFDS_DLY_ADJ am 
sinnvollsten erscheint, da das Delay dann im FPGA ausgeglichen wird, wo 
es auch erzeugt wird.

Du hattest Trainingsdaten angesprochen. Damit habe ich noch nie 
gearbeitet, kannst du vielleicht noch ein paar Worte dazu sagen, oder 
vielleicht eine passende App-note verlinken, denn diese Methode ist mir 
noch gänzlich unbekannt.

Vielen Dank für die schnelle Hilfe!

MfG Andi

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht ist folgendes hilfreich?

http://www.xilinx.com/support/documentation/white_...

Wenn Du DDR Daten auf DOUT (übrigens, warum DOUT wenn es sich um einen 
Eingang handelt? ) hast, dann wird zu den Zeiten 0 ns, 3,125 ns 6,25 ns 
abgetastet.
Folglich müssen sich die Daten dazwischen ändern; angenommen genau in 
der Mitte.
Sie ändern sich also an 1,56 ns, 4.68 ns usw.
In diesem Fall hast du 1,56 ns Setup-Zeit, diese Zeit wäre meiner 
Meinung nach im OFFSET In Constraint einzugeben, oder?
Die genauen Zeiten hängen aber von deiner Datenquelle ab.

Autor: Andreas B. (loopy83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus Falser schrieb:
> Wenn Du DDR Daten auf DOUT (übrigens, warum DOUT wenn es sich um einen
> Eingang handelt? ) hast, dann wird zu den Zeiten 0 ns, 3,125 ns 6,25 ns
> abgetastet.
> Folglich müssen sich die Daten dazwischen ändern; angenommen genau in
> der Mitte.
> Sie ändern sich also an 1,56 ns, 4.68 ns usw.
> In diesem Fall hast du 1,56 ns Setup-Zeit, diese Zeit wäre meiner
> Meinung nach im OFFSET In Constraint einzugeben, oder?
> Die genauen Zeiten hängen aber von deiner Datenquelle ab.

Ja genau. Ich habe das inzwischen auch so durchschaut, dass ich die 
constraints in folgende abändern muss:
NET "DOUT0A_N" OFFSET = IN 1.5625 ns VALID 3.125 ns BEFORE "TCLK_N" RISING;

DOUT heißen sie nur deswegen, weil es so in meinem ganzen Design, also 
auch außerhalb des FPGA, heißt. Einfach nur deswegen, damit ich nicht 
durcheinander komme und meine Bezeichnungen auch mit meinen schematics 
übereinstimmen :)

Vielen Dank!

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du kannst das ja auch mit dem PlanAhead Editor machen, der zeigt auch 
gleich an, wo genau die Zeiten dann am Signal sind, die du eingibst:

User Contraints -> Create Timing Constraints

Autor: Thomas Reinemann (Firma: abaxor engineering) (abaxor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas B. schrieb:
> Du hattest Trainingsdaten angesprochen. Damit habe ich noch nie
> gearbeitet, kannst du vielleicht noch ein paar Worte dazu sagen, oder
> vielleicht eine passende App-note verlinken, denn diese Methode ist mir
> noch gänzlich unbekannt.

Hallo Andreas,


trainieren heißt nichts anderes, als dass dein Sender ein dem Empfänger 
bekanntes Muster sendet und der sein Delay Leitung für Leitung so 
ausrichtet, bis die empfangenen Daten mit den erwarteten Daten überein 
stimmen. Dabei kann das Delay in den Leitungen unterschiedlich sein. Je 
nach Temperaturschwankungen kann es notwendig sein, das Training 
regelmäßig durch zu führen.

Wenn das einstellbare Delay im Empfänger nicht reicht, musst du 
zusätzliche ein konstantes im Sender einfügen.

Tom

Autor: Andreas B. (loopy83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ah ok, vielen Dank für die Info. Durch die 3bit Delay Werte beim 
IBUFDS_DLY_ADJ kann man das ganze ja auch automatisieren. Sehr 
interessante Möglichkeit.

Ich habe nur noch eine Frage zum manuellen Ermitteln des Delays.
Im Datenblatt und in weiteren App-notes habe ich gelesen, dass die 3bit 
Delaywerte mit DLEAY_OFFSET ON bzw. OFF zwischen 1 und 16 eingestellt 
werden können. Dieser Delay-value - was entspricht der? Ist das eine 
Anzahl von Takten, oder was kann ich mir darunter vorstellen? Ich hatte 
gehofft, dass ich mir daraus ns errechnen kann und damit einen 
theoretischen Wert ermitteln kann, bei dem es Sinn macht, das 
tatsächliche Delay auszutesten.

Vielen Dank, Andi :)

Autor: Thomas Reinemann (Firma: abaxor engineering) (abaxor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas B. schrieb:
> Dieser Delay-value - was entspricht der?

Siehe

http://www.xilinx.com/cgi-bin/SW_Docs_Redirect/sw_...

Seite 326 Dynamic Delay in the Extended Spartan-3A Family


Tom

Autor: Andreas B. (loopy83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

genau diesen Absatz habe ich mir mehrfach durchgelesen, aber leider 
konnte ich daraus keine verlässliche Information entnehmen, was diese 
Werte von 1-16 bedeuten. Grafik 10-12 wird sicher entscheidend sein, 
aber auch hier finde ich keine Angabe, auf was sich die Werte (z.B. 1/9, 
2/10, 3/11 usw) beziehen.

Das einzige, was ich mir bislang denken könnte ist, dass es Bruchteile 
von Taktperioden sind.
Also mit DELAY_OFFSET=OFF und IBUF_DELAY_VALUE=1, habe ich bei 160MHz 
eine Verzögerung von 0.694 ns.
Mit DELAY_OFFSET=OFF und IBUF_DELAY_VALUE=8, habe ich bei 160MHz eine 
Verzögerung von 3.125 ns.

Sehe ich das in etwa richtig? Oder habe ich es komplett falsch 
verstanden.

Vielen Dank, Andi

Autor: Thomas Reinemann (Firma: abaxor engineering) (abaxor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Andi,

also vom Virtex4 weiß ich, dass es sich bei den Inkrementen um feste 
Werte handelt, die nicht in Relation zum Takt stehen. Ich kann mir auch 
nicht vorstellen wie man das machen will. Denn woher soll die ISE den 
tatsächlichen Takt des FPGAs kennen.

Sieh mal im DC und Timing Datenblatt zum 3A-DSP nach oder du probierst 
es in der Simulation mal aus.


Das solltest du dir auch mal durch lesen.
http://www.xilinx.com/support/answers/25031.htm

Tom

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na beim Virtex benötigt man für das IDELAY immer ein IDELAY_CNTL 
Element. Und daran muss man zwingend einen 200MHz Referenz-Takt anlegen. 
Also weiß die ISE sehr wohl, wie die Delays wirklich sind.

Beim Spartan 3 ist das Delay auch fest, im Datenblatt steht, wieviele ps 
das sind pro Stufe. Ich glaub das waren beim Spartan 3e 25...45ps. Für 
viele Designs wird das anhand der Beziehung zwischen dem CLK und den 
Eingangsregistern das Delay automatisch von ISE gesetzt. Zumindest hab 
ich hier einige Designs mit IDDR Registern für einen Bus, da setzt ISE 
das Delay. Kann man sich im IOB Report angucken.

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas B. schrieb:
> aber leider
> konnte ich daraus keine verlässliche Information entnehmen, was diese
> Werte von 1-16 bedeuten.

Die Werte finden sich im Datenblatt (nicht in der User Guide), unter "DC 
and Switching Characteristics".
Dort finden sich die typischen Werte in ns, abhängig vom Modell und 
Speed Grade.

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

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

vielen, vielen Dank!

Ich denke ich habe die passende Tabelle gefunden (siehe Bild).
Dort sind Zeiten von 2,47ns angegeben. Bei nicht programmiertem Delay 
beträgt die Zeit noch 2,04ns. Kann ich also davon ausgehen, dass ich bei 
DELAY_VALUE = 1 eine zusätzliche Verzögerung von 0,43ns programmiert 
habe?

Die Werte beziehen sich alle auf den I/O-Standard LVCMOS25. Ich habe 
gerade mit Erschrecken festgestellt, dass ich auch für meine LVDS 
Eingänge diesen Default-Wert angenommen habe. Auf der Suche nach 
differentiellen Alternativen bin ich auf unterschiedliche Standards 
gestoßen. Darunter DIFF_HSTL und DIFF_SSTL in den verschiedensten 
Vairanten. Leider habe ich rein gar keine Ahnung, welche Einstellung nun 
die richtige ist, denn je nachdem wird ja dann für die Wandlung von 
LVCMOS25 in das entsprechende differentielle Format auch nochmal Zeit 
(um die 1ns) benötigt. Auch habe ich keine Datenblätter gefunden, wo die 
unterschiedlichen DIFF Standards erklärt sind. Mein LVDS Input Signal 
gestaltet sich so wie im Bild.
Ich habe bisher mit dem Default Wert gearbeitet und konnte via Chipscope 
auch Takte und Daten empfangen (wenn auch ungenau). Kann ich also diesen 
Wert beibehalten, oder sollte ich auf den passenden differentiellen 
Modus der Eingänge setzen?

MfG Andi

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas B. schrieb:
> denn je nachdem wird ja dann für die Wandlung von
> LVCMOS25 in das entsprechende differentielle Format auch nochmal Zeit
> (um die 1ns) benötigt

Warum sollte es?
Ich denke, die Zeiten für LVCMOS und LVDS sind ungefähr gleich.
Außerdem bringt es nichts, andere differentiells Standards (oder nicht 
differentielle) zu betrachten. Wenn deine Datenquelle LVDS liefert, dann 
mußt Du LVDS empfangen, punkt.

Die Zeiten um 2-2,5 ns müssen dich auch nicht erschrecken. Auch dein 
Taktsignal erfährt eine Verzögerung, und ausschlaggebend ist die 
Differenz mit der beide Signale beim IFF ankommen.

Vielleicht wäre es an der Zeit, dass Du kurz beschreibst, was Du tun 
möchtest, woher die Daten kommen, wie dein Aufbau aussieht und wo die 
Probleme liegen.

Autor: Andreas B. (loopy83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

die seriellen LVDS Daten kommen mit 160MHz von einem ADC. Dieser stellt 
32bit (2x16) Daten auf 4 Kanälen (je 8bit) bereit.

Kanal A0 - bit 15 bis 8
Kanal A1 - bit 7 bis 0
Kanal B0 - bit 15 bis 8
Kanal B1 - bit 7 bis 0

Es werden also zwei words mit je 4 Takten (steigende und fallende 
Flanke) übertragen.

Es werden also effektiv mit 40MHz zwei 16bit Wörter übertragen.

Diese Daten müssen von mir paralelisiert werden.
Das geschieht pro Kanal mit zwei Schieberegistern. Die Daten werden in 
steigende und fallende Flanke (je 4bit) aufgeteilt und dann wieder in 
die richtige Reihenfolge sortiert. Zusammen mit dem zweiten 
dazugehörigen Kanal ergibt sich dann durch den & Operator das komplette 
16bit Wort.

Die beiden 16 bit Wörter (eins von A und eins von B) werden dann in ein 
Fifo sortiert und von einem PowerPC ausgelesen.

Das eigentlich Problem ist nun, dass ich die 160MHz LVDS Daten sicher in 
den FPGA einlesen muss. Dafür habe ich die Timingconstraints verwendet, 
die ISE aber nicht einhalten kann. Das ist das eigentlich Problem

Ich hoffe es ist nun etwas verständlicher, was ich tun möchte?! :)

Ich wäre für weitere Hinweise, wie man mit einem Spartan 3A DSP die 
160MHz händeln kann, sehr sehr dankbar.

MfG Andi

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe ein sehr ähnliches Problem. Jedoch benutze ich momentan noch 
einen Virtex 5. Hier gibt es IDDR Module. Du hast einen Takt vom ADC. 
Dieser ist 160MHz. Mit der ansteigenden und abfallenden Flanke dieses 
Takts sendet Dein ADC die Daten an den FPGA. Wenn ich beim Virtex 5 ein 
IDDR-Modul benutze, dann bekommt der Modul den 160MHz Takt deines ADCs. 
Das IDDR Modul besitzt 2 Ausgänge. Der eine Ausgang steht für die 
ansteigende Flanke und der andere für die abfallende Flanke.

Ich weiß nicht ob wir aneinander vorbeireden. Ist der CLK den Du vom ADC 
bekommst 80MHz oder 160MHz oder ist die Datenrate einfach nur 160MHz

Fals die Datenrate 160MHz ist dann halbiert man mit den IDDR den Clock 
von 160MHz auf 80MHz, da das IDDR bei jeder ansteigenden Clock Flanke 
die beiden Bits des DDR-Signals ausgibt.

Autor: Andreas B. (loopy83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

der Takt des ADC hat wirklich 160MHz, also effektive 320MHz Datenrate :)

Deswegen ja auch ein Offset IN von 3.125ns und nicht 6.25ns.

Das Problem ist ja, dass die Daten nicht einal zuverlässig am IDDR2 
ankommen, auch wenn dahinter dann der Takt "nur" noch effektive 160MHz 
beträgt. Aber das Offset IN zum IDDR2 macht ja schon Probleme.

Ich habe so langsam jede Hoffnung verloren, dass ich die 3.125ns Offset 
IN realisieren kann. Mit einem Spartan3aDPS ist das wohl ein No-Go.
Kann ich das LVDS Signal vielleicht irgendwie extern in SDR wandeln, 
dass ich dann nur noch 160MHz Datenrate habe?

Von einem Sartan3  auf einen Virtex5 ist natürlich gleich wieder eine 
kostenintensive Sache.

MfG Andi

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du könntest auch den LVDS-Takt zuerst mal über eine DCM führen und dann 
im Training variabel in der Phase verschieben (oder für den ersten Test 
eine passende konstante Verschiebung finden). So habe ich das Timing 
eines DDR-Interface mit 132MHz sehr stabil bekommen. Allerdings ist das 
Training bei einem RAM natürlich etwas einfacher, weil man weiss, was 
man reingeschrieben hat...

Autor: Andreas B. (loopy83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo und Danke,

Der LVDS Takt geht auch bei mir zuerst über einen DCM, dieser erzeugt ja 
den 0° und 180° Takt für den IDDR2 Baustein.

Ich habe auch die Freiheiten, den Takt und die Daten im ADC zu 
verschieben. Nur gehe ich dann davon aus, dass das Delay immer absolut 
konstant ist. Kann ich das denn einfach annehmen?

MfG Andi

Autor: Frager (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieso braucht man denn da 2 Takte? Arbeitet das "Modul" nicht auf 
pos/neg?

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frager schrieb:
> Wieso braucht man denn da 2 Takte? Arbeitet das "Modul" nicht auf
> pos/neg?

Beim Spartan 3 IDDR2 Block braucht man die 2 Takte. Kann man entweder 
aus dem DCM nehmen (besser) oder mit dem Inverter auf dem IOB bereit 
stellen (schlechter).

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich weiß das so ein Virtex 5 deutlich teurer ist. Ich glaube die fangen 
so ab 200€ an. Jedoch denke ich auch das die GEschwindigkeit für einen 
Spartan 3 zu hoch ist. Vielleicht würde ja ein Spartan 6 reichen jedoch 
ist es sehr schwer einen zu bekommen.

Aber man kann doch mal den Spartan 3 durch einen Spartan 6 im Design 
ersetzten und dann mal schauen ob es geht. Wenn ISE dann keine Probleme 
anzeigt, dann hat man zu mindestens in einigen Monaten eine Alternative, 
denn 200€ pro Virtex 5 ist schon ein Unterschied.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach ie einfachste Möglichkeit ist natürlich dies im PCB der Paltine zu 
berücksichtigen. Du must dann einfach nur die CLK-Leitung vom ADC zum 
FPGA etwas länger machen als die Datenleitungen. Dies kann man 
berechnen. Dadurch benötigst Du diese Timings nicht.

Eine weitere Möglichkeit ist auch ein externes PLL oder eine Delay Line 
zu verwenden.

http://de.farnell.com/maxim-integrated-products/ds...

Bei der Delay Line verzögert man einfach den Clock um 0,25ns oder halt 
die 1,35ns.

Man nimmt einfach nur diese IC, dort kann man eine Schalterleiste 
einbringen oder dies sogar per FPGA verändern. Das IC hat 8 Pins so das 
man 256 Delays erzeugen kann.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry für die kure Ausführung jedoch mein Chef sitzt mir im Nacken ^^

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas B. schrieb:
> Das Problem ist ja, dass die Daten nicht einal zuverlässig am IDDR2
> ankommen, auch wenn dahinter dann der Takt "nur" noch effektive 160MHz
> beträgt. Aber das Offset IN zum IDDR2 macht ja schon Probleme.

Was macht denn nun genau das Problem?
- Dass ISE das Constraint nicht akzeptiert?
- Hast Du einen schon einen Testaufbau und Du bekommst Bitfehler?
Wie schaut denn der Aufbau aus? Du hältst Dich mit Informationen dazu 
sehr zurück.
160 MHz sind kein Pappenstiel, das ist schon Rundfunkfrequenz!

Auch wenn das Constraint von ISE falsch verstanden und nicht eingehalten 
wird, sollte es doch irgendwie laufen.
Wichtig ist, dass die Eingangsdaten im IFF abgetaktet werden. Das ergibt 
bestimmte Durchlaufzeiten und Setup/Hold-Zeiten. Diese kommen aber von 
der Hardware, das Constraint KONTROLLIERT nur die Zeiten, aber durch das 
Constraint wird die Hardware nicht schneller.
Sobald garantiert ist, dass die IFFs (für steigende und fallende Flanke) 
verwendet werden, hast Du die Möglichkeit, dein Zeitfenster für die 
Abtaktung zu verschieben.
Dazu kannst Du mit der DCM entweder den Takt oder mit den IDELAYs die 
Eingangsdaten verschieben.
Wenn Du mit diesen Verzögerungen ein bischen herumspielst, solltest DU 
zumindest sehen, ob es Verbesserungen oder Verschlechterungen gibt.

Externe Verzögerungen sollte man nicht benötigen, man hat im Inneren des 
FPGAs Möglichkeiten genug.

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Nur gehe ich dann davon aus, dass das Delay immer absolut
> konstant ist. Kann ich das denn einfach annehmen?

Absolut konstant sicher nicht, deshalb ist die PCB-Delay-Lösung auch 
untauglich. Mit der kann/sollte man nur einen potentiellen Skew der 
Datenleitungen untereinander ausgleichen, sonst muss man jedes Bit 
trainieren. Dann ist es nach einer Trainingssequenz für dieses eine 
Gerät und FPGA-Design aber schon soweit gleich, dass die 
Temperatur/Spannung keine Rolle mehr spielt.

Bei meinem DDR-Ding wird das Training vom Microblaze im "Bios" gemacht, 
daher kann man da die Werte gut analysieren, insb. auch die Schwankungen 
über mehrere Geräte. Bei 133MHz ist das Datenauge ungefähr 70 DCM-Steps 
breit (so grob 3ns), die Mitte schwankt über die unzähligen Geräte 
hinweg nur um so +-16, was ich erstaunlich wenig finde. Bei einem Gerät 
mit Temperatur/Spannungsänderung ist es maximal auch nur so +-16. Was 
ich noch nicht probiert habe (weil in dem Anwendungsfall unrealistisch), 
wäre eine grosse Temperaturdifferenz zwischen Speicher und FPGA, dann 
wäre das Tracking der Verzögerungszeiten sicher schlechter. Aber so oder 
so ist das Fenster recht gross.

Jetzt sind 133MHz (2*3.75ns) und deine 160Mhz (2*3.12ns) ja nicht so 
weit voneinander weg, das müsste da schon noch gehen. Schwieriger wird 
es IMO eher, die Daten nach den IDDR-FFs schnell genug loszuwerden, da 
darf nicht viel Logik dazwischensein...

BTW: Kontrolliere auch, dass die DDR-FFs wirklich in den Pins liegen und 
nicht aus irgendwelchen Gründen in die Slices gemapped werden. Das 
ruiniert jedes Timing... Hat mir auch mal den Tag versaut ;)

Autor: Andreas B. (loopy83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen und vielen Dank für die ausführliche Hilfe!

Zum Aufbau:
Wie schon gesagt, habe ich einen ADC mit LVDS Ausgängen. Dieser sitzt 
auf einer Platine, die via Steckverbinder mit der FPGA Platine verbunden 
ist. Beides sind eigene Designs und ich habe einen Längenausgleich 
gemacht. Leider war es nicht möglich, erst das FPGA Design zu machen und 
dann die PCBs herzustellen, da noch ein anderer Student an den Platinen 
arbeiten soll und sich um die Software kümmert.
Die Srecke zwischen ADC und FPGA beträgt ca. 7cm. Aber durch den 
Längenausgleich sollte das eigentlich keine Rolle spielen.

Ich habe mein Design mit Chipscope schon getestet und die Daten kommen 
an sich sehr sicher an. Ich kann also im CS sehen, welche Daten vom ADC 
kommen. Dort habe ich Testpattern eingestellt, damit ich auch weiß, was 
ankommen soll. Nur werden leider meine Offset IN Constraints nicht 
eingehalten und der Prof meinte, dass es schon besser wäre, wenn der 
Aufbau auch noch unter anderen "Umweltbedingungen". Ich würde mich also 
schon sicherer fühlen, wenn die Constraints korrekt angegeben wurden und 
dann auch eingehalten werden können. Denn nur so kann man sicher 
stellen, dass beim erneuten routen auch diese Sachen konstant bleiben.

Ich habe mal den Test gemacht und die Daten ohne IDDR2 direkt an ein FF 
geführt und abgetastet und selbst da komme ich auch errechnete Zeiten 
von ca. 5,8ns... also weit entfernt von meinen 3,125ns. Woran das genau 
liegt, kann ich leider nicht sagen, dafür fehlt mir einfach noch die 
Erfahrung. Manuelles Map/Place/Route ist also gar nicht zu denken.

Wenn man also mal davon ausgeht, dass diese Frequenzen mit dem Spartan 
3A machbar sind, muss ich also einen Weg finden, wie ich es ihm 
beibringe und er weiß, dass er es kann. Da liegt mein Problem.

Ich kann auch sehr gerne mal einen Teil meines Designs hochladen und ihr 
schaut mal drüber? Denn hinter dem IDDR2 kommen noch ein paar 
Schieberegister und solche Sachen, die eben die Daten parallelisieren 
und dann sortieren... also in meinen Augen nicht wirklich wenig Logik. 
Ich habe auch das IDDR2 durch folgenden Code ersetzt:
process (Clock_in_0_s)
begin
   if rising_edge(CLOCK_IN_0) then 
      Data_in_ris_s <= Data_in;
   end if;
end process;

process (CLOCK_IN_180)
begin
   if rising_edge(Clock_in_180_s) then 
      Data_in_fal_s <= Data_in;
   end if;
end process;
Nur dadurch bekomme ich jetzt die Daten ziemlich sicher in den FPGA. Mit 
dem IDDR2 ist es mir bisher nicht gelungen. Aber das probiere ich heute 
oder morgen noch einmal aus.

Ich hoffe, dass sich dieses Timingproblem noch lösen läßt. Der Prof wäre 
sicher nicht so erfreut, wenn die FPGA Wahl die Falsche war und nun ein 
neues PCB gemacht werden muss.

Nochmals vielen Dank für die Hilfe!

MfG Andi

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe auch einen ADC jedoch besitzt dieser keinen Test-Mode. Demnach 
habe ich halt nicht die Möglichkeit das ganze zu untersuchen. An den 
Pins des FPGAs und den ADC kann ich auch leider nicht messen (beides 
BGAs)

Selbst wenn ich ein bekanntes Signal zum Digitalisieren vorgebe kann ich 
nie sicher sein wie dicht ich am Worst Case mit dem Timing bin.

Kann mir jemand einen Rat geben wie ich dies überprüfen kann?

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann:
Naja, für solche Fälle kann man dann auch mal die Timing-Simulation 
bemühen. Muss man aber mindestens 4 Fälle simulieren: Minimale Zeiten 
aus dem Datenblatt des ADC mit -sdfmin und -sdfmax bei der Simulation 
und maximale Zeiten aus dem Datenblatt mit -sdfmin und -sdfmax. Dann 
schreibt die Modelsim die Timing-Verletzungen raus. Musst allerdings 
auch die Laufzeit der Leitungen richtig modellieren....aber ist ja kein 
Thema bei bekannter Länge.

Achja, Andreas, probier mal die Global Design Goals auf "Timing 
performance with IOB Packing" zu stellen, ob dann die Zeiten eingehalten 
werden. Außerdem gibts beim P&R auch noch einige Optionen, aber mit dem 
Goal Timing Performance gehts schon mal ein Stück schneller...

Autor: Andreas B. (loopy83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian R. schrieb:
> Achja, Andreas, probier mal die Global Design Goals auf "Timing
> performance with IOB Packing" zu stellen, ob dann die Zeiten eingehalten
> werden. Außerdem gibts beim P&R auch noch einige Optionen, aber mit dem
> Goal Timing Performance gehts schon mal ein Stück schneller...

Das habe ich schon getan, damit habe ich die 5,8ns erreicht...
Wahnsinnig schnell X-D
Ich arbeite gerade die App-Note xapp485 und die dazugehörogen 
Designfiles durch. Ich verstehe nur Bahnhof. Ich glaube ich muss noch 
VIEL lernen :)

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn man wissen will, warum da soviel Zeit verloren geht, ist der 
FPGA-Editor sehr hilfreich. Da kann man den Weg bis zum Ziel recht gut 
nachverfolgen (inkl. Delay) und bekommt auch so manchmal sein 
Aha-Erlebnis... Damit kannst du auch feststellen, ob deine Vorstellungen 
von der Art des Mappings im VHDL auch wirklich so ins FPGA umgesetzt 
wurden. Mit dem (Nicht)Packing in die IOBs hatte ich da eben schon 
vereinzelt böse Überraschungen...

BTW: Basierend auf der Ansicht kann man dann auch versuchen, einzelne 
FFs von Hand zu plazieren, wenn der Router irgendwie verplant ist...

Autor: Andreas B. (loopy83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich hatte heute noch etwas Zeit, mich erneut dem Timingproblem zu 
widmen.

Ich habe mir ein kleines Bsp Projekt gebaut und habe herausgefunden, 
dass der DCM Schuld ist. Scheinbar gleicht er die clock-skew aus und so 
sind Daten und CLock zwar Synchron, aber die COnstraints werden nicht 
eingehalten. Als Einstellung hatte ich System_synchron gewählt.

Nun habe ich im Bsp Projekt den DCM auf Source_synchron gestellt und nun 
klappt es, aber leider nicht bei meinem richtigen Projekt.

Dort habe ich folgende Analyse:
Slack (setup path):     -1.298ns (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:          3.250ns
  Data Path Delay:      5.843ns (Levels of Logic = 0)(Component delays alone exceeds constraint)
  Clock Path Delay:     1.295ns (Levels of Logic = 3)
  Clock Uncertainty:    0.000ns
Also der Datenzweig liegt direkt im IOB (Logic Level = 0) und das habe 
ich auch im FPGA Editor überprüft, die dirt liegenden FlipFlops sind 
aktiv.

Nur wieso habe ich dann immer noch so ein höllisch großes Data Path 
Delay von fast 6ns?

Meine constraints sehen wie folgt aus:
NET "DOUT0A_N" OFFSET = IN 3.125 ns VALID 3.125 ns BEFORE "TCLK_N" FALLING;
NET "DOUT0A_P" OFFSET = IN 3.125 ns VALID 3.125 ns BEFORE "TCLK_P" RISING;
NET "DOUT1A_N" OFFSET = IN 3.125 ns VALID 3.125 ns BEFORE "TCLK_N" FALLING;
NET "DOUT1A_P" OFFSET = IN 3.125 ns VALID 3.125 ns BEFORE "TCLK_P" RISING;
Habe ich das richtig gesetzt? Mal abgesehen von dem Umstand, das der 
erste Wert die Hälfe von 3.125 ns sein müßte.
Also das P Pad die Rising edge und das N Pad die Falling edge... sehe 
ich das richtig?

Womit kann das Data Path Delay noch zusammenhängen, wenn es doch direkt 
im IOB zum ersten FlipFlop geht und die Zeit des im Datenblatt stehenden 
Wertes von etwas über 2ns um Welten überboten wird?

Oder wird nun berücksichtigt, dass Daten und Clock durch das 
Source_synchrone Betreiben nicht mehr zueinander passen, was davor ja 
der DCM ausgeglichen hat?
Könnte ich mit diesem Delay im Data Path weiterarbeiten, indem ich den 
Clock im ADC um genau diese Zeit nach hinten verschiebe? Könnte ich dann 
die Fehlermeldung ignorieren?

Vielen Dank,
Andi

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.