RISCBoy - une console de jeu portable open source conçue de zéro

 (github.com/Wren6991)
1 points par GN⁺ 4 시간 전 | 1 commentaires | Partager sur WhatsApp
  • RISCBoy est une console de jeu portable dont la conception a été réalisée en interne, depuis le CPU compatible RISC-V jusqu’au pipeline graphique, au contrôleur d’affichage, à l’infrastructure mémoire et périphériques, ainsi qu’au PCB KiCad
  • Elle vise ce qu’aurait pu être une Game Boy Advance si RISC-V avait existé en 2001, est écrite en Verilog 2005 synthétisable, et implémente une console 32 bits sur un FPGA iCE40-HX8k doté de 7 680 éléments logiques
  • Le processeur prend en charge le jeu d’instructions RV32IMC ainsi que les CSR M-mode, les exceptions et les interruptions externes vectorisées, et a passé les tests de conformité RISC-V ainsi que la vérification riscv-formal
  • La synthèse utilise la chaîne d’outils open source Yosys·nextpnr·Project Icestorm, et prend aussi en charge les cartes ECP5 ainsi qu’une configuration RV32I pour le plus petit iCE40 UP5k
  • La simulation et l’environnement de développement officiel visent principalement Linux, tandis que le PCB Rev B, le bootloader, le gateware et l’arborescence logicielle sont encore en cours de développement

Une console portable conçue de zéro

  • Le périmètre de conception publique de RISCBoy couvre les éléments suivants
    • CPU compatible RISC-V
    • pipeline graphique raster et contrôleur d’affichage
    • infrastructure sur puce incluant fabric de bus, contrôleurs mémoire, UART, GPIO, etc.
    • layout PCB réalisé avec KiCad
  • L’objectif est une Game Boy Advance d’un univers parallèle où RISC-V existait en 2001, un projet nourri par l’attachement de son auteur aux consoles portables de son enfance et aux technologies qui les faisaient fonctionner
  • Des informations de conception plus détaillées sont disponibles dans le document doc/riscboy_doc.pdf du dépôt

Implémentation FPGA et processeur

  • La conception est écrite en Verilog 2005 synthétisable et ciblée pour le iCE40-HX8k, un FPGA à base de LUT4
    • le HX8k fournit 7 680 éléments logiques
    • faire tenir une console de jeu 32 bits dans des ressources aussi limitées demande une conception soignée
  • Le HX8k fut un temps le plus grand FPGA pris en charge par la chaîne d’outils open source Project Icestorm ; l’écosystème associé s’est ensuite étendu avec Project Trellis et Project X-Ray
  • Le processeur prend en charge le jeu d’instructions RV32IMC
    • il a passé les tests de conformité RISC-V pour ces instructions
    • il a passé la suite de vérification riscv-formal
    • une vérification formelle maison est aussi appliquée pour contrôler la cohérence du frontend d’instructions et la conformité de base du bus
  • Il prend en charge les CSR et exceptions du M-mode, et propose également une simple extension de conformité pour les interruptions externes vectorisées

Clonage du dépôt et toolchain

  • Le HDL et les tests utilisent des sous-modules Git ; il faut donc cloner récursivement comme suit
git clone --recursive https://github.com/Wren6991/RISCBoy.git riscboy
  • Après un clonage classique, les sous-modules peuvent être initialisés séparément
git clone https://github.com/Wren6991/RISCBoy.git riscboy
cd riscboy
git submodule update --init --recursive
  • La mise à jour récursive des sous-modules est nécessaire pour les tests autonomes du processeur, mais pas pour la construction du gateware RISCBoy
  • Pour compiler les tests basés sur logiciel, il faut construire la RISC-V GNU Toolchain en configuration RV32IMC·ILP32
./configure --prefix=/opt/riscv \
  --with-arch=rv32imc \
  --with-abi=ilp32 \
  --with-multilib-generator="rv32i-ilp32--;rv32ic-ilp32--;rv32im-ilp32--;rv32imc-ilp32--"
  • Sur de petits FPGA comme le iCE40 UP5k, une variante de processeur RV32I plus compacte peut être utilisée à la place du RV32IMC haute performance
  • Même si le compilateur prend en charge plusieurs variantes ISA de RISCBoy, une configuration multilib est nécessaire pour générer les bibliothèques standard adaptées à chaque variante
    • exécuter un binaire RV32I lié à une bibliothèque standard RV32IMC sur un processeur RV32I uniquement provoquera des problèmes

Simulation et tests

  • Le flux de simulation utilise Xilinx ISIM 14.x et le Makefile du répertoire scripts/
    • testé uniquement avec la version Linux d’ISIM
    • si ISIM est installé hors du chemin par défaut, il peut être nécessaire d’ajuster le chemin dans sourceme
  • La procédure pour lancer les tests au niveau HDL est la suivante
git submodule update --init --recursive
. sourceme
cd test
./runtests
  • Les tests logiciels nécessitent une toolchain RV32IC
  • Pour déboguer un test individuel dans un environnement graphique, il faut exécuter directement le Makefile correspondant
cd system
make TEST=helloworld gui

Conception du PCB

  • Le PCB Rev A est compatible avec le service de prototypage 4 couches 5×5 cm d’iTead
    • au moment de la rédaction du README, le coût était de 65 dollars pour 10 cartes
    • le schéma peut être consulté dans board/fpgaboy.pdf du dépôt
  • La Rev B devrait adopter une forme sensiblement différente de la Rev A, et son avancement attend que le gateware et le bootloader aient davantage mûri
  • Le matériel de développement actuel est similaire à la Snowflake FPGA board

Synthèse et cartes prises en charge

  • La synthèse FPGA pour iCE40 utilise la chaîne d’outils open source suivante
  • Ces outils n’ont été construits et vérifiés directement que sous Linux ; des builds Windows sont réputés possibles mais n’ont pas été testés
  • Il est aussi possible de construire la toolchain sur Raspberry Pi
  • L’image FPGA pour la carte d’évaluation Lattice HX8k se génère avec la commande suivante
. sourceme
cd synth
make -f HX8k-EVN.mk bit
  • Une prise en charge ECP5 est également fournie pour la carte d’évaluation Lattice LEF5UM5G-85F-EVN, mais il s’agit d’une configuration très expérimentale et non de la plateforme de développement principale
make -f ECP5-EVN.mk BUILD=full bit
  • Le build ECP5 remplace la SRAM externe 512 KiB·16 bits du matériel de développement par une mémoire synchrone intégrée de 256 KiB·32 bits
    • cette mémoire est configurée par Trellis comme un bloc ECP5 sysmem

Structure du dépôt

  • board : fichiers KiCad du PCB principal RISCBoy et des petites cartes utilisées pendant le développement
  • doc : sources LaTeX de la documentation, schémas et dernier PDF compilé
  • hdl : sources Verilog du gateware RISCBoy
    • busfabric : crossbar AHB-lite et fabric de périphériques APB
    • graphics : sources de l’unité de traitement des pixels
    • hazard5 : sources du processeur RISC-V conçu de manière entièrement indépendante
    • mem : contrôleurs mémoire et wrappers/modèles d’inférence et d’injection mémoire
    • peris : petits périphériques comme UART, SPI, PWM
    • riscboy_core : module structurel qui instancie et relie les composants RISCBoy
    • riscboy_fpga : wrapper de plus haut niveau reliant les E/S, horloges et resets de plusieurs FPGA et cartes
  • reference : PDF de standards utilisés par RISCBoy, dont le jeu d’instructions RISC-V
  • scripts : scripts n’appartenant à aucun autre répertoire
  • software : ensemble de fichiers C utilisés pour les tests au niveau système, pas encore une arborescence logicielle réellement exploitable
  • synth : répertoire de travail pour la synthèse du système complet, avec Makefile de haut niveau et fichiers de contraintes de broches
  • test : ensemble de tests de régression comprenant des testbenches Verilog et des cas de test logiciel exécutés dans des simulations du processeur ou du système complet

À lire aussi

1 commentaires

 
GN⁺ 4 시간 전
Commentaires sur Hacker News

  • La page GitHub le présente comme un Game Boy Advance d’un univers parallèle où RISC-V existait en 2001
    Le projet est décrit comme une lettre d’amour aux consoles portables de l’enfance, et comme un SMS envoyé à 3 heures du matin en état d’ivresse à la technologie qui les faisait tourner

  • C’est le travail de Luke Wren, ingénieur en conception ASIC chez Raspberry Pi. Un projet vraiment impressionnant

    • Le qualifier simplement d’ingénieur en conception ASIC sous-estime son rôle, puisqu’il participe aussi au développement de cœurs CPU

  • Ce développeur a aussi conçu PicoDVI, qui implémente le DVI/HDMI avec le RP2040
    https://github.com/Wren6991/PicoDVI

    • En travaillant chez Raspberry Pi, il a conçu le cœur RISC-V Hazard3, au cœur du RP2350. Cependant, Hazard3 a été développé sur son temps libre et provient d’une bifurcation du cœur Hazard5, conçu pour RISCBoy

  • Le GBA a été conçu avec une architecture sans cache. Hormis la RAM interne, la VRAM, les registres d’E/S, le BIOS, l’OAM, la palette, etc., tous les accès passent par le bus externe, et utiliser un bus externe sans cache le ramène pratiquement aux performances d’un ordinateur des années 1980. La vitesse de récupération des instructions depuis la cartouche n’est qu’environ deux fois supérieure à celle de la GBC
    Pour éviter cela, il faut utiliser un cache pour précharger plusieurs mots de façon séquentielle. Accélérer les accès séquentiels augmente le débit, et si les instructions et les données sont suffisamment mises en cache, la latence peut être masquée. Je me demande si ce système envoie tous les fetchs sur le bus mémoire ou s’il utilise un cache

  • Cette conception a été tape-out lors de la première production de wafer.space (https://github.com/wafer-space/ws-run1 à voir), mais je n’ai pas entendu dire si elle fonctionnait réellement correctement

  • Le pipeline de rendu programmable basé sur un tampon de scanlines présenté dans le PDF mérite la lecture si ce genre de technique vous intéresse

  • J’adore vraiment les projets qui imaginent et fabriquent du matériel d’univers parallèles

  • Je me demande si, lors de l’adoption de cette nouvelle architecture matérielle, le plus grand obstacle est la technologie elle-même, ou bien l’absence d’un écosystème de développeurs et d’une toolchain logicielle existants

    • Les deux posent problème. Cela dépend de ce qu’on veut construire précisément, mais en général, le développement matériel est plus difficile et plus coûteux que le développement logiciel
      Le manque d’outils logiciels peut se surmonter, mais l’absence de bibliothèques de jeux est un obstacle bien plus important. C’est particulièrement compliqué s’il n’existe pas de moyen très simple de porter les titres existants

  • Je suis surpris d’apprendre qu’on peut utiliser une implémentation open source d’AHB/APB à l’intérieur. Je pensais que c’était une technologie propriétaire d’ARM, donc je ne m’y étais jamais vraiment plongé

    • AMBA est un standard ouvert depuis très longtemps, probablement depuis son annonce initiale

  • Je pense que le développeur de ce projet est l’un des meilleurs ingénieurs de notre époque. Rien que cela est impressionnant, mais il a aussi conçu le cœur Hazard3 et le périphérique QSPI du RP2350
    En particulier, ce périphérique QSPI est le seul périphérique QSPI mappé en mémoire que j’aie utilisé jusqu’ici sans jamais réussir à le faire planter ou le bloquer

    • Je suis d’accord sur l’évaluation du QSPI, et le RP2350 est une puce formidable. On peut l’utiliser pour d’innombrables choses, et c’est un peu le tournevis sonique des outils de bus hacking