- AMD MicroBlaze V es una IP de procesador softcore RISC-V para usar dentro de los AMD adaptive SoC y FPGA, integrada en los flujos de diseño de Vivado y Vitis
- Mantiene la compatibilidad de hardware con diseños MicroBlaze existentes, mientras apunta a la portabilidad de software basada en la ISA RISC-V y al aprovechamiento del ecosistema open source
- Se puede configurar con los conjuntos base de instrucciones RV32I y RV64I, y permite elegir las extensiones M/A/F/C y las extensiones de manipulación de bits ZBa, ZBB, ZBc, ZBs
- Ofrece configuraciones predefinidas desde microcontroladores hasta procesadores de aplicaciones, e incluye 4 opciones de pipeline y funciones de seguridad como dual-core lockstep y TMR
- Puede apuntar a cualquier dispositivo AMD adaptive SoC o FPGA compatible con Vivado Design Suite sin costo adicional, aunque RV64I y la Memory Protection Unit están en Early Access y la Memory Management Unit sigue en la hoja de ruta
Procesador soft RISC-V para AMD adaptive SoC y FPGA
- AMD MicroBlaze V es una IP de procesador softcore RISC-V para AMD adaptive SoC y FPGA
- Está basado en la arquitectura de conjunto de instrucciones RISC-V (ISA) y ofrece una arquitectura configurable de forma modular para adaptarse a aplicaciones de sistemas embebidos
- Los desarrolladores pueden apuntar MicroBlaze V a dispositivos AMD adaptive SoC o FPGA compatibles con Vivado Design Suite sin costo adicional
- RISC-V es una ISA estándar open source administrada por la organización sin fines de lucro RISC-V Foundation, y AMD es miembro desde 2020
Configuración de la ISA RISC-V y portabilidad
- MicroBlaze V se basa en una ISA open source respaldada por un ecosistema de software y soluciones de toda la industria
- Su objetivo de diseño es facilitar la migración de hardware desde diseños existentes de procesadores MicroBlaze y mejorar la portabilidad de software de los diseños RISC-V
- Alcance del soporte ISA configurable:
- RV32I y RV64I Base Integer Instruction Set
- Extensión M para multiplicación y división
- Extensión A para instrucciones atómicas
- Extensión F para punto flotante
- Extensión C para compresión de código
- Extensiones ZBa, ZBB, ZBc, ZBs para manipulación de bits
- La compresión de código se usa para reducir el tamaño del código y ahorrar memoria en el diseño
Arquitectura, rendimiento y funciones de seguridad
- Se pueden elegir configuraciones predefinidas adaptadas a distintos rangos de aplicación, desde microcontroladores hasta procesadores de aplicaciones
- Ofrece 4 opciones de pipeline para optimizar área o rendimiento
- También incluye medidas de seguridad opcionales para sistemas críticos
-
Dual-core lockstep
- Triple modular redundancy(TMR)
-
Flujo de diseño basado en Vivado y Vitis, y periféricos
- MicroBlaze V ofrece un flujo de diseño integrado con Vivado Design Suite y Vitis software tools
- Es compatible con todos los AMD adaptive SoC y FPGA soportados por las herramientas de diseño Vivado
- Puede usarse desde la interfaz gráfica de usuario (GUI) y la interfaz de línea de comandos (CLI)
- Con IP optimizada, se puede colocar un subsistema de procesador MicroBlaze V integrado dentro de la lógica programable, con el objetivo de reducir la cantidad de componentes del sistema y el tiempo de desarrollo
- Principales categorías de periféricos que se pueden agregar con arrastrar y soltar:
- 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
Configuraciones de ejemplo, documentación y estado de soporte
- Hay dos configuraciones de diseño de ejemplo: MicroBlaze V Microcontroller y MicroBlaze V with Memory Protection Unit
-
Configuración MicroBlaze V Microcontroller
- 32-bit Processor Core RV32IMAFC
- JTAG Debug Interface
- Tightly Coupled Local Memory
- SPI controller, I2C Controller, UART
- Interrupt Controller, Timer, GPIO
-
Configuración MicroBlaze V with Memory Protection Unit
- Todos los bloques predefinidos de Microcontroller
- Instruction Cache
-
Memory Protection Unit
- Data Cache
- Memory Controller
-
Documentación y recursos de soporte
- MicroBlaze V Processor Quick Start Guide: guía para crear un sistema básico del procesador AMD MicroBlaze V usando diseños predefinidos del procesador
- MicroBlaze V Processor Reference Guide: ofrece información sobre los procesadores soft MicroBlaze V de 32 bits y 64 bits incluidos en AMD Vivado Design Suite
- MicroBlaze Debug Module V Product Guide: proporciona la especificación de diseño del core MDM V, que permite depurar por JTAG uno o más procesadores MicroBlaze V
- Webinar: Getting Started with Zephyr® RTOS on the AMD MicroBlaze™ V Processor: cubre la configuración de Zephyr, su ajuste y la compilación de aplicaciones dirigidas a MicroBlaze V
- Documentation: colección de guías de usuario y guías de producto de MicroBlaze V
- Wiki: trata la flexibilidad para elegir la combinación necesaria de periféricos, memoria e interfaces
-
Estado de soporte
- La configuración Microcontroller está disponible como Production
- AMD MicroBlaze V con RV64I y Memory Protection Unit está en Early Access
- AMD MicroBlaze V con Memory Management Unit está en la hoja de ruta
1 comentarios
Opiniones en Hacker News
Puede resultar confuso si no recuerdas que AMD adquirió Xilinx recientemente.
Es muy probable que en adelante veamos más productos nuevos de Xilinx con el nombre de AMD.
El equivalente del lado de Intel sería Altera NIOS II.
Según un comentario en Reddit [1], esto sería como poner un decodificador de instrucciones RISC-V al frente del RTL de MicroBlaze existente.
Desde la perspectiva de “hagamos el mejor núcleo RISC-V”, no parece tener sentido, pero ese nunca fue realmente el objetivo de Xilinx/AMD.
MicroBlaze era un buen ejemplo de una CPU RISC secuencial y aburrida para nichos aburridos, y para los proveedores de FPGA un softcore es medio producto gancho. Ayuda a vender silicio, pero no genera dinero por sí solo. No es la parte del FPGA que determina el rendimiento, sino una tecnología más cercana al “pegamento de integración”, así que con que sea “suficientemente buena” alcanza.
Si AMD realmente reutiliza el RTL de MicroBlaze, puede mantener el firmware existente (núcleo, FPU, depuración, periféricos, etc.) y el software (HAL, compilador, drivers). Es muy atractivo tanto para el proveedor como para los usuarios que quieren migrar al nuevo núcleo MicroBlaze sin dolor.
1: https://old.reddit.com/r/FPGA/comments/17mdcyt/microblaze_go...
No me apoyaría en esa información.
Dicho eso, sí tiene las mismas interfaces externas que el MicroBlaze existente, así que desde el punto de vista del hardware es un reemplazo que puede insertarse tal cual en diseños existentes.
Por eso los CEO multimillonarios de Xilinx y Altera sacuden la cabeza con tristeza cuando escuchan que Jensen Huang sigue metiendo dinero en el stack de software de Nvidia. Algún día aprenderán dónde está el verdadero valor.
¿Alguien puede explicar qué tan importante es este anuncio para RISC-V?
Claro que también se usan muchos núcleos de terceros de GitHub, pero que estén integrados y soportados oficialmente en el IDE y las herramientas significa mucho para muchos clientes.
MicroSemi ofrece softcores RISC-V desde 2017 y, desde fines de 2020, también ofrece núcleos duros como los de PolarFire SoC. Por ejemplo, las nuevas BeagleBoard Fire, Icicle, etc.
Lattice anunció su primer softcore RISC-V oficial alrededor de junio de 2020, anunció una colaboración con SiFive en diciembre de 2019 y, a mediados de 2021, lanzó mejoras como un núcleo de 800 LUT.
Intel introdujo Nios V en octubre de 2021.
Cosas como Tensilica y ARC también perdieron mucho valor agregado en este segmento. Hablando como alguien que ha porteado un kernel directamente a MicroBlaze, es un RISC clásico con pipeline, en el rango de unas 20 mil compuertas, más o menos entre MIPS y SH4.
Lo más interesante de este anuncio es que AMD/Xilinx se metió tan de lleno que llegó a redefinir el propio término registrado “MicroBlaze”, en lugar de crear un nombre nuevo y seguir manteniendo las actualizaciones del MicroBlaze existente.
La E/S era despareja y ni siquiera podía usar la DRAM integrada en la placa. Sería genial ver un softcore RV32 con soporte oficial en Artix-7.
En el pasado usé MicroBlaze con resultados bastante decentes, pero era tan cerrado que no pensaba usarlo fuera de pruebas o educación. No soy un fanático acérrimo de RISC-V, pero encaja bien en este tipo de área. Es como decir: “te damos herramientas que usan un conjunto de instrucciones en el que quizá ya invertiste, y no vamos a intentar atarte también a esa toolchain”.
Que AMD/Xilinx te ate por debajo del conjunto de instrucciones es aceptable hasta cierto punto. Al fin y al cabo, es muy probable que de todos modos tengas que pagar el hardware, ya sea comprando el FPGA o alguna pieza de catálogo que quizá aparezca algún día.
TMR en sí no es algo nuevo en RISC-V, pero significa que muchos proyectos que ya usan MicroBlaze, y otros que quieren usar MicroBlaze, ahora podrán usar RISC-V.
RISC-V ya es bastante popular en ese mercado.
Me pregunto cuáles serían los casos de uso de MicroBlaze V comparado, por ejemplo, con SERV https://serv.readthedocs.io/en/latest/servant.html
Es decir, aparte de la aprobación oficial del fabricante del chip, la única ventaja que parece ofrecer MicroBlaze V es la velocidad. ¿No se suelen usar las CPU en FPGA para tareas que no son tan sensibles al tiempo? Entiendo que la idea es que las tareas rápidas y sensibles al tiempo las maneje el fabric del FPGA junto con las interfaces de E/S en chip.
MicroBlaze te permite literalmente armar tu propio softcore eligiendo y arrastrando y soltando distintas opciones de configuración y periféricos. También incluye un SDK para la aplicación de usuario y herramientas de depuración para encontrar la causa de los problemas.
Si desarrollas con SERV, no me sorprendería que el desarrollo tome varios órdenes de magnitud más de tiempo solo por la menor madurez de las herramientas.
Está bien que salga un nuevo softcore, pero me pregunto si hacía falta ensuciar más el espacio de nombres
MicroBlaze ya es el nombre de una arquitectura que alguien podría buscar
Podrían haberlo llamado simplemente algo como AMDcoreV
Solo hay que recompilar y, esta vez, se pueden usar herramientas estándar de la industria y confiables como gcc, binutils y llvm, sin tener que lidiar con herramientas pobres, propietarias, hechas a medida y de baja calidad
¿Incluye algo equivalente al PSP o al ME? Ya estoy harto de esas sospechosas CPU de caja negra, inseguras e imposibles de parchear
¿El core en sí es open source?
Si hubiera que pagar regalías, no me interesaría este anuncio, porque hay alternativas gratuitas
Se puede asumir que este core está bien optimizado para usar eficientemente los recursos de las FPGA de Xilinx, y probablemente esa sea su ventaja frente a las alternativas
Ni siquiera habían eliminado los comentarios del código fuente
Sería bueno tener una vista general que compare de un vistazo estos softcores RISC-V
Cosas como si son open source, qué puntaje tienen en CoreMark, qué tamaño ocupan, etc.
neorv, serv, vexrisc, nios v, microblaze v, etc.
¿Hay algún kit de desarrollo con el que se pueda probar esto? ¿Cómo se empieza?
Como es un diseño FPGA de Xilinx, lo lógico es empezar con una placa de desarrollo de Xilinx
https://www.xilinx.com/products/boards-and-kits/cost-optimiz...
Si lo único que necesitas es un softcore RISC-V, también hay muchas opciones fuera del ecosistema Xilinx. Personalmente prefiero placas con buen soporte de yosys/nextpnr
0. https://www.joelw.id.au/FPGA/CheapFPGADevelopmentBoards
Este es un primer paso y es una buena señal
Aunque me habría gustado que fuera un core de 64 bits en vez de uno de 32 bits. Porque si escribes rutas de código en ensamblador RISC-V de 64 bits, realmente puedes reutilizarlas en escritorio, servidores y sistemas embebidos
Si quieres un core de 64 bits, probablemente no perteneces al mercado objetivo
Tampoco es realista reutilizar ensamblador RISC-V de 64 bits en escritorio, servidores y embebidos. Escritorio y servidores son prácticamente solo de 64 bits, y la mayoría de los embebidos usan cores de 32 bits, así que no hay mucha superposición
Además de la diferencia entre 32 y 64 bits, el entorno de programación también cambia mucho: la complejidad del sistema, el proceso de arranque, la forma de interactuar con el exterior, etc.
En resumen, hay que elegir el dispositivo objetivo y programar para él. Si quieres mover el código fácilmente entre distintos tipos de dispositivos, lo correcto es escribirlo en otro lenguaje, no en ensamblador