AMD MicroBlaze V Prozessor: flexibler RISC-V-Softcore für FPGAs

 (xilinx.com)
3 Punkte von GN⁺ 2023-11-05 | 1 Kommentare | Auf WhatsApp teilen
  • AMD MicroBlaze V ist eine Softcore-RISC-V-Prozessor-IP für AMD adaptive SoCs und FPGAs, integriert in die Design-Flows von Vivado und Vitis
  • Ziel ist es, die Hardware-Kompatibilität bestehender MicroBlaze-Designs beizubehalten und zugleich Software-Portabilität auf Basis der RISC-V-ISA sowie das Open-Source-Ökosystem zu nutzen
  • Die Basis-Befehlssätze RV32I und RV64I sind konfigurierbar; M/A/F/C-Erweiterungen sowie die Bitmanipulations-Erweiterungen ZBa, ZBB, ZBc, ZBs können optional gewählt werden
  • Es gibt Preset-Konfigurationen vom Mikrocontroller bis zum Applikationsprozessor, dazu vier Pipeline-Optionen und Sicherheitsfunktionen wie Dual-Core-Lockstep und TMR
  • Der Prozessor kann ohne zusätzliche Kosten auf alle von der Vivado Design Suite unterstützten AMD adaptive SoCs oder FPGA-Geräte ausgerichtet werden; RV64I und Memory Protection Unit sind jedoch im Early Access, die Memory Management Unit steht auf der Roadmap

RISC-V-Softprozessor für AMD adaptive SoCs und FPGAs

  • AMD MicroBlaze V ist eine Softcore-RISC-V-Prozessor-IP für AMD adaptive SoCs und FPGAs
  • Er basiert auf der RISC-V Instruction Set Architecture (ISA) und bietet eine modular konfigurierbare Architektur für Embedded-System-Anwendungen
  • Entwickler können MicroBlaze V ohne zusätzliche Kosten auf AMD adaptive SoCs oder FPGA-Geräte ausrichten, die von der Vivado Design Suite unterstützt werden
  • RISC-V ist eine Open-Source-Standard-ISA, die von der gemeinnützigen RISC-V Foundation verwaltet wird; AMD ist seit 2020 Mitglied

RISC-V-ISA-Konfiguration und Portabilität

  • MicroBlaze V basiert auf einer Open-Source-ISA, die von einem branchenweiten Ökosystem aus Software und Lösungen unterstützt wird
  • Ziel des Designs ist es, die Hardware-Migration bestehender MicroBlaze-Prozessordesigns zu erleichtern und die Software-Portabilität von RISC-V-Designs zu erhöhen
  • Umfang der konfigurierbaren ISA-Unterstützung:
    • RV32I und RV64I Base Integer Instruction Set
    • M-Erweiterung für Multiplikation und Division
    • A-Erweiterung für atomare Befehle
    • F-Erweiterung für Gleitkomma
    • C-Erweiterung für Code-Kompression
    • ZBa-, ZBB-, ZBc- und ZBs-Erweiterungen für Bitmanipulation
  • Die Code-Kompression wird genutzt, um die Codegröße zu reduzieren und Designspeicher zu sparen

Architektur, Leistung und Sicherheitsfunktionen

  • Für verschiedene Anwendungsbereiche, vom Mikrocontroller bis zum Applikationsprozessor, stehen Preset-Konfigurationen zur Auswahl
  • Zur Optimierung von Fläche oder Leistung werden vier Pipeline-Optionen angeboten
  • Optionale Sicherheitsmechanismen für sicherheitskritische Systeme sind ebenfalls enthalten

    • Dual-Core-Lockstep

      • Triple Modular Redundancy (TMR)

Design-Flow auf Basis von Vivado und Vitis sowie Peripherie

  • MicroBlaze V bietet einen Design-Flow, der in die Vivado Design Suite und die Vitis software tools integriert ist
  • Er ist mit allen AMD adaptive SoCs und FPGAs kompatibel, die von den Vivado-Design-Tools unterstützt werden
  • Er kann über eine grafische Benutzeroberfläche (GUI) und eine Kommandozeilenschnittstelle (CLI) verwendet werden
  • Mithilfe optimierter IP lässt sich ein integriertes MicroBlaze-V-Prozessor-Subsystem in programmierbarer Logik platzieren; Ziel ist es, die Zahl der Systemkomponenten und die Entwicklungszeit zu reduzieren
  • Wichtige Peripheriekategorien, die per Drag-and-drop hinzugefügt werden können:
    • General Purpose: Multichannel DMA, Streaming FIFO, Timer / Watchdog, Mutex / Mailbox
    • I/O: UART, USB 2.0, SPI, GPIO, PWM
    • Video: HDMI Camera/Display Interface, MIPI-CSI, MIPI-DSI, Video DMA
    • Memory: DDR, Quad SPI, SDRAM
    • Networking: Ethernet Subsystem, Controller Area Network

Beispielkonfigurationen, Dokumentation und Support-Status

  • Als beispielhafte Designkonfigurationen gibt es MicroBlaze V Microcontroller und MicroBlaze V with Memory Protection Unit

  • MicroBlaze V Microcontroller-Konfiguration

    • 32-bit Processor Core RV32IMAFC
    • JTAG Debug Interface
    • Tightly Coupled Local Memory
    • SPI controller, I2C Controller, UART
    • Interrupt Controller, Timer, GPIO

  • MicroBlaze V with Memory Protection Unit-Konfiguration

    • Alle Microcontroller Preset Blocks
    • Instruction Cache

    • Memory Protection Unit

      • Data Cache
      • Memory Controller

  • Support-Dokumentation und Ressourcen

  • Support-Status

    • Die Microcontroller configuration wird als Production bereitgestellt
    • AMD MicroBlaze V mit RV64I und Memory Protection Unit ist im Early Access
    • AMD MicroBlaze V mit Memory Management Unit steht auf der Roadmap

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-11-05
Hacker-News-Kommentare

  • Das kann verwirrend sein, wenn man nicht im Kopf hat, dass AMD vor Kurzem Xilinx übernommen hat.
    Künftig dürfte es häufiger vorkommen, dass neue Xilinx-Produkte den Namen AMD tragen.

    • Es ist kaum als irgendein zufälliges neues Produkt zu sehen. Xilinx MicroBlaze ist über 20 Jahre alte Technik und war einer der frühen „echten“ Softcores für FPGAs.
      Das Gegenstück bei Intel wäre ungefähr Altera NIOS II.

  • Laut einem Reddit-Kommentar [1] ist das im Grunde so, als hätte man vor das bestehende MicroBlaze-RTL einen RISC-V-Befehlsdecoder gesetzt.
    Aus der Perspektive „Lasst uns den besten RISC-V-Core bauen“ wirkt das unsinnig, aber das war nie das eigentliche Ziel von Xilinx/AMD.
    MicroBlaze war ein gutes Beispiel für eine langweilige, sequentiell arbeitende RISC-CPU für eine langweilige Nische, und für FPGA-Anbieter sind Softcores ein halbes Lockangebot. Sie helfen beim Verkauf von Silizium, verdienen aber für sich genommen kein Geld. Es ist eher eine Technik für „integrierten Klebstoff“ als ein Bereich des FPGA, der die Leistung bestimmt, daher reicht „gut genug“ völlig aus.
    Wenn AMD tatsächlich das MicroBlaze-RTL wiederverwendet, kann es bestehende Firmware (Core, FPU, Debug, Peripherie usw.) und Software (HAL, Compiler, Treiber) beibehalten. Das ist sowohl aus Sicht des Anbieters als auch für Nutzer, die ohne Schmerzen auf einen neuen MicroBlaze-Core wechseln wollen, sehr attraktiv.
    1: https://old.reddit.com/r/FPGA/comments/17mdcyt/microblaze_go...

    • Dieser Reddit-Nutzer hat Karma -5. Und in einer Situation, in der man einen einfachen RISC-V-Core in wenigen Tagen von Grund auf implementieren kann, ergibt die Idee fast keinen Sinn.
      Ich würde mich nicht auf diese Information verlassen.
      Allerdings hat er dieselben externen Schnittstellen wie der bestehende MicroBlaze und ist damit aus Hardwaresicht ein Drop-in-Ersatz für vorhandene Designs.
    • Dass Softcores für FPGA-Anbieter ein Lockangebot sind, trifft zu. Solche Enabling-Technologien bringen für sich genommen kein Geld ein und werden deshalb in Hardware-Unternehmen nicht als wertvoll angesehen.
      Deshalb schütteln die milliardenschweren CEOs von Xilinx und Altera bedauernd den Kopf, wenn sie hören, wie Jensen Huang weiter Geld in den Nvidia-Software-Stack pumpt. Irgendwann werden sie schon lernen, wo der echte Wert liegt.

  • Kann jemand erklären, wie wichtig diese Ankündigung für RISC-V ist?

    • Andere große FPGA-Hersteller haben bereits vor einigen Jahren begonnen, offiziell unterstützte RISC-V-Cores als Alternative zu ihren proprietären Befehlssatz-Cores anzubieten.
      Natürlich werden auch viele Third-Party-Cores von GitHub genutzt, aber offizielle Integration und Unterstützung in IDE und Tools ist für viele Kunden wichtig.
      MicroSemi bietet seit 2017 einen RISC-V-Softcore an und seit Ende 2020 auch Hardcores wie den PolarFire SoC. Beispiele sind das neue BeagleBoard Fire, Icicle usw.
      Lattice kündigte etwa im Juni 2020 seinen ersten offiziellen RISC-V-Softcore an, hatte bereits im Dezember 2019 eine Zusammenarbeit mit SiFive bekannt gegeben und brachte Mitte 2021 auch verbesserte Varianten wie einen 800-LUT-Core heraus.
      Intel führte im Oktober 2021 Nios V ein.
    • MicroBlaze war ein Core in einer Gate-Count-Klasse, in die RISC-V aktiv eindringt.
      Auch Tensilica, ARC und ähnliche haben in diesem Bereich viel Mehrwert verloren. Aus Sicht von jemandem, der selbst einmal einen Kernel auf MicroBlaze portiert hat, ist es ungefähr eine klassische Pipeline-RISC im Bereich von 20.000 Gates, irgendwo zwischen MIPS und SH4.
      Der interessanteste Teil dieser Ankündigung ist, dass AMD/Xilinx so tief eingestiegen ist, dass man den markenbehafteten Begriff „MicroBlaze“ selbst neu definiert, statt einen neuen Namen zu erfinden und einfach weiterhin Updates für den bestehenden MicroBlaze zu unterstützen.
    • Früher hatte SiFive einen RV32-Core, der in ein Artix-7 passte, aber er war recht rudimentär.
      Das I/O war uneinheitlich, und das auf dem Board vorhandene DRAM ließ sich ebenfalls nicht nutzen. Es wäre cool, einen offiziell unterstützten RV32-Softcore auf Artix-7 zu sehen.
      Ich habe MicroBlaze früher ganz ordentlich genutzt, aber weil es so geschlossen war, hätte ich nie daran gedacht, es außerhalb von Tests oder Ausbildung einzusetzen. Ich bin kein fanatischer RISC-V-Befürworter, aber für solche Bereiche passt es gut. Es folgt eher dem Prinzip: „Wir geben dir Werkzeuge für einen Befehlssatz, in den du vielleicht schon investiert hast, und versuchen dich nicht zusätzlich an dessen Toolchain zu ketten.“
      Dass AMD/Xilinx einen unterhalb des Befehlssatzes festhält, ist bis zu einem gewissen Grad akzeptabel. Die Hardwarekosten muss man wahrscheinlich ohnehin tragen, egal ob man ein FPGA kauft oder ein Katalogbauteil, das vielleicht irgendwann einmal erscheint.
    • Xilinx ist ein ziemlich großer FPGA-Hersteller, und MicroBlaze bietet recht gute Fehlertoleranzfunktionen einschließlich TMR.
      TMR selbst ist bei RISC-V nichts Neues, aber es bedeutet, dass viele bestehende Projekte mit MicroBlaze und neue Projekte, die MicroBlaze einsetzen wollen, nun RISC-V verwenden können.
    • Es kann zugleich Mikrocontroller und Echtzeit-CPU sein.
      RISC-V ist in diesem Markt bereits ziemlich populär.

  • Mich würde interessieren, wie sich die Einsatzgebiete von MicroBlaze V zum Beispiel im Vergleich zu SERV https://serv.readthedocs.io/en/latest/servant.html darstellen.
    Anders gesagt scheint der einzige wirkliche Vorteil von MicroBlaze V gegenüber der offiziellen Freigabe durch den Chip-Hersteller die Geschwindigkeit zu sein. FPGA-CPUs werden doch meist nicht für zeitkritische Aufgaben eingesetzt, oder? Für schnelle, zeitkritische Aufgaben ist doch eher die FPGA-Fabric zusammen mit den On-Chip-I/O-Schnittstellen gedacht.

    • Entscheidend sind Tools und Support. Man will nicht selbst an einem RISC-V-Softcore herumspielen, sondern einfach, dass es funktioniert und sauber mit den Dingen verbunden ist, die einen tatsächlich interessieren.
      Mit MicroBlaze kann man aus einer Vielzahl von Konfigurationsoptionen und Peripherie auswählen und per Drag-and-drop buchstäblich seinen eigenen Softcore zusammenstellen. Dazu kommen ein SDK für Benutzeranwendungen und Debugging-Werkzeuge, um Ursachen von Problemen zu finden.
      Wenn man mit SERV entwickelt, wäre es nicht überraschend, wenn die Entwicklungszeit allein wegen der geringeren Reife der Tools um mehrere Größenordnungen länger ausfällt.

  • Es ist zwar gut, dass ein neuer Softcore erscheint, aber ich frage mich, ob man dafür unbedingt den Namensraum verschmutzen musste.
    MicroBlaze ist bereits der Name einer Architektur, nach der jemand suchen könnte.
    Man hätte es auch einfach AMDcoreV oder so nennen können.

    • Stimmt. MicroBlaze ist ein Architekturname, der AMD gehört, und laut Artikel ist dieser Core damit kompatibel.

      It allows developers to leverage the open-source RISC-V software ecosystem, is hardware compatible with the classic MicroBlaze processor

    • Die Schnittstelle aus Sicht des HDL ist dieselbe. Auf der Software-Seite handelt es sich dagegen um den RISC-V-Befehlssatz, dessen Ökosystem gerade sehr schnell zum stärksten heranwächst.
      Man muss nur neu kompilieren und kann diesmal verlässliche Industriestandard-Tools wie gcc, binutils und llvm verwenden, statt sich mit schwachen, proprietären und maßgeschneiderten Werkzeugen geringer Qualität herumzuschlagen.
    • Das ist der neue Xilinx MicroBlaze. Er wechselt von einem AVR-ähnlichen Befehlssatz zu RV32.
    • Du meinst doch die MicroBlaze-Architektur, die AMD durch die Übernahme von Xilinx besitzt, oder?
    • Trotzdem ist MicroBlaze V besser, als es einfach ohne Suffix zu verwenden.

  • Ist da etwas wie die PSP oder die ME eingebaut? Ich habe diese unsicheren und nicht patchbaren verdächtigen Blackbox-CPUs langsam satt.

  • Ist der Core selbst Open Source?

    • Wahrscheinlich nicht, aber AMD hat gesagt, dass er auf jedem AMD-(Xilinx-)FPGA kostenlos verwendet werden kann.
      Wenn man dafür Nutzungsgebühren zahlen müsste, würde mich diese Ankündigung nicht interessieren, weil es kostenlose Alternativen gibt.
      Man kann wohl davon ausgehen, dass dieser Core gut darauf optimiert ist, die Ressourcen von Xilinx-FPGAs effizient zu nutzen, und dass das gegenüber den Alternativen sein Vorteil sein dürfte.
    • Vielleicht steht er nicht unter einer Open-Source-Lizenz, aber der Quellcode des früheren MicroBlaze-Cores war in den Development Kits enthalten und nur schwach obfuskiert.
      Es wurden nicht einmal die Quellcode-Kommentare entfernt.

  • Es wäre schön, eine Übersicht zu haben, die diese RISC-V-Softcores auf einen Blick vergleicht,
    also ob sie Open Source sind, wie hoch ihr CoreMark-Score ist, wie groß sie sind und so weiter.
    neorv, serv, vexrisc, nios v, microblaze v usw.

  • Gibt es ein Development Kit, mit dem man das ausprobieren kann? Wie fängt man an?

  • Das ist ein erster Schritt und ein gutes Zeichen.
    Allerdings hätte ich lieber einen 64-Bit-Core als einen 32-Bit-Core gesehen, weil man 64-Bit-RISC-V-Assembler-Codepfade dann auf Desktop, Server und Embedded tatsächlich wiederverwenden kann.

    • Ein „erster Schritt“ ist das nicht. Es ist nur einer von mehreren bereits gegangenen Schritten.
      Wenn du einen 64-Bit-Core willst, gehörst du wahrscheinlich nicht zum Zielmarkt.
      Außerdem ist die Vorstellung, 64-Bit-RISC-V-Assembler auf Desktop, Server und Embedded wiederzuverwenden, nicht realistisch. Desktop und Server sind faktisch auf 64 Bit festgelegt, während Embedded meist 32-Bit-Cores nutzt, sodass es nicht viele Überschneidungen gibt.
      Nicht nur 32 und 64 Bit unterscheiden sich, auch die Programmierumgebung ist sehr verschieden, etwa bei der Systemkomplexität, den Boot-Abläufen und der Art der Interaktion mit der Außenwelt.
      Kurz gesagt: Man muss das Zielgerät auswählen und passend dafür programmieren. Wenn man Code leicht zwischen verschiedenen Gerätetypen übertragen möchte, sollte man eher eine andere Sprache als Assembler verwenden.