Für ein aktuelles Projekt mit einem Spartan3A (BGA256-Gahäuse) habe ich mir für Testzwecke ein Mess/Testboard aufgebaut. Allerdings setze ich dort einen Spartan3 XC3S200 ein. Nun stelle ich fest, dass Spartan3 und 3A in der IOBank erheblich voneinander abweichen! Ich habe einen DAC mit 400MHz Taktfrequenz der differntielle (LVDS) DDR Eingänge besitzt. Leider scheint der Spartan3 mit seinen DDR-Primitives nur direkt einen Ausgangspin anzusprechen. Ich muss mich entscheiden, ob ich einen LVDS-Ausgang oder einen DDR-Ausgang haben will. Beides gleichzeitig geht wohl nicht. Nun habe ich die differentiellen Paare emuliert, in dem ich einfach zwei DDR AusgangsBlöcke jeweils an ein differentielles Paar angeschlossen habe, bei dem die Dateneingänge negiert sind. Dadurch wird leider mein DAC und der Spartan sehr warm, da ich nun 3,3VLVCMOS Pegel habe und erheblich oberhalb der LVDS Spek liege. Als Workarround habe ich die Ausgangstreiber auf 2mA Strom gestellt. (Ein echtes LVDS mit 3,3VIO kann ich laut Datenblatt auch nicht machen, das funktioniert nur mit LVDS25 bei 2,5V IO-Spannung.) Sieht jemand vielleicht eine Möglichkeit, wie man LVDS mit DDR zum Laufen bekommt?
Hallo, wage meinen ich zu wissen, dass beim Virtex4 nicht alle LVDS-Pins auch als LVDS-Ausgänge konfigurierbar sind. Vielleicht ist das auch bei deinem Spartan so. Tom
Hallo, ich verwende genau die andere Richtung. Wenn ich dein Problem richtig verstehe, dann willst du DDR Daten via LVDS zu deinem DAC schicken? Wer generiert den Takt? Der FPGA oder gibt den der DAC vor? Ich verwende dazu den IBUFGDS, der mir das Signal aus dem Differenziellen umwandelt und danach taste ich das Signal mit einem IDDR2 ab... das sollte doch auch in der anderen Richtung funktionieren, oder? MfG Andi PS: Beim Spartan 3A DSP sind nur die Bänke 0 und 2 als LVDS Ausgänge verwendbar... liegt vielleicht schon da das Problem?
Hallo Andreas, leider gibt es beim SPARTAN 3 (ohne A, ohne E, ohne AN) kein primitive mit dem Namen "IDDR2". Das ist letzlich mein Problem. DAC-Clocktakt, DAC-Datentakt und DAC Daten werden vom FPGA erzeugt. Zwar könnte der DAC auch SDR Daten empfangen, allerdings hören die RAMBlöcke bei 275MHz auf zuarbeiten.
Lies doch die daten dann mit SDR ein, und speichere sie mit der doppelten Breite dann brauchst du auf RAM Seite nur den halben Takt.
@Läubi Äh, das mache ich doch schon. 2xRAM @200MHz
Michael O. schrieb: > Hallo Andreas, > > leider gibt es beim SPARTAN 3 (ohne A, ohne E, ohne AN) kein primitive > mit dem Namen "IDDR2". Das ist letzlich mein Problem. Beim Spartan 3 gibts die "IFDDRRSE" Primitiven. Wie die benutzt werden, steht in ISe bei Edit -> Language Templates -> VHDL -> ... halt durchklicken.
Michael O. schrieb: > @Läubi > Äh, das mache ich doch schon. > 2xRAM @200MHz Und was hält dich davon ab einfach die Ramms mit doppelter Datenbusbreite zu nutzen? Dann mußt du nur einen Datensatz zwischenpuffern und reduzierst die nötige Schreibrate auf 100Mhz.
@Läubi Das Problem ist, dass ich mich entscheiden muss (soweit ich das Datenblatt und die LIB verstehe) entweder ein differentielles SDR Signal oder ein asymmetrisches DDR Signal zu erzeugen. Ich nutze nur ein DualPortedRAM und greife auf die beiden Seiten mit den um 180° verschobenen Takten zu. Ein Port liest alle gerade, der andere alle ungeraden Datenworte aus. Damit habe ich zwei Datenlinien. Nur dahinter ist mein Problem - die Kombination zu einem DDR-Datenstrom geht offensichtlich nur am Portpin selbst. Alternative wäre, einen Ausgangspin zu nutzen um den DDR-Strom zu erzeugen, dann per in buffer wieder einzulesen und auf einem anderen Port als differentielles Signal auszugeben. Das ist aber wegen der Laufzeiten sehr unschön! Der Ausgangsdatenstrom hat 400MHz mit 200MHz Basisclock. @Christian Das ist ja mein Problem - OFDDRRSE sitzt nur am Portpin und ist nicht als "Baustein" frei verfügbar.
Nehm mal das O weg, also http://www.xilinx.com/itp/xilinx5/data/docs/lib/lib0157_141.html Der OFDDRRSE hat einen Output buffer, deswegen kannst du da keine LVDS Treiber hinterhängen. der FDDRRSE ist ein Normaler DDR-FF Gruß John.
Hm... ich dachte du kannst den DAC auch in SDR betreiben?
Hm, su willst also das DDR-Signal quasi so lassen und nur über einen FIFO entkoppeln oder wie? Wie kommen denn de Daten dort? Sind das halbe Worte? Oder einzelne Datenworte pro Flanke? Welcher ADC ist das denn? Du müsstest ja dann intern mit einem Multiplexer die Daten wieder zu DDR machen, aber bei 200Mhz auf dem Spartan 3....puh...sportlich. Brauchst du die Daten denn in einem Strom gemultiplext hintereinander? Die normale Vorgehensweise wäre, die parallel weiter zu verarbeiten. Also IDDR rein, dann in 2 parallele FIFOs speichern und parallel weiter....das ist mit 200Mhz immer noch recht viel auf dem Spartan.
Holla, es ist immer noch ein DAC kein ADC! (AD9726) Datenrate ist immernoch 400MHZ (ich übertrage mit 400 MSPS)! IDDR2 gibt es nicht im SPARTAN3! Ich habe einen 16bit DAC mit 400MSPs und einem LVDS Eingang, den ich zwischen SDR und DDR umschalten kann. Die internen RAM_Blöcke können laut Xilinx bis 275MHz laufen. Da ich mehr benötige verarbeite ich zwei parallele 16bit Datenströme mit jeweils 200MHz (einmal 0° und einmal 180° Phasenlage) und baue diese zu einem DDR-Datenstrom am Ausgang zusammen. Der DAC erhält eine 200MHz Wordclock und sampled auf jede Flanke (effektiv 400MHz). Ferner benötigt er ein DAClock von 400MHz. @Christian Eigentlich habe ich alles schon in dem ersten Post geschrieben @John-Erik Im Libraryguide zur Version 8.1 gibt es dieses Primitive "FDDRRSE". In der Version 10 scheint es nur noch "IFDDRRSE" und "OFDDRRSE" zu geben. Es geht offensichtlich trotzdem nicht, selbst wenn ich FDDRSE verwende - Fehler: The dual data rate register OFDDRRSE_P_Buf[2].OFDDRRSE_P_inst failed to join an I/O component as required. Please try constraining the register together with a valid pad or output buffer symbol. Note that FDDR library symbols may drive output buffers only.
Also ich hab das bei meinem TFT mit LVDS so gemacht wie im Anhang. Ist nicht das komplette Projekt. in der wrapper.vhd ist der DDR-FF und im top_level.vhd ist die LVDS-Instanzierung und bei mir läuft das so ohne Probleme. Hast du vielleicht irgendwas vergessen? Gruß John
@John-erik Welchen Baustein hast Du genau? Welche ISE nutzt Du?
ISE 9.1.03i und ein Virtex2 Aber wenn ich mir http://www.xilinx.com/itp/xilinx5/data/docs/lib/lib0157_141.html anschaue steht da der Spartan 3 als Primitive verfügbar. >The dual data rate register OFDDRRSE_P_Buf[2].OFDDRRSE_P_inst failed to >join an I/O component as required. Please try constraining the register >together with a valid pad or output buffer symbol. Note that FDDR >library symbols may drive output buffers only. wenn ich das so lese hast du da doch immer noch den falschen drinnen. den OFDDRRSE anstelle des FDDRRSE. Bei mir ist der normale FDDRRSE auch nicht in der Libery Liste. Und wenn du mal den FDDRCPE probierst http://www.xilinx.com/itp/xilinx5/data/docs/lib/lib0155_139.html so wie ich den habe.
Interessant ist ja nicht unbedingt die VHDL Instantiierung sondern was die Kiste Hardwaremäßig verbaut hat. (Seite 13) http://www.xilinx.com/support/documentation/data_sheets/ds099.pdf Das sieht für mich so aus, dass man LVDS Eingänge mit DDR nutzen kann, aber keine Ausgänge mit LVDS. Oder habe ich Tomaten auf den Augen? @John-Eric Die Fehlermeldung mit dem "OFDDRRSE" habe ich bekommen, als ich explizit den primitive "FDDRRSE" zur Ausgabe verwendet habe. Vermutlich wird "FDDRCPE" auch nichts bringen, wenn die Hardware diese Kombi grundsätzlich nicht unterstützt. EDIT: Wie wird denn überhaupt ein differentielles Signal ausgegeben? Im Schaltbild sieht es nicht so aus, als ob dies überhaupt möglich wäre.
Sorry, mit dem IDDR hatte ich falsch gelesen oben. Ich hab mal schnell getestet. Ein Mini-Design mit XC3S200 und der Einfachheit halber die Schaltung drin. Keine Pins fest vorgegeben und das Design läuft ohne Fehler oder Warnungen durch. ISE 11.3 Muss mal noch raussuchen, welche Pins man benutzen kann, dann meld ich mich noch mal. Im Anhang auch das Design Summary und die verwendeten IOBs.
Angehängte Dateien:
-
LVDS_DDR.png
(4 KB)
-
Summary.png
(23 KB)
-
IOBs.png
(5,6 KB)
Alles klar, ich lade gerade ISE 11.1 herunter. Die Probleme habe ich mit ISE9.2.04i. Noch installiert habe ich eine ISE10.1. Leider fressen die blöden ISE-Installationen viel Speicher und sind dazu in den ersten Releases ziemlich instabil...
Dann nimm am besten gleich die 11.3 und nur die. Die ist super stabil. Wieso brauchst du mehrere Versionen? Musst du noch ganz alte Bausteine beschreiben?
Ich habe mit den ISEs schlechte Erfahrungen gemacht. ISE5.x funzte nicht, dann upgrade auf 6.1 Im Laufe der Entwicklung haben wir nur noch XST-Fehler bekommen - der Bug wurde mit der 6.3.03i gefixet. Die 7.x funktionierte dann wieder nicht mehr. Mit der 8.er ging es ganz gut, konnte die aber später nicht mehr herunter laden und musste die 9er installieren. Für ein AN-Design und weil die 9er mit dem Impact per JTAG am herumzicken war, habe ich die 10er installiert (5GB zusätzlich). Die 10er-Version ist aber nur noch halb so schnell wie die 9er-Version :((. Ich habe einfach keine Lust mehr GB-Weise den Xilinxkram herunterzuladen und dann mit den neusten Versionen Beta-Tester zu spielen. Xilinx hat (jedenfalls damals) zu festen Zeiten neue Releases und Servicepacks herausgebracht - ungeachtet des tatsächlichen Entwicklungs- und Stabilitätsgrades der Software.
Ja, das ist bei Xilinx leider so. Die 9.2.0.4 lief auch recht stabil, ist aber ab und an abgeschmiert und hat dann das ganze ProjektFile zerschossen. Mit der 10 kam dann die Umstellung auf XML ProjektFiles, da gabs das nicht mehr, dass das kaputt ging. Die 11.3 ist sehr stabil jetzt, hatte bisher noch keinen Absturz, und iMpact haben sie repariert. Das war irgendwie kaputt gegangen bei der 11.1 Beta-Tester musst du wohl bei so riesigen Software Paketen immer spielen. Allerdings kommen mit alten Versionen eben immer mal so blöde Fehler rein. Die neueste ist schon meist das gescheiteste, wenn man nicht gerade alte Virtex pro machen will.... Achja, die 11.3 ist sehr schnell geworden, viel schneller als die 9.x
Die ISE11.1 mit 9GB auf der Platte zu installieren war kein großes Problem, nur das Update läuft seit fast 3 Stunden und ist aktuell bei 115%. (ich will nach Hause...)