Hallo,
ich habe ein LVDS Daten Signal, welches ich über einen IBUFDS in den
FPGA bringe (Spartan 3A DSP) und einen LVDS Takt, den ich über ein
IBUFGDS verarbeite.
Nun habe ich also einen normalen Takt und einen normalen seriellen
Datenstrom. Die Daten welchseln mit jeder steigenden und fallenden
Flanke (DDR). Nun habe ich mir im UG331 das Kapitel zum IDDR2 angeschaut
und werde nicht so richtig schlau daraus.
Dort ist die Rede von zwei Takten, C0 und C1. Diese scheinen nach der
Abbildung entgegengesetzt zu verlaufen. Muss ich mir diese beiden Takte
erst aus dem Eingangstakt der Daten generieren? Oder wie genau kann ich
mit Hilfe des einzelnen Taktes meine Daten entsprechend verarbeiten?
Ich erhalte ja dann zwei getrennte Datenströme an Q0 und Q1. Einer
entspricht der steigenden Flanke, der andere der Fallenden. Kann ich
diese Daten dann nacheinander (also immer abwechseln Q1 - Q0 - Q1 ...)
und in der passenden Reihenfolge in ein Register speichern? Oder wäre es
besser Q1 und Q0 getrennt zu speichern und dann in einem zweiten Schritt
zu sortieren?
Gibt es irgendwo ein brauchbares und gutes HowTo, wie man Register
anlegt und diese dann beschreibt? Vielleicht in Verbindung mit
Chipscope, wo ich dann kontrollieren kann, ob meine LVDS Daten auch so
gespeichert wurden, wie sie auch verschickt worden sind?
Vielen Dank!
Also. Üblicherweise werden die Takte C0 und C1 über den DCM aus dem
Eingangstakt gewonnen. Das steht ja auch so im User Guide (S. 327). Dann
nimmst du den 0° und den 180° Takt. Bei Bedarf kannst du das dann noch
über den Pahse-Shift zurecht schieben. Wenn dein Eingangstakt aber mit
den Daten mitgeliefert wird, brauchst du das in der Regel nicht.
Die Daten kommen dann parallel aus dem IDDR2 FlipFlop, und zwar
ausgerichtet an den beiden Takten C0 und C1. Willst du die auf die
steigende Flanke ausgerichtet haben, musst du noch ein 2. FlipFlop
hinter den Q1 Ausgang schalten. Das klappt, steht auch so im user Guide
(S. 329), das sitzt dann direkt mit auf dem IO-Block und garantiert in
den allermeisten Fällen, dass die setup-Zeit trotzdem eingehalten wird.
Beim 3A kannst du glaube ich das Alignment Feature des IDDR2
benutzen....
Tj,a und wie du die Daten dannverarbeitetst, musst du dir selbst
ausdenken. Wenn du die eh hintereinander haben willst, brauchst du kein
IDDR2 sondern kannst die mit dem doppelten Takt (über DCM generiert)
direkt mit einem IFF einsammeln. Willst du die parallel verarbeiten,
nimmst du das IDDR2 Register.
ChipScope kannst du natürlich dann benutzen, aber solche grundlegenden
Sachen simuliert man vorher.
Hallo,
ich bekomme den IDDR2 im Chip einfach nicht zum laufen.
In der Simulation funktioniert alles tadellos... aber wenn es es an der
realen LVDS Quelle teste, kommen an den beiden Datenausgängen Q0 und Q1
keine Daten heraus.
Ich habe mir den Data-In von dem IDDR2 auf einen Pin gelegt und die
Daten kommen auch an, nur leider verschwindet dieses Signal im IDDR2. So
viel kann man da doch gar nicht falsch machen, oder?
CE ist auf 1 fixiert, set ist auf 0 fixiert...
Könnte jemand mal mein Design anschauen und versuchen den Fehler zu
finden?
Wie steht denn IDDR_Reset? Ist das auf 0? Und was sagt denn die
Timing-Simulation? Und mal genau alle Warnungen beim Routen angeschaut?
Speziell schauen, ob 653 dabei sind: Signal benutzt aber nicht
zugewiesen -> wird auf Null gezogen. Übersieht man leicht, und dann
läufts nicht.
Also der DCM Reset funktioniert. Da ich erst das Board und dann die LVDS
Quelle einschalte, muss ich den DCM erst reseten bevor er seine Arbeit
aufnimmt. Er spuckt ja auch einen plausiblen Takt aus.
Den IDDR2 Reset hab ich schon ausprobiert. Egal ob ich den Taster drücke
oder in Ruhe lasse...
Bei der ganzen Synthese, Implementierung usw habe ich keinerlei
Warnungen oder Fehler. Alles läuft sauber durch.
Timing Simulation müßte ich nochmal machen... hab ich noch nie
gebraucht, mal schauen wie und was ich da machen kann.
Ich habe alle unused Pins auf float gestellt, dass ich keine Gefahr
laufe mir beim rumprobieren was zu zerschießen.
DANKE für die Hilfe, aber ich werde wohl weiter suchen und probieren
müssen!
Andreas schrieb:
> Den IDDR2 Reset hab ich schon ausprobiert. Egal ob ich den Taster drücke> oder in Ruhe lasse...
Hat der denn einen Pull-Up bzw. Pull-Down Widerstand? Wie ist der Taster
angeschlossen? Nach Masse oder nach VCC? Generell ist ein Taster am FPGA
immer etwas mit Vorsicht zu genießen, speziell, wenn man auf synchronen
Reset aus ist. Nagel mal das DDR_Reset auf 0 fest, das braucht man
eigentlich sowieso nicht.
Und es gibt überhaupt keine Warnungen beim Implement? Nicht mal, das
"Instanciating Black Box Module...."? Das ist ja seltsam. Mach mal
Timing-Simulation.
Bei der Timing Analyse fällt mir auf, dass ich noch gar keine Timing
Contrains festgelegt habe, weil ich nie wußte, was da rein muss.
Die Analyse mach ich dann doch unter
Implement Design => Place & Route => Generate Post-Place & Rote Static
Timing => Analyze Post-Place & Rote Static Timing ?
Denn da spuckt er mir nix aus... außer meinen LVDS Takt, den ich mit
6,25ns Periode und 50% angegeben habe:
im ucf File:
NET "AFE_CLK_N" TNM_NET = AFE_CLK_N;
TIMESPEC TS_AFE_CLK_N = PERIOD "AFE_CLK_N" 6.25 ns HIGH 50%;
NET "AFE_CLK_P" TNM_NET = AFE_CLK_P;
TIMESPEC TS_AFE_CLK_P = PERIOD "AFE_CLK_P" 6.25 ns HIGH 50%;
Was genau fehlt mir noch, dass ich da eine Aussage treffen kann, mit der
man was anfangen kann? Mal abgesehen davon, dass ich lediglich weiß, das
mir die Analye die Zeiten angibt bzw. angeben soll, die die Signale vom
Eingang zum Ausgang brauchen, also quasi die Laufzeiten in den Gattern
ist das so korrekt?
MfG
Du sollst eine Timing-Simulation machen, keine statische Timing-Analyse.
Da musst du in der ISE links oben auf Simulation umschalten, und dann
auf "Post Route" stellen. Eventuell musst du die TestBench noch dem
Projekt hinzufügen, wenn noch nicht geschehen. Das mit den Contraints
sieht erst mal richtig aus, wenn dein Takt 160MHz ist. Nach dem Routen
müsste dann in der Zusammenfassung stehen, ob er das Timing geschafft
hat "All contraints met" wäre das dann.
Ich hangel mich von Frage zu Frage, von Problem zu Problem und von
Fehler zu Fehler. Sehr ernüchternd, wenn man nicht weiß, was man wie
machen soll und welches Ergebnis man erwarten kann. Jetzt habe ich
wieder im Netz gesucht und wieder nichts gefunden... wie lange will mir
diese FPGA Welt noch so verschlossen bleiben?
Der Unterschied zwischen statischer Timing-Analyse und Timing-Simulation
ist und war mir nicht bekannt, Verzeihung.
Ich habe nun oben links im ISE bei Sources for: auf Post-Route
Simulation gestellt, bin dann ein Fenster weiter unten auf ModelSim
Simulator gegangen und dann auf Simulate.
Nun bekomme ich fünf neue Warnungen, seit dem ich die Timing COntrains
eingefügt habe.
Aber einen Satz wie "All contraints met" kann ich weder im ISE noch im
Modelsim finden. Dann wirds wohl noch nicht so weit sein... dass alles
passt.
Ich frage mich nur langsam, wie man solche Probleme alleine lösen
kann/soll? Ich fühle mich langsam schlecht, dass ich immer wieder
nachfragen muss... wiel mir diverse Internetliks und seitenlange
Tutorials und Manuals nicht weiterhelfen.
Brauch ich für diese Art der Timing Analyse vielleicht wieder ein ISE
Simulator Projekt? Das werde ich dann später gleich nochmal
ausprobieren...
VIELEN VIELEN DANK!!!
Also zunächst mal lernt man sowas komplexes wie FPGA Design und
Verifikation im Studium. Zumindest hab ich das da gelernt. Die Erfahrung
kommt dann erst mit den Jahren im Job.
Naja, fangen wir vorn an. Ich hab mal ein Mini.Projekt mit deinem Code
gemacht. S3 A DSP 1800.
Bild 1: Nach dem Implement Design. "All Constraints Met" steht auf der
rechten Seite oben.
Bild 2: So muss das zur Timing-Simulation aussehen.
Die Warnungen sind OK, das kommt daher, dass er die Constraints, die du
vorgegeben hast, quasi in den DCM rein zieht. Das passt schon so.
VIELEN VIELEN DANK!!!
Hat denn diese Meldung auch ihre Ursache im DCM?
>WARNING:NetListWriters:674 - Mismatched property type detected - type S >expected
for property DESKEW_ADJUST:, but type integer detected, ignored.
Also dieses "All Constraints Met" steht nach dem Implement da. Sowohl
oben rechts als auch unten links im Design Summary.
Die Timing Analyse habe ich auch mit Modelsim durchgeführt, also wie auf
deinem zweiten Bild gezeigt. Nur leider kann ich hier keinen Unterschied
zur Behavioral Simulation feststellen.
Muss ich denn, bevor ich das Design in den FPGA lade, noch weitere
Constrains angeben? Denn bisher habe ich ja lediglich meine Taktfrequenz
festgelegt, indem ich die Periode der beiden LVDS Takt auf 6.25ns
gesetzt habe. Wird denn dann automatisch überprüft, ob diese
Taktfrequenz mit dem aktuellen Design, die Laufzeiten in den Gattern mit
eingerechnet, überhaupt möglich ist? Oder muss ich diesen Fakt noch aus
der Timing Analye herauslesen, was mir bisher noch nicht möglich ist.
DANKE!
Andreas schrieb:
> VIELEN VIELEN DANK!!!>> Hat denn diese Meldung auch ihre Ursache im DCM?>>WARNING:NetListWriters:674 - Mismatched property type detected - type S >expected> for property DESKEW_ADJUST:, but type integer detected, ignored.
Naja, da hast du irgendwie einen falschen Parameter angegeben. Mach doch
den DCM am besten als IP core über den Core-Generator. Da kannst du auch
gleich auf differenziellen Eingang stellen und sparst die ganze
Buffer-Instaziierungs-Geschichte.
> Die Timing Analyse habe ich auch mit Modelsim durchgeführt, also wie auf> deinem zweiten Bild gezeigt. Nur leider kann ich hier keinen Unterschied> zur Behavioral Simulation feststellen.
Dann ist an deiner Hardware was falsch. Die Timing-Simulation bildet
sehr genau die Wirklichkeit ab. Da muss irgendwas grundlegendes sein...
> Muss ich denn, bevor ich das Design in den FPGA lade, noch weitere> Constrains angeben? Denn bisher habe ich ja lediglich meine Taktfrequenz> festgelegt, indem ich die Periode der beiden LVDS Takt auf 6.25ns> gesetzt habe. Wird denn dann automatisch überprüft, ob diese> Taktfrequenz mit dem aktuellen Design, die Laufzeiten in den Gattern mit> eingerechnet, überhaupt möglich ist? Oder muss ich diesen Fakt noch aus> der Timing Analye herauslesen, was mir bisher noch nicht möglich ist.
Nö, musst du nicht, der Takt wird ja eh von außen engelegt und bestimmt,
was im FPGA passiert. Deine Angabe mit den 6,25ns besagt lediglich, dass
du von außen einen 160MHz Takt anlegen willst, und dass der Router das
möglichst so optimieren muss, dass er das schafft.
Ich habe das Problem erst einmal vertagt. Ich komme einfach nicht
weiter. Ich werde erstmal mit Single Edge Signalen weiterarbeiten und
werde jetzt einmal versuchen einen FiFo zu bauen, in dem ich die Daten
ablege und parallel an irgendwelchen Pins zur Verfügung stelle.
Werde mir dazu mal CHipsScope anschauen, dass ich das Programm dann nach
der Simulation auch im CHip noch nachvollziehen kann.
Vielen Dank für die ausdauernde Hilfe :)
Ich habe aber die Vermutung, dass es nicht mein letzter Thread gewesen
sein wird.
Andreas schrieb:
> Ich habe das Problem erst einmal vertagt. Ich komme einfach nicht> weiter. Ich werde erstmal mit Single Edge Signalen weiterarbeiten und> werde jetzt einmal versuchen einen FiFo zu bauen, in dem ich die Daten> ablege und parallel an irgendwelchen Pins zur Verfügung stelle.
Tu dir was gutes und benutze dazu den Core-Generator. Mit deinem
Kenntnisstand ist das das sinnvollste. Generische FIFO-Beschreibungen in
VHDL würde ich einem Anfänger nicht anraten.
Hast du mal den DCM als IP-Core versucht einzubinden?
Ja habe ich gemacht.
DCM als IP Core eingebunden, auf differentiell gestellt... hat alles
geklappt. Nur leider wieder das gleiche Bild. Simulation funktioniert,
in der Hardware dann nicht mehr. Sehr komisch.
Ich habe jetzt auch den FIFO als IP Core implementiert, nur scheint das
etwas anders zu sein, als mit dem DCM. Zumindest kann ich den scheinbar
nicht so einfach aufrufen in meinem Top-file.
Ich werde mich dann mal weiter einlesen... irgendwie muss es mal wieder
voran gehen und ich brauche mal wieder ein Erfolgserlebnis. Sonst gebe
ich noch auf :)
Hi,
Gedanken zum Wochenende:
Es könnte einen Versuch Wert sein, mit Chipscope dir relevante Signale
anzuschauen ... Vielleicht kannst du so herausfinden, ob es an einer
Stelle im Signal/Datenpfad zum Bruch kommt oder ob von vornherein nichts
Sinnvolles ins FPGA reinkommt.
SuperWilly