www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Bytefehler beim Schreiben ins DDR2


Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rick Dangerus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rick Dangerus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Tipps Rudolph! Werde mal alles morgen austesten.

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe probeweise einfach mal ODT abgeschaltet und jetzt scheinen keine 
Fehler mehr aufzutreten. Ob das so bleibt, werden weitere Tests zeigen.

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht bist Du ja auch davon betroffen:
http://www.xilinx.com/support/answers/34445.htm

Duke

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Subjekt5 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Anguel S. (anguel)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Subjekt5 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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_doc...
auf S. 69.

Autor: Subjekt5 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Subjekt5 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Subjekt5 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

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.