Introducing the AMD MicroBlaze™ V processor, a new soft-core RISC-V processor based on the RISC-V instruction set architecture (ISA). The MicroBlaze V processor is designed to be highly modular with a configurable architecture suitable for embedded systems applications. The MicroBlaze V processor is hardware compatible with the MicroBlaze processor and fully integrated in the Vivado™ and Vitis™ tools design flow.
A. F. schrieb: > Introducing the AMD MicroBlaze™ V processor, a new soft-core RISC-V > processor based on the RISC-V instruction set architecture (ISA). The > MicroBlaze V processor is designed to be highly modular with a > configurable architecture suitable for embedded systems applications. > The MicroBlaze V processor is hardware compatible with the MicroBlaze > processor and fully integrated in the Vivado™ and Vitis™ tools design > flow. https://www.xilinx.com/products/design-tools/microblaze-v.html ist aber nur eine variante da, und die auch nur EA zugang nicht für alle. Aber schon interessant das jetzt alle FPGA hersteller RISC-V machen!
> Aber schon interessant das jetzt alle FPGA hersteller RISC-V machen!
Anscheinend ist interesse an AMD RISC-V hier gleich null ;)
Viel mehr Infos gibt es auch zu Zeit nicht, in EA Lounge sind immer noch
nur die gleichen zwei documente von 18.10.2023 drin, nichts neues.
Microblaze-V scheint wirklich ein "drop-in replacement" für Classic-MB
sein,
alle interfaces sind die gleichen: AXI, LMB, streaming links (mit custom
instruction) alles da.
Ich muss sagen für mich ist eigentlich wichtig die frage ob der
classic-MB für immer bleibt oder irgendwann weg geht. Es wäre viel
Arbeit alle classic-MB Projekte auf MicroBlaze-V umzustellen.
YAMM - yet another marketing message. Spannender waere: - Im Source verfuegbar, ohne idiotische Verschluesselung oder hardcodierte Primitiven? - Resourcenbedarf an Beispielkonfigs (i/c/m)? - Wie konfigurierbar? Die Zeiten sind IMHO etwas passé, um sich an Hersteller mit volatilen Businessplaenen (was die Tools angeht) zu ketten, auch wenn sich C-Code typischerweise gut portieren laesst.
Martin S. schrieb: > YAMM - yet another marketing message. > Spannender waere: > - Im Source verfuegbar, ohne idiotische Verschluesselung oder > hardcodierte Primitiven? Wird sicherlich NICHT in quellcode da sein, da kann man sicher sein :( > - Resourcenbedarf an Beispielkonfigs (i/c/m)? ja da fehlen die infos komplett, ich nehme an kleinste Konfiguration wird nicht viel grösser sein als Classic Microblaze, aber den MCS wird es womöglich nicht geben (aber man weiss es nicht, vielleicht doch). > - Wie konfigurierbar? wird glaube relativ ähnlich sein wir wie bei Classic MB, die parameter die man ändern kann sind im EA access manual aufgelistet. > Die Zeiten sind IMHO etwas passé, um sich an Hersteller mit volatilen > Businessplaenen (was die Tools angeht) zu ketten, auch wenn sich C-Code > typischerweise gut portieren laesst.
Antti L. schrieb: > Martin S. schrieb: >> YAMM - yet another marketing message. >> Spannender waere: >> - Im Source verfuegbar, ohne idiotische Verschluesselung oder >> hardcodierte Primitiven? > > Wird sicherlich NICHT in quellcode da sein, da kann man sicher sein :( Zumindest für den PicoBlaze wurde menschenlesbares VHDL erzeugt. Ich habe sogar mal einen modifiziert und die Register von RAMS auf einzelne Flipflops umgebaut. Die RAMs waren Fenster ins configuration ram, aber wir mussten aus Strahlungsgründen das conf ram alle Minuten neu laden, bis etwa 1 Clock vor dem globalen Reset. Die Ladelogik war im gleichen FPGA in 3fach redundanter Ausführung mit voting... Das war so, wie wenn man den Teppich unter seinen Füßen austauscht, ohne zu stolpern oder runterzugehen. Der ganze Chip lief einfach weiter. Annti Lu, ich glaube, wir kennen uns von $GANZ_FRÜHER. usenet? Gerhard
:
Bearbeitet durch User
Gerhard H. schrieb: > Zumindest für den PicoBlaze wurde menschenlesbares VHDL erzeugt. Bezieht sich das auf die Funktion des Prozessors selber, oder auf das was darauf laufen sollte? Ließe sich (Fall 1) diese VHDL auf jeden beliebigen FPGA portieren?
Bernd schrieb: > Ließe sich (Fall 1) diese VHDL auf jeden > beliebigen FPGA portieren? Microblaze und picoblaze machen ausgiebig Gebrauch von harten Primitiven und sind so im ausgelieferten "Source" nur mit ausgiebiger Hackbereitschaft portabel - sprich, wer sich den Schuh anzieht, die Primitiven zu emulieren alias per yosys-Tricks fuer andere Architekturen zu konvertieren. Macht nur einfach keinen Sinn, wenn man portable und unabhängig verifizierte Prozessor-IPkerne an der Hand hat.
Zuhause im stillen Kämmerlein hann man das durchaus machen, aber die Lizenzbedingungen sagen halt, dass *Blaze nur für Xilinx Chips erlaubt sind. Zumindest für den Picoblaze gibt es keinen C-Compiler, und aus freien Stücken würde ich mir den PB nicht antun wollen. Bei uns war's halt ein alter. aber raumfahrttauglicher Virtex. Da war's schon schlimm genug, dass wir die Lötvor- schriften für die aktuellen Space-Virtexe nicht bekommen haben, und die redundancy tools von Xilinx sowieso nicht. Und das für Kram für die ISS. Meine TripleModuleRedundancy lib ist sowieso besser :-) Man läuft da manchmal auf Klippen, die hätte man nie erwartet. Gerhard
:
Bearbeitet durch User
Bernie schrieb: > Gerhard H. schrieb: >> Zumindest für den PicoBlaze wurde menschenlesbares VHDL erzeugt. > > Bezieht sich das auf die Funktion des Prozessors selber, oder auf das > was darauf laufen sollte? Ließe sich (Fall 1) diese VHDL auf jeden > beliebigen FPGA portieren? Die Hardware des Prozessors. Portabel wäre das im Prinzip wohl schon, aber nicht interessant, schon aufgrund der Lizenz.
Early access lounge ist jetzt aktiv, man kann da patch runterladen. https://account.amd.com/en/forms/registration/microblazev-tools-ea.html in 2024.1 wird es integriert sein.
:
Bearbeitet durch User
MCS für Microblaze V sollte auch kommen, ist aber bei EA noch nicht dabei.
Martin S. schrieb: > YAMM - yet another marketing message. > Spannender waere: > - Im Source verfuegbar, ohne idiotische Verschluesselung oder > hardcodierte Primitiven? > - Resourcenbedarf an Beispielkonfigs (i/c/m)? es sind 5 preset Konfigs konfigurierbar * Microcontroller Preset * Real-time Preset * RV32IMC * RV32IMAC * RV32IMACFC Resources: Mit debug und AXI UARTLITE: 1818 LUT Ohne debug und AXI UARTLITE: 1409 LUT Es scheint das Microblaze V ohne debug ist etwa so gross wie MB classic mit debug. > - Wie konfigurierbar? > haupt Optionen sind: * preset * optimization * enable/disable cache dann gibt es 6 Seiten von Advanced settings wo man es finetunen kann. Was ist nicht klar ob MDM-V auch den MDM-UART hat oder nicht, auswählen kann man es auf jeden fall nicht.
Mich würde aus technischer Sicht einige Beispiele interessieren, wo es wirklich lohnt, solche CPUs in programmierbarer Logik zu verbuddeln. Mir ist das nie klar. Warum nicht einfach einen wo ein Controller schon drin ist?
Martin K. schrieb: > Warum nicht einfach einen wo ein Controller schon drin > ist? Wieviele FPGA-Devices kennst Du, wo schon ein Controller drin ist?
Rick D. schrieb: > Martin K. schrieb: >> Warum nicht einfach einen wo ein Controller schon drin >> ist? > Wieviele FPGA-Devices kennst Du, wo schon ein Controller drin ist? es gibt schon mehr als eine mit hard CPU Altera Efinix Gowin Rapidsemi - (WENN die kommen)
xilinx mit PowerPC in recht frühen Virtexen. Ich kann mich dran erinnern, wie Peter Alfke auf einem X-Fest in Berlin geklagt hat, dass sie die Lizenz von (WIMRE) Motorola hatten und nicht direkt von IBM. Oder der ARM im Zync in meinem RedPitaya. Und in einem zeitgenösischem Virtex macht ein Microblaze auch nur ein kleines Eckchen aus und man hat dann auch im nächsten Projekt die gewohnte entlauste Infrastruktur.
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.