Hallo zusammen. Ich habe einen MicroBlaze, daran habe ich den LMB mit BRAM. Und zusätzlich möchte ich den LMB auch für eigene Hardware nutzen. Also habe ich im BlockDesign noch einen hinzugefügt und den auf extern gesetzt. Funktioniert auch soweit, ich habe ausserhalb des BlockDesigns einen ILA dran und sehe die Schreib- und Lesezugriffe auf Adresse 0x01000004. Aber eigentlich gehören da ja noch weitere Signale dazu, bei Lesen das ready und auch die ce, rst, ue, waitsig. Die bekomme ich nicht, weil etwas nicht passt. Und zwar die Adresse (siehe Bildchen). Gibt es eine Möglichkeit diesem externen LMB einen Addressspace zuzuweisen? Ich weiß, es gibt ein paar Workarounds: - AXI verwenden - Das IOModule und davon den IO BUS verwenden - Eine eigene Komponente im BlockDesign packagen mit LMB und Addressspace Will ich eigentlich vermeiden und gerne direkt mit dem LMB ins Toplevel und von dort an meine eigenen Komponenten. Hier wurde das auch gefragt und anscheinend eine Lösung gefunden, aber nicht mitgeteilt: https://adaptivesupport.amd.com/s/question/0D54U00007twJbtSAE/how-to-package-a-users-local-memory-bus-interface-design-to-ip-creation-for-lmb-qualified-as-shown-in-the-attached-image-?language=en_US Vielen Dank!
Angehängte Dateien:
-
LMB_bd.png
45 KB -
LMB_address.png
65 KB -
LMB_ila.png
21 KB
Wer hätte es gedacht, das funktioniert einfach so. Schreiben und Lesen. Ich bin begeistert!
Komisch, das mit dem Lesen geht irgendwie nicht immer. Aber gut, der uC kennt auch den Adressbereich nicht und ob dieser LMB Block da zwischen den Slaves umschaltet oder so ist leider nicht dokumentiert. Ich sehe an dem externen Port aber auch alle Zugriffe die zum anderen Port und dem BRAM gehen. Zumindest teilweise. Schade eigentlich.
Beitrag #7797789 wurde vom Autor gelöscht.
Mit den Bussen beim Xilinx schlagen wir uns auch herum. Je mehr do dort dranhängst, desto schlimmer wird es. Mehr als 3 Teilnehmer sind eigentlich nicht zu erlauben.
Rolf S. schrieb: > Mit den Bussen beim Xilinx schlagen wir uns auch herum. Je mehr do dort > dranhängst, desto schlimmer wird es. Mehr als 3 Teilnehmer sind > eigentlich nicht zu erlauben. geht es um LMB bus? Auf AXI bus kann man viele slaves haben ohne probleme!
Gustl B. schrieb: > Wer hätte es gedacht, das funktioniert einfach so. Schreiben und Lesen. > Ich bin begeistert! Wenn du mit AXI nichts machen willst und mit LMB nicht geht kannst eine AVALON bus core machen, das ist viel einfacher als AXI slave. Den musst du aber in IP Packager packen und da musst du address bereich definieren, dann geht es mit AXI-Avalon IP core von AMD sehr gut. Ich habe jetzt eigenen HyperRAM IP core was Avalon bus hat, läuft sehr gut mit Vivado!
Angehängte Dateien:
-
LMB_read_16.png
24 KB
Irgendwie passt was mit den Reads noch nicht ganz. Obwohl das auf dem ILA OK aussieht. Ich verwende sowohl für LMB als auch IOBUS vom IO Module (natürlich nicht Beide gleichzeitig) die Funktionen Xil_Out32 und Xil_In32. Ein Read an 0x0100_0010 sieht so aus wie im Bildchen. So habe ich das aktuell. Und gelesen werden sollte der Wert 0x0000FEDC. Ist das korrekt wie ich das Ready setze? Muss das schon zeitgleich mit dem Read_Strobe runter gehen (einen Takt früher)? Wie muss ich mit dem Wait umgehen, das verwende ich aktuell nicht. Und dann gibt es ja das Byte Enable. Das ist aber nur ein Output vom Master. Wenn also die Lesedaten gültig sind und das Ready wieder oben ist, dann steht da nicht mehr ein F sondern eben der für die laufende Transaktion passende Wert. Muss ich da mit einem Wait dafür sorgen, dass nicht weitergemacht wird in der Zwischenzeit? Edit: Was ich schon rausgefunden habe ist, dass der Read Bus nicht dauerhaft gesetz werden darf. Also für einen Takt setzen und sonst Hochohmig ist wohl OK, aber die Lesedaten stehen lassen bis zum nächsten Lesezugriff macht, dass der uBlaze nichtmehr weiterläuft. Seltsam eigentlich weil da soch extra der Block dazwischen ist der zwischen den beiden LMBs unterscheiden könnte.
:
Bearbeitet durch User
Angehängte Dateien:
-
bd_lmb_ila.png
92 KB
Sehr witzig dieses Xilinx, jetzt hab ich im BlockDesign einen ILA direkt an den DLMB angeschlossen und zack meldet Vivado Fehler bezüglich Adressen. [BD 41-1075] Cannot assign slave segment '/lmb_bram_d/SLMB/Mem' into address space '/microblaze_0/Data' at address '0x0000_0000 [ 128K ]'. Master segment '/microblaze_0/Data/SEG_lmb_bram_d_Mem' is invalid. The proposed address '0x0000_0000 [ 128K ]' cannot be assigned through an incomplete addressing path. Erkennt das einen LMB nur dann als verbunden wenn man das mit dem einzelnen Signal/Linie im Blockdesign macht und nicht, wenn man die Signale einzeln verbindet?
:
Bearbeitet durch User
Angehängte Dateien:
-
LMB_signals_port.png
27 KB -
LMB_signals_external.png
20 KB
Auch seltsam, an Block haben viele/meherer Ports die Breite 2. Aber am externen Signal/Bus haben die dann eine Range 0 to 0. Kann mir das Jemand erklären? Aktuell habe ich extern dann auch nur 1 Bit angeschlossen und da läuft die Synthese durch.
Kann es sein, dass die LMB Zugriffe irgendwie gecached werden? Ich habe den uBlaze ohne Cache konfiguriert, aber ich habe das komische Verhalten, dass Schreibzugriffe funktionieren, die kann ich in meinem VHDL auswerten. Lesezugriffe liefern (immer?) das zurück was zuletzt an diese Adresse geschrieben wurde. Auch wenn ich im VHDL den ReadDBus auf einen anderen Wert gelegt habe. Ich werde mich jetzt von der Idee des LMB verabschieden. Ohne da einen Adressbereich angeben zu können wird der zweite/externe Bus vermutlich nie beim Lesen angeguckt/ausgewertet.
Ich verwende aktuell Xil_Out32 und Xil_In32. Aber Lesen scheint weder mit dem IO Bus vom IOmodule noch mit dem LMB zu funktionieren. Muss man mit dem IOmodule die Funktionen XIOModule_IoWriteWord() und XIOModule_IoReadWord() verwenden und wenn ja, wieso? Edith meint:
1 | u32 XIOModule_IoReadWord(XIOModule *InstancePtr, u32 ByteOffset) |
2 | {
|
3 | Xil_AssertNonvoid(InstancePtr != NULL); |
4 | Xil_AssertNonvoid(InstancePtr->IsReady == XIL_COMPONENT_IS_READY); |
5 | |
6 | return XIomodule_In32((InstancePtr->IoBaseAddress + ByteOffset)); |
7 | } |
und
1 | #define XIomodule_In32 Xil_In32 |
:
Bearbeitet durch User
So, ich habe aus dem BlockDesign das VHDL vom IO-Module herausgefriemelt und simuliert. Dieses Modul unterscheidet zwischen Zugriffen auf die internen Register und auf den IO Bus. Und auch wenn man auf den IO Bus zugreift kommt gleich im nächsten Takt ein Ready Strobe auf dem LMB. Aber das Wait geht hoch und erst am Ende vom IO Bus Zugriff geht das Wait runter und es kommt ein zweiter - dann gültiger - Ready Strobe auf dem LMB. Aber ... nur wenn die Adressmasken passen. Und das tun sie nur, wenn man beim IO Module die Adressmasken enweder selber händisch in der GUI setzt (auch die für den Registerbereich!), oder beide Adressbereiche in der Adressmap behält. Wenn man den Register Adressbereich excludiert weil man ja nur den Adressbereich für den IO Bus haben will, dann geht auch der IO Bus nicht. Und dann habe ich es leider nicht geschafft direkt am externen LMB meine IP ranzubasteln. Schreiben funktioniert, aber Lesen nicht weil dieser LMB nie ausgewertet wird.
:
Bearbeitet durch User
> Ich werde mich jetzt von der Idee des LMB verabschieden. das ist vielleicht eine gute idee :) Ohne da einen > Adressbereich angeben zu können wird der zweite/externe Bus vermutlich > nie beim Lesen angeguckt/ausgewertet. du must die eigene VHDL code als IP Core packen, und bei IP Integrator einen address bereich definieren, dann erkennt Vivado das und mann kann "assign address" machen
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.