RISCBoy - consola portátil de videojuegos de código abierto diseñada desde cero

 (github.com/Wren6991)
1 puntos por GN⁺ 4 시간 전 | 1 comentarios | Compartir por WhatsApp
  • RISCBoy es una consola portátil de videojuegos diseñada directamente desde una CPU compatible con RISC-V hasta la tubería gráfica, el controlador de pantalla, la infraestructura de memoria y periféricos, e incluso la PCB en KiCad
  • Apunta a ser una Game Boy Advance que podría haber existido si RISC-V hubiera existido en 2001, y está implementada como una consola de 32 bits sobre un FPGA iCE40-HX8k con 7,680 elementos lógicos, escrita en Verilog 2005 sintetizable
  • El procesador soporta el conjunto de instrucciones RV32IMC junto con CSR de M-mode, excepciones e interrupciones externas vectorizadas, y pasa las pruebas de conformidad de RISC-V y la verificación con riscv-formal
  • Para la síntesis usa la cadena de herramientas de código abierto Yosys·nextpnr·Project Icestorm, y también soporta configuraciones para placas ECP5 y una variante RV32I para el iCE40 UP5k más pequeño
  • La simulación y el entorno de desarrollo oficial están orientados principalmente a Linux, y tanto la PCB Rev B como el bootloader, el gateware y el árbol de software siguen en desarrollo

Consola portátil construida desde cero

  • El alcance del diseño público de RISCBoy incluye lo siguiente
    • CPU compatible con RISC-V
    • Tubería de gráficos rasterizados y controlador de pantalla
    • Infraestructura del chip como bus fabric, controlador de memoria, UART y GPIO
    • Diseño de PCB hecho en KiCad
  • El objetivo es una Game Boy Advance de un universo paralelo donde RISC-V existía en 2001, y el proyecto refleja el cariño por las consolas portátiles de la infancia y la tecnología que las hacía funcionar
  • Se puede consultar información de diseño más detallada en el documento doc/riscboy_doc.pdf del repositorio

Implementación en FPGA y procesador

  • El diseño está escrito en Verilog 2005 sintetizable y ajustado para el iCE40-HX8k, un FPGA basado en LUT4
    • El HX8k ofrece 7,680 elementos lógicos
    • Hizo falta un diseño cuidadoso para meter una consola de videojuegos de 32 bits en recursos limitados
  • El HX8k fue en su momento el FPGA más grande soportado por la cadena de herramientas de código abierto Project Icestorm, y después el ecosistema relacionado se amplió con Project Trellis y Project X-Ray
  • El procesador soporta el conjunto de instrucciones RV32IMC
    • Pasa las pruebas de conformidad de RISC-V para esas instrucciones
    • Pasa la suite de verificación riscv-formal
    • También aplica verificación formal propia de propiedades para comprobar la coherencia del frontend de instrucciones y el cumplimiento básico del bus
  • Soporta CSR y excepciones de M-mode, y además ofrece una extensión simple de cumplimiento para interrupciones externas vectorizadas

Clonado del repositorio y toolchain

  • Como usa submódulos de Git para el HDL y las pruebas, hay que clonar recursivamente así
git clone --recursive https://github.com/Wren6991/RISCBoy.git riscboy
  • Después de un clonado normal, los submódulos pueden inicializarse por separado
git clone https://github.com/Wren6991/RISCBoy.git riscboy
cd riscboy
git submodule update --init --recursive
  • La actualización recursiva de submódulos es necesaria para las pruebas independientes del procesador, pero no para el build del gateware de RISCBoy
  • Para compilar pruebas basadas en software, hay que construir RISC-V GNU Toolchain con configuración RV32IMC·ILP32
./configure --prefix=/opt/riscv \
  --with-arch=rv32imc \
  --with-abi=ilp32 \
  --with-multilib-generator="rv32i-ilp32--;rv32ic-ilp32--;rv32im-ilp32--;rv32imc-ilp32--"
  • En FPGA más pequeños como el iCE40 UP5k, se puede usar una variante de procesador RV32I más pequeña en lugar del RV32IMC de alto rendimiento
  • Aunque el compilador soporte varias variantes ISA de RISCBoy, se necesita configuración multilib para que se generen bibliotecas estándar adecuadas para cada variante
    • Ejecutar un binario RV32I enlazado con una biblioteca estándar RV32IMC en un procesador solo RV32I causará problemas

Simulación y pruebas

  • El flujo de simulación usa Xilinx ISIM 14.x y el Makefile del directorio scripts/
    • Solo se ha probado con la versión Linux de ISIM
    • Si ISIM está instalado fuera de la ruta predeterminada, puede ser necesario ajustar la ruta en sourceme
  • El proceso para ejecutar pruebas a nivel HDL es el siguiente
git submodule update --init --recursive
. sourceme
cd test
./runtests
  • Las pruebas de software requieren un toolchain RV32IC
  • Para depurar una prueba individual en entorno gráfico, se ejecuta directamente el Makefile correspondiente
cd system
make TEST=helloworld gui

Diseño de PCB

  • La PCB Rev A es compatible con el servicio de prototipado de 4 capas y 5×5 cm de iTead
    • Al momento de redactar el README, el costo era de 65 dólares por 10 placas
    • El esquema puede verse en board/fpgaboy.pdf dentro del repositorio
  • Se espera que la Rev B tenga una forma bastante distinta de la Rev A, y por ahora está a la espera de que el gateware y el bootloader maduren antes de avanzar
  • El hardware de desarrollo actual tiene una forma similar a la Snowflake FPGA board

Síntesis y placas soportadas

  • Para la síntesis FPGA sobre iCE40 usa la siguiente cadena de herramientas de código abierto
  • Estas herramientas solo se han verificado construyéndolas directamente en Linux; se dice que existen builds para Windows, pero no se han probado
  • También se puede compilar la toolchain en Raspberry Pi
  • La imagen FPGA para la placa de evaluación Lattice HX8k se genera con el siguiente comando
. sourceme
cd synth
make -f HX8k-EVN.mk bit
  • También ofrece soporte para ECP5 dirigido a la placa de evaluación Lattice LEF5UM5G-85F-EVN, aunque es una configuración altamente experimental y no la plataforma principal de desarrollo
make -f ECP5-EVN.mk BUILD=full bit
  • El build para ECP5 reemplaza la SRAM externa de 512 KiB y 16 bits del hardware de desarrollo por una memoria sincrónica interna de 256 KiB y 32 bits
    • Esta memoria es configurada por Trellis como bloques sysmem de ECP5

Estructura del repositorio

  • board: archivos de KiCad de la PCB principal de RISCBoy y de las placas pequeñas usadas durante el desarrollo
  • doc: código fuente LaTeX de la documentación, diagramas y el PDF compilado más reciente
  • hdl: código fuente Verilog del gateware de RISCBoy
    • busfabric: crossbar AHB-lite y fabric de periféricos APB
    • graphics: código fuente de la unidad de procesamiento de píxeles
    • hazard5: código fuente del procesador RISC-V construido de forma totalmente independiente
    • mem: controlador de memoria y wrappers/modelos de inferencia e inyección de memoria
    • peris: periféricos pequeños como UART, SPI y PWM
    • riscboy_core: módulo estructural que instancia y conecta los componentes de RISCBoy
    • riscboy_fpga: wrapper de nivel superior que conecta E/S, reloj y reset para varios FPGA y placas
  • reference: PDF de estándares usados en RISCBoy, como el conjunto de instrucciones RISC-V
  • scripts: scripts que no pertenecen a otros directorios
  • software: colección de archivos C usados en pruebas a nivel sistema; todavía no es un árbol de software práctico
  • synth: directorio de trabajo para la síntesis del sistema completo, con el Makefile superior y archivos de restricciones de pines
  • test: conjunto de pruebas de regresión que incluye testbenches Verilog y casos de prueba de software ejecutados en simulaciones del procesador o del sistema completo

Lecturas relacionadas

1 comentarios

 
GN⁺ 4 시간 전
Opiniones en Hacker News

  • En la página de GitHub lo presentan como un Game Boy Advance de un universo paralelo donde RISC-V existía en 2001.
    Describen el proyecto como una carta de amor a las consolas portátiles de la infancia y, a la vez, como un mensaje de texto borracho enviado a las 3 a. m. a la tecnología que las hacía funcionar.

  • Es obra de Luke Wren, quien es ingeniero de diseño ASIC en Raspberry Pi. Es un proyecto realmente genial.

    • Llamarlo simplemente ingeniero de diseño ASIC subestima su papel; también participa en el desarrollo de núcleos de CPU.

  • Este desarrollador también diseñó PicoDVI, que implementa DVI/HDMI con el RP2040.
    https://github.com/Wren6991/PicoDVI

    • Trabaja en Raspberry Pi y diseñó el núcleo RISC-V Hazard3, pieza central del RP2350. Sin embargo, Hazard3 lo desarrolló en su tiempo libre y es un proyecto derivado del núcleo Hazard5 que había diseñado para RISCBoy.

  • El GBA fue diseñado con una arquitectura sin caché. Salvo la RAM interna, la RAM de video, los registros de entrada/salida, la BIOS, OAM, las paletas y otros elementos similares, todos los accesos pasan por el bus externo; usar un bus externo sin caché lo vuelve, en la práctica, tan lento como una computadora de los años 80. La velocidad para traer instrucciones desde el cartucho apenas duplica aproximadamente la del GBC.
    Para evitarlo, habría que usar caché y traer varias palabras de forma secuencial. Si se acelera el acceso secuencial, aumenta el rendimiento, y si las instrucciones y los datos se almacenan lo suficiente en caché, se puede ocultar la latencia. Me da curiosidad si este sistema envía todas las lecturas al bus de memoria o si usa caché.

  • Este diseño tuvo tape-out en la primera corrida de producción de wafer.space (ver https://github.com/wafer-space/ws-run1), pero no he escuchado si realmente funcionó correctamente.

  • El pipeline de renderizado basado en un búfer de scanlines programable presentado en el PDF vale la pena leerlo si te interesa este tipo de tecnología.

  • Me encantan los proyectos que imaginan y construyen hardware de universos paralelos.

  • Me pregunto si el mayor obstáculo para adoptar esta nueva arquitectura de hardware es la tecnología en sí, o la ausencia del ecosistema de desarrolladores y la cadena de herramientas de software existentes.

    • Ambos son un problema. Depende de qué se quiera construir exactamente, pero en general el desarrollo de hardware es más difícil y más caro que el desarrollo de software.
      La falta de herramientas de software se puede superar, pero la ausencia de bibliotecas de juegos es una barrera mayor. Es especialmente difícil si no hay una forma muy sencilla de portar títulos existentes.

  • Me sorprende que se pueda usar una implementación AHB/APB de código abierto en el interior. Pensaba que era tecnología propietaria de ARM, así que nunca la estudié a fondo.

    • AMBA ha sido un estándar abierto desde hace muchísimo tiempo; tengo entendido que probablemente lo fue desde que se anunció por primera vez.

  • Creo que el desarrollador de este proyecto es uno de los mejores ingenieros de nuestra época. Esto por sí solo ya es genial, pero también diseñó el núcleo Hazard3 y el dispositivo QSPI del RP2350.
    En particular, ese dispositivo QSPI es el único dispositivo QSPI con mapeo de memoria que he encontrado hasta ahora que no he logrado hacer fallar ni colgar.

    • Coincido con la valoración sobre QSPI, y el RP2350 es un chip impresionante. Tiene innumerables usos y es como el destornillador sónico de las herramientas de hackeo de buses.