Skip to content

About

The SoC for the introduction to chip design course spring 2026

Resources

Stars

21 stars

Watchers

2 watching

Forks

Latest commit

 

History

487 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

DTU SoC 2026 - Caravel User Project

License Scalatest CI Hardening Precheck

The Student Chip Design Project

This is the repository for the student chip design project for the course "Introduction to Chip Design" at DTU in 2026 (web page). The project involves designing a custom SoC using the Caravel user project template and integrating it with a Chisel-based RISC-V processor (Wildcat) and various peripherals.

The project is in fabrication at ChipFoundry, through the Skywater 130nm process and will be available for testing and use by the students.

Chip Layout

KLayout rendering of the OASIS file after tapeout

DTU Chip 2026

Chip Content

  1. The RISC-V processor Wildcat
  2. Two instruction memories initialized from Caravel via a Wishbone bus
  3. Data scratchpad memory implemented as an OpenRAM macro
  4. Data cache
  5. VGA controller with terminal functionality
  6. A ray tracing accelerator as a co-processor
  7. A SPI controller for off-chip memory access
  8. A floating-point unit
  9. A VGA clock
  10. A multicore system with 6 PicoRV32 cores and two scratchpad memories connected via the S4NoC
  11. A Wildcat core with an instruction memory initialized from a UART

This chip is 10 mm2 in size and will be fabricated in the Skywater 130nm process.

GDS Viewer

Chisel Project Setup

This repository contains a starting point for integrating a Chisel project into the Caravel harness using Librelane.

To use Chisel you need to have a JDK (up to 21) and sbt installed. See Chisel Setup.

Note that this repository contains Wildcat as a submodule. Therefore, check it out with:

git clone --recursive git@github.com:os-chip-design/dtu-soc-2026.git

Later you can update the submodules with:

git submodule update --init --recursive

To work with caravel, you will have to install the cf-cli tool and fetch dependencies using (best with a Python venv):

python3 -m venv venv
source venv/bin/activate
pip install chipfoundry-cli
cf setup

Whenever you work on a change do first:

git pull
git submodule update --init --recursive

The starting project includes a Chisel top-level module (CaravelUserProject) containing a simple GCD calculator which is connected to the Caravel's wishbone bus and GPIOs. The verilog for the CaravelUserProject module is generated by running:

make chisel-generate

The project contains a fixed OpenRAM macro. To avoid picking up the default OpenRAM macro delete the macros from the PDK (in dependencies/...)

The Chisel top-level is hardened separately as a macro which is placed into the Caravel user_project_wrapper. The configuration files for both are located in the openlane/ directory. They are hardened using the following commands:

cf harden RayTracerController
cf harden PicoMeshBigTop
cf harden CaravelUserProject
cf harden user_project_wrapper

There is a Make target (make all) which runs all the above commands in sequence form git pull until cf precheck.

You can use nix run to run part of LibreLane wihout cloning it. E.g., switch to the folder of the Caravel top-level and view the generated GDSII layout with:

nix run github:librelane/librelane -- --last-run --flow openinklayout config.json

The Chisel modules can be tested in Scala by calling:

make chisel-test

An integration test for the whole Caravel system can be run using cocotb. An example test case is included, which uses the GCD component and checks its output in verilog/dv/cocotb/user_proj_tests/gcd_example_test. To run this test, execute the following command:

cf verify --all

Group Projects

Group 0: CPU Addressable Memory

  • Mads A. Pedersen
  • Mathias Schyth
  • Filippo Pruzzi
  • Bertram Fink-Jakobsen

Add a SPI memory controller module between CPU and external memory (off-chip) SPI done, noy tested yet in an FPGA. ChiselTest of cache.

Group 1:

  • Martin Mejer (s235469)
  • Sebastian Tobias Holdt (s235475)
  • Karl Petersen (s235481)

VGA controller done. Communication bewteen Caravel and Wildcat done.

Group 2:

  • Célien Abbet
  • Amaury Chevoir
  • Aldric Rüedi

Goal: We replace the synthesized internal data memory of the Wildcat processor with a dense SRAM macro generated by OpenRAM. The work includes interface adaptation, RTL verification, Caravel integration, hard-macro hardening, and comparison of area and implementation complexity against the original memory solution.

Working with OpenRAM, but run into troubles. Did the system figure.

Group 3:

  • Amirhossein Yavarikhoo
  • Alireza Amirinejad Daryasari

Booting from Wishbone. Did a second booting memory. Working on booting fomr cocotb test via UART in simulation.

Group 4: Hardware Accelerated Ray Tracing

  • Rifki Firdaus (s250169)
  • Aoxuan Wang (s252619)
  • Christian Paus Damsgaard (s235255)
  • Roméo Clément Estezet (s234602)

Ray tracing will be connected to Wishbone. Did all GitHub actions. Output not yet decided.

Group 5:

  • Theodoros Pontzouktzidis (s250239)
  • Dimitrios Vlachos (s243192)

We will implement an SPI based memory controller. Commited SPI contoller. Group 5 report

Group 6:

  • Tore Kofod Beyer (s234377)

Run the whole project (including Caravel) in an FPGA - too much effort, Caravel is not designed for FPGA.

Booting from Wishbone (into OpenRAM memory).

Notes:

  • maybe ncs could be tied to GND
  • We also need to reset Wildcat from Caravel

Block diagram of the entire project

Block diagram

Needed Work (TODO List)

  • CI with LibreLane synthesis (Group 0)
  • Add Wildcat in repo (like the exercise) (Group 1)
  • CI with Wildcat in the test (Group 1)
  • Check compiler option for RV32IE (16 registers) (Group 5)
  • Block diagram in the README (Group 2)
  • Explore macro timing with LIB files (Group 4)
  • Harden with cf in CI (Roméo) (Group 4)
  • Fix any violations in CaravelUserProject hardening (pin assignment, placement, or config values)
  • What is the clock frequency in the board: 10 MHz
  • Need to check using the right IO pins (some are reserved by Caravel)
  • Adapt VideoController to use VGA pmod from TT (Group 1)
  • Add a super simple test for the VideoController (Group 1)
  • Use 10 MHz in the design (UART, VGA)
  • Booting from Wishbone (Group 6 and Group 3)
  • Adapt FPGA/VGA test to 10 MHz (Group 1)
  • Connect the UART and test
  • Wildcat Caravel communication (Group 1)
  • Reset port (Group 1)
  • Add .lib files and fix the timing
  • Test for serial port (UART) on Wildcat
  • data memory should extend PipeConDevice

Caravel Documentation

The remaining documentation is a general guide from the Caravel user project template.

Table of Contents

Overview

This repository contains a user project designed for integration into the Caravel chip user space. Use it as a template for integrating custom RTL with Caravel's system-on-chip (SoC) utilities, including:

  • IO Pads: Configurable general-purpose input/output.
  • Logic Analyzer Probes: 128 signals for non-intrusive hardware debugging.
  • Wishbone Port: A 32-bit standard bus interface for communication between the RISC-V management core and your custom hardware.

Documentation & Resources

For detailed hardware specifications and register maps, refer to the following official documents:


Prerequisites

Ensure your environment meets the following requirements:

  1. Docker Linux | Windows | Mac
  2. Python 3.8+ with pip.
  3. Git: For repository management.

Project Structure

A successful Caravel project requires a specific directory layout for the automated tools to function:

Directory Description
openlane/ Configuration files for hardening macros and the wrapper.
verilog/rtl/ Source Verilog code for the project.
verilog/gl/ Gate-level netlists (generated after hardening).
verilog/dv/ Design Verification (cocotb and Verilog testbenches).
gds/ Final GDSII binary files for fabrication.
lef/ Library Exchange Format files for the macros.

Starting Your Project

1. Repository Setup

Create a new repository based on the caravel_user_project template and clone it to your local machine:

git clone <your-github-repo-URL>
cd <project_name>

You need to install the ChipFoundry CLI tool to manage your project and run the necessary commands for setup, hardening, and verification. Best is to install it in a Python virtual environment:

python3 -m venv venv
source venv/bin/activate
pip install chipfoundry-cli

2. Project Initialization

Important

Run this first! Initialize your project configuration:

cf init

This creates .cf/project.json with project metadata. This must be run before any other commands (cf setup, cf gpio-config, cf harden, cf precheck, cf verify).

3. Environment Setup

Install the ChipFoundry CLI tool and set up the local environment (PDKs, OpenLane, and Caravel lite):

cf setup

The cf setup command installs:

  • Caravel Lite: The Caravel SoC template.
  • Management Core: RISC-V management area required for simulation.
  • OpenLane: The RTL-to-GDS hardening flow.
  • PDK: Skywater 130nm process design kit.
  • Timing Scripts: For Static Timing Analysis (STA).

Development Flow

Hardening the Design

Hardening is the process of synthesizing your RTL and performing Place & Route (P&R) to create a GDSII layout.

Macro Hardening

Create a subdirectory for each custom macro under openlane/ containing your config.tcl.

cf harden --list         # List detected configurations
cf harden <macro_name>   # Harden a specific macro

Integration

Instantiate your module(s) in verilog/rtl/user_project_wrapper.v.

Update openlane/user_project_wrapper/config.json environment variables (VERILOG_FILES_BLACKBOX, EXTRA_LEFS, EXTRA_GDS_FILES) to point to your new macros.

Wrapper Hardening

Finalize the top-level user project:

cf harden user_project_wrapper

Verification

1. Simulation

We use cocotb for functional verification. Ensure your file lists are updated in verilog/includes/.

Configure GPIO settings first (required before verification):

cf gpio-config

This interactive command will:

  • Configure all GPIO pins interactively
  • Automatically update verilog/rtl/user_defines.v
  • Automatically run gen_gpio_defaults.py to generate GPIO defaults for simulation

GPIO configuration is required before running any verification tests.

Run RTL Simulation:

cf verify <test_name>

Run Gate-Level (GL) Simulation:

cf verify <test_name> --sim gl

Run all tests:

cf verify --all

2. Static Timing Analysis (STA)

Verify that your design meets timing constraints using OpenSTA:

make extract-parasitics
make create-spef-mapping
make caravel-sta

Note

Run make setup-timing-scripts if you need to update the STA environment.


GPIO Configuration

Configure the power-on default configuration for each GPIO using the interactive CLI tool.

Use the GPIO configuration command:

cf gpio-config

This command will:

  • Present an interactive form for configuring GPIO pins 5-37 (GPIO 0-4 are fixed system pins)
  • Show available GPIO modes with descriptions
  • Allow selection by number, partial key, or full mode name
  • Save configuration to .cf/project.json (as hex values)
  • Automatically update verilog/rtl/user_defines.v with the new configuration
  • Automatically run gen_gpio_defaults.py to generate GPIO defaults for simulation (if Caravel is installed)

GPIO Pin Information:

  • GPIO[0] to GPIO[4]: Preset system pins (do not change).
  • GPIO[5] to GPIO[37]: User-configurable pins.

Available GPIO Modes:

  • Management modes: mgmt_input_nopull, mgmt_input_pulldown, mgmt_input_pullup, mgmt_output, mgmt_bidirectional, mgmt_analog
  • User modes: user_input_nopull, user_input_pulldown, user_input_pullup, user_output, user_bidirectional, user_output_monitored, user_analog

Note

GPIO configuration is required before running cf precheck or cf verify. Invalid modes cannot be saved - all GPIOs must have valid configurations.


Local Precheck

Before submitting your design for fabrication, run the local precheck to ensure it complies with all shuttle requirements:

Important

GPIO configuration is required before running precheck. Make sure you've run cf gpio-config first.

cf precheck

You can also run specific checks or disable LVS:

cf precheck --disable-lvs                    # Skip LVS check
cf precheck --checks license --checks makefile  # Run specific checks only

Checklist for Shuttle Submission

  • Top-level macro is named user_project_wrapper.
  • Full Chip Simulation passes for both RTL and GL.
  • Hardened Macros are LVS and DRC clean.
  • user_project_wrapper matches the required pin order/template.
  • Design passes the local cf precheck.
  • Documentation (this README) is updated with project-specific details.

About

The SoC for the introduction to chip design course spring 2026

Resources

Stars

21 stars

Watchers

2 watching

Forks

Releases

Packages

Contributors

Languages