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.
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.
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...
