Spartan-3E-Starterboard ReD; Probleme mit dem DDR-SDRAM

  Hallo phlug,

ich bin nicht weitergekommen (Phase-shifting-Versuche sind auch im Sand 
verlaufen); ich werde mit dem Board keine so "hochgestochenen" Dinge wie 
DDR_SDRAM-Verwendung mehr betreiben.
Bei Xapps von Xilinx wimmelt es von guten Ratschlägen zum Thema 
DDR-SDRAM. Das zeigt, daß dies ein "heißes" Thema bei Xilinx (und 
anderen FPGA-Herstellern, Altera etc. ist), kompliziert und offenbar 
sehr fehleranfällig. Und da darf man als Xlinx-Starterkit-Besitzer eben 
wochenlang üben (erfolglos)

Merkwürdig ist schon, daß Xilinx, das für alle möglichen Dinge einen 
Wizard hat, hier nichts vorzeigt.
Ein für Nichtspezialisten nachvollziehbares Tutorial zum DDR-SDRAM-/ 
Timing, Board-bezogen habe ich bei Xilinx auch nicht gefunden. So etwas 
gehört doch offensichtlich in den UserGuide vom Board / kit. Aber so 
teuer war das Starterkit nicht, wie kann man dann einen solchen 
"Service" erwarten ?!

Altera ist hier angeblich wesentlich weiter.

Also ab zu Altera.

Hier ein Link zu anderen "Leidtragenden"
(was natürlich nicht tröstet), vielleicht können die Dir helfen.

http://www10.edacafe.com/NewsPortal-0.37/article.php?id=114308&group=comp.arch.fpga


Gruß
walterludwig

Hallo,

auch ich habe dieses Problem in meinem RevD-Board festgestellt:(. Ich 
denke nicht, dass es sich um einen Produktionsfehler handelt. Das neue 
Spartan3 Starterkit hat zum Glück auch ein DDR-Ram und ist auch sonst 
dem Spartan3-Kit sehr ähnlich. Die Community der unzufriedenen DDR-User 
und somit der Druck auf Xilinx etwas zu unternehmen dürften somit größer 
werden.

Lukasz

Hallo,

ein Nachtrag von mir.
Ein Hauptunterschied zwischen Rev C und Rev D habe ich in den 
Schematic.pdf's für die Boardvarianten auf Seite 12 doch noch entdeckt 
(hatte ich mehrmals am Bildschirm übersehen).
Der DDR-SDRAM IC ist unterschiedlich (jeweils von Micron):
 bei Rev C lt. Angabe  MT46V16M16TG-75
 bei Rev D lt. Angabe  MT46V32M16TG-6T (der ist auch auf meinem Board).

Lt. Micron-Datenblättern soll der Chip auf der Rev C ab 100 Mhz, die auf 
der Rev D aber ab 133 Mhz laufen !!!

Und auch ein Blick über den Gartenzaun:

Das neue Starterkit Spartan-3e- Microblaze-1600 hat den gleichen 
DDR-SDRAM-IC wie die Rev D-Variante , aber zusätzlich einen 
CMOS-Oszillator mit 66,6 Mhz.
Sagt das uns etwas ? Z. B. diesen Oszillator in die Rev D einbauen und 
die Voraussetzungen für eine Inbetriebnahme des DDR-SDRAMs sind deutlich 
verbessert. Oder eher:  Das bringt nichts, schade um die zusätzliche 
Geldausgabe.

Anmerkung: Xilinx hat vor wenigen Tagen den Preis für das Spartan-3e- 
Starterkit reduziert (wegen Promotion , muß vielleicht eher 
Winter-Schlußverkauf heißen) ; "Nachtigall ick hör dir trappsen".

Gruß
walterludwig

Hallo,

> Ein Hauptunterschied zwischen Rev C und Rev D habe ich in den
> Schematic.pdf's für die Boardvarianten auf Seite 12 doch noch entdeckt
> (hatte ich mehrmals am Bildschirm übersehen).
> Der DDR-SDRAM IC ist unterschiedlich (jeweils von Micron):
>  bei Rev C lt. Angabe  MT46V16M16TG-75
>  bei Rev D lt. Angabe  MT46V32M16TG-6T (der ist auch auf meinem Board).

ACK, Ich habe hier auch auch Rev. D Board mit dem *-6T

> Lt. Micron-Datenblättern soll der Chip auf der Rev C ab 100 Mhz, die auf
> der Rev D aber ab 133 Mhz laufen !!!

Das glaube ich nicht -- es handelt sich wohl ehr um die max. Frequenz.

JEDEC-79E spezifiziert DDR herstellerunabhaenig, und da verlangt Seite 
56 "TABLE 11: ELECTRICAL CHARACTERISTICS AND AC TIMING" für DDR200, 
DDR266 und DDR333 ein maximales tclk von 12 ns. Also was um 85MHz.


Ausserdem habe ich auf genau dem Board einen selbstgeschriebenen DDR 
Controller mit 100MHz laufen. Der ist leider voll synchron, d.h. das 
restliche FPGA Design läuft mit 50MHz und sieht ein 64Bit breites 
Speicherinterface [1].
Der Controller braucht unbedingt mehr Doku und sollte mal mit FIFOs 
asynchron gemacht werden... wenn ich mal Zeit haette -- und genau 
wuesste wie am besten.

   j.


[1] https://roulette.das-labor.org/trac/wiki/wb_ddr

  Hallo,

habe ich richtig interpretiert:
 Der opb-ddr-Controller von Xilinx ist für das 
Xilinx-Spartan-3e-Starterkit ungeeignet, der Käufer muß sich seinen 
Controller selber schreiben / entwickeln ? ! Super !

gruß
walterludwig

Hallo,

> habe ich richtig interpretiert:
> Der opb-ddr-Controller von Xilinx ist für das
> Xilinx-Spartan-3e-Starterkit ungeeignet, der Käufer muß sich seinen
> Controller selber schreiben / entwickeln ? ! Super !

Zum opb controller kann ich nichts sagen -- den habe ich nicht 
ausprobiert weil ich den MicroBlaze wegen der hohen Lizenzkosten 
unattraktiv fand.

Aber ich habe 3 Wochen lang zwei anderen Controller von Xilinx versucht 
zum laufen zu bekommen:

1) Einen MIG (1.5) generierten
2) Einen, den mir Scott Schlachter von Xilinx zugeschickt hat. Habe mich 
dabei auf diesen Thread aus comp.sys.fpga berufen: 
http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/5b7b9ad71c8dcebe/75b7258c3fa9587e

Beides ohne Erfolg. Unklar ob ich mich einfach zu dumm angestellt habe. 
Waren halt meine ersten Schritte mit FPGAs. Der eigene, noch 
verbesserungsfaehige, lief dann nach 2 Wochen.


Gerüchteweise ist bei der neusten MIG Version aber ein speziell auf das 
Board angepasster DDR Controller dabei. Habe das aber nicht verifiziert.


  j.

   Hallo Jörg,

vielen Dank für Deinen ausführlichen Bericht zu Deinen Ergebnissen. Ich 
vermute allerdings, daß er den meisten Starterkit-Verwendern, die 
Probleme mit ihrem DDR-SDRAM via Microblaze und pdb-ddr-Controller 
haben, nicht viel hilft. Mir auf keinen Fall, ich bin Anfänger.
Deine Ergebnisse sagen aus, daß mit der Starterkit-DDR-SDRAM-Hardware 
unter bestimmten Bedingungen (z. B anderer Microcontroller-Softcore 
(Leon3)) und mit entsprechendem FPGA-Know-how gearbeitet werden kann.

Man darf also nicht sagen, daß das DDR-SDRAM auf dem Starterkit nur gut 
fürs Xilinx-Marketing ist und technisch nicht ernst zu nehmen. Auf diese 
Idee kann man bei so viel Frust auch kommen. Für Anfänger muß
Xilinx zum Thema DDR-SDRAM_-Verwendung auf preiswerten Starter-kits 
"nachsitzen" . Tutorial etc.
Daß man eine Lösung für den Controller im MIG versteckt, sagt meiner 
Meinung nach auch aus, daß sich Xilinx auf dem Gebiet "DDR-Controller 
fürs Starterkit" seiner Sache (noch ?) nicht sicher ist.


Gruß
walterludwig

Hallo walterludwig,

Ja, ich muss dir auf jeden Fall zustimmen -- das DDR Ram ist nicht 
sonderlich anfängerfreundlich.

Ich finde es auch --sagen wir mal-- unverstaendlich, dass Xilinx da 
nicht an exponierrter Stelle einen passenden Controller mitliefert. 
Zumindest dass der opb-controller aus dem EDK funktioniert haette ich 
erwartet.

Da hat wohl das Cyclone II Starter Kit [1] die Nase vorn. Altera hat 
neben SDRAM auch noch 512k SRAM verbaut. Simpel, flexibel zu benutzen 
und Anfängerfreundlich.



Andererseits: Ich wollte meinen DDR Controller noch so aufbohren, dass 
er asynchron ist und 2 Taktdomaenen hat: Einmal ca. 120 MHz (optimal 
133MHz, aber mal gucken ob das ohne Hand-Placing geht) fuer die DDR 
Seite, und einmal einen bel. anderen Takt mit dem man dann mit seinem 
eigenen Design gegen den Controller spricht.
Dann gäbe es zumindest einen einfach zu benutzenden Controller.

Eventuell haben die "alten Hasen" hier ja ein paar allg. Tips wie man an 
solche 2-Taktdomaenen-Probleme rangeht?



  j.


[1] http://www.altera.com/products/devkits/altera/kit-cyc2-2C20N.html

In den Releasenotes für den aktuellen MIG steht:

"Spartan-3E Starter Kit DDR1 design files are available only in Verilog 
from MIG v1.6. The VHDL version of the files can be downloaded from: 
ftp://ftp.xilinx.com/pub/applications/misc/s3e_starter_revd_mig_ddr[1].z 
ip"

Das ist natürlich nicht sehr vertrauenserweckend. Erst recht wenn man 
bedenkt wie lange Xilinx dafür gebraucht hat. Aber immerhin: die älteren 
Versionen davor konnten anscheinend überhaupt nichts brauchbares 
erzeugen. Ich würde hier aber eher den Boardhersteller (Digilent) in der 
Pflicht sehen. Irgendwie müssen die doch das Board getestet haben...

1MB SRAM wie auf dem Spartan 3 Board sind natürlich deutlich 
einsteigerfreundlicher. Aber solche Rams sind vergleichsweise teuer und 
werden dann doch schnell zu klein. Wenn es zum DDR SDRAM noch gleich 
noch einen brauchbaren Core gegeben hätte, dann wäre das auf jeden Fall 
die bessere Lösung gewesen.

Mässte ich mir jetzt ein neues Board kaufen, dann wäre es wohl das 
Terasic/Altera Cyclone II geworden. Aber jetzt muss ich aus dem was ich 
habe das Beste machen ;).

>Eventuell haben die "alten Hasen" hier ja ein paar allg. Tips wie man
>an solche 2-Taktdomaenen-Probleme rangeht?

Da der andere Takt beliebig ist, kommst du um eine per-Hand 
Synchronisation nicht herum. Wie man das bei einem single-RAM hinlegt, 
weiss ich. Mit DDR habe ich das noch nicht gemacht. Ich denke, du 
brauchts eine annehmende doppelte-FF-Architektur für den schreibenden 
Takt, sowie ein Multiplexer-Architektur für den lesenden Takt, weil Die 
die Daten nicht notwendigerweise mit einem DDR-Takt RAmseitig lesen 
kannst, sondern aufgrund desEintakten des Busses und der Steuerleitungen 
die RAm-Seite einen Takt dazwischenschalten könnte.

  Hallo,

wenn wir jetzt schon beim Altera-Cyclone-II-Starterkit landen.
Wo kauft man das kostengünstig (Versandkosten etc. nicht zu hoch, also 
nicht unbedingt in USA bestellen) ein, hier bei Digi-Key ?
Oder gibt es noch andere Adressen hier in Deutschland.
Wäre für ein Tip sehr dankbar.

Gruß
walterludwig

Hallo,

> Da der andere Takt beliebig ist, kommst du um eine per-Hand
> Synchronisation nicht herum. Wie man das bei einem single-RAM hinlegt,
> weiss ich. Mit DDR habe ich das noch nicht gemacht. Ich denke, du
> brauchts eine annehmende doppelte-FF-Architektur für den schreibenden
> Takt, sowie ein Multiplexer-Architektur für den lesenden Takt, weil Die
> die Daten nicht notwendigerweise mit einem DDR-Takt RAmseitig lesen
> kannst, sondern aufgrund desEintakten des Busses und der Steuerleitungen
> die RAm-Seite einen Takt dazwischenschalten könnte.


Ich bin mir nicht sicher ob ich dich richtig verstehe.

Dass ich Leseperationen source-synchron machen muss ist klar -- das habe 
ich auch schon.

Schreib Operationen mache ich mit PI/2 verschoben gegenueber dem Takt 
den ich dem DDR RAM gebe. Zum samplen der gelesenen Daten benutze ich 
einen zweiten, phasenverschobenen Takt den ich mit mit Hilfe der 
Takt-Feedbackleitung und einem DCM erzeuge. Das funktioniert soweit auch 
wunderbar.

Ich moechte jetzt aber, dass das Speicherinterface immer mit ~133 MHz 
lauft, waerend das restliche Design mit einem bel. Takt gegen den 
Controller spricht. Und es waere wohl gut wenn moeglichst viel 
Controller Logik mit dem (langsameren) Systemtakt lauft. (einfacheres 
P&R)

So haette ich also drei Tacktuebergaenge:

 1)  sys_clk   => ddr_w_clk    (fuer schreiben und ctrl-cmds)
 2)  ddr_r_clk => sys_clk      (klar, fuer gelesene daten)
 3)  ddr_w_clk => ddr_r_clk

Zu 3): der ddr_r_clk komponente muss taktgenau gesagt werden, wann
die Daten zu samplen sind. Das weiss wohl nur ddr_w_clk. Das hat die 
Steuerleitungen unter Kontrolle und lauft immerhin mit der gleichen 
Frequenz. Allerdings phasenverschoben.

Fuer 1) und 2) wuerde ich kleine async. FIFOs einsetzen.

Für 3) sollte ein FF reichen. Allerdings koennte es natuerlich sein,
dass der Phasenunterschied genau so ist, dass es haufig in den metastate 
gelangt. Dafuer wuerde ich einen zweiten Übergabe FF machen das PI 
Phasenverschoben taktet. Mind. einer der beiden FF muss doch 
zuverlaessig funktionieren.


Macht das Sinn? Oder gibt es ein schoeneres Design?


  j.

Hallo,

bei mir (Rev.D Board) funktioniert die DDR-Speicheransteuerung ebenfalls 
nicht.
Ich habe deswegen auch schon mit einem Xilinx Applikationsingenieur 
unterhalten. Dabei stellte sich heraus, dass eine von mir erzeugter 
Memorytest auf meinem Board fehlschlug, auf seinem Board ( ebenfalls 
Rec.D) aber lief. Auch auf einem zweiten Board, das ich testete, lief 
der Test nicht erfolgreich. Dieses zweite Board habe ich nun an den 
Ingenieur geschickt, der sich die Sache genauer ansehen will.
Auf meinen beiden Board ist ein MT46V32M16TG-6T Speicherbaustein 
verbaut, auf dem Board des Ingenieurs befindet sich ein  MT46V16M16TG-75 
Baustein.
Sobald ich neuere Information habe melde ich mich wieder.

Tobias

    Hallo,

theoretisch darf auf der Rev D lt. offiziellem schematic.pdf überhaupt 
kein MT46V16M16TG-75 sein.
Vielleicht hat der Ingenieur aber etwas verwechselt.
Und wenn doch ? Dann muß ein schönes Durcheinander muß bei der 
Produktion des Boardes bei Digilent geherrscht haben. Die armen 
Xilinx-App-Leute ! Kein Wunder, daß die keine passende Lösung 
präsentieren (können).

Hallo phlug, das mit dem M0:M1:M2 =0:1:0 funktioniert bei meinem Rev. D 
Board nicht, vor Wochen schon probiert.
Ein schönes Durcheinander !

Gruß walterludwig

Hallo,

Nach seinen Angaben hat der Ingenieur ein Rev.D mit MT46V16M16TG-75 
Speicher.
Das Umjumperen hat mir geholfen. Mit Jumper auf M1 und M0,M2 offen läuft 
der Speichertest einwandfrei.
Allerdings ist mir nicht ganz klar ob 1 oder 0 kein Jumper bedeutet, aus 
Tab 4-1 S.27 in der User Guide geht das nicht hervor. Vergleicht mal die 
Abbildungen mit den Zahlenangaben, da bedeutet eine 0 mal Jumper und mal 
kein Jumper. Nach dem Schaltplan 6/14 auf S.141 in der User Guide, 
bedeutet kein Jumper eine Verbindung mit 3,3V.

Tobias

hi zusammen,

ich hatte mal wieder probleme mit meinem DDR-speicher. allerdings trat 
dieser fehler nur mit der aktuellen EDK-version auf (9.x), bei 8.x läuft 
ein standard-design aus dem base system builder einwandfrei. ein 
unverändertes projekt von 8.x in 9.x übersetzt funktioniert auch. ich 
denke es liegt an irgendeiner neuen ip-version. habe leider keine zeit 
und lust es genauer zu testen. die lösung beseteht aus folgenden 
zusätzlichen zeilen in der UCF:

NET "*/DDR_DQ_I*" IOBDELAY=NONE;
NET "*/DDR_DQ_O*" IOBDELAY=NONE;
NET "*/DDR_DQ_T*" IOBDELAY=NONE;
NET "*/DDR_DQS_I*" IOBDELAY=NONE;
NET "*/DDR_DQS_O*" IOBDELAY=NONE;
NET "*/DDR_DQS_T*" IOBDELAY=NONE;

(die bezeichnungen können bei euch natürlich auch anders sein...)

viele grüße,
phlug