Architecture & Design Verification: 10. SystemC Tutorial - Program Counter & Instruction Fetch

Introduction

The Program Counter is the simplest register in the CPU. One word wide, one operation per clock: add four. Yet it is the register that determines everything — what instruction executes next, whether a branch was taken, whether the CPU is making forward progress or spinning in a loop. Every other register in the machine holds data. The PC holds control.

That simplicity is deceptive in two ways.

First, deceptively simple to implement incorrectly. A PC that increments by 4 works for sequential code. But the moment a program contains a branch, a jump, or a function call, the next PC is not pc + 4 — it is a function of execution results not known until late in the pipeline. In a single-cycle design like ours, that computation happens before the clock edge, so it is just combinational logic. But in a pipelined CPU, the PC must be updated speculatively, and a mispredicted branch means the speculatively-fetched instructions are wrong. The Cortex-A72 (used in the Raspberry Pi 4) has a 15-stage pipeline — a branch misprediction wastes 15 cycles of fetch bandwidth. The RISC-V SiFive U74 core uses a gshare branch predictor precisely to keep the misprediction rate below 5%. Even in our single-cycle design, the PC logic is the gateway through which every instruction enters the machine.

Second, deceptively simple to test incorrectly. Most engineers test the PC by checking that it increments. That is necessary but not sufficient. The real corner cases are: reset goes to address zero, a branch to address zero works (not just "reset looks like a branch"), JAL computes a PC-relative offset correctly at the maximum positive and negative offsets, JALR forces the lowest bit to zero per the RISC-V spec. Skipping these is how subtle control-flow bugs survive into silicon.

This post builds two modules:

pc — the Program Counter register with a next-PC multiplexer
imem — the Instruction Memory ROM, combinational read from a flat array

Together they form the fetch stage of our RISC-V CPU: given a PC, produce an instruction. The PC advances each cycle unless a branch or jump redirects it.

Prerequisites

Post 8 — Register File (SC_CTHREAD, synchronous reset pattern)
Post 9 — Instruction Decoder (encoding tables, field extraction)
Code for this post: GitHub — section2/post10

The Fetch Stage in Context

Before writing a line of code, orient the two modules in the full CPU datapath:

graph LR
    subgraph "Fetch Stage (This Post)"
        PC["pc module\n─────────\npc_out[31:0]"]
        IMEM["imem module\n─────────\ninstr[31:0]"]
        PC -->|pc_out| IMEM
    end

    subgraph "Control Inputs"
        BR["branch_taken\nbranch_offset[31:0]"]
        JMP["jump\njump_target[31:0]"]
        RST["clk / rst_n"]
    end

    subgraph "Downstream (Posts 9, 11+)"
        DEC["Instruction\nDecoder"]
        RF["Register\nFile"]
    end

    BR --> PC
    JMP --> PC
    RST --> PC
    IMEM -->|instr[31:0]| DEC
    DEC --> RF

    style PC fill:#06b6d4,color:#fff
    style IMEM fill:#10b981,color:#fff
    style DEC fill:#6366f1,color:#fff
    style RF fill:#f59e0b,color:#fff

The pc module is sequential: it updates on the clock edge. The imem module is combinational: it responds immediately to pc_out. That is why instruction fetch has zero latency after the PC updates — the ROM output is ready by the time the decoder needs it.

SystemC Language Reference

The table below is a quick-reference for every construct used in this post. Keep it open while reading the implementation sections.

Construct	Syntax	SV / Verilog Equivalent	Key Difference
Sequential PC register	`SC_CTHREAD(pc_reg_proc, clk.pos()); async_reset_signal_is(rst_n, false)`	`always_ff @(posedge clk or negedge rst_n)`	SystemC reset block is explicit C++ code; SV uses `if (!rst_n)` guard
Active-low async reset	Reset section before first `wait()` in SC_CTHREAD	`always_ff @(posedge clk or negedge rst_n) if (!rst_n) pc <= 0;`	SystemC separates reset body from main loop at language level
Combinational next-PC	`SC_METHOD(next_pc_proc); sensitive << branch_taken << ...`	`always_comb` with all inputs auto-sensed	SV `always_comb` infers sensitivity automatically; SystemC requires explicit list
Internal wire	`sc_signal<sc_uint<32>> next_pc_sig`	`logic [31:0] next_pc_sig`	`sc_signal` is a channel object; SV `logic` is a storage type
Combinational ROM read	`SC_METHOD(read_proc); sensitive << addr`	`assign instr = mem[pc>>2]` (classic) or `always_comb` (SV)	SystemC process fires on signal events, not continuous assignment
Word-aligned index	`byte_addr.range(31,2)`	`pc[31:2]` (classic Verilog) / `pc >> 2` (SV expression)	`sc_uint::range()` returns a sub-range value; SV slice syntax is cleaner
Force bit 0 to zero	`sc_uint<32> t = target; t[0] = 0;` or `target & sc_uint<32>(0xFFFFFFFEu)`	`{target[31:1], 1'b0}` (classic) / `target & 32'hFFFFFFFE` (SV)	SystemC bit-index assignment works on lvalue; SV concatenation is read-only
ROM initialization	`std::ifstream` + `std::hex >> word` in constructor	`$readmemh("file.hex", mem)`	SV built-in; SystemC uses standard C++ I/O — more flexible, more code
PC + constant	`pc_out.read() + 4`	`pc + 4` (implicit)	`.read()` required for sc_signal; SV wire reads implicitly
Signed offset addition	`(sc_int<32>)pc + (sc_int<32>)offset`	`$signed(pc) + $signed(offset)` (classic) / just `+` on `logic signed`	Must cast to `sc_int` for signed semantics; unsigned `sc_uint` wraps as expected

Translation Table

Concept	SystemVerilog	C++	SystemC
Sequential PC register	`always_ff @(posedge clk)`	n/a	`SC_CTHREAD(pc_proc, clk.pos())`
Async active-low reset	`if (!rst_n) pc <= 0;`	n/a	`if (!rst_n.read()) { pc_reg = 0; }` in reset loop
Combinational next-PC	`always_comb`	`uint32_t next = ...`	`SC_METHOD(next_pc_proc)`
Combinational ROM read	`assign instr = mem[pc>>2];`	`instr = mem[addr/4]`	`SC_METHOD(read_proc)`
Word-aligned index	`pc[31:2]` (drop lower 2 bits)	`pc >> 2`	`pc_in.read() >> 2`
Force bit 0 to zero (JALR)	`{target[31:1], 1'b0}`	`target & ~1u`	`sc_uint<32> t = target; t[0]=0;`
ROM initialization	`$readmemh("prog.hex", mem)`	`fread` / `std::ifstream`	`std::ifstream` in constructor

The key architectural difference from SystemVerilog: in SystemVerilog, always_ff and always_comb live in the same module file and share local signals without effort. In SystemC, you separate the sequential register update (SC_CTHREAD) from the combinational next-PC logic (SC_METHOD) using internal sc_signal wires. This separation makes the design more explicit — every value has a named signal — and is the pattern used throughout this series.

PC Next-Value Logic

The RISC-V ISA defines four sources for the next PC:

Condition	Next PC	RISC-V Instructions
Normal flow	`pc + 4`	All non-branch, non-jump
Branch taken	`pc + sign_extend(offset)`	BEQ, BNE, BLT, BGE, BLTU, BGEU
JAL (jump-and-link)	`pc + sign_extend(offset)`	JAL
JALR (jump-and-link register)	`(rs1 + sign_extend(imm)) & ~1`	JALR

The & ~1 on JALR is mandatory per the RISC-V spec (section 2.5): "The target address is obtained by adding the sign-extended 12-bit I-immediate to the register rs1, then setting the least-significant bit of the result to zero." This prevents jumping to a misaligned instruction. If your implementation omits this bit-clear, a program that computes a JALR target with an odd value will fetch from an unaligned address — a trap on real hardware, silent wrong behavior in simulation.

Mux logic:

next_pc = jalr        ? (jalr_target & ~1u)   :
          branch_taken ? (pc + branch_offset)  :
          jump         ? (pc + jump_offset)    :
                         (pc + 4)

Note that both JAL and branches use PC-relative addressing (offset added to current PC). JALR uses register-relative addressing (offset added to register value, result returned separately). In the full CPU, the ALU computes the JALR target; we receive it here as an input signal.

Full `pc` Module Implementation

// File: pc.h
// Program Counter module for RV32I single-cycle CPU
// Handles: sequential increment, branch, JAL, JALR
// SystemC 2.3.x compatible

#ifndef PC_H
#define PC_H

#include <systemc.h>

SC_MODULE(pc) {
    // ── Clock and reset ─────────────────────────────────────────────────────
    sc_in<bool>         clk;
    sc_in<bool>         rst_n;      // Active-low synchronous reset

    // ── Control inputs (from branch/jump resolution unit) ───────────────────
    sc_in<bool>         branch_taken;   // High when branch condition is met
    sc_in<sc_uint<32>>  branch_offset;  // Sign-extended branch immediate (B-type)
    sc_in<bool>         jump;           // High for JAL (PC-relative jump)
    sc_in<sc_uint<32>>  jump_offset;    // Sign-extended JAL immediate (J-type)
    sc_in<bool>         jalr;           // High for JALR (register-relative jump)
    sc_in<sc_uint<32>>  jalr_target;    // rs1 + sign_extend(imm12), computed by ALU

    // ── Output ──────────────────────────────────────────────────────────────
    sc_out<sc_uint<32>> pc_out;         // Current PC value (to imem and decoder)

    // ── Internal signals ────────────────────────────────────────────────────
    sc_signal<sc_uint<32>> next_pc_sig; // Combinational next-PC wire

    // ── Process declarations ─────────────────────────────────────────────────
    void next_pc_proc();    // SC_METHOD: combinational next-PC mux
    void pc_reg_proc();     // SC_CTHREAD: clocked register

    SC_CTOR(pc) {
        // Combinational next-PC mux — sensitive to all control inputs
        SC_METHOD(next_pc_proc);
        sensitive << branch_taken << branch_offset
                  << jump << jump_offset
                  << jalr << jalr_target
                  << pc_out;

        // Sequential register — updates on rising clock edge
        SC_CTHREAD(pc_reg_proc, clk.pos());
        async_reset_signal_is(rst_n, false); // Active-low
    }
};

#endif // PC_H

// File: pc.cpp

#include "pc.h"

// ─── Combinational: compute next PC ──────────────────────────────────────────
//
// Priority order (JALR > branch/jump > sequential):
//   JALR overrides branch_taken because it is a register-indirect target.
//   In a real pipeline the priority depends on instruction type (only one
//   can be true at a time in a single-cycle CPU).
//
void pc::next_pc_proc() {
    sc_uint<32> current = pc_out.read();
    sc_uint<32> next;

    if (jalr.read()) {
        // RISC-V spec: target = (rs1 + imm12) with bit 0 forced to zero
        sc_uint<32> target = jalr_target.read();
        target[0] = 0;  // Clear LSB — mandatory per ISA spec
        next = target;
    } else if (branch_taken.read()) {
        // B-type: PC-relative, offset already sign-extended and scaled by 2
        // branch_offset comes in as a signed 32-bit value; use sc_int for add
        sc_int<32> pc_signed  = (sc_int<32>)current;
        sc_int<32> off_signed = (sc_int<32>)branch_offset.read();
        next = (sc_uint<32>)(pc_signed + off_signed);
    } else if (jump.read()) {
        // J-type (JAL): PC-relative, offset sign-extended, scaled by 2
        sc_int<32> pc_signed  = (sc_int<32>)current;
        sc_int<32> off_signed = (sc_int<32>)jump_offset.read();
        next = (sc_uint<32>)(pc_signed + off_signed);
    } else {
        // Sequential: advance by one word (4 bytes)
        next = current + 4;
    }

    next_pc_sig.write(next);
}

// ─── Sequential: register update ─────────────────────────────────────────────
//
// Uses SC_CTHREAD reset idiom:
//   - Reset block: executes on async reset assertion (rst_n=0)
//   - Main block:  executes on each rising clock edge
//
void pc::pc_reg_proc() {
    // ── Reset state ────────────────────────────────────────────────────────
    pc_out.write(0x00000000);  // RISC-V: reset vector is implementation-defined
                                // For our CPU we use 0x0000_0000
    wait();                     // Wait for reset to deassert

    // ── Normal operation ───────────────────────────────────────────────────
    while (true) {
        pc_out.write(next_pc_sig.read());
        wait();  // Wait for next rising edge
    }
}

DV Insight The reset vector choice matters for testbench construction. If you hardcode 0x00000000, your instruction memory must have valid instructions at address 0. If you want to test the branch-to-zero case separately from reset, you need to distinguish "PC is zero because we just reset" from "PC is zero because a branch targeted it." Add a cycle counter to your monitor: if pc_out == 0 and cycle > 1, it was a jump, not a reset.

Full `imem` Module Implementation

The instruction memory is a ROM — initialized at simulation start, read-only during execution. In a real chip, the instruction cache sits here; in our model, a flat array is sufficient.

Key design decisions:

Byte-addressed, word-indexed: The PC is byte-addressed (increments by 4). The array is word-indexed. Conversion: word_index = pc >> 2. This mirrors the pc[31:2] slice in SystemVerilog.
Combinational read: No clock. When addr changes, instr updates immediately. This models a synchronous-read SRAM accessed with pc registered one cycle earlier — the standard pipeline assumption.
Parameterized size: Template parameter MEM_WORDS controls depth. Default 1024 words = 4KB, enough for any program in this series.
Hex file loader: A constructor utility reads Intel HEX format or plain 32-bit hex words from a text file. Shows the C++ file I/O that replaces $readmemh.

// File: imem.h
// Instruction Memory — combinational ROM for RV32I fetch stage
// Initialized from hex file or inline array

#ifndef IMEM_H
#define IMEM_H

#include <systemc.h>
#include <cstdint>
#include <string>
#include <fstream>
#include <sstream>
#include <iomanip>
#include <stdexcept>
#include <iostream>

// Default size: 1024 words × 4 bytes = 4 KB
static const int IMEM_DEFAULT_WORDS = 1024;

SC_MODULE(imem) {
    // ── Ports ───────────────────────────────────────────────────────────────
    sc_in<sc_uint<32>>  addr;   // Byte address (from pc_out)
    sc_out<sc_uint<32>> instr;  // 32-bit instruction word

    // ── Memory array ────────────────────────────────────────────────────────
    // uint32_t matches RV32I instruction width exactly.
    // 1024 entries = 4096 bytes = 4 KB of instruction space.
    static const int MEM_WORDS = IMEM_DEFAULT_WORDS;
    uint32_t mem[MEM_WORDS];

    // ── Process ─────────────────────────────────────────────────────────────
    void read_proc();

    // ── Constructor ─────────────────────────────────────────────────────────
    SC_CTOR(imem) {
        // Initialize to NOP (ADDI x0, x0, 0 = 0x00000013)
        for (int i = 0; i < MEM_WORDS; i++) {
            mem[i] = 0x00000013u;
        }

        SC_METHOD(read_proc);
        sensitive << addr;
    }

    // ── Hex file loader ─────────────────────────────────────────────────────
    // Reads a plain hex file: one 32-bit word per line (no address prefix).
    // Example file contents:
    //   00500093    # addi x1, x0, 5
    //   00300113    # addi x2, x0, 3
    //   002080b3    # add  x3, x1, x2
    //
    // Lines beginning with '#' are treated as comments and skipped.
    // Returns number of instructions loaded.
    int load_hex(const std::string& filename) {
        std::ifstream file(filename);
        if (!file.is_open()) {
            std::cerr << "[imem] ERROR: cannot open hex file: " << filename << std::endl;
            return -1;
        }

        int count = 0;
        std::string line;
        while (std::getline(file, line)) {
            // Strip leading whitespace
            size_t start = line.find_first_not_of(" \t\r\n");
            if (start == std::string::npos) continue;
            line = line.substr(start);

            // Skip comment lines
            if (line[0] == '#' || line[0] == '/') continue;

            // Strip inline comments (everything after '#' or '//')
            size_t comment = line.find('#');
            if (comment != std::string::npos) line = line.substr(0, comment);
            comment = line.find("//");
            if (comment != std::string::npos) line = line.substr(0, comment);

            // Strip trailing whitespace
            size_t end = line.find_last_not_of(" \t\r\n");
            if (end == std::string::npos) continue;
            line = line.substr(0, end + 1);
            if (line.empty()) continue;

            if (count >= MEM_WORDS) {
                std::cerr << "[imem] WARNING: hex file exceeds MEM_WORDS="
                          << MEM_WORDS << ", truncating." << std::endl;
                break;
            }

            // Parse hex word
            uint32_t word = 0;
            std::istringstream iss(line);
            iss >> std::hex >> word;
            if (iss.fail()) {
                std::cerr << "[imem] WARNING: cannot parse line: '" << line << "'" << std::endl;
                continue;
            }

            mem[count++] = word;
        }

        std::cout << "[imem] Loaded " << count << " instructions from " << filename << std::endl;
        return count;
    }

    // ── Inline program loader ───────────────────────────────────────────────
    // Loads instructions from a C++ array. Used in testbenches to avoid
    // file dependency. Mirrors the hex loader interface.
    void load_program(const uint32_t* prog, int num_words) {
        int limit = (num_words < MEM_WORDS) ? num_words : MEM_WORDS;
        for (int i = 0; i < limit; i++) {
            mem[i] = prog[i];
        }
    }
};

#endif // IMEM_H

// File: imem.cpp

#include "imem.h"

// ─── Combinational ROM read ───────────────────────────────────────────────────
//
// Converts byte address to word index (divide by 4 = right-shift by 2).
// Bounds-checks to prevent array overrun during simulation.
// Returns NOP (0x00000013) for out-of-range addresses.
//
void imem::read_proc() {
    sc_uint<32> byte_addr = addr.read();

    // Word index: drop the 2 LSBs (byte offset within word is always 0 for
    // a correctly-aligned PC — instructions are 4-byte aligned in RV32I base)
    sc_uint<30> word_idx = byte_addr.range(31, 2);  // Equivalent to byte_addr >> 2

    if (word_idx >= (sc_uint<30>)MEM_WORDS) {
        // Out-of-range fetch — return NOP, warn once
        // In real hardware this would be a bus error / instruction access fault
        std::cerr << "[imem] WARNING: fetch from out-of-range address 0x"
                  << std::hex << std::setw(8) << std::setfill('0')
                  << (uint32_t)byte_addr << std::dec << std::endl;
        instr.write(0x00000013u);  // NOP
        return;
    }

    instr.write(mem[(uint32_t)word_idx]);
}

Harvard vs Von Neumann: Why We Have Separate imem and dmem

Our design uses separate instruction memory (imem) and data memory (dmem, Post 11). This is called a modified Harvard architecture — the conceptual separation of instruction and data address spaces.

The original Von Neumann architecture (1945) stores instructions and data in the same memory. Simple to implement, but creates a bottleneck: the CPU can fetch an instruction or access data, not both simultaneously. This is the Von Neumann bottleneck.

Real processors solve this with caches:

Architecture	Instruction Access	Data Access	Example
Von Neumann	Shared bus	Shared bus	Early 8-bit MCUs, simple FPGAs
Harvard	Separate buses	Separate buses	PIC MCUs, DSPs, Harvard cache design
Modified Harvard	Separate L1 caches	Separate L1 caches	ARM Cortex-M3, RISC-V SiFive E21
Unified L2	Separate L1	Separate L1	Cortex-A72, SiFive U74 (unified L2)

The ARM Cortex-M3 Technical Reference Manual (DDI0337H, section 3.1) states: "The Cortex-M3 processor has a Harvard architecture with separate instruction and data buses." The SiFive E21 core (FE310-G002 Manual, chapter 4) similarly documents separate I-cache and D-cache buses feeding a unified TileLink crossbar.

Our imem/dmem split models this in miniature. The benefits:

Simultaneous access: The fetch stage reads imem while the execute stage accesses dmem. No structural hazard.
Separate optimization: imem can be read-only flash; dmem can be SRAM. Different timing, different voltage.
Security: Harvard-strict systems (like some DSPs) prevent self-modifying code entirely.

The cost: programs cannot live-patch their own instructions (without explicit cache flush operations), and you need to map two separate address spaces in your linker script.

Loading a Program: The Hex File

Here is a minimal 10-instruction RV32I program that exercises the key control flow paths:

# File: test_program.hex
# RV32I test program — sequential, branch, jump
# One 32-bit hex word per line (little-endian, no address prefix)
# Comments are stripped by the hex loader

00500093    # [0x00] addi x1, x0, 5       # x1 = 5
00300113    # [0x04] addi x2, x0, 3       # x2 = 3
002080b3    # [0x08] add  x3, x1, x2      # x3 = 8
40208133    # [0x0C] sub  x2, x1, x2      # x2 = 2  (5 - 3)
0000a463    # [0x10] beq  x1, x0, +8      # branch NOT taken (x1=5 != 0)
00108093    # [0x14] addi x1, x1, 1       # x1 = 6  (falls through)
fe1ff06f    # [0x18] jal  x0, -32         # jump back to 0x00 (infinite loop demo)
00000013    # [0x1C] nop                  # unreachable (after jal)
fff00113    # [0x20] addi x2, x0, -1      # x2 = 0xFFFF_FFFF (sign extension test)
00000013    # [0x24] nop                  # padding

Decoding the JAL Encoding

The jal x0, -32 at address 0x18 encodes a jump back to 0x18 + (-32) = 0x18 - 0x20 = -8... wait, let me compute carefully:

Target = PC + offset
0x00   = 0x18 + offset
offset = 0x00 - 0x18 = -0x18 = -24 decimal

J-type immediate encoding for offset = -24 (0xFFFFFFE8):
  Binary: 1111_1111_1110_1000
  imm[20]    = 1
  imm[10:1]  = 11_1111_1100
  imm[11]    = 0
  imm[19:12] = 1111_1111
  rd         = 00000 (x0)
  opcode     = 110_1111

Assembled: 0xFE1FF06F  ✓

This is why disassembling hex by hand requires the RISC-V ISA manual. Use riscv64-unknown-elf-objdump -d to verify your programs.

Testbench

The testbench exercises four scenarios: sequential fetch, branch-not-taken, branch-taken, and JALR with odd target (to verify bit-0 clearing).

// File: tb_pc_imem.cpp
// Testbench for pc + imem modules
// Tests: sequential, branch taken, branch not taken, JAL, JALR bit-0 clear

#include <systemc.h>
#include <iostream>
#include <iomanip>
#include <cassert>
#include "pc.h"
#include "imem.h"

// ─── Helper: print pass/fail ──────────────────────────────────────────────────
static int test_pass = 0;
static int test_fail = 0;

void check(const char* name, uint32_t got, uint32_t expected) {
    if (got == expected) {
        std::cout << "  PASS  " << name
                  << " = 0x" << std::hex << std::setw(8) << std::setfill('0') << got
                  << std::dec << std::endl;
        test_pass++;
    } else {
        std::cout << "  FAIL  " << name
                  << " got 0x" << std::hex << std::setw(8) << std::setfill('0') << got
                  << " expected 0x" << std::setw(8) << std::setfill('0') << expected
                  << std::dec << std::endl;
        test_fail++;
    }
}

// ─── Testbench module ─────────────────────────────────────────────────────────
SC_MODULE(tb_pc_imem) {
    sc_clock        clk{"clk", 10, SC_NS};
    sc_signal<bool> rst_n{"rst_n"};

    // PC control signals
    sc_signal<bool>         branch_taken{"branch_taken"};
    sc_signal<sc_uint<32>>  branch_offset{"branch_offset"};
    sc_signal<bool>         jump{"jump"};
    sc_signal<sc_uint<32>>  jump_offset{"jump_offset"};
    sc_signal<bool>         jalr{"jalr"};
    sc_signal<sc_uint<32>>  jalr_target{"jalr_target"};

    // PC/IMEM outputs
    sc_signal<sc_uint<32>>  pc_out{"pc_out"};
    sc_signal<sc_uint<32>>  instr{"instr"};

    // DUT instances
    pc   dut_pc{"dut_pc"};
    imem dut_imem{"dut_imem"};

    void test_proc();

    SC_CTOR(tb_pc_imem) {
        // Connect PC
        dut_pc.clk(clk);
        dut_pc.rst_n(rst_n);
        dut_pc.branch_taken(branch_taken);
        dut_pc.branch_offset(branch_offset);
        dut_pc.jump(jump);
        dut_pc.jump_offset(jump_offset);
        dut_pc.jalr(jalr);
        dut_pc.jalr_target(jalr_target);
        dut_pc.pc_out(pc_out);

        // Connect IMEM
        dut_imem.addr(pc_out);
        dut_imem.instr(instr);

        // Load a small test program inline
        // (hex file loader also shown in load_hex() test below)
        static const uint32_t prog[] = {
            0x00500093u,  // [0x00] addi x1, x0, 5
            0x00300113u,  // [0x04] addi x2, x0, 3
            0x002080b3u,  // [0x08] add  x3, x1, x2
            0x40208133u,  // [0x0C] sub  x2, x1, x2
            0x0000a463u,  // [0x10] beq  x1, x0, +8
            0x00108093u,  // [0x14] addi x1, x1, 1
            0xfe1ff06fu,  // [0x18] jal  x0, -24
            0x00000013u,  // [0x1C] nop
            0xfff00113u,  // [0x20] addi x2, x0, -1
            0x00000013u,  // [0x24] nop
        };
        dut_imem.load_program(prog, 10);

        SC_THREAD(test_proc);
    }

    // ── Utility: apply reset for 2 cycles ────────────────────────────────────
    void do_reset() {
        rst_n.write(false);
        wait(clk.posedge_event()); wait(clk.posedge_event());
        rst_n.write(true);
        wait(clk.posedge_event());
    }

    // ── Utility: set all control inputs to "normal flow" default ─────────────
    void set_sequential() {
        branch_taken.write(false);
        branch_offset.write(0);
        jump.write(false);
        jump_offset.write(0);
        jalr.write(false);
        jalr_target.write(0);
    }
};

// ─── Main test procedure ──────────────────────────────────────────────────────
void tb_pc_imem::test_proc() {

    // =========================================================================
    // TEST 1: Reset — PC must come out of reset at 0x00000000
    // =========================================================================
    std::cout << "\n=== TEST 1: Reset ===\n";
    set_sequential();
    do_reset();

    check("PC after reset", (uint32_t)pc_out.read(), 0x00000000u);
    check("IMEM[0x00] after reset", (uint32_t)instr.read(), 0x00500093u);

    // =========================================================================
    // TEST 2: Sequential fetch — PC must increment by 4 each cycle
    // =========================================================================
    std::cout << "\n=== TEST 2: Sequential fetch ===\n";
    set_sequential();
    do_reset();

    for (int i = 0; i < 6; i++) {
        uint32_t expected_pc = i * 4;
        check(("PC[" + std::to_string(i) + "]").c_str(),
              (uint32_t)pc_out.read(), expected_pc);
        wait(clk.posedge_event());  // Advance one cycle
        wait(SC_ZERO_TIME);         // Let combinational settle
    }

    // =========================================================================
    // TEST 3: Branch NOT taken — PC continues sequentially
    // =========================================================================
    std::cout << "\n=== TEST 3: Branch not taken ===\n";
    set_sequential();
    do_reset();
    // Start at PC=0, advance to PC=0x10 (4 cycles)
    for (int i = 0; i < 4; i++) { wait(clk.posedge_event()); wait(SC_ZERO_TIME); }

    check("PC before branch decision", (uint32_t)pc_out.read(), 0x00000010u);

    // branch_taken = false → PC should go to 0x14 (0x10 + 4)
    branch_taken.write(false);
    branch_offset.write((sc_uint<32>)(sc_int<32>)8);  // +8 (would go to 0x18 if taken)
    wait(clk.posedge_event()); wait(SC_ZERO_TIME);
    check("PC after branch NOT taken", (uint32_t)pc_out.read(), 0x00000014u);

    // =========================================================================
    // TEST 4: Branch TAKEN — PC jumps to PC + offset
    // =========================================================================
    std::cout << "\n=== TEST 4: Branch taken ===\n";
    set_sequential();
    do_reset();
    // Advance to PC=0x10
    for (int i = 0; i < 4; i++) { wait(clk.posedge_event()); wait(SC_ZERO_TIME); }

    // Apply branch-taken with offset = +8 → target = 0x10 + 8 = 0x18
    branch_taken.write(true);
    branch_offset.write((sc_uint<32>)(sc_int<32>)8);
    wait(clk.posedge_event()); wait(SC_ZERO_TIME);
    check("PC after branch TAKEN", (uint32_t)pc_out.read(), 0x00000018u);
    check("IMEM at branch target 0x18", (uint32_t)instr.read(), 0xfe1ff06fu);

    // =========================================================================
    // TEST 5: Backward branch — negative offset
    // =========================================================================
    std::cout << "\n=== TEST 5: Backward branch (negative offset) ===\n";
    set_sequential();
    do_reset();
    // Advance to PC=0x18
    for (int i = 0; i < 6; i++) { wait(clk.posedge_event()); wait(SC_ZERO_TIME); }

    // branch to 0x18 + (-24) = 0x00
    branch_taken.write(true);
    branch_offset.write((sc_uint<32>)(sc_int<32>)(-24));
    wait(clk.posedge_event()); wait(SC_ZERO_TIME);
    check("PC after backward branch", (uint32_t)pc_out.read(), 0x00000000u);

    // =========================================================================
    // TEST 6: JAL (PC-relative jump)
    // =========================================================================
    std::cout << "\n=== TEST 6: JAL PC-relative jump ===\n";
    set_sequential();
    do_reset();
    // At PC=0x04
    wait(clk.posedge_event()); wait(SC_ZERO_TIME);

    // JAL with offset = +16 → target = 0x04 + 16 = 0x14
    jump.write(true);
    jump_offset.write((sc_uint<32>)(sc_int<32>)16);
    wait(clk.posedge_event()); wait(SC_ZERO_TIME);
    check("PC after JAL +16 from 0x04", (uint32_t)pc_out.read(), 0x00000014u);
    jump.write(false);

    // =========================================================================
    // TEST 7: JALR — register-relative jump, bit-0 must be cleared
    // =========================================================================
    std::cout << "\n=== TEST 7: JALR bit-0 clear ===\n";
    set_sequential();
    do_reset();

    // JALR target = 0x0000_0015 (odd — LSB must be cleared → 0x14)
    jalr.write(true);
    jalr_target.write(0x00000015u);
    wait(clk.posedge_event()); wait(SC_ZERO_TIME);
    check("PC after JALR to 0x15 (cleared to 0x14)", (uint32_t)pc_out.read(), 0x00000014u);

    // JALR target already even — should be unchanged
    jalr_target.write(0x00000008u);
    wait(clk.posedge_event()); wait(SC_ZERO_TIME);
    check("PC after JALR to 0x08 (already even)", (uint32_t)pc_out.read(), 0x00000008u);
    jalr.write(false);

    // =========================================================================
    // TEST 8: IMEM bounds check — read all 10 loaded instructions
    // =========================================================================
    std::cout << "\n=== TEST 8: IMEM — verify all 10 loaded instructions ===\n";
    static const uint32_t expected_prog[] = {
        0x00500093u, 0x00300113u, 0x002080b3u, 0x40208133u, 0x0000a463u,
        0x00108093u, 0xfe1ff06fu, 0x00000013u, 0xfff00113u, 0x00000013u
    };
    set_sequential();
    do_reset();

    for (int i = 0; i < 10; i++) {
        check(("IMEM[0x" + [](int a){ char buf[8]; snprintf(buf,8,"%02X",a*4); return std::string(buf); }(i) + "]").c_str(),
              (uint32_t)instr.read(), expected_prog[i]);
        wait(clk.posedge_event());
        wait(SC_ZERO_TIME);
    }

    // =========================================================================
    // TEST 9: Second reset mid-run — PC must snap back to 0
    // =========================================================================
    std::cout << "\n=== TEST 9: Mid-run reset ===\n";
    set_sequential();
    // PC is currently somewhere after the loop above; apply reset
    rst_n.write(false);
    wait(clk.posedge_event()); wait(SC_ZERO_TIME);
    check("PC during reset (async)", (uint32_t)pc_out.read(), 0x00000000u);
    rst_n.write(true);
    wait(clk.posedge_event()); wait(SC_ZERO_TIME);
    check("PC after mid-run reset", (uint32_t)pc_out.read(), 0x00000004u);

    // =========================================================================
    // Summary
    // =========================================================================
    std::cout << "\n========================================\n";
    std::cout << "  PASS: " << test_pass << "   FAIL: " << test_fail << std::endl;
    std::cout << "========================================\n";
    if (test_fail == 0) {
        std::cout << "  ALL TESTS PASSED — PC + IMEM verified\n";
    } else {
        std::cout << "  FAILURES DETECTED — review output above\n";
    }
    sc_stop();
}

// ─── sc_main ─────────────────────────────────────────────────────────────────
int sc_main(int argc, char* argv[]) {
    tb_pc_imem tb{"tb"};
    sc_start();
    return 0;
}

CMake Build

# CMakeLists.txt — Post 10: PC + IMEM
cmake_minimum_required(VERSION 3.16)
project(post10_pc_imem CXX)

set(CMAKE_CXX_STANDARD 17)

# Find SystemC (set SYSTEMC_HOME environment variable)
find_package(SystemCLanguage QUIET)
if(NOT SystemCLanguage_FOUND)
    set(SYSTEMC_HOME $ENV{SYSTEMC_HOME})
    include_directories(${SYSTEMC_HOME}/include)
    link_directories(${SYSTEMC_HOME}/lib-linux64)
    set(SC_LIBS systemc)
endif()

add_executable(tb_pc_imem
    pc.cpp
    imem.cpp
    tb_pc_imem.cpp
)
target_link_libraries(tb_pc_imem ${SC_LIBS})

# Build and run
mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=Debug
make -j4
./tb_pc_imem

Expected output:

[imem] Loaded 10 instructions from inline array

=== TEST 1: Reset ===
  PASS  PC after reset = 0x00000000
  PASS  IMEM[0x00] after reset = 0x00500093

=== TEST 2: Sequential fetch ===
  PASS  PC[0] = 0x00000000
  PASS  PC[1] = 0x00000004
  PASS  PC[2] = 0x00000008
  ...

=== TEST 7: JALR bit-0 clear ===
  PASS  PC after JALR to 0x15 (cleared to 0x14) = 0x00000014
  PASS  PC after JALR to 0x08 (already even) = 0x00000008

========================================
  PASS: 28   FAIL: 0
  ALL TESTS PASSED — PC + IMEM verified
========================================

PC Coverage Strategy

DV Insight: PC coverage is one of the trickiest items in a CPU verification plan, because the PC is an address — a 32-bit value — and you cannot cover all 4 billion possible values. Instead, you write structural coverage: coverage of the PC's behavior across its operating modes.

A production-grade PC coverage model tracks four dimensions:

Jump type coverage: Was each next-PC source exercised? (Sequential / Branch-Taken / Branch-Not-Taken / JAL / JALR)

Branch direction coverage: For each branch instruction, was it taken AND not-taken at least once?

Jump target coverage: Were forward jumps, backward jumps, and jump-to-zero all exercised?

JALR alignment coverage: Was JALR exercised with an even target? With an odd target (bit-0 clear)?

Here is a SystemC monitor that tracks this structural coverage:

// File: pc_monitor.h
// PC coverage monitor — tracks structural fetch behavior
// Attach to the PC/IMEM outputs; call report() at end of sim

#ifndef PC_MONITOR_H
#define PC_MONITOR_H

#include <systemc.h>
#include <iostream>
#include <set>

SC_MODULE(pc_monitor) {
    sc_in<bool>         clk;
    sc_in<sc_uint<32>>  pc_out;
    sc_in<bool>         branch_taken;
    sc_in<bool>         jump;
    sc_in<bool>         jalr;
    sc_in<sc_uint<32>>  jalr_target;

    // ── Coverage buckets ────────────────────────────────────────────────────
    bool cov_sequential    = false;
    bool cov_branch_taken  = false;
    bool cov_branch_not_taken = false;
    bool cov_jal           = false;
    bool cov_jalr_even     = false;
    bool cov_jalr_odd      = false;   // odd target → bit cleared
    bool cov_branch_to_zero = false;  // branch target = 0x0
    bool cov_jump_backward  = false;  // jump to lower address

    std::set<uint32_t> visited_pcs;   // Set of PCs observed

    sc_uint<32> prev_pc;

    void monitor_proc() {
        sc_uint<32> current_pc = pc_out.read();

        // Track visited addresses
        visited_pcs.insert((uint32_t)current_pc);

        // Sequential increment
        if (!branch_taken.read() && !jump.read() && !jalr.read()) {
            cov_sequential = true;
        }

        // Branch coverage
        if (branch_taken.read()) {
            cov_branch_taken = true;
            if (current_pc == 0) cov_branch_to_zero = true;
            // Backward: new PC < previous PC
            if (current_pc < prev_pc) cov_jump_backward = true;
        } else if (prev_pc != 0 || current_pc != 0) {
            // branch_taken was deasserted on a cycle where we expected a branch
            // In real use, you'd track "was a branch instruction decoded"
            // For simplicity: if branch_offset is nonzero and not taken, mark it
        }

        // JAL
        if (jump.read()) {
            cov_jal = true;
            if (current_pc < prev_pc) cov_jump_backward = true;
        }

        // JALR
        if (jalr.read()) {
            if (jalr_target.read()[0] == 1) cov_jalr_odd  = true;
            else                             cov_jalr_even = true;
        }

        prev_pc = current_pc;
    }

    void report() {
        std::cout << "\n=== PC Coverage Report ===\n";
        auto chk = [](const char* name, bool hit) {
            std::cout << "  [" << (hit ? "X" : " ") << "] " << name << std::endl;
        };
        chk("Sequential increment",    cov_sequential);
        chk("Branch taken",            cov_branch_taken);
        chk("Branch not taken",        cov_branch_not_taken);
        chk("JAL (PC-relative)",       cov_jal);
        chk("JALR even target",        cov_jalr_even);
        chk("JALR odd target (cleared)", cov_jalr_odd);
        chk("Branch to address 0x0",   cov_branch_to_zero);
        chk("Backward jump",           cov_jump_backward);
        std::cout << "  Unique PCs visited: " << visited_pcs.size() << std::endl;

        int total = 8, hit = cov_sequential + cov_branch_taken +
                             cov_branch_not_taken + cov_jal + cov_jalr_even +
                             cov_jalr_odd + cov_branch_to_zero + cov_jump_backward;
        std::cout << "  Coverage: " << hit << "/" << total
                  << " (" << (100*hit/total) << "%)\n";
    }

    SC_CTOR(pc_monitor) : prev_pc(0) {
        SC_METHOD(monitor_proc);
        sensitive << clk.pos();
    }
};

#endif // PC_MONITOR_H

This is the pattern you will see in UVM-SystemC environments: a monitor attached to the DUT's output signals, collecting functional coverage points in a structured way. Post 6 introduced the pattern; here it tracks architectural behavior rather than operation correctness.

Simulation Semantics: How the Simulator Executes These Constructs

Understanding exactly when each process runs is essential for debugging the PC module. The SystemC simulation kernel uses an evaluate-update-notify cycle (also called the delta-cycle mechanism), which is the exact same mechanism underlying SV's non-blocking assignments.

Delta Cycles in the PC Module

At time T (rising clock edge), the simulation kernel executes in this order:

Time T — rising clock edge event:
  Phase 1 (evaluate):
    - sc_clock fires posedge event
    - SC_CTHREAD (pc_reg_proc) resumes from wait()
    - Reads next_pc_sig.read()  ← value from previous delta
    - Writes pc_out.write(next_val) — queued, not yet visible

  Phase 2 (update):
    - pc_out signal updated to new value
    - pc_out.default_event() fires

  Phase 3 (evaluate — delta cycle 1):
    - SC_METHOD (next_pc_proc) wakes (sensitive to pc_out)
    - Reads pc_out (new value), branch_taken, etc.
    - Writes next_pc_sig.write(computed) — queued

  Phase 4 (update — delta cycle 1):
    - next_pc_sig updated

  [No further events → simulation advances to time T+period]

Compare to SV non-blocking assignment semantics:

// SV: this pair behaves identically to the SystemC delta-cycle sequence
always_ff @(posedge clk or posedge rst) begin
    if (rst) pc <= '0;
    else     pc <= next_pc;   // NB: schedules update for end of time step
end

always_comb
    // Evaluates after pc updates — same as SystemC delta-cycle 1
    if      (jump)         next_pc = jump_target;
    else if (branch_taken) next_pc = branch_target;
    else                   next_pc = pc + 4;

The SV non-blocking assignment (<=) and the SystemC sc_signal::write() both schedule an update for the end of the current time step. Reading a signal mid-evaluation gives the old value. This is the fundamental rule that makes flip-flops work correctly in simulation: the register captures what was there before the clock edge, not what the combinational logic computes during the edge.

The Importance of `wait(SC_ZERO_TIME)` in Testbenches

In testbenches you often see:

wait(clk.posedge_event());
wait(SC_ZERO_TIME);  // Let combinational settle

The wait(SC_ZERO_TIME) advances simulation by one delta cycle without advancing real time. This is necessary after a clock edge to let all SC_METHOD processes (combinational logic) evaluate before reading their outputs. Without it, you read stale values from the previous cycle.

SV equivalent: sampling in a clocking block with ##1 advances one clock cycle and implicitly samples after the clock edge in the next timestep — the equivalent of wait(edge); wait(SC_ZERO_TIME).

Combinational vs. Sequential in the Same Module — The Two-Process Pattern

The PC module contains both SC_CTHREAD (sequential register) and SC_METHOD (combinational mux). This is the standard SystemC pattern for any sequential block that has combinational output logic. Every register-with-logic block in RTL follows this structure.

SC_MODULE(pc) {
    // Sequential: register update at clock edge
    SC_CTHREAD(pc_reg_proc, clk.pos());
    async_reset_signal_is(rst_n, false);   // active-low

    // Combinational: next_pc mux (branch/jump/sequential)
    SC_METHOD(next_pc_mux);
    sensitive << branch_taken << branch_offset
              << jump << jump_offset
              << jalr << jalr_target
              << pc_out;   // feeds back through the register
};

The SystemVerilog equivalent uses two separate always blocks, which map one-to-one:

// Sequential part — maps to SC_CTHREAD
always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) pc <= '0;
    else        pc <= next_pc;
end

// Combinational part — maps to SC_METHOD
always_comb begin
    if      (jalr)         next_pc = (jalr_target) & 32'hFFFFFFFE;
    else if (jump)         next_pc = pc + jump_offset;
    else if (branch_taken) next_pc = pc + branch_offset;
    else                   next_pc = pc + 4;
end

Both produce identical hardware. The SV synthesis tool sees always_ff → flip-flop. It sees always_comb → combinational mux. The SystemC synthesis tool (if using commercial HLS) sees the same structure. The code style is different; the RTL intent is the same.

Why the feedback path is safe: pc_out is in the sensitivity list of next_pc_mux. This looks like a combinational loop, but it is not — pc_out is the registered output (driven by SC_CTHREAD). The loop is broken by the register: the mux computes next_pc based on the current registered pc_out, and the result is captured at the next clock edge. This is the standard sequential feedback topology.

Memory Initialization: `$readmemh` vs. C++ File I/O

This is one of the most commonly asked questions when moving from SV to SystemC: "Where is $readmemh?"

SV has $readmemh as a language built-in:

// SV: load hex file into memory array — one line in the source
logic [31:0] mem [0:1023];
initial $readmemh("program.hex", mem);

// With explicit address range:
initial $readmemh("program.hex", mem, 0, 255);  // load first 256 words only

$readmemh understands @address directives in the hex file (allows non-contiguous loading), handles comments (lines starting with //), and automatically scales to the array width. It is hardwired into every major SV simulator.

SystemC has no equivalent built-in — you use standard C++ file I/O:

// SystemC / C++: equivalent loader — more code, more control
void load_hex(const std::string& fname) {
    std::ifstream f(fname);
    if (!f.is_open()) {
        SC_REPORT_ERROR("imem", ("Cannot open: " + fname).c_str());
        return;
    }
    uint32_t word_idx = 0;
    std::string line;
    while (std::getline(f, line)) {
        // Strip comments, skip blank lines (see full imem.h loader above)
        if (line.empty() || line[0] == '#') continue;
        uint32_t word = 0;
        std::istringstream iss(line);
        if (iss >> std::hex >> word) {
            if (word_idx < MEM_WORDS) mem[word_idx++] = word;
        }
    }
}

Which is better? The C++ loader is more flexible: you can parse any file format, add address-directive support, validate checksums, report precise error messages with file and line number, or load from a network socket. In a real VIP environment you would wrap this in a class (MemLoader) that all memory modules share.

The SV $readmemh is more concise and supported by every tool with no implementation effort. For simple simulations it is strictly better. The SystemC approach is better when you need the loader to be part of a larger infrastructure (e.g., a UVM-style environment that manages program images across multiple memories and CPUs).

Hex file format compatibility: Both SV $readmemh and the imem loader above accept a file with one 32-bit hex word per line and # comments. This format is produced by:

# From RISC-V ELF binary:
riscv32-unknown-elf-objcopy -O binary program.elf program.bin
xxd -e -g 4 -c 4 program.bin | awk '{print $2}' > program.hex

# Or using objdump (shows instruction hex only):
riscv32-unknown-elf-objdump -d program.elf | \
    grep '^\s*[0-9a-f]*:' | awk '{print $2}' > program.hex

JALR Target Generation — The Bit-0 Clear

JALR computes its target as PC = (rs1 + imm) & ~1 (equivalently, & 0xFFFFFFFE). The AND with ~1 clears bit 0 — the LSB. This is mandatory per the RISC-V specification (ISA Manual Vol I, Section 2.5).

Why does the spec require this?

RISC-V supports the C extension (compressed 16-bit instructions). A C-extension program can mix 16-bit and 32-bit instructions freely. When JALR is used to call a function, the caller may not know whether the target is a 16-bit or 32-bit entry point. Clearing bit 0 of the target address ensures that the jump always arrives at a 2-byte boundary — valid for both 16-bit (C extension) and 32-bit instruction alignment. If bit 0 were preserved, an odd return address would cause an instruction-address-misaligned exception on any implementation that enforces alignment.

// SystemC implementation:
sc_uint<32> jalr_target = jalr_target_from_alu.read();
jalr_target[0] = 0;   // Bit-index assignment on sc_uint lvalue
// Or equivalently:
// jalr_target = jalr_target & sc_uint<32>(0xFFFFFFFEu);

Classic Verilog vs. SV vs. SystemC comparison:

// Classic Verilog (concatenation to force bit 0 = 0):
assign jalr_target_out = {jalr_raw[31:1], 1'b0};

// SystemVerilog (bitwise AND — identical result):
assign jalr_target_out = jalr_raw & 32'hFFFFFFFE;

// SystemC (bit-index assignment on sc_uint lvalue):
sc_uint<32> t = jalr_raw.read();
t[0] = 0;
next_pc_sig.write(t);

All three express the same hardware: a combinational AND gate on bit 0 with a constant 0. The synthesis tool produces a wire tied to 0 (not even a gate) for bit 0, and a passthrough for bits 31:1.

JALR vs. JAL — the critical distinction:

Property	JAL	JALR
Addressing	PC-relative	Register-relative
Target formula	`PC + sign_extend(imm20)`	`(rs1 + sign_extend(imm12)) & ~1`
Range	±1 MB from current PC	Anywhere in 4 GB address space
Typical use	Function call (known at compile time)	Function return, virtual dispatch
Bit-0 clear	Not needed (imm is always even)	Mandatory per ISA spec

JAL immediates are always even (the LSB of J-type is implied 0), so JAL cannot generate a misaligned target. JALR uses a 12-bit signed immediate added to an arbitrary register value — the result may be odd, hence the mandatory bit-0 clear.

Section 2 Progress

graph LR
    P8["Post 8\nRegister File\n(SC_CTHREAD)"]
    P9["Post 9\nInstruction\nDecoder"]
    P10["Post 10\nPC + IMEM\n← You are here"]
    P11["Post 11\nData Memory\n(dmem)"]
    P18["Post 18\nSingle-Cycle\nCPU Integration"]

    P8 --> P10
    P9 --> P10
    P10 --> P11
    P11 --> P18

    style P10 fill:#f59e0b,color:#fff
    style P18 fill:#6366f1,color:#fff

At this point in the series, every CPU block has been built except the data memory and the control unit. The fetch stage is complete.

Common Pitfalls for SV Engineers

Moving from SV to SystemC on the PC and fetch logic, these are the errors that appear most frequently.

Pitfall 1: Confusing JALR (register-relative) with JAL (PC-relative)

Both instructions jump. Both use funct3 = 000. The critical difference is the base address:
- JAL: next_pc = PC + offset — the program counter is the base
- JALR: next_pc = (rs1 + imm) & ~1 — a register is the base

A decoder bug that treats JALR as JAL (using PC instead of rs1) will pass all tests that happen to call functions from the start of the program (where PC ≈ rs1). It breaks on virtual function dispatch, function pointers, and computed GOT entries. The fix: check that sig_jump_jalr is correctly set to 1 for JALR and that branch_logic reads sig_rs1_data, not sig_pc_out, as the base.

Pitfall 2: Branch offset is already a byte offset — do not multiply by 4

The B-type immediate in the RISC-V encoding is a byte offset with the LSB implied to be 0 (the immediate encodes bits 12:1, with bit 0 = 0). The offset is already scaled for byte addressing.

Correct:   next_pc = PC + sign_extend(imm_b)
Incorrect: next_pc = PC + sign_extend(imm_b) * 4   ← double-counting the scale

When you decode the B-type immediate in the decoder (Post 9), you reconstruct bits [12:1] and append a 0 for bit 0, then sign-extend from bit 12. The result is a byte offset ready for addition. Many engineers multiply by 2 or 4 "to convert from instruction count" — but the encoding already accounts for this.

Pitfall 3: The combinational loop hazard — feedback through registers

The next_pc_mux SC_METHOD has pc_out in its sensitivity list. This looks like a combinational loop:

pc_out → next_pc_mux → next_pc_sig → pc_reg_proc → pc_out

It is not a loop because pc_reg_proc (SC_CTHREAD) only propagates the value on a clock edge. The register breaks the combinational path. The flow is:
1. Clock edge → pc_reg_proc reads next_pc_sig → writes pc_out
2. pc_out change → next_pc_mux runs → writes next_pc_sig
3. next_pc_sig waits until next clock edge to be consumed

A true combinational loop would require next_pc_mux to write to pc_out directly (bypassing the register). Never drive an sc_out from a SC_METHOD and also have that port in the same method's sensitivity list without a sequential element in between.

Pitfall 4: $readmemh loads starting at address 0 by default; your C++ loader must match

$readmemh("file.hex", mem) starts loading at mem[0]. If you add an @100 directive in the hex file, loading begins at mem[0x100] instead. Your C++ loader must match this behavior — otherwise the first instruction will not be at word index 0 and reset (which starts at PC=0) will fetch garbage.

The load_hex() function in imem.h (above) starts at count=0 and increments sequentially — matching the default $readmemh behavior. If you need @address directive support (for non-contiguous programs), add that parsing explicitly.

Pitfall 5: Reset vector initialization — never rely on default values

SV logic initializes to X in simulation. SystemC sc_uint<32> initializes to 0 by default. This difference means that a SystemC simulation that "works" without explicit reset may fail in SV simulation (or in FPGA where registers power up to unknown state).

Always write the reset state explicitly in the SC_CTHREAD reset block, even if the default is correct:

void pc::pc_reg_proc() {
    pc_out.write(0x00000000u);   // Explicit — do not rely on sc_uint default
    wait();
    while (true) { ... }
}

And in SV:

always_ff @(posedge clk or posedge rst)
    if (rst) pc <= 32'h0000_0000;   // Explicit reset value
    else     pc <= next_pc;

The reset vector 0x00000000 is our implementation choice. The RISC-V specification leaves the reset vector implementation-defined. The SiFive E31 uses 0x20400000. The VexRiscv soft-core defaults to 0x80000000. Always document your reset vector.

What's Next

Post 11 completes the memory subsystem with dmem — the data memory that handles load/store instructions. Where imem is read-only and word-granular, dmem supports byte, halfword, and word access with sign extension, byte-enable logic, and the alignment constraints that have caused real silicon bugs in production chips.

After Post 11, Section 2 closes with a brief capstone (Post 12) that wires together all five Section 2 blocks — register file, decoder, PC, imem, dmem — into a testbench that fetches instructions and simulates the data-path side of execution. The single-cycle CPU integration comes in Post 18, once the control unit (Posts 13-17) is in place.

Key takeaways from this post:

The PC is a SC_CTHREAD with an internal combinational next-PC (SC_METHOD) — split the sequential and combinational concerns into separate processes
JALR must force bit 0 of the target to zero — this is a spec requirement, not an implementation choice
Harvard architecture (separate instruction and data buses) is the reason imem and dmem are distinct modules
PC coverage is structural, not value-based: cover jump types, branch directions, and target ranges — not individual addresses
The hex loader pattern (std::ifstream + hex parse) replaces $readmemh and is reusable across all memory modules in this series

← Part 9: Instruction Decoder: RV32I Part 10 of 13 Part 11: Data Memory Interface →

10. SystemC Tutorial - Program Counter & Instruction Fetch

Introduction

Prerequisites

The Fetch Stage in Context

SystemC Language Reference

Translation Table

PC Next-Value Logic

Full `pc` Module Implementation

Full `imem` Module Implementation

Harvard vs Von Neumann: Why We Have Separate imem and dmem

Loading a Program: The Hex File

Decoding the JAL Encoding

Testbench

CMake Build

PC Coverage Strategy

Simulation Semantics: How the Simulator Executes These Constructs

Delta Cycles in the PC Module

The Importance of `wait(SC_ZERO_TIME)` in Testbenches

Combinational vs. Sequential in the Same Module — The Two-Process Pattern

Memory Initialization: `$readmemh` vs. C++ File I/O

JALR Target Generation — The Bit-0 Clear

Section 2 Progress

Common Pitfalls for SV Engineers

What's Next

Comments (0)

Leave a Comment

10. SystemC Tutorial - Program Counter & Instruction Fetch

Introduction

Prerequisites

The Fetch Stage in Context

SystemC Language Reference

Translation Table

PC Next-Value Logic

Full pc Module Implementation

Full imem Module Implementation

Harvard vs Von Neumann: Why We Have Separate imem and dmem

Loading a Program: The Hex File

Decoding the JAL Encoding

Testbench

CMake Build

PC Coverage Strategy

Simulation Semantics: How the Simulator Executes These Constructs

Delta Cycles in the PC Module

The Importance of wait(SC_ZERO_TIME) in Testbenches

Combinational vs. Sequential in the Same Module — The Two-Process Pattern

Memory Initialization: $readmemh vs. C++ File I/O

JALR Target Generation — The Bit-0 Clear

Section 2 Progress

Common Pitfalls for SV Engineers

What's Next

Comments (0)

Leave a Comment

Full `pc` Module Implementation

Full `imem` Module Implementation

The Importance of `wait(SC_ZERO_TIME)` in Testbenches

Memory Initialization: `$readmemh` vs. C++ File I/O