Hallo, Seit Tagen sitze ich verzweifelt an einem Problem. Ich benutze einen Xilinx Spartan 6 und möchte mit Hilfe der ISE und EDK (14.1) einen AXI Blockram in das bestehende Microblaze-System integrieren. Nun verstehe ich hierbei nicht, wie ich die Logik für den Speicher (ISE) und den BRAM (EDK) zusammenbringe. Im EDK bin ich in der Lage einen BRAM-Controller sowie einen BRAM dem Bus-Interface hinzuzufügen, wie füge ich nun meine Logik hinzu? Im ISE gibt es die Möglichkeit eines Core Generators, bei dem direkt ein BRAM erstellt werden kann. Meine Schreiblogik ist hierbei das Top-Modul und den erstellten BRAM-IP-Core füge ich als Komponente zusammen mit der Port-Map hinzu. Irgendwie funktioniert das aber nicht. Wie bring ich meine Logik mit dem BRAM "zusammen"??? Ich habe wirklich schon zahlreiche Tutorials und Foren auf Xilinx durch. Kann mir bitte jemand helfen und mir so den Sonntag retten? Vielen Dank im Voraus.
Werner Motz schrieb: > Hallo, > > > Seit Tagen sitze ich verzweifelt an einem Problem. Ich benutze einen > Xilinx Spartan 6 und möchte mit Hilfe der ISE und EDK (14.1) einen AXI > Blockram in das bestehende Microblaze-System integrieren. Nun verstehe > ich hierbei nicht, wie ich die Logik für den Speicher (ISE) und den BRAM > (EDK) zusammenbringe. Im EDK bin ich in der Lage einen BRAM-Controller > sowie einen BRAM dem Bus-Interface hinzuzufügen, wie füge ich nun meine Hallo Werner, auch wenn ich vor ein paar Tagen anlässlich der Xilinx Zync7 Schulung etwas anderes gehört habe ist das Ansinnen einen Mikroblaze mit AXI Interface zu verbinden, nicht unbedingt das im Moment zu bevorzugendste... In den 13er Releases der ISE war das AXI Interface noch im BETA beziehungsweise Kleinkindstatus. Vorteile ergibt das AXI Interface im Mikroblaze nicht wirklich (ausser seine IP viellicht mal in den 7er Bausteinen weiterzuverwenden). Und groesser duerfte das Design auch werden. Dagegen sind die Nachteile (vom aktuellen Stand) noch gravierender. Die von Xilinx versprochenen Templates dürfen ruhig noch etwas reifen, der AXI ist in den Foren ein noch sehr unbeschriebenes Blatt... Mein Tipp im Moment wäre die Legacyschnittstellen noch solange zu nutzen, wie es Sie noch gibt. Dann lassen sich auch mehr Hilfen in diversen Foren finden. Gruss Vanilla
Hallo Vanilla, Danke für deine Antwort. Ich habe auf dich gehört und bin auf den PLB Bus umgestiegen. Jetzt sitz ich am nächsten Problem: Mit dem CoreGen hab ich mir einen True Dual Port RAM erstellt. Mit dem CoreGen habe ich mir auch eine Testbench generieren lassen. Ich möchte nun an Port B einen Schreibzugriff simulieren und versteh nicht wirklich, welche erzeugten Dateien ich dafür brauche. Im Ordner Simulation erzeugte Dateien: addr_gen.vhd bmg_stim_gen.vhd bmg_tb_pkg.vhd BRAM_synth.vhd BRAM_tb.vhd checker.vhd data_gen.vhd random.vhd 2 Ordner: functional timing Wie gehe ich nun vor, um einen Schreibzugriff zu simulieren? Vielen Dank im Voraus.
Hallo Werner, fuer den Anfang und den Anfaenger ist es im Moment wohl das beste, mit den althergebrachten Bussen zu arbeiten. > Danke für deine Antwort. Ich habe auf dich gehört und bin auf den PLB > Bus umgestiegen. Jetzt sitz ich am nächsten Problem: Hört sich jetzt aber nach dem Beginn einer Lernphase und nicht nach einem Problem an? > Mit dem CoreGen hab ich mir einen True Dual Port RAM erstellt. Mit dem > CoreGen habe ich mir auch eine Testbench generieren lassen. Ich möchte > nun an Port B einen Schreibzugriff simulieren und versteh nicht > wirklich, welche erzeugten Dateien ich dafür brauche. Dann gehen wir die Daten mal durch, ohne dass ich die Daten im Einzelnen jetzt im Zugriff habe: > BRAM_tb.vhd Das ist das Toplevelfile, in dem Fall eine Testbench > bmg_stim_gen.vhd > data_gen.vhd > random.vhd erzeugt wohl daten welche in das Ram hineingeschrieben werden > addr_gen.vhd Dürfte wohl ein Adresszaehler sein > checker.vhd Checkt die Daten auf Korrektheit > bmg_tb_pkg.vhd Ein Hilfspaket, mit routinen oder Konstanten welche von der TB oder den drei anderen Modulen genutzt werden. > BRAM_synth.vhd Die eigntliche Beschreibung zum BRAM. > 2 Ordner: > functional > timing Timing ist für Dich erstmal komplett ohne Bedeutung. Simuliert wird erst mal auf funktioneller Basis. So um selbst einen Schreibzugriff auf ein Dual Port Block Ram zu simulieren, muß man erst einmal wissen wie das Ding funktioniert: 1) Die BlockRams sind voll synchrone Rams, d.h. Lesen und Schreiben ist mit dem (jeweiligen Takt synchronisiert). 2) Das RAM hat je nach verwendeter Bauteilfamilie einen oder mehrere Writeenables: Kleine Stolperfalle am Rande, auch wenn nur ein WE vorhanden oder gewünscht ist, ist der entsprechende Eingang ein STD_LOGIC_VECTOR wenn auch ggfls. nur ein Bit breit (0 DOWNTO 0). Sprich um einen Schreibzugriff zu machen müssen Adressen,Daten und WE gesetzt werden und eine steigende Flanke am CLK anliegen. Das wars. Lesezugriff: Daten, Adresse, WE=> (others => '0') und steigende flanke Clock, nach einer weiteren Clockflanke stehen die Daten zur Weiterverarbeitung zur Verfügung... > Wie gehe ich nun vor, um einen Schreibzugriff zu simulieren? > > > > Vielen Dank im Voraus.
Angehängte Dateien:
-
Testbench.png
30 KB
Nochmals vielen Dank an Vanilla, für die ausführliche Antwort und die Engelsgeduld :) Ich habe inzwischen meine eigene Testbench für den BRAM geschrieben, in der ich in einer Schleife über Port A den gesamten Speicher beschreibe und über eine weitere Schleife den Speicherinhalt wieder über Port B auslese. (Schon mal ein riesen Fortschritt) :) Wie ich in den BRAM schreibe und lese ist mir bekannt, nur hab ich eines noch nicht ganz verstanden: Bei der Simulation ist mir aufgefallen, dass obwohl ich über Port A schreibe d.h wea[0:0]="1" ist, jeweils einen Takt versetzt, das 8 bit Wort am selben Port (doutA[7:0]) wieder herausbekomme. Hast du da vll eine Ahnung warum?(Hoffe die Frage ist jetzt nicht zu dumm^^) Vielen Dank Gruß, Werner
Das ist normal, schließlich gibt es ja kein Read Enable. Und in welcher Art das passiert, kann man normalerweise beim BlockRAM einstellen. Da gibt es Write First, Read First oder No Change. Lies mal den Block RAM User Guide.
Ich habe (ebenfalls bei einem Spartan 6 !) gerade ein ähnliches Problem in der Mache: Daten, die ins Ram geschrieben werden, sind transparent aüf den Ausgang, bowohl sie dort nicht sein dürften, da eine andere Adresse ausgelesen wird. Dort hängt sich entweder der Simulator, oder die Synthes auf! Ich beobachte das nämlich real in ChipsScope!
Werner Motz schrieb: > Bei der Simulation ist mir aufgefallen, dass obwohl ich über Port A > schreibe d.h wea[0:0]="1" ist, jeweils einen Takt versetzt, das 8 bit > Wort am selben Port (doutA[7:0]) wieder herausbekomme. > Hast du da vll eine Ahnung warum?(Hoffe die Frage ist jetzt nicht zu > dumm^^) (Supa)chris hat schon geschrieben, dass das eine Eigenheit der BRAMS ist, sprich es wird immer gelesen, auch wenn Daten geschrieben werden. Ob du als Ergebnis das alte oder bereits neue Datum erhällst, lässt sich im BRAM einstellen. Achtung: Sollten im DualPort Ram Betrieb die selbe Adresse geschrieben und zur gleichen Zeit gelesen werden, dann die Erratas von Xilinx genau beachten! Noch zu beachten: In deiner Simulation ist schön zu sehen, dass die Daten aus dem Ram ein paar hundert ps nach der steigenden Clockflanke herauskommen. Ansonsten sehen wir ja nur ideale Timings der funktionalen Simulation. Wenn man jetzt zeitlich heraus zoomt, dann kann man das schnell vergessen und fragt sich warum die Schaltung nicht wie erwartet tut, die Daten stehen ja "vermeintlich" einen Takt früher an... @Dipl.-Ing. (Gast) > bowohl sie dort nicht sein dürften, da eine andere Adresse ausgelesen wird. Du schreibst ein Datum auf eine Adresse, und Du bekommst einen Takt später den Inhalt genau der Adresse aus dem Schreibzugriff am DOUT wieder raus. Ob das geschriebene oder das alte Datum wird bei der BRAM Synthese festgelegt. Wieso dürfen die Daten da nicht sein? Ich hätte eher ein Problem wenn dem nicht so wäre...
Vanilla schrieb: >> bowohl sie dort nicht sein dürften, da eine andere Adresse ausgelesen wird. Das ist wirklich seltsam. Auf der gleichen Adresse muss das sein, aber so? Ist da vielleicht der BRAM Bug vom Spartan 6 im Spiel?
Christian R. schrieb: > Vanilla schrieb: >>> bowohl sie dort nicht sein dürften, da eine andere Adresse ausgelesen wird. > > Das ist wirklich seltsam. Auf der gleichen Adresse muss das sein, aber > so? Ist da vielleicht der BRAM Bug vom Spartan 6 im Spiel? Ich denke hier hat der Orginalposter hat hier nur die Latenz nicht im Kalkuel gehabt. In Richtung BRAM Bug im Spartan kenn ich nur den Bug bezueglich der Initialisierung von BRAM9 konfigurierten BRAMS.
Angehängte Dateien:
-
PortAB.png
21 KB
Hallo, nochmals vielen Dank für die vielen Antworten. Sie haben mir sehr weiter geholfen. Leider hab ich schon wieder ein anderes Problem: Nachdem ich im ISE mit dem Core Generator einen True Dual Port RAM erzeugt und simuliert habe, habe ich meine User-Logic in VHDL geschrieben und simuliert. Anschließend hab ich beides in ein Schematic gepackt (miteinander verdrahtet) und wieder simuliert - alles ohne Probleme. (Kurzer Einschub: Ich möchte einen True Dual Port RAM realisieren, der über Port B mit einer User-Logic verbunden ist, die lediglich Daten in dan BRAM schreibt, über Port A holt sich der Microblaze, auf dem ein LwIP Stack läuft, über einen BRAM Controller, die Daten. Siehe Bild) Jetzt habe ich versucht, das ganze ins EDK zu importieren. Hat auch alles fehlerfrei funktioniert. Beim verdrahten aber nun mit dem BRAM Controller liegt mein Problem. Die Vektoren der Adressleitungen (Controller zu BRAM)stimmen nicht überein. Mein BRAM verfügt über einen Datenausgang von (7 downto 0), der Controller unterstützt jedoch nur (0 to 31)!! Gut, habe anschließend mit dem Core Generator einen neuen BRAM konfiguriert und Little Endian bzw. Big Endian berücksichtigt. Der neue, wieder ins EDK importierte BRAM, lässt sich aber trotzdem nicht mit den Pins des Controllers verbinden, obwohl die Vektoren alle dieselbe Formatierung besitzen. Woran kann das liegen? Wie soll ich vorgehen? Controller und BRAM im EDK erstellen und das System anschließend ins ISE importieren und als Top-Model meine User-Logic verwenden? Kann mir vll jemand helfen, der schon einmal einen BRAM mit seiner User-Logic zusammen gebracht hat? Vielen Dank. Gruß, Werner
Werner Motz schrieb: > (Controller zu BRAM)stimmen nicht überein. Mein BRAM verfügt über einen > Datenausgang von > (7 downto 0), der Controller unterstützt jedoch nur (0 to 31)!! > Wie soll ich vorgehen? Controller und BRAM im EDK erstellen und das > System anschließend ins ISE importieren und als Top-Model meine > User-Logic verwenden? > Kann mir vll jemand helfen, der schon einmal einen BRAM mit seiner > User-Logic zusammen gebracht hat? Freut mich dass Du schon etwas weiter gekommen bist. Ich habe eigentlich immer ein EDK Projekt innerhalb der ISE aufgebaut, ist aber wohl Ansichtssache. Ich meine mich erinnern zu können, dass innerhalb der EDK Vectoren 0 to xx, anstatt xx downto 0 nummeriert wurde... Gruß Andreas
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.