line Register Modules Documentation

General Structure

Each pipeline-stage register module implements:

• A synchronous register bank (built from multiple registerX instances).
• Independent clock/reset buffering for synthesis across multiple fanouts.
• Write-enable control where needed (IF/ID stage uses IFID_we; others use constant write-enable).
• Clean separation of stage-specific architectural data: operands, opcode, destination register, control flags, and PC.

These modules do not perform computation; their responsibility is to latch values between pipeline stages and maintain precise in-order semantics.

The following sections document each register stage.

1. IFID Stage Register

Purpose

The IFID module forms the boundary between the Instruction Fetch (IF) and Instruction Decode (ID) stages. It captures:

• The fetched instruction (IFID_instr__in)
• The program counter of that instruction (IFID_pc__in)

Inputs / Outputs

Operation

• If reset is asserted: outputs clear to zero (NOP equivalent).
• If IFID_we = 1: new instruction and PC propagate into ID.
• If IFID_we = 0: stage holds previous values (stall behavior).

Architectural Role

This module determines whether the pipeline:

• Accepts new instructions from IF,
• Stalls (e.g., load-use interlock),
• Flushes (by injecting a NOP into the inputs in the top module).

Pseudocode Representation

if reset:
    instr_out = 0
    pc_out = 0
else if IFID_we:
    instr_out = instr_in
    pc_out = pc_in
else:
    hold previous values

2. IDEX Stage Register

Purpose

The IDEX module forms the boundary between the Instruction Decode (ID) and Execute (EX) stages.

It captures decoded-data signals:

• Two register operand values (op0, op1)
• Immediate or extended operand (op2)
• ALU operation code (op)
• Destination register index (rT)
• Control bit x (pipeline-dependent; usually indicates whether this instruction writes a result or has special semantics)
• Program counter (for branch target calculation or JALR)

Inputs / Outputs

Write enable is permanently 1, meaning the ID→EX stage always advances (ID stalls are handled earlier in the top module).

Operation

• Always latches inputs every cycle unless reset is asserted.
• No stall input; upstream logic must ensure correctness before driving into this module.

Pseudocode

if reset:
    op0 = op1 = op2 = 0
    op = 0
    rT = 0
    x = 0
    pc = 0
else:
    op0 = op0_in
    op1 = op1_in
    op2 = op2_in
    op = op_in
    rT = rT_in
    x = x_in
    pc = pc_in

Architectural Role

• Preserves operand and control information exactly one pipeline stage before ALU execution.
• No hazard resolution occurs here; this stage simply conveys data.

3. EXMEM Stage Register

Purpose

The EXMEM module forms the boundary between the Execute (EX) and Memory (MEM) stages.

It captures:

• ALU result (EXMEM_ALUout__in)
• Store-data operand (EXMEM_stdata__in)
• Operation code (EXMEM_op__in)
• Destination register index
• Control flag x
• PC (for branch or JALR tracking)

Inputs / Outputs Table

Operation

• Always latches on the rising edge.
• Reset initializes to zero.
• No stall logic here; stall handling is done before entering EX.

Pseudocode

if reset:
    ALUout = 0
    stdata = 0
    op = 0
    rT = 0
    x = 0
    pc = 0
else:
    ALUout = ALUout_in
    stdata = stdata_in
    op = op_in
    rT = rT_in
    x = x_in
    pc = pc_in

Architectural Role

This stage passes:

• Load/store addresses
• Store data
• ALU results
• Register targets

into the memory stage.

Because forwarding uses the EXMEM outputs, this register is a key participant in the forwarding network.

4. MEMWB Stage Register

Purpose

The MEMWB module forms the boundary between Memory (MEM) and Writeback (WB) stages.

It captures:

• The final result to be written to the register file (MEMWB_rfdata__in)
• The destination register index
• Control flag x
• PC value (for JALR writeback)

Inputs / Outputs Table

Operation

• Latches new data every cycle.
• Reset clears the stage to zero.
• No stall logic; always advances.

Pseudocode

if reset:
    rfdata = 0
    rT = 0
    x = 0
    pc = 0
else:
    rfdata = rfdata_in
    rT = rT_in
    x = x_in
    pc = pc_in

Architectural Role

This register forms the final stage before register-file commit. It also supplies critical data to the forwarding network (MEM→EX forwarding).

Pipeline Register Summary Table

Functional Role in the Superscalar Pipeline

The combined pipeline-register set ensures:

1. Precise in-order execution semantics Each register stage ensures only one cycle’s worth of architectural data is forwarded at a time.

2. Dual-lane independence These modules are instantiated once per lane, maintaining separation of slot 0 and slot 1 flows.

3. Hazard-interaction points Forwarding network uses IDEX, EXMEM, and MEMWB outputs. Stall logic primarily interacts with IFID through its write-enable.

4. Flush insertion points Squash logic in the top module forces NOPs into IFID or IDEX to flush mispredicted or invalid instructions.