Vector CPU

Vector-CPU-Tape-out

A single-cycle RISC-V CPU with a small subset of the RISC-V Vector (RVV) extension. It was designed in SystemVerilog and taken from RTL to GDS for a 180 nm tape-out in UCLA EE209AS (2026).

The core runs a subset of RV32I plus vsetvli, unit-stride 32-bit vector loads and stores, and four vector ALU ops on a 4-lane, 128-bit SIMD datapath. The chip has only 23 signal pins, so programs are loaded one byte at a time over an 8-bit port. A debug mode streams every write-back result out over an 8-bit output bus.

Repository layout

Architecture

• Single-cycle scalar core. Fetch, decode, execute, memory and write-back all happen in one clock. The instruction and data memories are read combinationally, so the longest path is a load that goes through both memories in one cycle.
• Vector unit added next to the scalar datapath:
  • VLEN = 128 bits, SEW = 32 only, LMUL = 1 only, so VLMAX = 4
  • 4 vector registers (v0–v3), unmasked instructions only
  • simd_alu_4lane: four 32-bit lanes in parallel, with tail-undisturbed or tail-agnostic handling (the agnostic tail is written with all 1s)
  • Vector loads and stores share the one data-memory port with the scalar core and take one 32-bit element per cycle
• Memories (set as parameters in chip_top): 32-word instruction memory, 64-byte data memory.
• Illegal or unsupported instructions stop the CPU. The PC stays where it is, so a program ends by running into an unloaded (all-zero) word.

Supported instructions

Chip interface

14 inputs, 9 outputs, plus VDD and VSS. Everything runs on one clock (clk, with a 10 ns / 100 MHz target).

Operating the chip

1. Reset: pulse rst.
2. Load the program: raise load_mode. For each 32-bit instruction, send 4 bytes least-significant byte first, holding instr_byte_valid high for one clock per byte. Words are written in order starting at address 0.
3. Run: lower load_mode and raise cpu_en. Execution starts at PC 0.
4. Observe (optional): with debug_stream_mode high, each result the core writes back goes out as 4 bytes, LSB first, with stream_valid_out high. Results come from scalar rd writes, the new vl from vsetvli, each vector-load element, and each lane of a SIMD result. The core stalls while it streams, so no results are lost. With debug_stream_mode low, the core runs at full speed and nothing is streamed.

Verification

The testbenches in Vector_CPU/tb/ check themselves. They load a program through the byte port, step through it checking the scalar and vector registers, then check that the debug output stream matches the expected sequence of words.

Physical design flow

The design was implemented with Hammer driving Cadence Genus (synthesis), Innovus (place and route), Tempus (STA) and Conformal (equivalence), Mentor Calibre (DRC/LVS), and Synopsys VCS (RTL and gate-level simulation).

• design/design.yml: top module, RTL file list, clock and I/O constraints, a 600 × 720 µm floorplan, pin placement and the power-ring/strap script
• design/tb.yml: simulation setup for RTL, post-synthesis and post-PAR runs

Note on the PDK: the process design kit is under NDA. In the published design.yml files, process-specific values (technology, node, cell names, metal layer names and design-rule values) are replaced with <placeholders>. Fill these in from your own PDK before running Hammer. Hammer's own configs (env.yml and the tech plugin) are not included.

The input_files paths in the configs (../ECE209/...) are relative to the original Hammer run directory. Update them to point at Vector_CPU/rtl/ and Vector_CPU/tb/ in this repo.

Test PCB

Vector_CPU/PCB/ has the KiCad project for the chip-testing PCB: schematic, board layout, and the chip's symbol and footprint.