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:
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:
Hallo,
Ich habe es nochmal mit den globalen Constraints versucht:
1
OFFSET = IN 1.5625 ns VALID 3.125 ns BEFORE "TCLK_P" RISING;
2
OFFSET = IN 1.5625 ns VALID 3.125 ns BEFORE "TCLK_P" FALLING;
3
OFFSET = IN 1.5625 ns VALID 3.125 ns BEFORE "TCLK_N" RISING;
4
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
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
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
Vielleicht ist folgendes hilfreich?
http://www.xilinx.com/support/documentation/white_papers/wp237.pdf
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.
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:
1
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!
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
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
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 :)
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
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
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.
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.
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
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.
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
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.
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
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...
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
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).
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.
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/ds1021s-25/delay-line-8bit-73-75ns-soic16/dp/1306314
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.
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.
> 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 ;)
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:
1
process(Clock_in_0_s)
2
begin
3
ifrising_edge(CLOCK_IN_0)then
4
Data_in_ris_s<=Data_in;
5
endif;
6
endprocess;
7
8
process(CLOCK_IN_180)
9
begin
10
ifrising_edge(Clock_in_180_s)then
11
Data_in_fal_s<=Data_in;
12
endif;
13
endprocess;
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
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?
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...
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 :)
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...
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:
Data Path Delay: 5.843ns (Levels of Logic = 0)(Component delays alone exceeds constraint)
7
Clock Path Delay: 1.295ns (Levels of Logic = 3)
8
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:
1
NET "DOUT0A_N" OFFSET = IN 3.125 ns VALID 3.125 ns BEFORE "TCLK_N" FALLING;
2
NET "DOUT0A_P" OFFSET = IN 3.125 ns VALID 3.125 ns BEFORE "TCLK_P" RISING;
3
NET "DOUT1A_N" OFFSET = IN 3.125 ns VALID 3.125 ns BEFORE "TCLK_N" FALLING;
4
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
Thread beobachten
Seitenaufteilung abschalten