RISC-V Design · All levels

Base Integer ISA (RV32I and RV64I) Execution Model

RISC-V ISA Fundamentals: The base integer ISA defines a clean load/store architecture: arithmetic and logical operations act only on registers, while memory is accessed through explicit load and store instructions. RV32I and RV64I share the same core design philosophy, with RV64I widening register and address operations and adding word-specific variants for 32-bit subword behavior. The ISA keeps the architectural state intentionally small and regular (32 integer registers plus program counter), making decode and hazard handling straightforward in simple pipelines while still scaling to out-of-order designs. Control flow is formed by conditional branches and jumps with well-defined PC-relative semantics, and the system model separates user-visible instructions from privileged behavior so implementations can reuse the base frontend across microcontrollers, Linux-capable cores, and accelerator-adjacent control processors.

What this topic teaches

Base Integer ISA (RV32I and RV64I) Execution Model trains mechanism-first reasoning for RISC-V design closure. The base integer ISA defines a clean load/store architecture: arithmetic and logical operations act only on registers, while memory is accessed through explicit load and store instructions. RV32I and RV64I share the same core design philosophy, with RV64I widening register and address operations and adding word-specific variants for 32-bit subword behavior. The ISA keeps the architectural state intentionally small and regular (32 integer registers plus program counter), making decode and hazard handling straightforward in simple pipelines while still scaling to out-of-order designs. Control flow is formed by conditional branches and jumps with well-defined PC-relative semantics, and the system model separates user-visible instructions from privileged behavior so implementations can reuse the base frontend across microcontrollers, Linux-capable cores, and accelerator-adjacent control processors.

Senior-engineer framing question

When Instruction count mix, branch density, and CPI breakdown by ALU, load/store, branch, and control-transfer classes. moves, can you isolate first failing mechanism, request decisive evidence, assign owner, and decide release-safe action?

diagram

RISC-V PIPELINE DIAGRAM - Base Integer ISA (RV32I and RV64I) Execution Model

PC -> IF -> ID -> EX -> MEM -> WB
      |     |      |      |      |
  i-cache decode  ALU/BR  LSU    regfile write
              \   |
               +-> branch resolve + redirect

Hot paths:
  - branch + load-use dependencies in ID/EX
  - memory latency stretching MEM stage
  - writeback arbitration for integer/vector units

Focus: map symptom to first failing stage

Architecture visuals

Draw before you tune. Use these visuals in design reviews, interview loops, and post-silicon triage.

Decode and control map

diagram

DECODE CONTROL MAP - Base Integer ISA (RV32I and RV64I) Execution Model

opcode/funct3/funct7      controls asserted
-----------------------   ---------------------------------------
LUI / AUIPC               rd_write, imm_select(U), alu_add_pc
JAL / JALR                rd_write, pc_redirect, link_write
BRANCH                    cmp_enable, branch_type, pc_redirect
LOAD                      mem_read, rd_write, wb_sel(memory)
STORE                     mem_write, store_size, addr_calc
OP-IMM                    alu_enable, imm_select(I), rd_write
OP                        alu_enable, src2_reg, rd_write
SYSTEM / CSR              csr_readwrite, trap_check, privilege_gate
VECTOR (V extension)      vdecode, lane_mask, vtype_update

Privilege stack

diagram

PRIVILEGE MODE STACK - Base Integer ISA (RV32I and RV64I) Execution Model

            +------------------------------+
            | Machine mode (M)             |
            | firmware, PMP, trap root     |
            +---------------+--------------+
                            |
                    delegated traps
                            v
            +------------------------------+
            | Supervisor mode (S)          |
            | kernel, page tables, drivers |
            +---------------+--------------+
                            |
                    ecall / syscall
                            v
            +------------------------------+
            | User mode (U)                |
            | applications, libraries      |
            +------------------------------+

Key rule: each upward transition records cause + PC in trap CSRs.

Translation path

diagram

MMU PAGE WALK DIAGRAM - Base Integer ISA (RV32I and RV64I) Execution Model

virtual address
    |
    +--> TLB lookup hit? ---- yes ---> physical address -> cache/memory
    |             |
    |             no
    v
satp root PPN + VPN indices
    |
    +--> level-2 PTE fetch (valid?)
    |         |
    |         +-- no -> page fault trap
    v
level-1 PTE fetch -> level-0 PTE fetch
    |
    +--> permissions check (R/W/X, U/S, A/D)
             |
             +-- fail -> access fault trap
             +-- pass -> install TLB entry -> continue

Vector lane lens

diagram

VECTOR LANE VIEW - Base Integer ISA (RV32I and RV64I) Execution Model

VLEN register file
   |
   +--> lane0: ALU/MUL/permute
   +--> lane1: ALU/MUL/permute
   +--> lane2: ALU/MUL/permute
   +--> lane3: ALU/MUL/permute
            ...
mask register -> per-lane predicate enable
load/store unit -> strided/segmented access queue

Throughput model:
effective ops/cycle = active_lanes * issue_rate * mask_density

Focus: balance lane utilization and memory feed

Ownership layers

diagram

RISC-V OWNERSHIP LAYERS - Base Integer ISA (RV32I and RV64I) Execution Model

layer                  owner                         closure artifact
--------------------   ----------------------------  -----------------------------
ISA compliance         architecture/spec team        unpriv + priv test evidence
decode/control         front-end RTL owner           decode matrix + assertions
pipeline timing        microarchitecture owner       hazard/perf regression trends
memory + MMU           LSU/MMU owner                 TLB/pagewalk trace checks
privilege/CSR path     firmware + kernel interface   trap/interrupt conformance
vector subsystem       vector RTL + compiler owner   lane-utilization profiles

Evidence required

Primary metric: Instruction count mix, branch density, and CPI breakdown by ALU, load/store, branch, and control-transfer classes..
Primary artifact: Base ISA execution map covering instruction classes, dataflow constraints, and implementation implications from single-cycle to superscalar pipelines..
Owners to include: CPU microarchitecture lead, compiler backend owner, verification lead, performance modeling owner, firmware and bring-up owner.
One reproducible workload and one stable comparator run.
One run with locked environment metadata for causal confidence.

Root-cause tree

diagram

ROOT CAUSE TREE - Base Integer ISA (RV32I and RV64I) Execution Model

Instruction count mix, branch density, and CPI breakdown by ALU, load/store, branch, and control-transfer classes. regressed
          |
   reproducible on fixed seed?
      /                 \
    no                   yes
    |                     |
env/tool drift       first failing domain?
                     /        |         \
                  decode    execute    memory/MMU
                    |         |            |
               control map  bypass/FU   TLB/walk/perm
                    |
         privilege/CSR side effects checked?

Stop at first confirmed mechanism, then assign explicit owner + fix proof.

Movement trend

diagram

BEFORE / AFTER TREND - Base Integer ISA (RV32I and RV64I) Execution Model

Instruction count mix, branch density, and CPI breakdown by ALU, load/store, branch, and control-transfer classes.
  ^
  |                           o target band
  |                    o after fix + reruns
  |             o
  |      o baseline (failing)
  +--------------------------------------------------> iteration
       capture issue      isolate mechanism      close + monitor

Use this view to confirm the gain is causal and stable across seeds.

Key takeaways

Classify mechanism before proposing fixes.
Tie every claim to one proving artifact.
Close with owner accountability and rollback criteria.

Common pitfalls

Averaging away tail behavior and mode-specific failures.
Blending results from mismatched build/runtime metadata.
Declaring closure before cross-workload validation.

Practice this lesson