XiangShan – un processeur RISC-V hautes performances open source

 (github.com/OpenXiangShan)
2 points par GN⁺ 2025-01-04 | 1 commentaires | Partager sur WhatsApp
  • XiangShan (香山) est un projet open source visant à créer un processeur RISC-V hautes performances ; la version actuelle, Kunminghu (昆明湖), est en cours de développement sur la branche master
  • La documentation est publiée sur docs.xiangshan.cc, et les documents de conception de Kunminghu V2R2 ainsi que le guide utilisateur sont fournis séparément
  • Les microarchitectures stables sont Yanqihu (雁栖湖) et Nanhu (南湖) ; Yanqihu est la première microarchitecture stable, développée depuis juin 2020
  • Le flux de développement se compose du code de conception Scala, de la conversion FIRRTL, du sous-système de cache, du framework de cosimulation difftest et d’images de simulation précompilées
  • Le projet fournit des chemins pour générer du Verilog, exécuter un simulateur basé sur Verilator et lancer xspdb, afin de réaliser la génération de conception et la simulation de programmes au sein du projet

Présentation du projet

  • XiangShan (香山) est un projet open source de processeur RISC-V hautes performances
  • Une description en chinois est fournie dans un README séparé
  • La documentation du projet est disponible sur docs.xiangshan.cc
  • Le document de conception de XiangShan pour Kunminghu V2R2 est publié séparément sur docs.xiangshan.cc/projects/design
  • Le guide utilisateur de XiangShan est disponible sur docs.xiangshan.cc/projects/user-guide et dans XiangShan-User-Guide/releases
  • La traduction de la documentation utilise Weblate et accepte les contributions de traduction en anglais et dans d’autres langues
  • Toute la documentation de XiangShan est sous licence CC-BY-4.0

Article publié et méthodologie de développement

  • L’article MICRO 2022 « Towards Developing High Performance RISC-V Processors Using Agile Methodology » traite de XiangShan et de l’application de méthodes de développement agiles au développement de processeurs RISC-V hautes performances
  • L’article couvre les outils développés et utilisés pour accélérer le processus de conception de puces
    • Conception
    • Vérification fonctionnelle
    • Débogage
    • Vérification des performances
  • Cet article a reçu les trois badges Available, Functional et Reproduced lors de l’évaluation des artefacts
  • Liens vers les ressources :

Versions de microarchitecture

  • La première microarchitecture stable est Yanqihu (雁栖湖), disponible sur la branche yanqihu
    • Développée depuis juin 2020
  • La deuxième microarchitecture stable est Nanhu (南湖), disponible sur la branche nanhu
  • La version actuelle est également appelée Kunminghu (昆明湖) et reste en cours de développement sur la branche master
  • Le README inclut un schéma de présentation de la microarchitecture Kunminghu

Structure du dépôt

  • Les principaux répertoires sont répartis entre code de conception, scripts de développement, sous-modules, cache, cosimulation et images exécutables
  • src/main/scala : emplacement des fichiers de conception
    • device : périphériques virtuels pour la simulation
    • system : wrapper SoC
    • top : module de plus haut niveau
    • utils : code utilitaire
    • xiangshan : code de conception principal
    • xiangshan/transforms : transformations FIRRTL utiles
  • scripts : scripts pour le développement agile
  • yunsuan : sous-module yunsuan de XiangShan
  • XSCache : sous-système de cache de XiangShan
  • difftest : framework de cosimulation difftest
  • ready-to-run : images de simulation précompilées

IDE et génération de Verilog

  • La configuration BSP s’effectue avec make bsp
  • La configuration IDEA s’effectue avec make idea
  • Le code Verilog se génère avec make verilog
    • Plusieurs fichiers .sv sont générés dans le dossier build/rtl/
    • Un fichier d’exemple est build/rtl/XSTop.sv
    • Pour plus d’informations, consulter le Makefile

Exécution de la simulation

  • Pour exécuter un programme en simulation, des variables d’environnement et des outils dépendants sont nécessaires
  • Étapes de préparation :
    • Définir NEMU_HOME sur le chemin absolu du projet NEMU
    • Définir NOOP_HOME sur le chemin absolu du projet XiangShan
    • Définir AM_HOME sur le chemin absolu du projet AM
    • Installer mill
    • Après avoir cloné le projet, initialiser les sous-modules avec make init
  • Simulateur basé sur Verilator :
    • Nécessite l’installation de Verilator
    • make emu compile le simulateur C++ basé sur Verilator ./build/emu
    • Les arguments d’exécution sont disponibles avec ./build/emu --help
    • Pour plus d’informations, consulter le Makefile et verilator.mk
  • Exemples d’exécution :
    • make emu CONFIG=MinimalConfig EMU_THREADS=2 -j10
    • ./build/emu -b 0 -e 0 -i ./ready-to-run/coremark-2-iteration.bin --diff ./ready-to-run/riscv64-nemu-interpreter-so

Modes d’exécution de xspdb

  • xspdb peut être utilisé de deux manières
  • Démarrage rapide avec un binaire précompilé :
    • Aucune compilation n’est nécessaire, et un environnement Python standard suffit pour l’exécuter
    • Fournit une expérience XiangShan complète avec une faible consommation mémoire
    • La dernière version de XSPdb est disponible dans le résumé d’exécution du workflow Actions du dépôt
  • Compilation depuis le code source :
    • Nécessite l’installation de l’outil de vérification picker, qui prend en charge les langages de haut niveau
    • make pdb compile le binaire Python de XiangShan
    • make pdb-run exécute le binaire XiangShan
  • Les exemples d’interaction avec xspdb incluent le chargement d’un binaire, la définition d’un watchpoint sur le PC de commit, l’exécution pas à pas instruction par instruction, l’affichage des informations de PC et l’exécution jusqu’au point de sortie du binaire

Dépannage, communauté et licence

  • La documentation de dépannage est disponible dans le Troubleshooting Guide
  • Canaux de contact :
  • L’implémentation s’inspire de plusieurs articles majeurs ; la liste des articles concernés se trouve dans les Acknowledgements de la documentation XiangShan
  • Les mentions de copyright incluent les institutions suivantes
    • 2020-2025 Institute of Computing Technology, Chinese Academy of Sciences
    • 2021-2025 Beijing Institute of Open Source Chip
    • 2020-2022 Peng Cheng Laboratory
  • XiangShan est sous licence Mulan PSL v2

À lire aussi

1 commentaires

 
GN⁺ 2025-01-04
Avis sur Hacker News

  • Si vous voulez essayer une simulation, vous pouvez créer un environnement basé sur Ubuntu 24.04 avec le Dockerfile que j’utilise.
    Il clone OpenXiangShan/xs-env, installe les outils, installe Verilator, initialise XiangShan, compile DRAMsim3, compile l’émulateur DefaultConfig, puis compile l’exemple nexus-am/apps/hello.
    Il faut 64 Go de RAM ; dans mon cas, ça a fonctionné avec 16 Go de RAM et 48 Go de swap ajoutés. Il peut y avoir des étapes redondantes, mais c’est la méthode qui a marché lors de mon dernier essai.

    • Je me demande pourquoi cela consomme autant de mémoire.

  • Ce projet est le premier depuis longtemps à vraiment me stimuler intellectuellement, parce qu’il recoupe étrangement plusieurs de mes centres d’intérêt récents.
    Mais même après un survol très rapide, j’ai eu beaucoup d’empathie pour les utilisateurs non anglophones. Le README est assez accueillant pour un anglophone, mais en le lisant j’avais l’impression de devoir constamment remplacer mentalement les noms de tokens pour suivre, et deux choses m’ont sauté aux yeux.
    Premièrement, cela m’a rappelé pourquoi je n’arrive pas à aller au bout des classiques russes : des noms qui ne font pas partie de l’ensemble de noms qui m’est familier arrivent en rafale dès le début, et je me perds comme lors d’un cache miss.
    Deuxièmement, les anglophones n’ont pas vraiment eu besoin de développer ce muscle culturel. La Terre utilise l’anglais plus ou moins comme langue commune depuis assez longtemps, et cela m’a aussi rappelé la blague : « Comment appelle-t-on quelqu’un qui ne parle qu’une seule langue ? Monolingue… non, je plaisante : Américain. »
    On pourrait imaginer qu’un registre public prétraitant les tokens dans la documentation et le code soit maintenu par des « Américains comme moi ». Un registre de définitions façon DefinitelyTyped serait très niche, mais sans doute assez utile.

    • Quand on se sent vexé d’être monolingue, il existe un texte qui dit qu’une question plus juste que « combien de langues connaissez-vous ? » serait « quel pourcentage des langues parlées par plus de 5 millions de personnes dans un rayon d’environ 1 000 miles autour de chez vous connaissez-vous ? »
      https://structuredprocrastination.com/light/biling.php

  • https://github.com/OpenXiangShan/XiangShan-doc/blob/main/doc...
    La liste des instructions fusionnées est assez particulière. À part celles correspondant à SH{1,2,3,4}ADD, je ne m’attendais pas vraiment au reste.
    Je lis avec Google Translate, mais je n’y vois pas non plus l’exécution conditionnelle de sauts courts à la manière de SiFive.

    • Je me demande si l’organisation RISC-V elle-même tient quelque part une liste ou une documentation des séquences de fusion d’instructions recommandées.
      Le wiki technique qu’ils utilisent est assez difficile à parcourir et à rechercher, et les dépôts GitHub non officiels ne sont pas vraiment meilleurs, au point qu’il est difficile de savoir si cela existe même.

  • J’avais déjà publié un lien vers ce projet il y a quelques semaines, et c’est vraiment intéressant de voir ce genre de projet académique.
    Pour ceux que ça intéresse, le blog bimensuel est lié ici, et certains billets sont aussi disponibles en anglais : https://docs.xiangshan.cc/zh-cn/latest/blog/

  • J’aime le fait que les noms de microarchitectures suivent un thème de lacs, comme Yanqihu (雁栖湖), Nanhu (南湖) et Kunminghu (昆明湖).
    Coffee Lake ? Skylake ? Non, Kunming Lake.
    https://en.m.wikipedia.org/wiki/List_of_Intel_codenames

  • Il faut bien noter que la Chine progresse fortement en IA, robotique et processeurs, et il est aussi impressionnant qu’une grande partie de ces travaux soit publiée en open source.
    Excellent travail, et très inspirant.

    • RISC-V n’est-il pas, à la base, du logiciel libre et open source ?
    • Le fait de publier en open source est probablement aussi une partie du facteur de succès.
      La culture chinoise est structurée autour de la reproduction constante et de l’amélioration incrémentale, et cela remonte au moins à l’époque de Confucius. Certains y voient du copiage sans discernement, mais en réalité c’est plutôt une manière d’apprendre en profondeur et de se hisser sur les épaules des autres.
      Cette attitude de « forker » s’accorde assez bien avec l’open source, même si elle peut évidemment être agaçante du point de vue des licences de propriété intellectuelle ou des brevets.
      Cela ne veut toutefois pas dire que cette ouverture s’étend facilement hors de Chine, en particulier au-delà de la culture et de la sphère linguistique chinoises.

  • Il existe un produit commercial utilisant l’ancienne architecture Nanhu de XiangShan. Il ne semble pas encore être sorti, mais c’est tout de même intéressant.
    https://milkv.io/ja/ruyibook

  • Quelle est la stratégie derrière le fait de publier ça en open source ?

    • Ils l’ont présenté à HotChips 2024 : https://www.youtube.com/watch?v=4_R0S6piLA0&t=2114s
      L’un des points mentionnés était qu’ils souhaitent que RISC-V en général, et leurs cœurs en particulier, deviennent une plateforme de recherche académique. Ainsi, les idées de pointe sont partagées publiquement et l’industrie en bénéficie à l’échelle mondiale.
      Vu avec optimisme, c’est le souhait d’un meilleur avenir pour tous ; vu avec cynisme, l’open source est beaucoup plus difficile à sanctionner ou à contrôler à l’export. La vérité se situe probablement quelque part entre les deux.
    • Les universités publient toujours en open source, c’est normal. Moi aussi, tout ce que je fais à l’université est publié en open source.
      De toute façon, il est difficile d’en tirer de l’argent, les universités l’autorisent généralement, et c’est très bon pour le CV.
      Il y a aussi beaucoup d’open source en Europe et, franchement, les gouvernements ne complotent pas pour détruire les États-Unis. Je ne vois pas Linux comme un plan du gouvernement suédois pour détruire l’Amérique.
      D’après mon expérience, la plupart des Chinois ne se préoccupent pas beaucoup des pays hors de Chine, sauf s’ils travaillent dans le commerce international. La Chine est tellement grande, même comparée à des pays comme les États-Unis, qu’on a l’impression d’y vivre dans sa propre bulle ; je ne pense pas qu’ils réfléchissent à ce genre de questions tous les jours, ni même tous les mois.
    • Une autre motivation pourrait être d’affaiblir la domination occidentale dans la conception de puces.
      C’est une façon de distribuer gratuitement quelque chose d’« assez bon » qui attaque le fossé concurrentiel de l’adversaire. Si l’écart n’est pas énorme, cela peut même abîmer son activité.
      On peut voir de la même manière le financement d’OpenStreetMap par Apple et les grandes entreprises tech face à Google Maps. Réduire les revenus d’un concurrent a déjà une valeur stratégique.
      C’est aussi dans le même esprit que Satya Nadella disant en interview que si ChatGPT ne faisait qu’augmenter les coûts de Google Search, ce serait déjà une grande victoire pour Microsoft.
    • Plus réalistement, il est probable qu’un groupe interne de l’Académie chinoise des sciences veuille de meilleurs indicateurs d’impact dans ses évaluations, comme d’autres organismes de recherche financés par l’État.
    • La stratégie semble plutôt être de la promotion pour la Chine, du marketing pour accroître l’adoption, casser le duopole des puces, obtenir des contributions, et transformer la technologie en commodité générale afin de la rendre immunisée aux sanctions.

  • Content de voir un autre projet qui utilise Chisel. Je me demande dans quelle direction va l’industrie.
    Verilog et VHDL semblent mûrs pour être remplacés. Je me souviens avoir utilisé l’un des deux à l’université, et c’était vraiment désagréable.

    • Je me demande ce qui a changé pour qu’il soit maintenant temps de remplacer Verilog et VHDL.
      Mon directeur de mémoire de licence dirige une entreprise qui essaie de remplacer Verilog et VHDL, et cela fait largement plus de dix ans qu’il s’y consacre. Je n’ai pas l’impression que cela ait encore laissé une grande trace, même si je n’ai pas continué à suivre ce domaine : https://github.com/clash-lang/clash-compiler
      Il existe aussi une implémentation RISC-V écrite avec cet outil.
      Les outils dans ce domaine sont trop coûteux à créer et à valider, et le marché est trop petit ; il semble presque impossible que quelque chose émerge dans un délai raisonnable pour menacer l’écosystème existant.