RISCBoy – eine Open-Source-Handheld-Spielkonsole, von Grund auf entworfen

 (github.com/Wren6991)
1 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • RISCBoy ist eine Handheld-Spielkonsole, bei der vom RISC-V-kompatiblen CPU über die Grafikpipeline, den Display-Controller sowie die Speicher- und Peripherie-Infrastruktur bis hin zum KiCad-PCB alles selbst entworfen wurde
  • Sie orientiert sich an einem Game Boy Advance, der hätte erscheinen können, wenn es RISC-V schon 2001 gegeben hätte, ist in synthetisierbarem Verilog 2005 geschrieben und implementiert eine 32-Bit-Konsole auf einem iCE40-HX8k-FPGA mit 7.680 Logikelementen
  • Der Prozessor unterstützt den RV32IMC-Befehlssatz sowie M-mode-CSR, Ausnahmen und vektorisierte externe Interrupts und besteht RISC-V-Konformitätstests sowie die Verifikation mit riscv-formal
  • Für die Synthese wird die Open-Source-Toolchain Yosys·nextpnr·Project Icestorm verwendet; unterstützt werden auch ECP5-Boards und eine RV32I-Konfiguration für das kleinere iCE40 UP5k
  • Simulation und offizielle Entwicklungsumgebung orientieren sich hauptsächlich an Linux, und PCB Rev B sowie Bootloader, Gateware und Software-Tree sind noch in Entwicklung

Eine von Grund auf aufgebaute Handheld-Konsole

  • Der öffentlich verfügbare Entwurfsumfang von RISCBoy umfasst Folgendes
    • RISC-V-kompatiblen CPU
    • Raster-Grafikpipeline und Display-Controller
    • Bus-Fabric, Speicher-Controller und Chip-Infrastruktur wie UART und GPIO
    • PCB-Layout, erstellt mit KiCad
  • Das Ziel ist ein Game Boy Advance aus einem Paralleluniversum, in dem es 2001 bereits RISC-V gab – ein Projekt, das die Begeisterung für Handheld-Konsolen der Kindheit und die Technik dahinter ausdrückt
  • Detailliertere Informationen zum Design finden sich im Dokument doc/riscboy_doc.pdf im Repository

FPGA-Implementierung und Prozessor

  • Das Design ist in synthetisierbarem Verilog 2005 geschrieben und auf den iCE40-HX8k zugeschnitten, einen LUT4-basierten FPGA
    • Der HX8k bietet 7.680 Logikelemente
    • Um eine 32-Bit-Spielkonsole in die begrenzten Ressourcen zu packen, war sorgfältiges Design nötig
  • Der HX8k war einst der größte FPGA, der von der Open-Source-Toolchain Project Icestorm unterstützt wurde; später wurde das zugehörige Ökosystem um Project Trellis und Project X-Ray erweitert
  • Der Prozessor unterstützt den RV32IMC-Befehlssatz
    • Er besteht die RISC-V-Konformitätstests für diesen Befehlssatz
    • Er besteht die Verifikationssuite riscv-formal
    • Zusätzlich kommen eigene formale Property-Verifikationen zum Einsatz, die die Konsistenz des Instruction-Frontends und die Einhaltung grundlegender Bus-Spezifikationen prüfen
  • Unterstützt werden M-mode-CSR und Ausnahmen; zudem gibt es eine einfache Compliance-Erweiterung für vektorisierte externe Interrupts

Repository klonen und Toolchain

  • Für HDL und Tests werden Git-Submodule verwendet, daher sollte das Repository rekursiv wie folgt geklont werden
git clone --recursive https://github.com/Wren6991/RISCBoy.git riscboy
  • Nach einem normalen Klonen lassen sich die Submodule auch separat initialisieren
git clone https://github.com/Wren6991/RISCBoy.git riscboy
cd riscboy
git submodule update --init --recursive
  • Das rekursive Aktualisieren der Submodule ist für eigenständige Tests des Prozessors erforderlich, jedoch nicht für den Build der RISCBoy-Gateware
  • Um softwarebasierte Tests zu kompilieren, muss die RISC-V GNU Toolchain mit der Konfiguration RV32IMC·ILP32 gebaut werden
./configure --prefix=/opt/riscv \
  --with-arch=rv32imc \
  --with-abi=ilp32 \
  --with-multilib-generator="rv32i-ilp32--;rv32ic-ilp32--;rv32im-ilp32--;rv32imc-ilp32--"
  • Auf kleineren FPGAs wie dem iCE40 UP5k kann statt des leistungsfähigeren RV32IMC eine kleinere RV32I-Prozessorvariante verwendet werden
  • Selbst wenn der Compiler mehrere ISA-Varianten von RISCBoy unterstützt, ist eine Multilib-Konfiguration nötig, damit für jede Variante die passende Standardbibliothek erzeugt wird
    • Auf einem reinen RV32I-Prozessor führt das Ausführen einer RV32I-Binärdatei, die gegen eine RV32IMC-Standardbibliothek gelinkt wurde, zu Problemen

Simulation und Tests

  • Der Simulationsablauf verwendet Xilinx ISIM 14.x und das Makefile im Verzeichnis scripts/
    • Getestet wurde nur mit der Linux-Version von ISIM
    • Falls ISIM nicht im Standardpfad installiert ist, muss eventuell der Pfad in sourceme angepasst werden
  • So werden Tests auf HDL-Ebene ausgeführt
git submodule update --init --recursive
. sourceme
cd test
./runtests
  • Für Softwaretests wird eine RV32IC-Toolchain benötigt
  • Um einzelne Tests in einer grafischen Umgebung zu debuggen, wird das jeweilige Makefile direkt ausgeführt
cd system
make TEST=helloworld gui

PCB-Design

  • Das Rev-A-PCB ist mit dem 4-Lagen-5×5-cm-Prototyping-Service von iTead kompatibel
    • Zum Zeitpunkt der README-Erstellung betrugen die Kosten 65 US-Dollar für 10 Platinen
    • Den Schaltplan gibt es unter board/fpgaboy.pdf im Repository
  • Rev B wird voraussichtlich deutlich anders ausfallen als Rev A; derzeit wartet das Projekt darauf, dass Gateware und Bootloader reifer werden, bevor es weitergeht
  • Die aktuelle Entwicklungshardware hat eine ähnliche Form wie das Snowflake FPGA board

Synthese und unterstützte Boards

  • Für die FPGA-Synthese auf iCE40 kommt folgende Open-Source-Toolchain zum Einsatz
  • Diese Tools wurden nur unter Linux direkt gebaut und verifiziert; Windows-Builds sollen möglich sein, wurden aber nicht getestet
  • Die Toolchain lässt sich auch auf einem Raspberry Pi bauen
  • Ein FPGA-Image für das Lattice-HX8k-Evaluierungsboard wird mit folgendem Befehl erzeugt
. sourceme
cd synth
make -f HX8k-EVN.mk bit
  • Es gibt auch ECP5-Unterstützung für das Evaluierungsboard Lattice LEF5UM5G-85F-EVN, allerdings als stark experimentelle Konfiguration und nicht als primäre Entwicklungsplattform
make -f ECP5-EVN.mk BUILD=full bit
  • Der ECP5-Build ersetzt das externe 512-KiB-16-Bit-SRAM der Entwicklungshardware durch einen internen 256-KiB-32-Bit-Synchronspeicher
    • Dieser Speicher wird von Trellis als ECP5-sysmem-Block konfiguriert

Repository-Struktur

  • board: KiCad-Dateien für das RISCBoy-Haupt-PCB und kleinere Boards, die während der Entwicklung verwendet wurden
  • doc: LaTeX-Quellen der Dokumentation, Diagramme und das aktuelle Build-PDF
  • hdl: Verilog-Quellen der RISCBoy-Gateware
    • busfabric: AHB-lite-Crossbar und APB-Peripherie-Fabric
    • graphics: Quellcode der Pixelverarbeitungseinheit
    • hazard5: Quellcode des vollständig eigenständig aufgebauten RISC-V-Prozessors
    • mem: Speicher-Controller sowie Wrapper und Modelle für Speicherinferenz und -injektion
    • peris: kleine Peripherie wie UART, SPI und PWM
    • riscboy_core: Strukturmodul, das RISCBoy-Komponenten instanziiert und verbindet
    • riscboy_fpga: Top-Level-Wrapper, der Ein-/Ausgabe, Takt und Reset für verschiedene FPGAs und Boards verbindet
  • reference: Standard-PDFs, die in RISCBoy verwendet wurden, etwa zum RISC-V-Befehlssatz
  • scripts: Skripte, die keinem anderen Verzeichnis zugeordnet sind
  • software: Sammlung von C-Dateien für Tests auf Systemebene, noch kein praktikabler Software-Tree
  • synth: Arbeitsverzeichnis für die Synthese des Gesamtsystems mit Top-Level-Makefile und Pin-Constraint-Dateien
  • test: Sammlung von Regressionstests, einschließlich Verilog-Testbenches und Software-Testfällen, die in der Simulation des Prozessors oder des Gesamtsystems ausgeführt werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Meinungen auf Hacker News

  • Auf der GitHub-Seite wird es als Game Boy Advance aus einem Paralleluniversum, in dem RISC-V im Jahr 2001 existierte, beschrieben.
    Das Projekt wird als Liebesbrief an die Handheld-Konsole der Kindheit beschrieben – und als eine betrunkene SMS um 3 Uhr morgens an die Technik, die diese Konsole antrieb.

  • Es ist eine Arbeit von Luke Wren, einem ASIC Design Engineer bei Raspberry Pi. Ein wirklich großartiges Projekt.

    • Ihn nur als ASIC Design Engineer zu bezeichnen, unterschätzt seine Rolle; er ist auch an der Entwicklung von CPU-Kernen beteiligt.

  • Dieser Entwickler hat auch PicoDVI entworfen, das DVI/HDMI auf dem RP2040 implementiert.
    https://github.com/Wren6991/PicoDVI

    • Er arbeitet bei Raspberry Pi und hat den Hazard3-RISC-V-Core entworfen, der das Herzstück des RP2350 bildet. Hazard3 wurde allerdings in seiner Freizeit entwickelt und ist ein Projekt, das aus dem ursprünglich für RISCBoy entworfenen Hazard5-Core hervorgegangen ist.

  • Der GBA wurde mit einer Architektur ohne Cache entworfen. Abgesehen von internem RAM, Video-RAM, Ein-/Ausgabe-Registern, BIOS, OAM, Paletten usw. läuft jeder Zugriff über den externen Bus; nutzt man den externen Bus ohne Cache, wird das System praktisch so langsam wie ein Computer aus den 1980er-Jahren. Auch das Holen von Instruktionen aus der Cartridge ist nur etwa doppelt so schnell wie beim GBC.
    Um das zu vermeiden, muss man einen Cache verwenden und mehrere Words sequenziell holen. Wenn man sequenzielle Zugriffe beschleunigt, steigt der Durchsatz, und wenn Instruktionen und Daten ausreichend gecacht werden, lässt sich die Latenz verbergen. Ich frage mich, ob dieses System alle Fetches auf den Speicherbus schickt oder ob es einen Cache verwendet.

  • Dieses Design wurde im ersten Produktionslauf von wafer.space getape-outet (siehe https://github.com/wafer-space/ws-run1), aber ich habe nicht gehört, ob es tatsächlich korrekt funktioniert hat.

  • Die im PDF vorgestellte programmierbare Scanline-Buffer-basierte Rendering-Pipeline ist lesenswert, wenn man sich für solche Technik interessiert.

  • Ich liebe Projekte, die sich Hardware aus einem Paralleluniversum vorstellen und sie dann bauen.

  • Ich frage mich, ob die größte Hürde bei der Einführung dieser neuen Hardwarearchitektur die Technik selbst ist oder eher das Fehlen eines bestehenden Entwickler-Ökosystems und einer Software-Toolchain.

    • Beides ist ein Problem. Es hängt davon ab, was genau man bauen will, aber im Allgemeinen ist Hardwareentwicklung schwieriger und teurer als Softwareentwicklung.
      Fehlende Software-Tools lassen sich überwinden, aber das Fehlen von Game Libraries ist eine größere Hürde – besonders dann, wenn es keinen sehr einfachen Weg gibt, bestehende Titel zu portieren.

  • Es überrascht mich, dass man darin eine Open-Source-Implementierung von AHB/APB verwenden darf. Ich dachte, das sei proprietäre ARM-Technologie, und habe mich deshalb bisher nie tiefer damit beschäftigt.

    • AMBA ist schon seit sehr langer Zeit ein offener Standard; soweit ich weiß, vermutlich seit seiner ersten Veröffentlichung.

  • Ich halte den Entwickler dieses Projekts für einen der besten Ingenieure unserer Zeit. Schon das hier ist beeindruckend, aber er hat auch den Hazard3-Core und das QSPI-Gerät des RP2350 entworfen.
    Insbesondere dieses QSPI-Gerät ist das einzige memory-mapped QSPI-Gerät, mit dem ich bisher zu tun hatte, das ich nicht zum Absturz bringen oder zum Hängen bringen konnte.

    • Der Einschätzung zu QSPI stimme ich zu, und der RP2350 ist ein großartiger Chip. Er hat unzählige Einsatzmöglichkeiten und ist so etwas wie der Sonic Screwdriver unter den Bus-Hacking-Tools.