Hallo Zusammen, mein letzter Kontakt mit dem MicroBlaze ist schon eine Weile her, damals noch mit XPS und ISE. Vivado ist bisher für mich noch Neuland und ich muss mich noch etwas orientieren. Ich muss gestehen, dass ich schon damals kein Freund des von Xilinx aufgezwungenen Designflows war, bei dem das Prozessorsystem der Ausgangspunkt des Designs ist, und man sich seine Custom IPs ebenfalls im XPS erzeugt und dann mit Leben füllt. Bei Vivado scheint mir die Philiosphie mit dem Block-Design nochmal mehr in diese Richtung zu gehen. Das mag OK sein, wenn man sich dauerhaft auf Xilinx festlegen will und alles vom Scratch neu macht. Wenn es schon einen Haufen eigener IPS gibt, die angebunden werden sollen, finde ich den Ansatz unschön. Ich habe lieber den Prozessor als abgeschlossenen Block, mit den entsprechenden Schnittstellen zu meinen Modulen und das Top-Level komplett selbst in der Hand. So kann ich das Design auch besser auf andere Plattformen portieren. Außerdem kann ich so ein Kern-Prozessorsystem in unterschiedlichen Designs verwenden, die eine identische Grundstruktur haben und sich nur in der Peripherie und der Software leicht unterscheiden. Kann mir jemand sagen, ob Vivado diesen Ansatz unterstützt, ohne dass man irgendwelche Verrenkungen machen muss?
Philip schrieb: > Kann mir jemand sagen, ob Vivado diesen Ansatz unterstützt, ohne dass > man irgendwelche Verrenkungen machen muss? Ja, Vivado unterstützt beide Ansätze. Du kannst Dir zu einem (Prozessor-)Block einen Wrapper generieren lassen und den bindest Du dort ein, wo Du es für richtig erachtest. Das geht auch mit dem ARM-Prozessor auf den Zynq-FPGAs. Umgekehrt kannst Du Dir aus Deiner Logik einen Block erzeugen lassen und diesen dann an einen Microblaze oder ARM anstückeln, als so wie früher. Duke
Philip schrieb: > Ich habe lieber den Prozessor als abgeschlossenen Block, mit den > entsprechenden Schnittstellen zu meinen Modulen und das Top-Level > komplett selbst in der Hand. > > Kann mir jemand sagen, ob Vivado diesen Ansatz unterstützt, ohne dass > man irgendwelche Verrenkungen machen muss? Kommt auf des device/µC-Core an: *bei Zynq/Zybo haste wegen dem multi stage bootkonzeptes des SoC keine Chance verrenkungsfrei zu arbeiten. *Nimmste den Vivado-µBlaze aus dem Block-view hast das Problem, daste dessen Bussystem mit nehmen musst und dan wohl auch deine eigene IP umstricken musst. *Du kannst natürlich versuchen den µBlaze Block aus den ISE - Coregen ( Xilinx Microblaze MCS Workflow ) zu verwenden, den soll es auch im Vivado geben: https://www.xilinx.com/products/design-tools/mb-mcs.html
Duke Scarring schrieb: > Ja, Vivado unterstützt beide Ansätze. Du kannst Dir zu einem > (Prozessor-)Block einen Wrapper generieren lassen und den bindest Du > dort ein, wo Du es für richtig erachtest. Ist das dann ein separates Vivado Projekt? Fpgakuechle K. schrieb: > *Nimmste den Vivado-µBlaze aus dem Block-view hast das Problem, daste > dessen Bussystem mit nehmen musst und dan wohl auch deine eigene IP > umstricken musst. Ich würde dafür einen IP implementieren, der mir AXI-Lite Zugriffe auf ein einfaches generisches Registerinterface abbildet, das ich an meine vorhandenen Blöcke anschließe. Das bringt mich zu meiner nächsten Frage - ich habe gerade mal versucht einen IP zu bauen, aber mir ist nicht klar, wie ich eigene Ports hinzufüge.
Philip schrieb: > Duke Scarring schrieb: >> Ja, Vivado unterstützt beide Ansätze. Du kannst Dir zu einem >> (Prozessor-)Block einen Wrapper generieren lassen und den bindest Du >> dort ein, wo Du es für richtig erachtest. > Ist das dann ein separates Vivado Projekt? Nein, das nennt sich in Vivado-Sprache "Block Design". Das ist aber so eine Art Projekt-im-Projekt. Genauso wie die eigenen IP-Cores. Philip schrieb: > ich habe gerade mal versucht > einen IP zu bauen, aber mir ist nicht klar, wie ich eigene Ports > hinzufüge. Klick Dich mal durch das UG1119-Tutorial: https://www.xilinx.com/support/documentation/sw_manuals/xilinx2018_1/ug1119-vivado-creating-packaging-ip-tutorial.pdf Duke
Philip schrieb: > Das bringt mich zu meiner nächsten Frage - Mich würde besonders die übernächste Frage interessieren, Wie klinge ich die richtigen BRAM's in die Software-toolchain ein? (Vorausgesetzt der Core hat seinen gesamten Arbeitsspeicher in BRAM's intern.) Und am besten so, das man nicht bei jeder Softwäreänderung alles synthetisieren muß, sondern nur den bitstream an den BRAM-stellen patched. Da hatte ich persönlich so meine Kämpfe mit mit der Xilinx-software, das in einem script und nicht per ISE-GUI zu machen.
Duke Scarring schrieb: > Klick Dich mal durch das UG1119-Tutorial: > https://www.xilinx.com/support/documentation/sw_manuals/xilinx2018_1/ug1119-vivado-creating-packaging-ip-tutorial.pdf Da finde ich leider nicht wirklich eine Antwort auf meine Frage. Aber hier habe ich was gefunden, wie die Änderungen im VHDL File in die Blockansicht komme: https://forums.xilinx.com/t5/Design-Entry/Add-ports-to-IP-in-IP-packager/td-p/657787 Aber in dem Projekt, in das ich den IP einbinde tauchen die hinzugefügten Ports immer noch nicht auf... Fpgakuechle K. schrieb: > Mich würde besonders die übernächste Frage interessieren, > Wie klinge ich die richtigen BRAM's in die Software-toolchain ein? > (Vorausgesetzt der Core hat seinen gesamten Arbeitsspeicher in BRAM's > intern.) Und am besten so, das man nicht bei jeder Softwäreänderung > alles synthetisieren muß, sondern nur den bitstream an den BRAM-stellen > patched. > > Da hatte ich persönlich so meine Kämpfe mit mit der Xilinx-software, das > in einem script und nicht per ISE-GUI zu machen. Ja, daran kann ich mich auch noch erinnern, dafür hatte ich ein extra Script mit einem data2mem Aufruf.
Fpgakuechle K. schrieb: > Mich würde besonders die übernächste Frage interessieren, > Wie klinge ich die richtigen BRAM's in die Software-toolchain ein? > (Vorausgesetzt der Core hat seinen gesamten Arbeitsspeicher in BRAM's > intern.) Und am besten so, das man nicht bei jeder Softwäreänderung > alles synthetisieren muß, sondern nur den bitstream an den BRAM-stellen > patched. (Ich hoffe ich hab die Frage richtig interpretiert.) Das geht im SDK. Da waehlst du das Bitfile aus und dann wird der BRAM Inhalt des Bitfiles mit dem Software Binary ueberschrieben. Siehe hier z.B.: https://wiki.trenz-electronic.de/display/TEUSB/Download+the+bitstream+and+the+elf+file Das ELF File muss natuerlich in den BRAM passen. Falls nicht, muss man sich einen Bootloader schreiben, der die Daten z.B. vom SPI Flash nachlaedt. Auf der Kommandozeile ist updatemem das entsprechende Tool. UG898 hat dazu ein Kapitel. Updatemem ist der Vivdao Nachfolger von data2mem.
:
Bearbeitet durch User
Philip schrieb: > Kann mir jemand sagen, ob Vivado diesen Ansatz unterstützt, ohne dass > man irgendwelche Verrenkungen machen muss? Exakt das wurde diese Woche im Meeting diskutiert. Das Ergebnis: "SO WENIG BLOCKDESIGN, WIE MÖGLICH". Es wird also nur der MicroBlaze mit Umgebung genutzt, Ankoppelung an das RAM und Flash, damit das Zeug läuft. Dann kommen AXI-"normal Bus"-Konverter an die Ausgänge des designs und das wird als wrapper überall instanziiert. Andere Blockdesigns werden auch autark gehandhabt, z.B. die DDR-IP und die Transceiver-IOs mit AXI-Ankoppelung. Das topdesign ist immer vhdl.
@Herbert Das ist ja genau der Ansatz, den ich will. Wie spielt Ihr denn die Software ein?
Wer etwas Ketzerei mag und aus der Vivado-Bloatware raus will: Aus der MyHDL-Ecke gibt es Hilfstools wie Ovenbird und Kea, mit denen man sich einen deutlich effizienteren Flow aufbauen kann. Laeuft dann auch auf anderen Architekturen oder laesst sich legal in die CI-Cloud stecken. Fuer SoC, die zwingend den AXI-Overhead erfordern, der eigene IPcore aber nicht den Bus als 'Master' bedienen muss, wuerde ich grundsaetzlich immer vermeiden, zuviele AXI-Interfaces zu instanzieren (also, Methode 'Herbert' nutzen). Fuer einen ueberschaubar vollen Memory-Mapper-Register-Space ist das meist Kanonen auf Spatzen. Und Vivado hilft nicht bei der Registerdokumentation...
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.