www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Einbinden von DDR RAM in EDK-Projekt


Autor: Andreas N. (poolspieler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich will ein Spartan-3E Custom Board entwickeln.
Darauf wird ein Großteil der Hardware des Spartan3E-Starter Boards drauf 
sein.
Im Prinzip bin ich guter Dinge, nur beim DDR-RAM hakt es.
Ich habe sowohl hier im Forum, als auch bei Xilinx und Google gesucht. 
Aber die wirkliche Erkleuchtung kam noch nicht.

Mein Problem:
Es gibt ja den MIG von Xilinx. Damit habe ich auch einen Custom Core 
erzeugt.
Aber wie ist die weitere Vorgehensweise im EDK??? (Ich habe mit dem IP 
core generator bis jetzt noch nicht gearbeitet...)
Ich habe versucht den Core im EDK zu importieren - habe es aber nicht 
geschafft :-(
Oder kann ich einfach eine Standard mpmc-IP nehmen und das UCF-File aus 
dem MIG portieren???

Wie macht Ihr es, wenn Ihr im EDK einen custum DDR-RAM in Betrieb nehmen 
wollt?
Oder sollte ich einfach den auf dem Starterkit vorhandenen RAM nehmen 
und die UCF aus dem Beispiel kopieren???


Ich würde mich über jede Anregung freuen!

Gruß,
Poolspieler

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der MPMC ist schon mal ein guter Ansatz, der stellt alle 
Timing-Parameter usw ein. Kannst ja über den Base System Builder ein 
ähnliches Xilinx Board benutzen und dann die UCF anpassen.

Autor: Andreas N. (poolspieler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Chris,
danke für die Antwort! Das werde ich für den ersten Schritt wohl so 
machen. Also exakt der selbe FPGA und RAM wie auf dem Starter Kit...

Nur zum Verständnis:
Wie müßte ich dann vorgehen, wenn ich auf einen anderen Spartan3E oder 
anderen RAM wechseln wollte?
Muss ich dann doch über den MIG gehen - und wie geht es dann weiter?
Oder kann ich einfach MPMC benutzen. Aber wo bekomme ich dann die 
Details der UCFs her???

Könntest Du mir da nochmal einen Hinweis geben?

Gruß,
Poolspieler

Autor: Andreas N. (poolspieler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oder kann ich einfach den MPMC mit einem RAM-Typ meiner Wahl 
konfigurieren, anschließend eine Synthese laufen lassen und einfach 
schauen, welche Pins gesetzt werden OHNE UCF. Diese Pins trage ich dann 
in die UCF-Datei ein - oder wäre das nun  wirklich zu einfach?

Es muss doch irgendwo ein Tutorial geben, in dem steht, wie man im EDK 
ein custom Board mit DDR-RAM erstellt. Am besten Schritt für Schritt.
Oder kennt jemand eine gute Literatur zum Thema?

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meine Erfahrungen mit den DDR-Controller-Cores von Xilinx lassen sich in 
zwei Worten zusammenfassen: Absoluter Schrott. Hier stimmt es wirklich, 
was nichts kostet, taugt auch nichts.

Das Zeug hat nicht nur eine Performance zum Weglaufen, sondern ist auch 
ziemlich instabil und hat IMO untaugliche Interfaces für High-Speed-DMA.

Ich habe mich damit 2 Monate bis zur Frustration abgemüht und musste 
feststellen, dass weder der schlechte Durchsatz noch die Instabilitäten 
von mir kamen. Am Anfang sucht man den Schuldigen ja meist bei sich 
selbst.

Wenn man sich aber den VHDL-Code anschaut, ist es kein Wunder. Da waren 
wohl 15jährige Inder am Werk, die zwar ein VHDL-Lehrbuch verschluckt 
haben und nach Zeilen bezahlt werden, aber sonst keinen blassen Schimmer 
von sauberem, verständlichem und effizientem HW-Entwurf hatten. Ein 
Student, der mir sowas abliefert, würde es um die Ohren gehauen 
bekommen.

Ich habe dann den ganzen Mist in die /dev/null-Tonne geworfen und einen 
DDR-Controller-Core in 3-4 Wochen selber geschrieben. Der Microblaze 
bekommt damit ca. 30-50% mehr Durchsatz. Über eine vernünftige extra 
DMA-Schnittstelle kann man tatsächlich mit 400MByte/s lesen (vorher 
20MB/s aus einem 16Bit DDR mit 133MHz). Ein kontinuierliches DMA-Saugen 
von 100MB/s merkt der Microblaze nur mit ca. 5-7% Bandbreitenverlust.

Langer Rede kurzer Sinn: Du kannst für den Lerneffekt den Xilinx-Core 
einbauen. Wenn er dir aber von der Geschwindigkeit und Stabilität nicht 
reicht: SOFORT aufhören, NICHT lange debuggen und gleich selber was 
machen. Das geht schneller und ist IMO die einzige Möglichkeit, die 
Probleme wirklich zu lösen.

Und damit es etwas konstruktiver wird:

Mein Controller hat als Basis kein normales "Stream"-Zugriffsinterface 
(ala OPB/PLB). Stattdessen ist jeder Port ein kleiner "Cache" mit 
2*16*32Bit Distributed RAM DP-RAMs, getrennt für Lesen und Schreiben. 
Neben den LSBs der Addresse (für das DPR) gibt es noch die MSBs der 
Adresse, startread/write und donerea/write. Damit ist es für die 
angeschlossene Logik einfacher, die Daten in beliebigem Timing und 
(innerhalb der 16 Worte) beliebiger Reihenfolge zu erzeugen (write) bzw. 
zu verarbeiten (read) und das auch parallel(zB. fürs Speicher kopieren). 
Damit kann man DDR-Bursts sehr effizient ausnutzen.

Da das Interface zum DDR-Controller im wesentlichen aus den 
DP-RAM-Leitunge besteht, ist es auch kein Problem, mehrere dedizierte 
Ports zu haben. Der DDR-Controller selbst bedient über einen Arbiter mit 
Mux immmer nur einen Port, bekommt also gar nichts von den vielen Ports 
mit. So nebenbei erlaubt die Sache mit den DPRs auch, die etwas krummen 
Timingverhältnisse durch das DDR-Einlesen zu entkoppeln, man muss sich 
nicht ganz soviele Gedanken um die Synchronisierung machen.

Der Arbiter ist dann für die Priorisierung und das Weiterleiten der 
start/done-Signale zuständig. Zur Zeit der Controller 5 Ports. 2 für das 
D/I-Cache-MCH-Interface des MB, einen für den rohen Zugriff über 
OPB/PLB, einen für PCI-Busmaster und einen für eine 
DMA-Streaming-Engine.

Autor: Andreas N. (poolspieler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Georg,
vielen Dank für Deine umfangreiche Antwort.
Ich habe verstanden, dass es wohl besser wäre sich den core komplett 
selbst zu schreiben - dann hat man das ganze auch selbst in der Hand...
Doch leider habe ich nicht so viel Zeit. Da meine VHDL-Kenntnisse auch 
noch nicht auf dem obersten Level sind, würde ich wahrscheinlich eher 8 
Wochen dafür brauchen...

Trotzdem nochmal eine kurze Frage zu den XILINX-cores:
Wie fahre ich nun am günstigsten? Soll ich mir die UCF-Daten vom MIG 
generieren lassen und dann diese Daten in mein EDK-Projekt mit dem MPMC 
eintragen?
Aber was mache ich mit den generierten VHDL-Files des MIGs? Kann ich die 
ignorieren? Oder bin ich hier komplett auf dem falschen Weg?

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also du musst dich da nochmal eingehender mit EDK befassen. Der MIG aus 
dem CoreGen von ISE ist nur für ISE. Im EDK brauchst du ja was mit PLB 
Interface. Dem MPMC kannst du auch nach Erstellung des Systems noch 
sagen, welcher RAM dran ist, und die UCF Datei kannst du natürlich auch 
komplett von Hand verfassen...oder in Teilen aus einem Xilinx Board 
Prijekt kopieren, da hast du schon mal alle Namen. Die Implementierung 
durchlaufen lassen ohne UCF wird nicht gehen, da wird ja alles 
wegoptimiert und alle nicht angeschlossenen Eingänge werfen Fehler. 
Klick dich doch einfach durch den Base System Builder und gibt am Anfang 
an, dass du ein Custum Design machst. Alles andere sagt der dir dann 
schon. Nachher fügst du den MPMC zum Design hinzu und wählst in der 
Konfig deinen RAM Chip aus. Dann gehst du auf Adresses und klickst auf 
"Generate Adresses". Da werden die Adressräume passend voreingestellt. 
Und anschließen gehst du auf Ports und legst alle DDR_x Ports, die der 
MPMC hat mit "Make Externel" nach außen. Die musst du dann alle noch ins 
UCF File eintragen, da hab ich noch keinen Automatismus gefunden. Aber 
da kannst du ja viel mit Copy-Paste aus einem fertigen Projekt machen.

Autor: Andreas N. (poolspieler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Christian,
genau hier war auch mein Verständnisproblem! Ich dachte, man könne eine 
mit dem core generator generierte IP direkt in EDK einbinden. Wenn man 
WEIß, dass es NICHT gehen kann, dann ist natürlich alles klar... ;-)

Ansonsten bin ich jetzt weiter gekommen:
Meine Vorgehensweise:
1. MPMC-IP im EDK-Projekt einfügen und die Ports "external" machen
2. mit dem MIG-Generator eine IP für das gewünschte RAM + FPGA 
generieren
3. Wie im User Guide zu MPMC beschrieben "Converting MIG UCF to MPMCv.4 
UCF"
A script is provided at:
<EDK Install Dir>/hw/XilinxProcessorIPLib/pcores/mpmc_<version>/data/convert_ucf.pl to assist
with the process of converting a MIG UCF into an MPMC UCF.
4. den Text im generierten UCF-File kopieren und im EDK-Projekt einfügen
5. Im EDK "generate Bitstream"
--> sollte gehen - hoffe ich. Konnte es nur theoretisch machen --> die 
Hardware werde ich jetzt zeichnen und entflechten...

Kurz zum UCF-File mit fehlenden Einträgen:
Ich habe es gerade nochmal ausprobiert. Wenn ein Pin unter "System 
Assembly View"-"Ports" external gemacht wurde und KEIN UCF-Eintrag 
vorhanden ist, dann wird bei "generate Bitstream" ein beliebiger freier 
Pin verwendet. Das ist natürlich nicht wirklich sinnvoll, wenn bei jeder 
Synthese evtl. das Pinout anders ist...

Gruß,
Poolspieler

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, eigentlich kannst du den Schritt mit dem MIG weglassen, denn das 
macht (bis auf das UCF) alles der MPMC Generator im EDK. Aber wenn du 
den benutzt, um das UCF (teilweise) zu erzeugen, dann ist ja auch gut.

Klar, dass die auf freie Pins gelegt werden, wenn nix im UCF steht. 
Sinnvoll wäre so eine Art "Assign Package Pins" wie im ISE, aber das hab 
ich dort noch nicht gefunden. Wir gehen den Weg anders herum: Wir suchen 
uns ein Xilinx Board, was am besten passt und lassen vom BSB das System 
dafür erstellen. Die Pinbelegung der Komponenten, die wir verbauen 
(SDRAM, GbE Phy usw) übernehmen wir dann vom Xilinx Design und fügen nur 
noch unsere Sachen hinzu. Spart etwas Arbeit, und man kann davon 
ausgehen, dass Xilinx die Pins schon sinnvoll verteilt hat.

Autor: Andreas N. (poolspieler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Christian,
prinzipiell ist es sicherlich "intelligent" ein bereits existierendes 
Board zu "klonen". Allerdings sollte man dabei etwas aufpassen. Weil 
manchmal macht xilinx ein paar "Schweinereien".
Die RAM-Geschichte beschäftigt mich (mit ein paar Pausen) schon einige 
Monate. Ich habe damals versucht, für das Starterboard im Base System 
Builder ein Customboard für mein Starterboard zu bauen. Ich wollte 
einfach ein eigenes Design "simulieren". Ich habe es damals lange Zeit 
nicht zum laufen bekommen - wegen den UCF-konfigurationen.

Nach seeeehr langem Suchen wurde ich im MHS-File fündig:
BEGIN mpmc
...
 PARAMETER C_SPECIAL_BOARD = S3E_STKIT
...
END

Xilinx hat hier ernsthaft den Parameter C_SPECIAL_BOARD eingeführt um 
ein nicht Synthesefähiges System Synthesefähig zu machen! OK, sowas kann 
man machen - aber dann sollten die Xilinx-Leute etwas deutlicher darauf 
hinweisen... Weil ein Neuling in dieser Materie wundert sich schon sehr 
über all die schönen Fehlermeldungen...

Wegen MPMC und UCF:
Im Reiter "Base Configuration" der MPMC-IP steht folgender Hinweis (mit 
gelben Ausrufezeichen):
The pinout of MPMC must be compatible with MIG (Memory Interface Generator), please see MPMC data sheet for mor information.

--> Ich wollte hier nur meine Erkenntnisse für die Nachwelt festhalten. 
Vielleicht hilft es ja jemandem... ;-)

Gruß und schönes WE,
Poolspieler

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, es gibt bei Xilinx viele nicht dokumentierte Schweinereien. Das mit 
dem PARAMETER wusste ich gar nicht, beim ML405 steht da nix drin. Muss 
ich mal den Kollegen fragen, der das bearbeitet hat. Ich "darf" immer 
nur die Peripheral-Cores schreiben. Das ist schon Krampf genug.

Gerade für Anfänger ist ISE und EDK wirklich grottig. Da gibts so viele 
Fallstricke und halb ausgegorene Sachen, gruselig.

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.