XiangShan – Open-Source-Hochleistungsprozessor auf Basis von RISC-V

 (github.com/OpenXiangShan)
2 Punkte von GN⁺ 2025-01-04 | 1 Kommentare | Auf WhatsApp teilen
  • XiangShan(香山) ist ein Open-Source-Projekt mit dem Ziel, einen leistungsstarken RISC-V-Prozessor zu entwickeln; die aktuelle Version Kunminghu(昆明湖) wird derzeit im master-Branch entwickelt
  • Die Dokumentation ist unter docs.xiangshan.cc öffentlich verfügbar, und die Entwurfsdokumentation für Kunminghu V2R2 sowie das Benutzerhandbuch werden als separate Dokumente bereitgestellt
  • Als stabile Mikroarchitekturen gibt es Yanqihu(雁栖湖) und Nanhu(南湖); Yanqihu ist die erste stabile Mikroarchitektur und wird seit Juni 2020 entwickelt
  • Der Entwicklungsablauf besteht aus Scala-Entwurfscode, FIRRTL-Transformation, Cache-Subsystem, dem Co-Simulations-Framework difftest und vorkompilierten Simulations-Images
  • Das Projekt bietet Pfade zur Verilog-Generierung, zur Ausführung eines Verilator-basierten Simulators und zur Nutzung von xspdb, sodass die Erstellung des Designs und die Programmsimulation innerhalb des Projekts durchgeführt werden können

Projektüberblick

  • XiangShan(香山) ist ein Open-Source-Projekt für einen leistungsstarken RISC-V-Prozessor
  • Eine chinesische Beschreibung wird in einer separaten README bereitgestellt
  • Die Projektdokumentation ist unter docs.xiangshan.cc verfügbar
  • Die XiangShan-Entwurfsdokumentation für Kunminghu V2R2 ist separat unter docs.xiangshan.cc/projects/design veröffentlicht
  • Das XiangShan-Benutzerhandbuch ist unter docs.xiangshan.cc/projects/user-guide und XiangShan-User-Guide/releases verfügbar
  • Für Dokumentationsübersetzungen wird Weblate verwendet; Beiträge zu englischen und anderen Sprachübersetzungen sind willkommen
  • Alle XiangShan-Dokumente stehen unter der Lizenz CC-BY-4.0

Veröffentlichte Paper und Entwicklungsmethodik

  • Das MICRO-2022-Paper „Towards Developing High Performance RISC-V Processors Using Agile Methodology“ behandelt XiangShan und die Anwendung agiler Entwicklungsmethodik bei der Entwicklung leistungsstarker RISC-V-Prozessoren
  • Das Paper behandelt die Werkzeuge, die entwickelt und verwendet wurden, um den Chip-Entwicklungsprozess zu beschleunigen
    • Entwurf
    • funktionale Verifikation
    • Debugging
    • Performance-Verifikation
  • Das Paper erhielt in der Artifact Evaluation alle drei Badges: Available, Functional und Reproduced
  • Materiallinks:

Mikroarchitektur-Versionen

  • Die erste stabile Mikroarchitektur ist Yanqihu(雁栖湖) und befindet sich im yanqihu-Branch
    • Entwicklung seit Juni 2020
  • Die zweite stabile Mikroarchitektur ist Nanhu(南湖) und befindet sich im nanhu-Branch
  • Die aktuelle Version wird auch Kunminghu(昆明湖) genannt und befindet sich noch in Entwicklung im master-Branch
  • Die README enthält ein Überblicksdiagramm der Mikroarchitektur Kunminghu

Repository-Struktur

  • Die wichtigsten Verzeichnisse sind in Entwurfscode, Entwicklungsskripte, Submodule, Cache, Co-Simulation und ausführbare Images unterteilt
  • src/main/scala: Speicherort der Entwurfsdateien
    • device: virtuelle Geräte für die Simulation
    • system: SoC-Wrapper
    • top: Top-Level-Modul
    • utils: Utility-Code
    • xiangshan: zentraler Entwurfscode
    • xiangshan/transforms: nützliche FIRRTL-Transformationen
  • scripts: Skripte für die agile Entwicklung
  • yunsuan: das yunsuan-Submodul von XiangShan
  • XSCache: das Cache-Subsystem von XiangShan
  • difftest: das Co-Simulations-Framework difftest
  • ready-to-run: vorkompilierte Simulations-Images

IDE und Verilog-Generierung

  • Die BSP-Konfiguration erfolgt mit make bsp
  • Die IDEA-Konfiguration erfolgt mit make idea
  • Der Verilog-Code wird mit make verilog erzeugt
    • Mehrere .sv-Dateien werden im Ordner build/rtl/ erzeugt
    • Eine Beispieldatei ist build/rtl/XSTop.sv
    • Weitere Informationen sind im Makefile zu finden

Ausführung der Simulation

  • Um Programme in der Simulation auszuführen, werden Umgebungsvariablen und abhängige Werkzeuge benötigt
  • Vorbereitung:
    • NEMU_HOME auf den absoluten Pfad des NEMU project setzen
    • NOOP_HOME auf den absoluten Pfad des XiangShan-Projekts setzen
    • AM_HOME auf den absoluten Pfad des AM project setzen
    • mill installieren
    • Nach dem Klonen des Projekts die Submodule mit make init initialisieren
  • Verilator-basierter Simulator:
    • Verilator muss installiert sein
    • Mit make emu wird der Verilator-basierte C++-Simulator ./build/emu gebaut
    • Ausführungsargumente sind unter ./build/emu --help einsehbar
    • Weitere Informationen stehen im Makefile und in verilator.mk
  • Ausführungsbeispiele:
    • 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

xspdb-Ausführungspfade

  • xspdb kann auf zwei Arten verwendet werden
  • Schneller Einstieg mit vorkompilierten Binärdateien:
    • Keine Kompilierung erforderlich; ausführbar mit einer Standard-Python-Umgebung
    • Bietet die vollständige XiangShan-Erfahrung bei geringem Speicherverbrauch
    • Die neueste XSPdb kann in der Ausführungszusammenfassung des Actions-Workflows des Repositorys heruntergeladen werden
  • Build aus dem Quellcode:
    • Erfordert die Installation des Verifikationswerkzeugs picker, das Hochsprachen unterstützt
    • Mit make pdb wird die XiangShan-Python-Binärdatei gebaut
    • Mit make pdb-run wird die XiangShan-Binärdatei ausgeführt
  • Beispielinteraktionen mit xspdb umfassen das Laden einer Binärdatei, das Setzen eines Watchpoints auf die Commit-PC, schrittweises Ausführen auf Instruktionsebene, die Ausgabe von PC-Informationen und das Ausführen bis zum Endpunkt der Binärdatei

Fehlerbehebung, Community und Lizenz

  • Eine Dokumentation zur Fehlerbehebung ist im Troubleshooting Guide verfügbar
  • Kontaktkanäle:
  • Die Implementierung wurde von mehreren grundlegenden Papern inspiriert; eine Liste relevanter Veröffentlichungen findet sich in den Acknowledgements der XiangShan-Dokumentation
  • Die Copyright-Angaben umfassen die folgenden Institutionen
    • 2020-2025 Institute of Computing Technology, Chinese Academy of Sciences
    • 2021-2025 Beijing Institute of Open Source Chip
    • 2020-2022 Peng Cheng Laboratory
  • XiangShan steht unter der Lizenz Mulan PSL v2

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-01-04
Meinungen auf Hacker News

  • Wenn man eine Simulation ausprobieren möchte, kann man mit dem Dockerfile, das ich verwende, eine Umgebung auf Basis von Ubuntu 24.04 erstellen.
    Es klont OpenXiangShan/xs-env und erledigt die Installation der Tools, die Installation von Verilator, die Initialisierung von XiangShan, den Build von DRAMsim3, den Build des DefaultConfig-Emulators sowie den Build des Beispiels nexus-am/apps/hello.
    Man braucht 64 GB RAM; in meinem Fall lief es mit 16 GB RAM plus 48 GB Swap. Es kann sein, dass einige Schritte doppelt sind, aber beim letzten Versuch hat es so funktioniert.

    • Ich frage mich, warum es so viel Speicher braucht.

  • Dieses Projekt war das erste seit Langem, das mein Gehirn wirklich gekitzelt hat, weil sich darin einige meiner aktuellen Interessen auf merkwürdige Weise überlappen.
    Allerdings habe ich schon nach einem sehr kurzen Überfliegen stark mit nicht englischsprachigen Nutzern mitgefühlt. Das README ist für englischsprachige Nutzer ausreichend freundlich, aber beim Lesen fühlte es sich so an, als müsste ich im Kopf ständig Token-Namen umbenennen, um folgen zu können; dabei sind mir zwei Dinge aufgefallen.
    Erstens erinnerte es mich daran, warum ich klassische russische Literatur nie zu Ende lese: Schon am Anfang prasseln Namen auf einen ein, die nicht zu den vertrauten Namensmengen gehören, und man verliert sich wie bei einem Cache Miss.
    Zweitens scheint diese kulturelle Muskulatur für englischsprachige Nutzer kaum nötig gewesen zu sein. Schließlich verwendet die Welt Englisch seit ziemlich langer Zeit in gewissem Maß als Lingua franca, und mir fiel auch der Witz ein: „Wie nennt man jemanden, der nur eine Sprache spricht? Monolingual … nur ein Scherz, Amerikaner.“
    Es scheint möglich, dass „Amerikaner wie ich“ ein öffentliches Registry pflegen könnten, das Token in Dokumentation und Source vorverarbeitet. Eine Definitions-Registry im Stil von DefinitelyTyped wäre zwar extrem nischig, aber vermutlich ziemlich nützlich.

    • Es gibt einen Artikel, der sagt: Wenn man sich schlecht fühlt, weil man monolingual ist, sei die fairere Frage nicht „Wie viele Sprachen kennst du?“, sondern „Welchen Prozentsatz der Sprachen kennst du, die innerhalb von etwa 1.000 Meilen von deinem Wohnort gesprochen werden und mehr als 5 Millionen Sprecher haben?“
      https://structuredprocrastination.com/light/biling.php

  • https://github.com/OpenXiangShan/XiangShan-doc/blob/main/doc...
    Die Liste der fusionierten Instruktionen ist etwas ungewöhnlich. Abgesehen von den Entsprechungen zu SH{1,2,3,4}ADD hätte ich den Rest jedenfalls nicht erwartet.
    Ich lese das zwar gerade mit Google Translate, aber die Kurzsprung-Prädikation im SiFive-Stil scheint dort auch nicht aufzutauchen.

    • Ich frage mich, ob die RISC-V-Organisation selbst irgendwo empfohlene Instruktionsfusions-Sequenzen auflistet oder dokumentiert.
      Das verwendete Technik-Wiki ist ziemlich schwer zu navigieren und zu durchsuchen, und inoffizielle GitHub-Repositories sind auch nicht viel besser, sodass es schwer ist, überhaupt herauszufinden, ob so etwas existiert.

  • Ich habe den Link zu diesem Projekt schon vor ein paar Wochen gepostet; solche akademischen Projekte anzusehen ist wirklich spannend.
    Für Interessierte ist der zweiwöchentliche Blog hier verlinkt, einige Beiträge gibt es auch auf Englisch: https://docs.xiangshan.cc/zh-cn/latest/blog/

  • Mir gefällt, dass die Mikroarchitektur-Namen wie Yanqihu (Yanqi-See), Nanhu (Südsee) und Kunminghu (Kunming-See) ein See-Thema haben.
    Coffee Lake? Skylake? Nein, Kunming Lake.
    https://en.m.wikipedia.org/wiki/List_of_Intel_codenames

  • Man sollte zur Kenntnis nehmen, dass China bei KI, Robotik und Prozessoren große Fortschritte macht, und es ist beeindruckend, dass ein großer Teil davon als Open Source veröffentlicht wird.
    Großartige Arbeit und inspirierend.

    • Ist RISC-V nicht von vornherein freie Open-Source-Software?
    • Es ist gut möglich, dass die Veröffentlichung als Open Source selbst ein Teil des Erfolgsfaktors ist.
      Die chinesische Kultur ist um ständige Reproduktion und schrittweise Verbesserung herum aufgebaut, und das reicht mindestens bis in die Zeit von Konfuzius zurück. Manche sehen das als wahlloses Kopieren, tatsächlich geht es aber eher um tiefes Lernen und darum, auf den Schultern anderer zu stehen.
      Diese „Fork it“-Haltung passt ziemlich gut zu Open Source, kann aber bei IP-Lizenzen oder Patenten natürlich ziemlich ärgerlich sein.
      Allerdings bedeutet diese Offenheit nicht, dass sie sich leicht über China hinaus ausdehnt, insbesondere nicht außerhalb des chinesischen Kultur- und Sprachraums.

  • Es gibt ein kommerzielles Produkt, das XiangShans frühere Nanhu-Architektur verwendet. Es scheint zwar noch nicht auf dem Markt zu sein, ist aber trotzdem interessant.
    https://milkv.io/ja/ruyibook

  • Welche Strategie steckt dahinter, das als Open Source zu veröffentlichen?

    • Sie haben es auf der HotChips 2024 vorgestellt: https://www.youtube.com/watch?v=4_R0S6piLA0&t=2114s
      Einer der Punkte, die dort genannt wurden, war, dass sie hoffen, RISC-V insgesamt und insbesondere ihre eigenen Kerne würden zu einer akademischen Forschungsplattform werden. Dann würden State-of-the-Art-Ideen öffentlich geteilt, und die Industrie weltweit würde profitieren.
      Optimistisch betrachtet wünschen sie sich eine bessere Zukunft für alle; zynisch betrachtet bedeutet Open Source, dass Sanktionen oder Exportkontrollen sehr viel schwerer durchzusetzen sind. Die Wahrheit liegt vermutlich irgendwo dazwischen.
    • Universitäten veröffentlichen ohnehin immer als Open Source. Ich stelle auch alles, was ich an der Universität mache, als Open Source bereit.
      Es ist sowieso schwer, damit Geld zu verdienen, und die Universität erlaubt es normalerweise; für den Lebenslauf ist es sehr gut.
      Auch in Europa gibt es viel Open Source, und ehrlich gesagt heißt das nicht, dass die Regierung eine Verschwörung zur Zerstörung der USA plant. Ich sehe Linux nicht als Plan der schwedischen Regierung zur Zerstörung der USA.
      Nach meiner Erfahrung kümmern sich die meisten Chinesen auch nicht besonders um Länder außerhalb Chinas, sofern sie nicht im Außenhandel arbeiten. China ist selbst im Vergleich zu Ländern wie den USA so groß, dass man dort in einer eigenen Blase lebt, und solche Fragen scheinen sie nicht einmal monatlich, geschweige denn täglich zu beschäftigen.
    • Ein anderes Motiv könnte sein, die Dominanz des Westens im Chipdesign zu schwächen.
      Es wäre eine Methode, etwas „gut genuges“ kostenlos zu verbreiten, das den Burggraben der Konkurrenz angreift. Wenn der Abstand nicht groß ist, kann das das Geschäft der Konkurrenz beschädigen.
      Dass Apple und große Tech-Unternehmen OpenStreetMap als Gegengewicht zu Google Maps finanzieren, kann man ähnlich sehen. Schon die Verringerung der Einnahmen eines Konkurrenten hat strategischen Wert.
      In dieselbe Richtung ging Satya Nadellas Aussage in einem Interview, dass es für Microsoft schon ein großer Sieg wäre, wenn ChatGPT lediglich die Kosten der Google-Suche erhöht.
    • Realistischerweise liegt es wohl daran, dass eine Gruppe innerhalb der Chinesischen Akademie der Wissenschaften, wie andere staatlich geförderte Forschungseinrichtungen auch, bei der Bewertung größere Impact-Metriken haben möchte.
    • Die Strategie scheint eher in Richtung China-PR, Marketing zur Erhöhung der Adoption, Aufbrechen der Duopol-Struktur bei Chips, Gewinnung von Beiträgen und Umwandlung der Technologie in ein Commodity-Gut zu gehen, das gegen Sanktionen immun ist.

  • Es ist schön, ein weiteres Projekt zu sehen, das Chisel verwendet. Ich frage mich, wohin sich die Branche bewegt.
    Es wirkt, als sei es an der Zeit, dass Verilog und VHDL ersetzt werden. An eines von beiden habe ich aus dem Studium wirklich unangenehme Erinnerungen.

    • Ich frage mich, was sich geändert hat, sodass es jetzt an der Zeit sein soll, Verilog und VHDL zu ersetzen.
      Mein Betreuer der Bachelorarbeit betreibt ein Unternehmen, das versucht, Verilog und VHDL zu ersetzen, und macht das schon deutlich länger als zehn Jahre. Es scheint noch keine großen Spuren hinterlassen zu haben, aber ich habe das Feld nicht weiter verfolgt: https://github.com/clash-lang/clash-compiler
      Es gibt auch eine RISC-V-Implementierung, die damit geschrieben wurde.
      Tools in diesem Bereich sind zu teuer zu bauen und zu verifizieren, und der Markt ist zu klein; daher wirkt es fast unmöglich, dass innerhalb eines vernünftigen Zeitraums etwas entsteht, das das bestehende Ökosystem ernsthaft bedroht.