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
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.
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
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?
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.
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?
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.
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"
1 | A script is provided at: |
2 | <EDK Install Dir>/hw/XilinxProcessorIPLib/pcores/mpmc_<version>/data/convert_ucf.pl to assist |
3 | 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
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.
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:
1 | BEGIN mpmc |
2 | ... |
3 | PARAMETER C_SPECIAL_BOARD = S3E_STKIT |
4 | ... |
5 | 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):
1 | 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
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.
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.