Solo Squash (a Caravel User Project)

Overview

This is a simple hardware video game digital design made by Anton Maurovic, as a possible student submission for the Zero to ASIC course, and in this case designed to target a Caravel ASIC as part of the Google Skywater Open MPW shuttle program, in collaboration with Efabless.

The design itself is a Verilog HDL project that implements a primitive digital-logic-based video game that resembles Pong, but with one player just bouncing a ball within a 3-walled space, resembling a game of squash but with just 1 paddle.

To read a lot more about this project, see the much-more-detailed README for the base design in my solo_squash repo.

License

This repo, the project itself, and all related files are licensed with Apache 2.

Cloning this repo

This code uses at least one git submodule, so to clone it make sure you do:

git clone --recursive https://github.com/algofoogle/solo-squash-caravel-v2

...which will make sure solo_squash is also pulled in at verilog/rtl.

If you feel you need to, you could also update submodules to their latest commits by doing:

git pull --recurse-submodules

...but the chosen commit as specified by this solo-squash-caravel-v2 repo is the one that was last successfully used, so you probably don't want to change that.

Details

This is intended to drive a VGA display at 640x480 resolution, ~60Hz, and it could be adapted to different targets, including FPGA, Verilator-based VGA simulation, and Caravel ASIC.

It has been tested on a DE0-Nano FPGA board (Altera Cyclone IV), along with Verilator, and other formal testing (i.e. Icarus Verilog and cocotb).

Its inputs are:

Core:
    clock                       (25.175MHz ideal for VGA, 25.000MHz OK)
                           See: https://caravel-harness.readthedocs.io/en/latest/external-clock.html
    resetb                      (SoC reset, i.e. full reset. Also resets our design)

The following may only be operational after SoC firmware has finished executing
(but that's within a few hundred microseconds of power-up, and only part-way
through the first frame anyway):
    GPIO[ 8]    <- ext_reset_n  (External active-low reset)
    GPIO[ 9]    <- pause_n      (Momentary pause, active-low)
    GPIO[10]    <- new_game_n   (Reset game state without full reset, active-low)
    GPIO[11]    <- up_key_n     (Move paddle up, active-low)
    GPIO[12]    <- down_key_n   (Move paddle down, active-low)

Its outputs are:

The following may only be active after SoC firmware has finished executing,
and hi-Z otherwise. They also go hi-Z during reset (either resetb or
ext_reset_n being asserted):

    GPIO[13]    -> red          (VGA red channel on/off via 270R resistor => 0.7V nominal)
    GPIO[14]    -> green        (VGA green channel, as above)
    GPIO[15]    -> blue         (VGA blue channel, as above)
    GPIO[16]    -> hsync        (VGA HSYNC, via 100R safety resistor)
    GPIO[17]    -> vsync        (VGA VSYNC, via 100R safety resistor)
    GPIO[18]    -> speaker      (Speaker, ideally should run to an amplifier to avoid overcurrent)

The following may only be active after SoC firmware is finished, but they
remain active even during a reset (for debugging reasons):

    GPIO[19] -> debug_design_reset  (Follows internal reset state, based on ext_reset_n/resetb)
    GPIO[20] -> debug_gpio_ready    (Pulsed by SoC internally to show when GPIO config is finished)