3 puntos por GN⁺ 2023-11-05 | 1 comentarios | Compartir por WhatsApp
  • 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

  • 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

 
GN⁺ 2023-11-05
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.

    • Difícil verlo como un producto nuevo al azar. Xilinx MicroBlaze es una tecnología de más de 20 años y fue uno de los primeros softcores “reales” desarrollados para FPGA.
      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...

    • Ese usuario de Reddit tiene karma -5. Y en una situación en la que implementar desde cero un núcleo RISC-V simple toma apenas unos días, la idea casi no tiene sentido.
      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.
    • Es correcto decir que, para los proveedores de FPGA, un softcore es un producto gancho. Estas tecnologías habilitadoras no ganan dinero por sí mismas, así que en las empresas de hardware no se las trata como algo valioso.
      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?

    • Otros grandes fabricantes de FPGA ya empezaron hace años a ofrecer núcleos RISC-V con soporte oficial como alternativa a sus núcleos con conjuntos de instrucciones propietarios.
      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.
    • MicroBlaze era un núcleo ubicado en la escala de conteo de compuertas que RISC-V está invadiendo activamente.
      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.
    • Antes, SiFive tenía un núcleo RV32 que podía entrar en un Artix-7, pero era bastante básico.
      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.
    • Xilinx es un fabricante de FPGA bastante grande, y MicroBlaze ofrece bastante bien funciones de tolerancia a fallas, incluido TMR.
      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.
    • Puede funcionar como microcontrolador y también como CPU en tiempo real.
      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.

    • La clave son las herramientas y el soporte. No quieres ponerte a trastear con un softcore RISC-V por tu cuenta; solo quieres que funcione y que ya esté bien conectado con las cosas que realmente te importan.
      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

    • Sí. MicroBlaze es el nombre de una arquitectura que pertenece a AMD y, según el artículo, este core es compatible con ella

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

    • La interfaz vista desde HDL es la misma. En cambio, del lado del software, es el conjunto de instrucciones RISC-V, que está creciendo rápido hasta convertirse en el ecosistema más fuerte
      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
    • Este es el nuevo Xilinx MicroBlaze. Pasó de un conjunto de instrucciones parecido a AVR a RV32
    • ¿No se refieren a esa arquitectura MicroBlaze que AMD pasó a poseer mediante la adquisición de Xilinx?
    • Aun así, es mejor que sea MicroBlaze V en vez de usarlo sin sufijo
  • ¿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?

    • Probablemente no, pero AMD dijo que se puede usar gratis en cualquier FPGA de AMD(Xilinx)
      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
    • Puede que no tenga una licencia open source, pero el código fuente del core MicroBlaze anterior venía incluido en el kit de desarrollo y estaba ligeramente ofuscado
      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?

  • 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

    • No es un “primer paso”. Ya es uno de varios pasos
      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