CS 631-01 Systems Foundations — Meeting Summary¶

Date: Apr 16, 2026
Time: 08:11 AM Pacific Time (US and Canada)
Meeting ID: 870 0988 0761

Quick Recap¶

Greg led a detailed discussion on RISC-V processor design, focusing on:

Implementing instruction decoding and control signals.
Roles of key decoders: register (reg) decoder, immediate decoder, and main instruction decoder.
A spreadsheet-driven process to determine control outputs for various instructions and to generate ROM contents for the instruction decoder.
Adding branching logic and memory access paths, including handling different data sizes with a 64-bit RAM.
A walkthrough of circuit components in Digital (simulation tool), emphasizing data and control paths for correct processor behavior.
Assurance that starter code, project descriptions, and recordings will be provided in the GitHub repository.

Greg:
Release the Project 4 starter code, GitHub repository, project description, and recordings.
Include instructions for the “MakeRom” process and related workflow in the project description.
Students:
Work through the provided spreadsheet to update control output values for each supported instruction, ensuring control and data paths are understood and implemented.
Update the ROM in the processor design with the spreadsheet-generated output bits to pass autograder tests.
Implement and test updates incrementally, getting subsets of tests to pass before adding more instructions.
Complete the project deliverables (populate the spreadsheet, update the ROM, and pass all tests) within approximately one week.

Greg reviewed the project status and outlined a plan for the team to continue development over the next week.
He described the main instruction decoder and its subcomponents.
The team’s immediate task: provide control signals and decoder logic via a structured spreadsheet process.
All recordings, notes, and guides will be made available to support this work.

Control lines will be set via instruction word decoding, mirroring the emulator’s approach.
Instruction fields (opcode, func3, func7) will drive inputs to the register file and ALU (e.g., destination register writes, ALU ops).
Initial execution target: a simple program that halts on the unimp instruction.
Requires basic ALU functionality (e.g., add) and immediate handling.
Current limitation: single-instruction execution without branch or jump support.

The 32-bit instruction word is split into RS1, RS2, and RD fields for operations.
Immediate extraction and reformatting are implemented for I-, S-, B-, U-, and J-types (demonstrated in Eagle).
An enable mechanism prevents state updates until execution is explicitly started.

Immediate decoding for S-type and B-type instructions uses splitters, mergers, and sign extension to produce 64-bit values.
A comparator circuit detects unimp and halts the clock to stop execution.
Instruction memory is structured so program selection chooses the instruction word input.
Control lines drive MUXes and other decoder components.

A spreadsheet enumerates instructions and their control/data paths.
Columns include opcode, func3, func7, func6, and auto-generated control outputs.
Generated output bits populate a ROM to set control signals for data-path components.

Opcode, func3, and func7 are extracted from the instruction word.
Select bits determine data sources for the register file and PC.
A priority encoder consolidates multiple matches to a single encoded index for ROM control bits.
Instruction identification is performed by matching fixed bit patterns.

Instruction matches are based on fixed opcode and func3 fields (with comparators).
Implementations cover I-type, R-type, and J-type instructions.
The circuit evolves with added MUX pathways to support new instructions.
A spreadsheet template and circuit will be provided; ROM-loading details to follow.

Greg planned a demonstration for populating the spreadsheet and transferring control signals to the decode ROM.
He noted the manual process is tedious and suggested a potential code-based approach to generate variants with different instruction subsets.
He also discussed plans to incorporate GenAI and agent-focused coursework in future semesters.

Simulation improvements include run, reset, single-step, and stop/kill features.
Layout challenges (notably around the ALU) are being addressed.
Probes act like printf for digital circuits; specific outputs are required for autograder tests.
Participants were encouraged to explore the provided code and ask questions.

Project 4 versions (V0, V1, V2) were compared; later versions support additional instructions.
The final version must include data memory support for stack operations and register saves.
Discrepancies in instruction sets across versions were identified and will be resolved.
A clarifying exercise was proposed; a V1 run revealed some issues to be fixed.

A spreadsheet process was shown to generate output bits for processor components and convert them into .hex for ROM loading.
The instruction decoder and ROM coordinate instruction handling across the data path.
The branch unit determines next PC via PC+4 or a target address, based on instruction type and branch conditions.

A digital RAM component design supports 64-bit reads/writes in a single clock, plus byte and word operations.
Handling of different sizes involves extracting and manipulating segments of 64-bit values using address and word selectors.
Students are tasked with implementing the RAM component and passing tests by updating the spreadsheet and ROM.
Timeline: approximately one week, with an OS unit starting the following week.