RISCBoy — console portátil de jogos open source projetado do zero

 (github.com/Wren6991)
1 pontos por GN⁺ 4 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • RISCBoy é um console portátil de jogos projetado diretamente desde a CPU compatível com RISC-V até o pipeline gráfico, controlador de tela, infraestrutura de memória e periféricos, além da PCB em KiCad
  • Mira em um Game Boy Advance que poderia ter existido se o RISC-V já existisse em 2001, e implementa um console de 32 bits em um FPGA iCE40-HX8k com 7.680 elementos lógicos, escrito em Verilog 2005 sintetizável
  • O processador dá suporte ao conjunto de instruções RV32IMC, a CSRs de M-mode, exceções e interrupções externas vetorizadas, e passou nos testes de conformidade RISC-V e na verificação riscv-formal
  • A síntese usa a cadeia de ferramentas open source Yosys·nextpnr·Project Icestorm, e também há suporte a placas ECP5 e a uma configuração RV32I para o iCE40 UP5k, menor
  • O ambiente oficial de simulação e desenvolvimento é baseado principalmente em Linux, e a PCB Rev B, o bootloader, o gateware e a árvore de software ainda estão em desenvolvimento

Console portátil construído do zero

  • O escopo do projeto aberto do RISCBoy inclui:
    • CPU compatível com RISC-V
    • Pipeline gráfico raster e controlador de tela
    • Infraestrutura de chip, como bus fabric, controlador de memória, UART e GPIO
    • Layout de PCB feito em KiCad
  • O objetivo é um Game Boy Advance de um universo paralelo em que o RISC-V existia em 2001, em um projeto que expressa carinho pelos consoles portáteis da infância e pela tecnologia que os movia
  • Informações mais detalhadas de projeto podem ser encontradas no documento doc/riscboy_doc.pdf do repositório

Implementação em FPGA e processador

  • O projeto foi escrito em Verilog 2005 sintetizável e é voltado para o iCE40-HX8k, um FPGA baseado em LUT4
    • O HX8k oferece 7.680 elementos lógicos
    • Foi necessário um projeto cuidadoso para encaixar um console de jogos de 32 bits em recursos limitados
  • O HX8k já foi o maior FPGA suportado pela cadeia de ferramentas open source Project Icestorm, e depois o ecossistema relacionado se expandiu com Project Trellis e Project X-Ray
  • O processador dá suporte ao conjunto de instruções RV32IMC
    • Passou nos testes de conformidade RISC-V para essas instruções
    • Passou na suíte de verificação riscv-formal
    • Também aplica verificação formal própria de propriedades que checam a consistência do front-end de instruções e a conformidade básica do barramento
  • Dá suporte a CSRs e exceções em M-mode, além de fornecer uma extensão simples e compatível para interrupções externas vetorizadas

Clonagem do repositório e toolchain

  • Como o HDL e os testes usam submódulos Git, é preciso clonar recursivamente da seguinte forma:
git clone --recursive https://github.com/Wren6991/RISCBoy.git riscboy
  • Depois de uma clonagem normal, os submódulos podem ser inicializados separadamente:
git clone https://github.com/Wren6991/RISCBoy.git riscboy
cd riscboy
git submodule update --init --recursive
  • A atualização recursiva de submódulos é necessária para os testes standalone do processador, mas não para o build do gateware do RISCBoy
  • Para compilar testes baseados em software, é preciso compilar o RISC-V GNU Toolchain com configuração RV32IMC·ILP32
./configure --prefix=/opt/riscv \
  --with-arch=rv32imc \
  --with-abi=ilp32 \
  --with-multilib-generator="rv32i-ilp32--;rv32ic-ilp32--;rv32im-ilp32--;rv32imc-ilp32--"
  • Em FPGAs menores, como o iCE40 UP5k, é possível usar uma variante menor do processador RV32I em vez do RV32IMC de alto desempenho
  • Mesmo que o compilador dê suporte às várias variantes de ISA do RISCBoy, a configuração de multilib é necessária para que as bibliotecas padrão adequadas a cada variante sejam geradas
    • Executar em um processador apenas RV32I um executável RV32I vinculado a uma biblioteca padrão RV32IMC causa problemas

Simulação e testes

  • O fluxo de simulação usa o Xilinx ISIM 14.x e os Makefiles do diretório scripts/
    • Foi testado apenas na versão Linux do ISIM
    • Se o ISIM estiver instalado fora do caminho padrão, talvez seja necessário ajustar o caminho em sourceme
  • O processo para executar testes em nível de HDL é:
git submodule update --init --recursive
. sourceme
cd test
./runtests
  • Os testes de software exigem uma toolchain RV32IC
  • Para depurar um teste individual em ambiente gráfico, execute diretamente o Makefile correspondente:
cd system
make TEST=helloworld gui

Projeto da PCB

  • A PCB Rev A é compatível com o serviço de prototipagem 5×5 cm em 4 camadas da iTead
    • No momento em que o README foi escrito, o custo era de US$ 65 por 10 placas
    • O esquemático pode ser visto em board/fpgaboy.pdf no repositório
  • A Rev B deverá ter um formato consideravelmente diferente da Rev A, e está aguardando o amadurecimento do gateware e do bootloader antes de avançar
  • O hardware de desenvolvimento atual tem um formato semelhante ao da placa FPGA Snowflake

Síntese e placas suportadas

  • A síntese de FPGA para iCE40 usa a seguinte cadeia de ferramentas open source:
  • Essas ferramentas foram compiladas e verificadas diretamente apenas no Linux; builds para Windows são conhecidos como possíveis, mas não foram testados
  • A cadeia de ferramentas também pode ser compilada no Raspberry Pi
  • A imagem de FPGA para a placa de avaliação Lattice HX8k é gerada com o seguinte comando:
. sourceme
cd synth
make -f HX8k-EVN.mk bit
  • Também há suporte a ECP5 para a placa de avaliação Lattice LEF5UM5G-85F-EVN, mas trata-se de uma configuração altamente experimental e não da plataforma principal de desenvolvimento
make -f ECP5-EVN.mk BUILD=full bit
  • O build para ECP5 substitui a SRAM externa de 512 KiB e 16 bits do hardware de desenvolvimento por memória síncrona interna de 256 KiB e 32 bits
    • Essa memória é configurada pelo Trellis como blocos sysmem do ECP5

Estrutura do repositório

  • board: arquivos KiCad da PCB principal do RISCBoy e das pequenas placas usadas durante o desenvolvimento
  • doc: código-fonte LaTeX da documentação, diagramas e o PDF da build mais recente
  • hdl: código-fonte Verilog do gateware do RISCBoy
    • busfabric: crossbar AHB-lite e fabric de periféricos APB
    • graphics: código-fonte da unidade de processamento de pixels
    • hazard5: código-fonte do processador RISC-V composto de forma totalmente independente
    • mem: controladores de memória, wrappers e modelos de inferência/injeção de memória
    • peris: pequenos periféricos como UART, SPI e PWM
    • riscboy_core: módulo estrutural que instancia e conecta os componentes do RISCBoy
    • riscboy_fpga: wrapper de nível superior que conecta entradas/saídas, clocks e resets de vários FPGAs e placas
  • reference: PDFs de padrões usados no RISCBoy, como o conjunto de instruções RISC-V
  • scripts: scripts que não pertencem a outros diretórios
  • software: coleção de arquivos C usada em testes de nível de sistema; ainda não é uma árvore de software prática
  • synth: diretório de trabalho para a síntese do sistema completo, incluindo o Makefile de nível superior e arquivos de restrições de pinos
  • test: coleção de testes de regressão que inclui testbenches Verilog e casos de teste de software executados em simulações do processador ou do sistema completo

Leituras relacionadas

1 comentários

 
GN⁺ 4 시간 전
Opiniões no Hacker News

  • Na página do GitHub, ele é apresentado como um Game Boy Advance de um universo paralelo onde o RISC-V existia em 2001
    É descrito como uma carta de amor aos consoles portáteis da infância e como um projeto que parece uma mensagem de texto enviada às 3 da manhã, bêbado, para a tecnologia que fazia aqueles consoles funcionarem

  • É um trabalho de Luke Wren, que é engenheiro de projeto de ASIC na Raspberry Pi. Projeto realmente incrível

    • Chamar ele apenas de engenheiro de projeto de ASIC subestima seu papel, já que ele também participa do desenvolvimento de núcleos de CPU

  • Esse desenvolvedor também projetou o PicoDVI, que implementa DVI/HDMI no RP2040
    https://github.com/Wren6991/PicoDVI

    • Trabalhando na Raspberry Pi, ele projetou o núcleo RISC-V Hazard3, peça central do RP2350. No entanto, o Hazard3 foi desenvolvido no tempo livre e é um projeto derivado do núcleo Hazard5, que ele havia projetado para o RISCBoy

  • O GBA foi projetado com uma arquitetura sem cache. Tirando RAM interna, VRAM, registradores de E/S, BIOS, OAM, paleta e afins, todo acesso passa pelo barramento externo, e usar esse barramento sem cache o torna, na prática, tão lento quanto um computador dos anos 1980. A velocidade de busca de instruções a partir do cartucho também é apenas cerca de duas vezes maior que a do GBC
    Para evitar isso, é preciso usar cache para buscar várias palavras em sequência. Aumentar a velocidade do acesso sequencial eleva a taxa de transferência e, se instruções e dados puderem ser suficientemente colocados em cache, dá para esconder a latência. Fico curioso se esse sistema envia todas as buscas para o barramento de memória ou se usa cache

  • Esse projeto foi tape-outado na primeira execução de produção da wafer.space (https://github.com/wafer-space/ws-run1 para referência), mas não ouvi dizer se chegou a funcionar corretamente na prática

  • O pipeline de renderização baseado em buffer de scanline programável apresentado no PDF vale a leitura para quem se interessa por esse tipo de tecnologia

  • Eu realmente adoro projetos que imaginam e criam hardware de universos paralelos

  • Fico curioso se, ao adotar essa nova arquitetura de hardware, a maior dificuldade está na tecnologia em si ou na ausência de um ecossistema de desenvolvedores e cadeia de ferramentas de software já estabelecidos

    • Os dois são problemas. Depende do que exatamente se quer construir, mas, em geral, desenvolver hardware é mais difícil e também mais caro do que desenvolver software
      A falta de ferramentas de software dá para contornar, mas a ausência de bibliotecas de jogos é uma barreira ainda maior. Especialmente se não houver uma forma muito fácil de portar títulos existentes

  • É surpreendente saber que dá para usar uma implementação open source de AHB/APB internamente. Eu achava que era uma tecnologia proprietária da ARM e por isso nunca fui muito a fundo

    • AMBA é um padrão aberto há muito tempo, e, pelo que sei, provavelmente desde quando foi anunciado pela primeira vez

  • Acho que o desenvolvedor desse projeto é um dos maiores engenheiros da nossa era. Só isso já seria impressionante, mas ele também projetou o núcleo Hazard3 e o dispositivo QSPI do RP2350
    Em especial, esse dispositivo QSPI é o único dispositivo QSPI com mapeamento de memória que já usei e que nunca consegui travar ou fazer colidir

    • Concordo com essa avaliação do QSPI, e o RP2350 é um chip extraordinário. Tem aplicações incontáveis e é como uma chave de fenda sônica para ferramentas de hacking de barramento