Hallo Leute! Ich kämpfe seit mehreren Tagen mit einem seltsamen Problem mit einem Spartan-3A FPGA das in den externen DDR2 Speicher mit Hilfe des Xilinx MIG Controllers schreibt. Zum Testen verwende ich einen 16 bit Zähler, den ich inkrementiere. Ich schreibe die Werte des Zählers in den DDR2 Speicher und lese sie dann wieder heraus und vergleiche. Meistens ist auch alles in Ordnung. Habe aber leider festgestellt, dass manchmal in 100 MByte Daten z.B. so um die 10 Bytefehler auftreten und zwar meistens wenn mein Zähler von FF00 nach FF01 umspringt, dann kommt statt FF01 z.B. F701, DF01, C001, 2801, also ist immer das erste Byte falsch. Mit der Xilinx Testbench des MIG 2.3 ließ sich der Fehler übrigens nicht entdecken, weil der Zähler dort schnell wieder auf 0 zurückgesetzt wird und gar nicht erst in den hohen Bereich (FF00) kommt. Dass der Fehler vom Zähler kommt, kann ich eigentlich ausschließen, weil alles registriert ist. Hat jemand eine Idee, was die Ursache dieses Fehlermusters sein könnte? Ich verwende z.B. zwei hintereinandergeschaltete DCMs um von 66.66 MHz auf 133 MHz zu kommen. Kann es das sein? Außerdem scheint das Signal dqs_div_rst des original von MIG generierten Testprojekts das Timing um 0.008ns zu verfehlen - ist das normal? Zudem habe ich das Gefühl, dass die Fehler eher dann auftreten, wenn das Board für längere Zeit vom Netz getrennt war. Bin für jeden Tipp sehr dankbar! Grüße, Anguel
Anguel S. schrieb: > wenn das Board für längere Zeit vom Netz > getrennt war Klingt nach einem thermischen Problem. Hier mal ein paar Anregungen: Das Timing sollte bei so kritischen Anwendungen wie DDR-Speicher schon stimmen, bzw. geschafft werden. Evtl. kannst Du den P&R Effort noch etwas hochsetzen? Sind die Offsetconstraints der Datenpins richtig gesetzt? Schau mal mit dem FPGA-Editor nach, ob er die Ausgangsregister wirklich mit in die IOBs packt. Macht der MIG am Anfang ein Augen-Training? Kannst Du Dir davon mal die Delay-Taps ausgeben lassen? Evtl. hast Du in Deinem Speicher noch ein paar Bit über und kannst mittels Parity oder Codespreizung Bitfehler detektieren, bzw. sogar korrigieren. Rick
Es gibt WIMRE zwei Einstellungen in ISE die zwingend erforderlich sind, damit ein MIG-Design läuft. Hba' natürlich nicht mehr im Kopf, welche das waren... Mit http://www.xilinx.com/support/answers/25245.htm kannst Du überprüfen, das MIG-Design ordentlich implementiert wurde. Wenn es bei Dir nicht so wie auf den Bildchen aussieht, kann es genau zu dem beschriebenen Fehlerbild kommen.
Erstmal danke an Rick und Rudolph für die Tipps! Habe zwischenzeitlich festgestellt, dass der MIG für bestimmte FPGAs (z.B. die meisten Spartan-3A) selbst mit den Default-Einstellungen, d.h. man clickt alles nur durch ohne MIG-Parameter zu verändern, Designs generiert, die die eigenen Timing-Constraints NICHT erfüllen. Das ist wohl auch der Grund, warum der Constraint für dqs_div_rst bei mir nicht erfüllt werden kann (ich habe einen XC3S200A-4FT256). Ich habe übrigens mit dem original von MIG generierten Design getestet, um eigene Fehler auszuschliessen. Habe auch, wie von Rick vorgeschlagen, den Synthesis-Effort und den Place&Route-Effort auf High gesetzt, leider ohne Erfolg - die dqs_div_rst MAXDELAY Constraint kann nicht erfüllt werden. Ansonsten gehe ich davon aus, dass eigentlich alle nötigen Constraints in der von MIG generierten UCF gesetzt sein müssten, oder? Übrigens wird ja das Projekt mit der create_ise.bat automatisch mit den richtigen Einstellungen erzeugt. Habe auch die von Rudolph vorgeschlagenen Bildchen angeschaut (stehen übrigens inzwischen auch im MIG User Guide). Das scheint alles OK zu sein, zumindest sieht alles so ähnlich aus, auch wenn im Dokument nicht genau gesagt wird, worauf man denn achten soll. Das einzige was nicht hinkommt, sind die angesprochenen Werte für dqs*_delayed_col*, da sollten laut UG für Spartan-3A der Net Skew < 65ps und der Max Delay < 400ps sein, bei dem generierten Design für den XC3S200A-4FT256 sind es 72ps und 495ps. @Rick: Was meinst Du mit Augen-Training beim MIG? Bin leider kein Experte :( Nochmals zu dem von mir beschrieben Fehler: Hatte vergessen zu sagen, dass es sich hierbei um einen DDR2-Chip mit 8 bit Datenbreite handelt. Habe nun meinen 16 bit Counter so verändert, dass er nicht voll durchläuft, sondern genau den kritischen Bereich mit dem Wechsel von FF00 nach FF01 durchläuft. Wie erwartet, treten nun die Byte-Fehler sehr häufig auf. Kann das evtl. etwas mit dem Umschalten mehrerer Datenbits auf einmal zu tun haben? Da jeweils nur 8 bits durch die Datenleitungen zum DDR2 gehen, kommt es zu einer Übertragung von FF, dann 00 und dann wieder FF. Genau dieses zweite FF ist am anfälligsten für Fehler. Wenn ich den Counter stattdessen auf einen anderen Bereich umprogrammiere, wo dieser Wechsel des FF auf 00 und dann wieder auf FF nicht vorkommt, treten die Fehler gar nicht oder nur sehr sehr selten auf.
Anguel S. schrieb: > Was meinst Du mit Augen-Training beim MIG? Ich hatte mir mit dem MIG mal QDR-Design erzeugt. Da wurde beim Initialisieren eine Sequenz abgefahren, die die Delays in den IOBs getunt hat. Ich weiß gar nicht, ob der Spartan das hat (IODELAY). Dadurch wurde durch permanentes Lesen einer bekannten Sequenz der optimale Samplezeitpunkt bestimmt (einmal minimales Delay bis Bitfehler, einmal maximales Delay bis Bitfehler und dann die Mitte davon). Was hast Du eigentlich für ein Board? Was selbergebautes? Wenn viele Pins auf einmal schalten und die Masse schlecht gelegt ist, wandert die u.U. weg und verursacht Bitfehler. Vielleicht kannst Du Deinen Zähler nochmal abwandeln und gucken, ob das bei anderen Bitmustern mit vielen 0-1-Wechseln auch so ist. Rick
Rick Dangerus schrieb: > Anguel S. schrieb: >> Was meinst Du mit Augen-Training beim MIG? > > Ich hatte mir mit dem MIG mal QDR-Design erzeugt. Da wurde beim > Initialisieren eine Sequenz abgefahren, die die Delays in den IOBs > getunt hat. Ich weiß gar nicht, ob der Spartan das hat (IODELAY). Nicht direkt, MIG macht aber sowas ähnliches (nennt sich WIMRE TAP-Delay). Das kann man sogar in 5 Stufen einstellen, entweder hart codiert im Quelltext oder im Betrieb mit Chipscope. Im UG086 sollte drinstehen, wie das geht. Zum Augentraining siehe z.B. http://de.wikipedia.org/wiki/Augendiagramm - man sucht sich die Stelle mit der weitesten Augenöffnung. Die Frage nach der Hardware hätte ich jetzt auch gestellt: Eval-Board von Xilinx oder einem Dritten? Eine eigene Entwicklung? Sind alle Hardware-Constraints eingehalten worden? Skew der Datenleitungen zueinander, Impedanz, Terminierung? Ground-Bouncing könnte, wie erwähnt, auch ein Problem sein.
Hallo Leute! Ich habe das ganze Wochenende mit Testen verbracht :( Das Board, das ich verwende ist dieses: http://www.dlpdesign.com/dlp-hs-fpga-ds-v12.pdf Habe mitlerweile den Support auch angeschrieben, mal sehen ob die mir antworten... Habe übrigens jetzt das Timing für den MIG hinbekommen, musste das Constraint von BEL G nach BEL F verschieben. Das ganze hat aber die auftretenden DDR2 Fehler nicht beseitigt. Die mit Coregen erzeugten kaskadierten DCMs scheinen gut zu laufen, verlieren den Lock nicht. Damit ich ausschliessen kann, dass es an der USB-Spannungsversorgung liegt, habe ich das Board mit ext. Spannungsversorgung getestet - leider keine Verbesserung. Komischerweise scheint das ganze ab und zu fehlerfrei (!) zu laufen und zwar immer dann, wenn ich das Board an USB für längere Zeit angeschlossen hatte, dann geflasht habe und das Design gleich gestartet habe ohne das Board vom Netz zu trennen - das lief dann sogar mehrmals hintereinander ohne Probs. Nach dem Trennen von USB (kein Strom) und Wiederanschliessen ist das Problem wieder da. Habe dann den Xilinx MIG Code leicht so modifiziert, dass die Addressen in den "inaktiven" Zuständen des Controllers nicht auf "000..000" zurückspringen, sondern beibehalten werden. Das hat IMHO die Fehler etwas reduziert. Habe dann sogar versucht die Address-Zähler als Gray-Zähler zu implementieren, hat aber keine Verbesserung gebracht. Eine Verbesserung brachte hingegen eine Änderung der Burstlänge von 8 auf 4. Das hat die Fehler stark reduziert, so das ich in 50 MB Daten "nur" noch 0 bis 1 Fehler hatte, wenn in meinem Zählbereich der Wechsel von FF00 nach FF01 nur 1 mal vorkam. Dann bin ich aber dazu übergegangen, statt mit einem Zähler immer mit den gleichen Test-Muster zu testen, mit folgendem Ergebnis: Bei Testmuster FF00 -> viele Fehler (z.B. ca. 4000 Fehler in 50 MB), also wird dann statt FF00 ein XY00 gelesen, wobei XY irgendein korruptes Byte ist. Bitte beachten, dass die Datenbreite 8 bits ist. FF ist hier also das erste zu übertragende Byte vom 16-bit Wort. Und da geht was schief... Bei 0FF0, F00F und 00FF dagegen keine Fehler oder nur sehr selten Fehler. Besonderheiten in dem vom Boardhersteller generierten MIG Design sind: Bank1: Data, Address/Control, System Control Bank2: System Control, System Clock RTT (nominal) ODT = 50 Ohm Pin Standards für DDR2 Pins: NET "ddr2_dq[*]" IOSTANDARD = SSTL18_II | SUSPEND = 3STATE; NET "ddr2_a[*]" IOSTANDARD = SSTL18_I | SUSPEND = 3STATE_PULLUP; NET "ddr2_ba[*]" IOSTANDARD = SSTL18_I | SUSPEND = 3STATE_PULLUP; NET "ddr2_cke" IOSTANDARD = SSTL18_I | SUSPEND = 3STATE_PULLUP; NET "ddr2_cs_n" IOSTANDARD = SSTL18_I | SUSPEND = 3STATE_PULLUP; NET "ddr2_ras_n" IOSTANDARD = SSTL18_I | SUSPEND = 3STATE_PULLUP; NET "ddr2_cas_n" IOSTANDARD = SSTL18_I | SUSPEND = 3STATE_PULLUP; NET "ddr2_we_n" IOSTANDARD = SSTL18_I | SUSPEND = 3STATE_PULLUP; NET "ddr2_odt" IOSTANDARD = SSTL18_I | SUSPEND = 3STATE_PULLUP; NET "rst_dqs_div_in" IOSTANDARD = SSTL18_II | SUSPEND = 3STATE_PULLUP; NET "rst_dqs_div_out" IOSTANDARD = SSTL18_II | SUSPEND = 3STATE_PULLUP; NET "sys_clk_in" IOSTANDARD = LVCMOS33 | SUSPEND = 3STATE; # was 18; ##NET "led_error_output1" IOSTANDARD = LVCMOS33 | SUSPEND = 3STATE; # was 18; #r0.08 ##NET "data_valid_out" IOSTANDARD = LVCMOS33 | SUSPEND = 3STATE; # was 18; NET "init_done" IOSTANDARD = LVCMOS33 | SUSPEND = 3STATE; # was 18; NET "reset_in_n" IOSTANDARD = LVCMOS33 | SUSPEND = 3STATE; # was 18; NET "ddr2_dqs[*]" IOSTANDARD = DIFF_SSTL18_II | SUSPEND = 3STATE_PULLUP; NET "ddr2_dqs_n[*]" IOSTANDARD = DIFF_SSTL18_II | SUSPEND = 3STATE_PULLUP; NET "ddr2_ck[*]" IOSTANDARD = DIFF_SSTL18_II | SUSPEND = 3STATE_PULLUP; NET "ddr2_ck_n[*]" IOSTANDARD = DIFF_SSTL18_II | SUSPEND = 3STATE_PULLUP; NET "ddr2_rfu_*" IOSTANDARD = LVCMOS18 | SUSPEND = 3STATE_PULLUP; #r0.05 spares for 2Mb DDR2 added Gleichzeitig ist im UCF aber noch definiert: CONFIG ENABLE_SUSPEND = "NO"; Habe bis jetzt keine der obengenannten Einstellungen verändert. Sollte ich da etwas ändern? Danke im Voraus für jede Hilfe! Grüße, Anguel
Anguel S. schrieb: > Das Board, das ich verwende ist dieses: > http://www.dlpdesign.com/dlp-hs-fpga-ds-v12.pdf Läuft denn das Reference Design?
Rudolph schrieb: > Läuft denn das Reference Design? Beim Referenz-Design ist das so, dass die die DDR2 Userside-FSM komplett umgeschrieben haben. Diese empfängt Kommandos von der USB-FSM und gibt sie wieder an die USB-FSM zurück. Sieht auch ganz anders als die Xilinx Testbench aus. Außerdem werden Schreib-/Leseaddressen für DDR2 nicht automatisch erhöht, sondern explizit über USB-Kommandos empfangen. Die sind da wohl von einem anderen Board mit SRAM ausgegangen und haben da ganze an DDR2 angepasst. Dort wird auch nur ein einziger Burst geschrieben oder gelesen. Xilinx dagegen macht je 5 Bursts hintereinander. Ich habe versucht die DLP-FSM zu verstehen, habe es dann aber gelassen und alles wieder auf Xilinx-Testbench umgestellt, da ich deren Address-Generator gut verstanden habe und meinen Zwecken angepasst habe. Und als ich dachte, dass alles läuft, habe ich meinen Counter höher zählen lassen und die TB auf den gesamten Speicher erweitert und dann kamen die Probleme... Laut DLP lief das ganze aber auch schon mal mit der Xilinx TB. Das Problem ist, dass die Xilinx TB in der ursprünglichen Variante weder den gesamten Speicher durchläuft, noch den Zähler höher zählen lässt, also treten da die Fehler nicht auf. Sehr komplex und nervig das ganze... Ein weiteres Problem ist, dass deren Clock auf 66.666 MHz läuft (laut UCF zumindest), die nehmen den dann mal 2 und kommen auf 133.332 MHz. Das ganze passiert leider über DCMs und dazu kommt noch, dass mir der MIG Gen für den S3A Speed Grade -4 nur Frequenzen bis 133 MHz erlaubt, also wären das 0.332 MHz zu viel. Ich muss zugeben, dass ich da aber kein Experte bin und kann nicht sagen, ob diese Abweichung diese Probleme machen kann.
Interessant wäre evtl. auch: -inwieweit ausreichend gesunde Stützkondensatoren in der Nähe sind -ob der Fehler auch beim Test mit Zufallsdaten auftritt Die meisten Fehler sind mir früher erst beim Zufallstest nach einer längeren Aufwärmzeit aufgefallen. Ob Hersteller ewig Prüf-Zeit haben?
Hallo! Nochmals danke an alle für die Tipps. Habe inzwischen mein Design auf das Spartan-3E Starter Board (DDR statt DDR2 und 16 bit statt 8 bit Daten) portiert, der MIG Code war praktisch der gleiche, und es scheint dort ohne Fehler zu laufen :) NEUE Beobachtung beim DLP-Board: Interessanterweise zeigt sich am Oszi, dass die Fehler nach ca. 0.5 s vollkommen verschwinden und dann nicht mehr auftauchen. Wodurch kann sowas kommen??? Habe darauf folgendes probiert: Ich erzeuge ein künstliches Reset im FPGA für einige Sekunden, um die Cascaded DCMs (mit Coregen erzeugt) solange in Reset zu halten. Nachdem die zweite DCM locked meldet, halte ich das Design zusätzlich noch ein paar Sekunden im "not locked" Zustand und setzte dcm_locked erst dann auf '1'. Die Idee war, das sich alles stabilisieren kann, bevor es losgeht. Das ganze hat leider auch nichts gebracht :( Der Board-Hersteller DLP hat mir mitgeteilt, dass er das Board nur mit der Original-Xilinx-TB getestet habe. Diese testet aber nur einen minimalen Teil des Speichers und die Bitmuster enthalten auch nicht diejenigen, die bei mir die Fehler verursachen. Außerdem meinte DLP, dass ich das Design geändert hätte und könne mir nicht weiterhelfen. Sie können mir aber auch nicht zusichern, dass das Board "bullet-proof" ist. Es sei schließlich nur ein Demo-Board... Würde mich sehr freuen, wenn jemand zu meiner neuen Beobachtung (siehe oben)eine Idee hätte :) Viele Grüße, Anguel
Hast Du, wie oben schon mal erwähnt, probiert das TAP-Delay zu modifizieren? WIMRE gab es in cal_ctl.vhd neben einer Reihe tapx-Konstanten ein default_tap-Signal (oder ähnlich), dass ein Bitmuster wie eine der tapx-Konstanten zugewiesen bekommt, ich meine es sei ein Muster aus Einsen mit einer Null. Die Postion der Null kann man testhalber verschieben und damit den Samplezeitpunkt der Datenleitungen verschieben. Mal beide Richtungen ausprobieren. Wegen der 0.5s: Warte mal nicht auf die DCM sondern lass für ein paar Sekunden dein Memory-Interface laufen. Wenn es ein thermisches Problem sein sollte, liegt es evtl. im RAM (ein kleines Wandern im Timing reicht ja evtl. schon), das bleibt bei Deiner Methode aber kalt. Mal Kältespray probiert?
Danke für die Tipps Rudolph! Werde mal alles morgen austesten.
Habe probeweise einfach mal ODT abgeschaltet und jetzt scheinen keine Fehler mehr aufzutreten. Ob das so bleibt, werden weitere Tests zeigen.
Irgendwas scheint mit der Terminierung auf dem Board gar nicht zu stimmen, werde mal einen Bekannten fragen, der mehr Ahnung von HW hat. Sehr ärgerlich das ganze... Nochmals danke an alle für die Hilfe!
Duke Scarring schrieb: > Vielleicht bist Du ja auch davon betroffen: > http://www.xilinx.com/support/answers/34445.htm Da geht's aber um DDR3 und Virtex-6, nicht DDR2 und Spartan-3A...
Anguel S. schrieb: > Nochmals danke an alle für die Tipps. Habe inzwischen mein Design auf > das Spartan-3E Starter Board (DDR statt DDR2 und 16 bit statt 8 bit > Daten) portiert, der MIG Code war praktisch der gleiche, und es scheint > dort ohne Fehler zu laufen :) Hallo, ich versuche den Controller aus dem MIG für das Spartan-3E Starter Board fehlerfrei zum laufen zu bringen (unter ISE 12.3). Leider scheitert es an einigen Timings. Seltsam ist, dass einige Netze, die im UCF-File contrained werden gar nicht zu existieren scheinen. Auch ist mir unklar, was mit den ctrl0_rst_dqrs_div-Signalen zu geschehen hat. Ich würde sie ja gern auf freie Ports legen, doch leider gibt es die nicht mehr für die Bank 3. Derzeit habe ich die Loop auf Topebene geschlossen. Trotzdem wird automatisch irgendwo ein Port dafür angelegt... Die benötigten Clocksignale gewinne ich aus der Kaskadierung von 2 DCMs. Die erste DCM erhöht die Frequenz und die 2. erzeugt das eigentliche Clock-Signal und die um 90° verschobene Phase. Das scheint auch zu funktinieren. Könntest du bitte dein funktionierendes ucf-File schicken? Bin dankbar für jeden Tipp. Grüße Subjekt5
Subjekt5 schrieb: > ich versuche den Controller aus dem MIG für das Spartan-3E Starter Board > fehlerfrei zum laufen zu bringen (unter ISE 12.3). Leider scheitert es > an einigen Timings. Woran erkennst Du das? Es ist normal, dass einige Timings nicht hinkommen, weil das MIG Design an sich nicht immer 100% mit den Timings hinkommt, außerdem "gehackt" werden musste, damit er überhaupt auf dem S3E board läuft. Warnings kommen also massenweise, auch wenn es eigentlich läuft. Benutzt Du die Dateien aus dem ZIP-Archiv, das mit Coregen erstellt wird? Lies mal die TXT Files drin, da steht was die alles verändert haben. > Die benötigten Clocksignale gewinne ich aus der Kaskadierung von 2 DCMs. > Die erste DCM erhöht die Frequenz und die 2. erzeugt das eigentliche > Clock-Signal und die um 90° verschobene Phase. Das scheint auch zu > funktinieren. > > Könntest du bitte dein funktionierendes ucf-File schicken? Hab hier eins gefunden, weiss aber nicht 100%, ob es das letzte ist, habe damals in der Verzweifelung viel getestet und inzwischen schon vergessen... Wichtig ist, dass Du den Clock-Pin im original-UCF änderst. Und die TIMESPEC constraints. Grüße, Anguel
Anguel S. schrieb: Danke für die schnelle Antwort! > Subjekt5 schrieb: > >> ich versuche den Controller aus dem MIG für das Spartan-3E Starter Board >> fehlerfrei zum laufen zu bringen (unter ISE 12.3). Leider scheitert es >> an einigen Timings. > > Woran erkennst Du das? Es ist normal, dass einige Timings nicht Nun, ich sehe in der Netzlisten-Timing-Simulation eindeutig, dass das DDR-SDRAM falsch angesteuert wird. z.B. werden die Control-Signale erheblich vor den Clock-Signalen generiert, was zu einem Fehlverhalten führt. Nach einigem Experimentieren und Änderungen der Synthese- und Mapping-Optionen kann ISE nun zum Glück alle Contraints fehlerfrei einlesen. > hinkommen, weil das MIG Design an sich nicht immer 100% mit den Timings > hinkommt, außerdem "gehackt" werden musste, damit er überhaupt auf dem > S3E board läuft. Warnings kommen also massenweise, auch wenn es > eigentlich läuft. Benutzt Du die Dateien aus dem ZIP-Archiv, das mit > Coregen erstellt wird? Lies mal die TXT Files drin, da steht was die > alles verändert haben. Jetzt wird es interessant! Ich habe den Controller direkt mit dem MIG (v3.6) erzeugt. Von ZIP-Files ist da keine Spur. Nun liest sich deine Antwort für mich so, als ob es eine überarbeitete Version des Controllers direkt für das Spartan-3E Starter Board gibt. Interessiert mich brennend, wie ich an das Teil herankomme. > Hab hier eins gefunden, weiss aber nicht 100%, ob es das letzte ist, > habe damals in der Verzweifelung viel getestet und inzwischen schon > vergessen... Wichtig ist, dass Du den Clock-Pin im original-UCF änderst. > Und die TIMESPEC constraints. Danke für das UCF. Wie ich sehe hast du das cntrl0_rst_dqs_div Signal auf einen INOUT gelegt und auf der Top-Ebene zurückgekoppelt. Richtig? Ansonsten unterscheiden sich die zugeordneten LOCs erheblich von denen in meinem UCF. Auch scheint ein wenig hinzugekommen zu sein. Vielen Dank schonmal Subjekt5
Subjekt5 schrieb: > Ich habe den Controller direkt mit dem MIG (v3.6) erzeugt. Von ZIP-Files > ist da keine Spur. Da kannst Du bestimmt im MIG Generator irgendwo ganz am Anfang Eval Boards als Target wählen. Und da ist auch das Spartan 3E Starter Board. Das war bei allen MIGs bis 3.4 zumindest der Fall. > Nun liest sich deine Antwort für mich so, als ob es eine überarbeitete > Version des Controllers direkt für das Spartan-3E Starter Board gibt. Ja, weil das Board nicht den standard MIG Design-Anforderungen entspricht. > Danke für das UCF. > Wie ich sehe hast du das cntrl0_rst_dqs_div Signal auf einen INOUT > gelegt und auf der Top-Ebene zurückgekoppelt. Richtig? Nicht ich, die Schlaumeier von Xilinx, damit das Design überhaupt läuft. > Ansonsten unterscheiden sich die zugeordneten LOCs erheblich von denen > in meinem UCF. Auch scheint ein wenig hinzugekommen zu sein. Ich hab eigentlich nur das modifiziert, wo "anguel" daneben steht :) Anguel Nachtrag: Guckst Du hier: http://www.xilinx.com/support/documentation/ip_documentation/ug086.pdf auf S. 69.
Anguel S. schrieb: > Subjekt5 schrieb: >> Ich habe den Controller direkt mit dem MIG (v3.6) erzeugt. Von ZIP-Files >> ist da keine Spur. > Da kannst Du bestimmt im MIG Generator irgendwo ganz am Anfang Eval > Boards als Target wählen. Und da ist auch das Spartan 3E Starter Board. > Das war bei allen MIGs bis 3.4 zumindest der Fall. Vielen Dank! Das war der entscheidende Hinweis! Im MIG v3.4 existiert der Controller für das Board tatsächlich. In den folgenden Versionen kann man es nicht mehr auswählen (oder ich habe es nicht gefunden?). Mal sehen, ob ich das nun zu laufen bekomme. Grüße Subjekt5
Subjekt5 schrieb: > Vielen Dank! Das war der entscheidende Hinweis! Freut mich, Dir geholfen zu haben :) > Im MIG v3.4 existiert der Controller für das Board tatsächlich. In den > folgenden Versionen kann man es nicht mehr auswählen (oder ich habe es > nicht gefunden?). Würde mich gar nicht wundern, wenn die das mal eben rausgenommen haben. Das Board ist vermutlich inzwischen als veraltet eingestuft. Außerdem spart das Support und Fragen, warum das Board nicht richtig designed wurde, damit es mit dem MIG kompatibel ist. Ich hatte bis jetzt sowieso kein einziges Board, das problemlos mit MIG lief. Schau Dir auf jeden Fall mal die ganzen Textdateien im ZIP Archiv an. Da sind Hinweise, wo Xilinx beim Board Mist gebaut hat und wie sie die Probleme durch Modifikationen im Design umgehen. Außerdem ist mir ein Rätsel, warum die in deren Design keine DCM nutzen, sondern einen externen Clock-Generator fordern. > Mal sehen, ob ich das nun zu laufen bekomme. Sollte eigentlich laufen. MIG scheint toleranter zu sein, als erwartet :) Grüße, Anguel
Anguel S. schrieb: >> Vielen Dank! Das war der entscheidende Hinweis! > Freut mich, Dir geholfen zu haben :) Jetzt läuft es auch mit dem generierten Controller aus dem MIG v3.6 und mit 50 MHz On-Board-Oszillator. Xilinx hat wohl den Controller doch noch zu guten hin überarbeitet. Vielen dank nochmal Subjekt5
Subjekt5 schrieb: > Jetzt läuft es auch mit dem generierten Controller aus dem MIG v3.6 und > mit 50 MHz On-Board-Oszillator. Xilinx hat wohl den Controller doch noch > zu guten hin überarbeitet. Interessant, d.h. Du generierst das Design ganz normal aus dem MIG heraus und musst da nichts per Hand ändern?
Anguel S. schrieb: > Subjekt5 schrieb: >> Jetzt läuft es auch mit dem generierten Controller aus dem MIG v3.6 und >> mit 50 MHz On-Board-Oszillator. Xilinx hat wohl den Controller doch noch >> zu guten hin überarbeitet. > > Interessant, d.h. Du generierst das Design ganz normal aus dem MIG > heraus und musst da nichts per Hand ändern? > > > > Beitrag melden | Bearbeiten | Löschen | So ist es. Natürlich gibt es einige Knackpunkte, die ich mal kurz anreiße. Das DDR-SDRAM betreibe ich mit 100 MHz. Die Frequenz muss man auch extakt dem MIG mitteilen, sonst kommt nur Murks raus. Die 100 MHz und das 90° phasengeschobene Signal erzeuge ich, wie schon erwähnt, mittels 2 seriell geschalteter DCMs. Das rst_dqs_div Signal führe ich gleich auf Topebene wieder zurück. Trotzdem wird ein FPGA-Pin dafür gemappt. Den habe ich auf P13 gelegt (wie in deinem UCF-File). Um dann noch das Timing zu verbessern habe ich alle Platzierungsvorgaben aus dem UCF-File entfernt, die mit rst_dqs_div_delayed zusammenhängen. Die Timings bekommt das automatische Place&Route dann besser hin. Natürlich müssen noch alle FPGA-Pins im UCF-File an das Board angepasst werden (also so wie in deinen UCF). Aber das ist nur ein direktes Ummappen auf die richtigen Positionen. Dann nur noch die Clocks anpassen. Ansonsten das UCF-File wie vorgegeben lassen. Das Memory-Model scheint nicht ganz fehlerfrei zu sein und es bedurfte einer kleinen Anpassung, damit die Timing-Simulation fehlerfrei lief. Aber der eigentliche Controller braucht nicht verändert zu werden. Grüße Subjekt5
Interessant. Ich frage mich bei solchen Sachen immer, ob nicht die Chips einfach sehr tolerant sind, so dass es im Endeffekt dann doch läuft, obwohl die Timings auf dem Papier nicht eingehalten werden ;)
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.