Skip to content

Meeting Summary: CS 631-02 Systems Foundations

  • Date: Apr 16, 2026
  • Time: 02:53 PM Pacific (US and Canada)
  • Meeting ID: 882 2309 0019

Quick Recap

The session focused on next steps and requirements for Project 4. Greg guided students through implementing an instruction decoder for a RISC-V processor. He demonstrated the complete data and control path, including the register file, ALU, instruction memory, and decoders, and explained how to extract register fields and immediate values from instruction words.

The central task is to populate a spreadsheet with control line values for different instructions. These values will be used to generate a ROM that drives how the processor executes each instruction. Greg also covered:

  • Branch unit logic for conditional branches
  • RAM design supporting multiple data sizes (byte, word, double-word)
  • A recommended workflow: implement a few instructions, run the autograder, iterate until all tests pass

Next Steps

  • Greg:
  • Post additional lecture recordings and notes.
  • Add the link to the Digital application (Java program/JAR) to the project specification.

  • Share details on the minor autograder configuration referenced in the transcript.

  • Students:

  • Install the Digital application (if not already installed) and configure the autograder’s config.toml if Digital is not in the default home directory.
  • Import the provided Project Forward Decoder spreadsheet into Google Sheets and begin populating control line values as described.
  • Use the provided Python script to generate the ROM output bits/hex file from the completed spreadsheet, then load it into the project ROM.
  • Work incrementally: fill out control values for a few instructions, run the autograder after each update, and continue until all required instructions pass.

Summary

Processor Implementation Progress

Greg reported that the processor’s technical components are usable, though the full schematic visualization is still in progress. The plan is to automate instruction execution by decoding register selection (e.g., RS1, RD/“RR1”) and selecting ALU operations from opcodes and function codes. The scope is designed to be achievable within a week while still requiring meaningful problem-solving.

Project 4 Circuit Plan

Greg outlined next steps: wire components and implement the instruction decoder. The primary student task is to understand the circuit and set correct control line values in the Project 4 file. He will provide a methodology and examples for encoding control bits via a ROM. Autograder tests and the Digital application will be available for verification.

Instruction Execution Flow

Greg explained how programs load into instruction memory and how termination is detected using a reserved “unimplemented” instruction value. Jump/branch targets are computed by adding the PC to a signed offset. A register decoder demonstration with an ADDI instruction showed how RS1, RD, and RS2 are extracted. A probe tool was introduced for monitoring wire values during simulation.

Data Path Overview

Greg walked through the data path and instruction execution sequence, showing a simple addition program executing one instruction at a time. He emphasized that this processor is not pipelined and performs no instruction-level parallelism. The instruction decoder determines control signals and data routing each cycle.

Instruction Decoding

Using an ADDI example, Greg demonstrated how bit fields in the instruction word are matched against known patterns to identify instruction types (e.g., I-type, R-type). Multiple detection circuits evaluate in parallel; their outputs determine the final control line values.

ALU Operation and Priority Encoding

The ALU computes all candidate operations in parallel. A control signal selects the correct result based on the decoded instruction. A priority encoder consolidates multiple one-bit “matches” into a single instruction number (INUM), which indexes the ROM to fetch control outputs.

ROM Control Outputs and Spreadsheet

Students will use a spreadsheet to define control outputs per instruction. These outputs are concatenated into binary values that populate the decode ROM. INUM indexes the ROM to retrieve control lines. Greg will demonstrate filling out initial rows and clarified the required files: the instruction decoder and the main project circuit.

Bit Extraction and Routing

Greg described hardware-level bit extraction and routing, comparing it to software bitwise operations in C or Rust. He emphasized that hardware directly processes signals, avoiding multi-instruction software overhead. A brief aside noted an estimated headquarters timing of approximately 15 months.

RISC-V Spreadsheet Evolution

Greg explained how to evolve the spreadsheet by importing Excel into Google Sheets. Each row includes: - Instruction identification and assembly mnemonic - Opcode/func3/func7 (or equivalent) encodings - Detection order matching the priority encoder inputs - Control values for ALU ops, register file writes, and related signals

Maintaining consistent instruction order with the detection logic is critical.

ALU Input Values and Hex Generation

Greg showed how to determine ALU input selections and convert spreadsheet outputs into a hex file for the decode ROM using the provided Python script. The circuit structure is similar to an earlier version but now routes immediate values to the ALU more frequently, increasing input options.

Branch Unit and RAM

  • Branch Unit:
  • Supports comparisons such as BEQ, BNE, VLT, VGE

  • Selects between PC+4 and the computed target based on PC-select control

  • RAM:

  • Configured for 64-bit elements with 7 address bits (128 entries)
  • Supports byte, word, and double-word operations
  • A size parameter determines how data is read/written and whether full 64-bit output is used

64-bit Data Storage and Access

Greg detailed load/store behavior in a 64-bit system: - Word/byte selectors access specific portions of 64-bit data - Store operations use read-modify-write to update subword regions safely - Students should build logic incrementally and rely on tests/autograder for validation

Greg will post lecture recordings and notes on GitHub and reminded students to install required software and configure the autograder as needed.