KONERU LAKSHMAIAH EDUCATION FOUNDATION

AZIZ NAGAR, HYDERABAD

DEPARTMENT OF ECE

Project Proposal
1.0 Details of Candidates: (i) [Link] Vardan(2210049149)

(ii) [Link] Venkata Ramana(2210049154)

(iii)[Link] Kiran Reddy(2210049156)

Course of Study: [Link]/ECE

Year: IV

Semester: I

Batch No.: 2204024R

2.0 Course Details: 22IE4053R

22IE4053R
3.0 Name of Supervisor: [Link] Kumar Kayam,
Assistant Professor, KLEF/ECE

4.0 Proposed Title: Design and Implementation of 32-bit Multi stage

RISC-V Processor

November, 2026

Page 1 of
36
5.0 Introduction

5.1 General Introduction

In recent years, a new instruction set architecture (ISA) has gained significant momentum: RISC-V
Originating from the University of California, Berkeley, RISC-V is a free and open-source ISA. This
openness distinguishes it from proprietary architectures like ARM and x86, removing licensing barriers
and fostering a global community of innovation in processor design. Its modular nature allows designers
to implement a minimal base integer instruction set and add standard or custom extensions as needed,
making it scalable for a wide range of applications, from embedded systems to supercomputers.

A key technique to enhance processor throughput is pipelining, where the execution of an instruction is
broken down into a series of independent steps or stages. By overlapping the execution of multiple
instructions, with each one in a different stage, a pipelined processor can, in ideal conditions, complete
one instruction per clock cycle. This project focuses on the design and implementation of a 32-bit, multi-
stage pipelined processor based on the RISC-V ISA. Specifically, it targets the RV32I base integer
instruction set, which is the foundation for all RISC-V implementations. The processor will be described
using the Verilog Hardware Description Language (HDL), a standard for designing and verifying digital
circuits. This project serves as a practical exploration of modern computer architecture principles,
demonstrating the complete design flow from architectural specification and logic design in Verilog to
functional verification through simulation. It aims to create a tangible, working model of a processor that
embodies the elegance of the RISC philosophy and the transformative potential of the open-source RISC-
V standard.

Page 2 of
36
RISC-V is an open instruction set architecture that focuses on simplicity and modularity. It is based on
reduced instruction principles that use fewer instruction types to execute operations efficiently. The core
idea is to provide a clean base instruction set and let designers add extensions depending on the
application. The base ISA is small and easy to implement, which makes it suitable for low power devices,
embedded controllers and teaching students the fundamentals of processor design. RISC-V avoids vendor
lock-in because the specification is open and free from licensing fees. Anyone can design, fabricate or use
a RISC-V core without paying royalties. This has encouraged a global community to build hardware,
software tools, peripherals and research projects around it. The ISA is modular, meaning cores can include
features like integer arithmetic only, or add extensions such as multiplication and division, atomic
operations, floating point or vector processing. This allows the same architecture to scale from tiny
microcontrollers to high-performance computing platforms. The design also supports both 32-bit, 64-bit
and 128-bit address space variants, enabling chips for consumer devices, servers and future systems.
RISC-V places importance on a fixed instruction length for the base encoding, which simplifies pipeline
stages and decoding.

Page 3 of
36
The figure illustrates the complete datapath of a five-stage pipelined RISC-V processor. It brings together
instruction fetch, register decode, arithmetic execution, memory access, and write-back operations into a
continuous hardware pipeline. Each functional block is separated by pipeline registers that preserve
instruction state and structural consistency. This design makes it possible for multiple instructions to be
in different phases simultaneously, improving throughput without reducing clock frequency. The diagram
clearly shows how the datapath is constructed, how control signals flow, and how data hazards are
avoided. Understanding this drawing is essential because it transitions the design from abstract ISA
concepts to physical RTL implementation.

1. Instruction Fetch Stage and Program Counter

The pipeline begins with the Program Counter (PC) located on the far left. The PC stores the memory
address of the current instruction. During each clock cycle, the PC either increments by four or redirects
based on control decisions such as branch outcomes. The PC connects directly to the instruction memory
block, which supplies the 32-bit instruction corresponding to the address. Once retrieved, the instruction
is moved to the IF/ID pipeline register. This register is the first checkpoint in the pipeline, ensuring that
instruction bits do not change after they have been fetched.

The PC update logic is shown as a multiplexer with two inputs. One input provides PC + 4, used for
sequential instruction flow. The other input accepts a branch target or jump destination. The multiplexer
selects between these values based on a control line, typically resolved in later pipeline stages. This
mechanism helps redirect control flow without breaking the pipeline structure. Instruction fetch does not
decode or interpret the opcode; it simply retrieves the binary instruction and passes it forward. This
simplicity is essential for clocking efficiency, as fetch must be fast and predictable.

2. Instruction Decode and Register Read

The output of the IF/ID register enters the decode stage. Here, the instruction is broken into its fields:
register index values, immediate data segments, opcode, and function codes. These fields are passed into
a set of dedicated units. The register file is one of the central components. It provides two read ports that
deliver operand values based on register index inputs. It also includes a write port that receives results
during the write-back stage. In the diagram, read register 1 and read register 2 inputs travel into the register
file, producing read data outputs that will feed the ALU in later stages.

The decode stage also prepares immediate values. Immediate extraction is not a single operation; different
instruction types require different slices of bits, sign extension rules, and shifts. The diagram shows
separate immediate generation paths for I-type, S-type, and B-type instructions. These are combined into
a unified 32-bit immediate that will be forwarded to the Execute stage through the ID/EX register. The
decode stage also contains the control logic that interprets the opcode. This block generates the signals
that determine ALU behavior, register writes, memory operations, and branching. These signals flow in
parallel with the data they manipulate and are stored in the pipeline boundary alongside operand values.

Page 4 of
36
The ID/EX pipeline register serves as the buffer between decode and execute. It captures the operands,
immediate, destination register, and the control lines associated with this instruction. Without this register,
datapath values could fluctuate as new instructions are decoded, making the pipeline unstable. Capturing
state at this boundary ensures that the execute stage only sees finalized inputs.

3. Execute Stage and ALU Operation

At the heart of the datapath lies the Execute stage. Here, arithmetic and logic operations are performed,
and branch decisions are evaluated. The ALU is depicted in green, sitting inside the center of the diagram.
It receives operands from two possible paths. One input always comes from the register file output. The
other input may come from either a second register operand or an immediate value. The multiplexer
labeled ALUSrc decides which type of second operand to send. Instruction format determines this
selection. Arithmetic instructions use register operands, while immediate instructions pass the sign-
extended immediate.

Once both inputs are selected, the ALU performs the operation determined by the control unit. The ALU
control logic is shown below the multiplexer. It resolves opcodes and function bits into specific hardware
actions such as addition, subtraction, logical AND, or shift. The result of this computation becomes the
write-back candidate, but it also may serve as an address for load/store instructions.

The diagram also reveals branch comparison logic. Instead of relying on software flags, the ALU directly
checks if two operands satisfy the condition. A dedicated branch decision output is fed back into the PC
multiplexer. If the outcome is true, the next PC value will be the branch target, not PC+4. This structural
approach reduces branch latency because comparison is done in hardware during execution.

The EXE/MEM pipeline register sits at the boundary to preserve intermediate state. In addition to the
ALU output, it carries the data that may be written to memory, the destination register index, and the
control bits that govern memory and write-back behavior. These control bits must remain synchronized
with the data they affect, and so they are transported together.

4. Memory Stage and External Data Access

The Memory stage processes only those instructions that use external storage. Load and store operations
rely on the address produced by the ALU in the execute stage. In the diagram, the address enters the Data
Memory module. For store instructions, the register value collected in ID/EX flows to EXE/MEM and
becomes the write input. For load instructions, the memory returns a 32-bit word which is transported
forward. Non-memory instructions pass through this stage unused, but their datapath state is still carried
by pipeline registers.

The memory subsystem is represented as a combinational read structure in basic simulations, but
conceptually it models synchronous RAM. The pipeline cannot stall arbitrarily, so memory access must
remain deterministic. Reads are treated as returning a value at the end of the MEM clock cycle, which
ensures load results are valid by the time they enter Write-Back. The memory block does not perform any
Page 5 of
36
interpretation; it simply transfers data based on the address and control signals forwarded from previous
stages.

The MEM/WB register captures the output of this stage. It stores the memory read data, the ALU result,
and the identity of the destination register. These signals proceed to the final stage where the correct write-
back value is chosen.

5. Write-Back Stage and State Retirement

In the final stage, the processor decides whether the write-back value should come from the ALU or from
the data memory. The Write Back multiplexer, shown on the far right, implements this decision. If the
instruction was arithmetic or logical, the ALU result is selected. If it was a load instruction, the memory
data is used. The selected value is then sent back to the register file’s write port. Only instructions that set
the RegWrite control line will modify the register file. Others, such as stores or branches, do not alter
register state.

This mechanism completes the instruction lifecycle. The write-back stage marks the moment when an
instruction permanently changes the architectural state. From the pipeline perspective, an instruction that
reaches write-back is “retiring” from active execution. The process aligns performance with consistency,
enabling one instruction to retire per cycle in steady-state operation.

Final Perspective

The image captures the architecture of a practical five-stage RISC-V processor. Instruction fetch provides
the binary program code, decode interprets it, execute performs the core computation and branch logic,
memory accesses external data when required, and write-back updates registers. Pipeline registers isolate
each stage to maintain stability and timing alignment. Every arrow and multiplexer highlights a specific
decision point where architectural behavior is determined. The design is not theoretical; it directly
translates to synthesizable Verilog RTL and behaves like a real CPU under simulation.

Page 6 of
36
5.2 Problem Statement

Modern computing systems require processors that deliver high performance while keeping
power consumption low and maintaining flexibility for a wide range of applications. Traditional
proprietary processor architectures limit innovation because they involve licensing costs, closed
specifications and restricted access to internal design. These barriers make it difficult for
researchers, students and small companies to experiment with new approaches or customize
hardware for domain-specific needs. In this context, there is a need for an architecture that is
simple to implement, scalable across devices and free from ownership constraints. The challenge
is to design and evaluate a processor solution that supports core functionality, can be modified
for specialized tasks and integrates smoothly with existing hardware and software ecosystems.
The problem addressed in this work is to explore a RISC-V based design that satisfies these
requirements by providing an open, modular and extensible instruction set suitable for
embedded, educational and industrial environments.

5.3 Objectives of the study

The scope of this project is focused on creating a foundational, educational model of a 32-bit RISC-V
processor. The specific boundaries are as follows:
 Instruction Set: The processor will implement the base integer instruction set, RV32I, as defined
by the RISC-V standard. This includes integer arithmetic, logical operations, load/store
instructions, and conditional branches. Extensions such as multiplication/division (M), atomic
operations (A), or floating-point (F/D) are outside the scope of this project.
 Architecture: The design is a 5-stage scalar pipeline. Advanced architectural features such as
superscalar execution, out-of-order execution, caching, virtual memory, and complex branch
prediction are not included.
 Implementation: The processor will be implemented in Verilog HDL. The project will focus on
the RTL design and functional simulation. Physical design aspects like synthesis, placement, and
routing for a specific FPGA or ASIC target are not within this project's scope.
 Hazard Handling: The design will include logic to detect and mitigate data hazards using
forwarding and pipeline stalls. Control hazards resulting from branch instructions will be handled
using a simple "predict not taken" strategy and pipeline flushing.

Page 7 of
36
5.4 Literature Review

The development of open instruction set architectures has gained momentum in recent years, with RISC-V
becoming one of the most prominent candidates. Early work on reduced instruction sets showed that
minimizing the number of instructions can simplify processor design and improve performance per watt.
This concept originated from Stanford and Berkeley projects in the 1980s, which demonstrated that
simpler hardware pipelines can yield efficient execution. Later commercial architectures such as ARM
and MIPS adopted these ideas but remained proprietary. Researchers and industry practitioners identified
the need for a universal instruction set that could be studied, implemented and extended without licensing
barriers. This context led to the RISC-V initiative at the University of California, Berkeley, which aimed
to create a clean ISA capable of scaling across heterogeneous computing platforms.
Studies comparing RISC-V with legacy commercial ISAs emphasize that openness is a core advantage.
Unlike ARM or x86, RISC-V does not impose closed vendor constraints, allowing designers to freely
experiment with processor pipelines, microarchitectural modifications and custom extensions. Literature
highlights that this freedom accelerates academic research because performance-critical features such as
branch prediction, accelerator integration and fault tolerance can be explored without proprietary
limitations. Researchers have used RISC-V to prototype low power processors, chiplet-based designs and
configurable digital architectures. This has made it a preferred teaching platform for digital design courses
and VLSI laboratories where students gain practical experience by modifying the ISA or implementing
new features.
Modularity is another theme in published work. The ISA defines a compact base instruction set, with
additional extensions for multiplication, floating point arithmetic, atomic operations and vector
processing. Research shows that this structure allows processor implementations to remain lightweight
for embedded devices or scale to high performance computing. For example, RV32 cores are widely used
in microcontroller research, while RV64 and RV128 are examined for servers, accelerators and emerging
computing platforms. The compressed instruction extension has received attention for reducing memory
size in edge applications, proving valuable in real-time embedded systems where instruction space is
limited.
Performance studies explore how RISC-V pipelines behave under different workloads. Papers analyzing
single cycle and multi-stage pipeline designs show that instruction throughput improves significantly
when hazards are resolved through forwarding or stalling methods. Researchers have also explored
superscalar and out-of-order execution in RISC-V cores. The BOOM project, for instance, investigates
high performance backend structures that support predictive execution and wide instruction issue.
Comparisons between simple educational cores and advanced implementations underline that the ISA
does not constrain microarchitecture, giving designers broad freedom to optimize hardware.
Another large area of literature focuses on domain specific acceleration. RISC-V supports custom
instructions, which has been used to integrate neural processing units, cryptographic accelerators and
DSP engines. Publications show that these extensions reduce latency and power when compared to off-
chip acceleration. In contrast to proprietary ISAs, these modifications can be developed, tested and
distributed openly. This promotes industrial and academic collaboration, which is reflected in the rapid
growth of open source processor repositories and development frameworks.
Toolchain and software support appear frequently in the literature as well. Compiler research shows how
instruction scheduling, loop unrolling and vectorization can be optimized for RISC-V hardware. Projects
such as GCC and LLVM provide an established foundation for code generation, while simulators like
Spike and gem5 allow full-stack architectural evaluation. Operating system research demonstrates stable
Page 8 of
36
 Linux and RTOS support, which has enabled experiments in embedded computing, IoT security and
hardware virtualization. As a result, RISC-V has moved beyond theoretical interest and entered
commercial and industrial development.
Overall, the existing body of research presents RISC-V as a flexible, transparent and future-oriented
architecture. Publications consistently report that it encourages innovation by lowering entry barriers and
maintaining technical clarity. Whether used for introductory digital design, advanced microarchitectural
research or specialized accelerator exploration, RISC-V has become a reference point for modern
hardware design. The literature suggests that ongoing community and industry involvement will continue
strengthening its ecosystem, making it a long term solution for both academic and commercial computing
environments.

Pipelining and Hazard Management

To achieve high performance, modern processors rely on pipelining. This technique is analogous to an
assembly line, where the process of executing an instruction is divided into several stages. The classic
RISC pipeline, as detailed by Patterson and Hennessy, consists of five stages:
1. IF (Instruction Fetch): Fetches the next instruction from memory.
2. ID (Instruction Decode): Decodes the instruction and reads the required operands from the register
file.
3. EX (Execute): Performs the arithmetic or logical operation using the ALU.
4. MEM (Memory Access): Reads from or writes to data memory.
5. WB (Write-Back): Writes the result back into the register file.

Hazards in a pipeline occur when different instructions interfere with each other during execution. A hazard
appears because the pipeline moves several instructions at the same time through different stages, and
not all instructions have independent data or resources. A common cause is when one instruction
produces a result that another instruction needs, but the result is not ready yet. The later instruction
reaches a point where it expects valid data, but the earlier one is still computing it. The pipeline has to
wait, which reduces the flow of instructions and slows performance. Another frequent cause is when two
instructions use the same hardware block. Many pipeline designs share execution units, buses, caches or
Page 9 of
36
 memory ports. If two instructions arrive at that unit during the same cycle, only one can execute, causing
the other to pause. This leads to wasted cycles and lower throughput. Hazards can also arise from changes
in instruction flow. If the program decides to branch, the pipeline may continue fetching instructions from
the wrong path until the branch decision is known. Those instructions become invalid and must be
discarded. This creates bubbles in the pipeline and increases total execution time. When processors
attempt to increase speed with deeper pipelines or wider issue slots, hazards become more likely because
more instructions are active at once. The hardware has to track relationships between instructions .

Hazards in computer architecture are conditions that interrupt the smooth flow of instructions in a pipeline.
When a pipeline works correctly, each stage handles part of an instruction every clock cycle. Hazards
create situations where one stage has to wait or the output becomes incorrect. Understanding hazards
helps in designing better processors and improving performance.
1. Structural Hazards
These occur when two or more instructions need the same hardware resource at the same time. If the
processor has a single memory unit for both instruction fetch and data access, a load instruction might
conflict with the next instruction fetch. To solve this, designers can duplicate hardware, use multi-port
memory or stall the pipeline to wait for the resource.
2. Data Hazards
Data hazards happen when instructions depend on results that are not yet available. There are three
common types:
 RAW (Read After Write). The most frequent one. An instruction needs a value that a previous
instruction is still computing.
 WAR (Write After Read). A later instruction writes to a register before an earlier instruction has
read it.
 WAW (Write After Write). Two instructions want to write to the same register, but the order
must be preserved.
Forwarding, operand bypassing and pipeline stalls are common solutions. Out-of-order processors
use register renaming to remove WAR and WAW issues.
3. Control Hazards
These occur when the pipeline cannot predict the next instruction because of branches or jumps. When
a branch decision is not known, the pipeline may fetch the wrong instruction. Designers use branch
Page 10 of
36
 prediction, delay slots or speculative execution to reduce these penalties. Modern CPUs use dynamic
predictors that track past branch outcomes to guess future behavior.
Hazards slow down pipelines because they cause bubbles or stalls. A bubble is an empty slot inserted into
the pipeline so that instructions do not collide or produce wrong results. The more hazards appear, the
lower the instruction throughput. High performance processors try to detect hazards early and deal with
them in hardware, while simple processors often accept stalls for easier design.
In summary, hazards are a natural side effect of pipelining. They occur when resources conflict, when data
is unavailable or when control flow changes. Good processor design focuses on minimizing their
impact with forwarding paths, prediction methods and careful hardware organization. Understanding
hazards is essential for designing efficient single-cycle, pipelined and superscalar architectures.

Page 11 of
36
Page 12 of
36
 6.0 Abstract:

The demand for high-performance computing platforms that maintain energy

efficiency, adaptability and scalability has led to renewed interest in open
processor architectures. RISC-V is one of the most significant contributions in this
direction, providing a clean and modular instruction set that can be implemented
without licensing barriers. Its design supports a compact base instruction set and
optional extensions that allow developers to tailor a processor to the needs of
embedded, general-purpose or high-end computing systems. The openness of the
architecture encourages academic exploration, industrial customization and rapid
innovation in processor design. This work examines the development of a RISC-
V based system and evaluates its suitability for modern digital applications.

The project begins with a study of the RISC-V instruction set, focusing on the structure
of the base ISA and the role of extensions. The simplicity of the core instruction
set makes it easier to understand execution flow, while the modular approach
allows targeted enhancement. A key portion of the study involves examining
pipelined operation and identifying hazards that affect instruction throughput.
Structural conflicts, data dependencies and control changes create performance
penalties in a pipeline. Standard techniques such as forwarding, stalling and branch
prediction are reviewed as methods for reducing these effects. These concepts form
the foundation for designing efficient microarchitectures capable of handling real
workloads.

Implementation focuses on a practical system where a RISC-V processor is modeled

and simulated. The design process explores trade-offs between single-cycle and
pipelined execution, highlighting the benefits of overlapping instruction stages and
the challenges introduced by hazards. Simulation tools and testbenches are used to
verify functional correctness and analyze timing behavior. Observations from this
phase provide insight into how architectural choices influence performance and
resource cost. The study also investigates how extensions or custom logic can be
integrated to accelerate specific tasks, showing the advantage of an open
instruction set.

The outcomes demonstrate that RISC-V can serve as a flexible platform for education,
research and industry. Its transparency supports learning, its modularity helps
designers create efficient processors, and its open ecosystem reduces barriers for
hardware development. The findings suggest that continued growth of the RISC-
V community will strengthen compiler support, operating system compatibility
and hardware optimization techniques. This work contributes to the understanding
of how open processor architectures can shape future digital systems and offers a
foundation for further exploration of low-power design, fault tolerance and
domain-specific acceleration.

Page 13 of
36
 This paper presents the design and implementation of a 32-bit, five-stage pipelined
processor based on the open-source RISC-V instruction set architecture (ISA). The
increasing adoption of RISC-V in both academia and industry highlights the need for a
clear, practical model for educational and research purposes. The core problem this project
addresses is the abstraction gap between the theoretical principles of computer architecture
and the practical register-transfer level (RTL) implementation. Our work provides a
complete and functional processor design that adheres to the RV32I base integer
instruction set, serving as a hands-on platform for understanding modern processor design.

The proposed processor employs a classic five-stage RISC pipeline: Instruction Fetch (IF),
Instruction Decode (ID), Execute (EX), Memory Access (MEM), and Write-Back (WB).
This architecture is designed to achieve a throughput approaching one instruction per
clock cycle. The entire processor is implemented using the Verilog Hardware Description
Language (HDL). Key components, including the 32-bit ALU, the 32-entry register file,
the control unit, and the datapath, are modularly designed and integrated. To ensure
correct execution in the pipelined environment, hardware mechanisms to handle data and
control hazards are implemented. Data hazards are resolved using a comprehensive
forwarding unit and a stall-generation unit, while control hazards from branch instructions
are managed by flushing the pipeline.

The functionality of the processor is verified through extensive simulation using a Verilog
testbench. A series of test programs written in RISC-V assembly are used to validate the
correct execution of all implemented RV32I instructions. The expected result is a fully
functional Verilog model of the RV32I processor that passes all simulation tests. The final
design will successfully demonstrate the core principles of pipelining, including hazard
detection and resolution, providing a robust and well-documented foundation for future
extensions and research in computer architecture.

7.0 Methodology
The methodology for this project follows a structured digital design flow, encompassing
specification, architectural design, RTL implementation, and functional verification.

1. Specification: The first step was to define the precise requirements of the
processor.
o ISA: The RISC-V RV32I Base Integer Instruction Set was chosen as
the target ISA. All instruction formats (R-type, I-type, S-type, B-type,
U-type, J-type) and opcodes were studied and mapped.
o Architecture: A classic 5-stage pipeline (IF, ID, EX, MEM, WB) was
selected as the microarchitecture. This provides a balance of
performance improvement and design comprehensibility.
o Features: The processor was specified to include a 32-bit datapath, 32
general-purpose registers, and support for handling data hazards via
forwarding and stalling, and control hazards via pipeline flushing.

Page 14 of
36
2. Architectural Design: This phase involved creating a high-level blueprint of the
processor.

The development of the pipelined RISC-V processor was guided by a

carefully organized digital design process. The project progressed in multiple
phases, each building upon the outcomes of the previous stage. The aim was
to transform a functional idea into a fully verified hardware model that
behaves consistently under simulation. The methodology followed a classical
engineering approach, starting from understanding the problem space and
concluding with a verified Register-Transfer Level implementation. Although
this design was implemented for educational and experimental purposes, the
same principles mirror those used in professional chip-design environments.

3. Understanding Requirements and Defining the Target System

The first task was to clearly define what type of processor needed to be built. A digital design cannot
begin with coding or schematic construction because hardware behaves deterministically. Every
signal, register, and functional unit must be known before writing the first line of Verilog. The system
requirements focused on creating a 32-bit pipelined processor based on the RISC-V instruction set.
Unlike proprietary ISAs, RISC-V offers an open standard that is well documented, stable, and suitable
for educational research. The RV32I instruction set was chosen as the starting point. It provides the
essential arithmetic, branch, load, and store instructions needed to execute fundamental programs.
Since the objective was not to build a superscalar or deeply optimized CPU, RV32I offered the correct
balance of simplicity and realism.

Studying the ISA was necessary to understand the instruction formats. The six formats—R-type, I-
type, S-type, B-type, U-type, and J-type—determine how opcodes, register identifiers, immediates,
and control bits are encoded in a 32-bit field. Every bit in the instruction has meaning, and the
processor must decode this structure correctly. Decisions made at this level affect every stage of the
pipeline. A wrong bit mapping leads to a broken datapath. For this reason, the decoding rules were
examined thoroughly, including sign-extension behavior, immediate generation, and field slicing.
Understanding how these formats work also affects execution resource decisions. For example, branch
instructions require comparison and program counter updates, while store operations depend on
memory addressing and write enable logic.

After the ISA selection was finalized, the performance model had to be chosen. A classical five-stage
pipeline was selected as the architectural foundation. This model consists of Instruction Fetch,
Instruction Decode, Execute, Memory Access, and Write Back. The choice was not arbitrary. A single-
cycle CPU would be simpler, but it wastes performance because only one instruction can be processed
at a time. A multi-cycle CPU improves cycle time but complicates control flow. The five-stage
pipeline is well understood, has predictable timing behavior, and offers a balanced speed improvement
without overwhelming complexity. Its structure makes it ideal for academic projects, textbooks, and
introductory microarchitectural experiments.

With the functional and architectural scope decided, the design requirements were finalized. The
processor would contain a 32-bit datapath and a bank of 32 registers, with the zero register hardwired.
It would also include hazard resolution units. Hardware hazards are unavoidable in pipelines because
Page 15 of
36
 data often appears later than the instruction that needs it. Without mitigation, the processor would
produce incorrect results. Designing with hazard support from the start ensures the implementation
aligns with real CPU needs.

4. Conceptual Model and High-Level Layout

The architectural phase dealt with translating written specifications into a visual structure. This step of the
design flow resembles drawing a circuit floorplan rather than writing code. Each functional block was
placed conceptually in the pipeline so that data could flow along defined paths. The datapath became the
backbone. It connects the Program Counter, the instruction memory, the register file, the ALU, the
memory interface, and the write-back connections. Every component must have predictable behavior. If
the ALU expects two operands during a cycle, they must be available. If the register file is written during
the Write Back stage, the updated value must not leak into earlier stages prematurely.

The Program Counter subsystem was one of the first blocks to be designed. Its job is deceptively simple:
hold the address of the next instruction. In a real pipeline, however, the PC must respond to branches,
sequential increments, stalls, and flush events. It cannot merely add four and advance. That works only if
every instruction completes normally. When a branch is taken, the PC must redirect to a target address.
When the decoding stage detects a load hazard, the PC must pause for one cycle. These behaviors need
explicit circuitry. The architectural stage modeled these possibilities and prepared the PC logic to accept
control signals from other parts of the processor.

Next, the register file was defined. It stores the working data used by instructions. Two read ports deliver
operands, and one write port updates results at completion. Designing this component is not about memory
capacity; it is about timing. Reads must complete during the Decode stage so that the ALU receives valid
data during Execute. This requirement means the register file is a combinational read structure. There is
no time to clock a value in the middle of a pipeline stage. Writes, on the other hand, must occur at the end
of the pipeline when the instruction retires. This dual behavior requires separate control conditions. In
addition, the register at index zero is constant. The design implements this rule explicitly so that no module
can inadvertently modify it.

The ALU becomes the core computational engine. It receives two source operands and a control code that
determines the type of arithmetic or logical operation. Part of architectural design is matching ALU
capabilities to instruction requirements. For example, shift operations, additions, comparisons, and logic
functions were all mapped to ALU subunits. The ALU also produces branch comparison signals, which
allows the processor to determine whether to redirect execution.

With the datapath roughly laid out, the pipeline register boundaries were defined. Each stage must capture
every relevant signal so it does not change before the next clock edge. This includes the instruction bits,
register indices, immediate values, ALU results, and control flags. The architectural blueprint listed
everything to be stored at each stage boundary and ensured that no signal crossed stages unsafely.

Page 16 of
36
5. Designing the Control Behavior

The central brain of the processor is its control system. Unlike datapath blocks, which operate on values,
control logic determines how each block behaves. Instruction decoding was mapped to a combinational
logic system that interprets opcodes and generates control outputs. When an instruction arrives at the
Decode stage, the control unit generates RegWrite, ALUSrc, Branch, MemRead, and MemWrite signals.
These control lines tailor the processor behavior for each instruction type. The advantage of combinational
control over microcoded control is reduced latency and easier debugging. There is no need for an
instruction template or sequencing engine; decisions are made instantly based on bits.

Control signals must travel through the pipeline as well. A write enable for instruction N+1 cannot
interfere with instruction N being executed. To avoid confusion, each stage carries its own private set of
control lines. These lines are not re-computed; they are captured when the instruction enters the stage.
This design choice prevents misalignment and avoids situations where the wrong instruction drives the
ALU or memory.

Branching behavior adds another layer of complexity. A branch instruction cannot know its outcome
immediately. The condition is checked during Execute, but Instruction Fetch may already be loading the
next instruction. If the branch is taken, the partially fetched instruction must be discarded. This means
flushing logic must purge the incorrect instruction from the pipeline. The architectural model accounted
for this behavior by introducing invalidation paths and redirection signals.

6. Avoiding Data Collisions and Pipeline Interruptions

One of the most important challenges in pipelined systems is resolving data hazards. These occur when
two instructions need access to the same register data at different times. A Read-After-Write dependency
is the most common. An instruction calculates a value, but the next instruction needs it immediately. In a
naive pipeline, this scenario would create a wrong result. To avoid delays, hardware forwarding was
implemented. Instead of waiting for a value to appear in the register file, the processor redirects it from
later pipeline stages back into the ALU. This produces correct behavior without inserting bubbles.

Forwarding is not always possible. Load instructions produce data only after the Memory stage. If the
next instruction depends on that value in the very next cycle, no forwarding path can satisfy it. The
processor must pause. The stall control unit detects this condition and freezes the pipeline for one cycle.
The pipeline registers shift in a bubble so that the dependent instruction enters Execute only when the data
becomes available. This technique maintains correctness at the expense of a single cycle delay.

These hazard mechanisms required a careful structural design. The hazard detection systems monitor
register indices of the instructions currently occupying the ID, EX, and MEM stages. They then decide
when to forward, when to stall, and when to let execution proceed normally. Their behavior is proactive
rather than reactive. They do not wait for a wrong case to appear; they anticipate it and prevent it before
any incorrect value is consumed.

Page 17 of
36
7. From Architecture to RTL Code

Once the conceptual model was complete, the processor was implemented using Verilog HDL. This stage
brought the abstract processor to life. Each block was coded as a separate module, following a modular
structure. The ALU, register file, hazard logic, pipeline registers, PC logic, and control decode were each
implemented independently. This approach increased clarity. If errors were found later, debugging was
more focused because each module had a defined responsibility.

The top-level module tied everything together. It served as the silicon skeleton. Individual functional
blocks were instantiated, and signals were routed from one module to another. Care had to be taken
regarding bit widths and timing. Every signal crossing pipeline boundaries became clocked logic. Pure
combinational paths had to complete computation in less than one cycle of simulation time.

Memory models were then developed. The project did not use physical RAM, so behavioral memory
modules were created. The instruction memory was pre-loaded with programs. The data memory
responded to read and write requests. These models were simple but complete, allowing the system to
simulate real scenarios without requiring external hardware.

8. Validation of Design and Simulation

Testing began once the RTL code was stable. Verification was not a single test run; it was a staged and
incremental process. Small programs were written in assembly language to exercise individual
instructions. Arithmetic sequences confirmed ALU correctness. Load and store programs verified memory
behavior. Branch sequences confirmed PC update logic. After these basic tests passed, more advanced
programs were created to trigger hazards. These sequences purposely produced back-to-back
dependencies or branch redirections.

The simulation environment was developed to monitor processor state. A testbench controlled clocks,
resets, and memory initialization. Its responsibility was not only to drive input signals but also to check
final results. The system compared register values to expected outcomes at the end of simulation.
Waveforms were observed using GTKWave or ModelSim. They allowed visual inspection of internal
signals and confirmed pipeline movement cycle by cycle. In cases where a wrong register value appeared,
waveforms pinpointed the exact cycle that produced the discrepancy.

Debugging followed a disciplined pattern. If a mismatch occurred, the failure was traced backward
through the pipeline to locate the misconfigured control signal or decoding error. Adjustments were made
only where necessary. Eventually, the processor passed every test, which confirmed the correctness of the
RTL design and logical consistency of the architecture.

Page 18 of
36
 o Datapath Design: The datapath was designed, outlining the flow of
data between the main functional units. This included designing the
Program Counter (PC) logic, instruction and data memory interfaces,
the register file, the ALU, and the pipeline registers that separate the
five stages.
o Control Unit Design: The control unit was designed as a
combinational logic block. Its main role is to decode the instruction
opcode and generate all the necessary control signals for the datapath
(e.g., RegWrite, ALUSrc, MemRead, MemWrite, Branch).
o Hazard Unit Design: Dedicated units for hazard detection were
designed. The forwarding unit detects Read-After-Write (RAW)
dependencies and provides forwarding paths from the EX and MEM
stages back to the EX stage. The stall unit detects load-use hazards that
forwarding cannot resolve, forcing a one-cycle bubble into the
pipeline.
9. RTL Implementation: The architectural design was translated into hardware code
using Verilog HDL.
o Modular Implementation: The design was implemented in a
modular fashion. Separate Verilog modules were created for the ALU,
register file, control unit, hazard unit, and each pipeline stage register.
o Top-Level Integration: A top-level module was created to instantiate
and interconnect all the sub-modules, forming the complete processor.
o Memory Modeling: Simple behavioral models for instruction and
data memory were created in Verilog to support the simulation
environment.
10. Verification: A rigorous verification process was designed to ensure the
correctness of the implementation.
o Test Program Development: A suite of test programs was written in
RISC-V assembly language. These tests were designed to individually
and collectively exercise every RV32I instruction and to create
specific data and control hazard scenarios.
o Testbench Creation: A comprehensive Verilog testbench was
developed. The testbench initializes the instruction memory with the
assembled test programs, drives the processor clock, and monitors key
outputs (such as register values and memory state).
o Simulation and Debugging: The design was simulated using a
Verilog simulator (e.g., ModelSim, Icarus Verilog). The simulation
output and waveforms were analyzed to debug and fix any logical
errors in the design until the processor produced the correct results for
all test programs.

Page 19 of
36
This work explores the design and implementation of a RISC-V based processing
system with a focus on understanding pipeline behavior and handling hazards.
RISC-V provides an open and modular instruction set that simplifies hardware
development and allows architectural customization without licensing barriers.
The project examines how a clean base ISA enables stable execution while
extensions offer flexibility for real applications. The processor model is
implemented using a pipelined structure, which improves throughput by
overlapping multiple instruction stages. Hazards caused by resource conflicts, data
dependencies and control flow changes are analyzed and managed using practical
techniques such as forwarding and pipeline stalls. Simulation results highlight how
performance changes when mitigation strategies are applied and how pipeline
depth influences overall efficiency. The study shows that RISC-V is suitable for
educational and experimental use because it provides a transparent environment
for testing microarchitectural ideas. The work concludes that a modular ISA,
combined with careful pipeline design, can deliver efficient computation while
remaining flexible for future extensions and optimization.

Page 20 of
36
8.0 Expected Output

Page 21 of
36
The figure represents the final RTL schematic generation of the complete 32-bit pipelined RISC-V
processor design. This generated view is commonly produced by HDL tools after synthesis or
elaboration. It shows how all logical blocks of the processor interconnect at the gate-level and how
data flows through different functional components. Unlike conceptual block diagrams, this view
reveals every wire, multiplexer, gate, and bus connection. It verifies that the architecture has been
translated into actual hardware, and it provides insight into the scale and complexity of a real
processor.

The schematic corresponds to a five-stage pipeline in which each instruction moves through Instruction
Fetch, Instruction Decode, Execute, Memory, and Writeback stages. The top region contains high-
fanout signal lines such as the system clock and reset. These global signals are required by every
major submodule. Once these signals enter the datapath, they are distributed to the pipeline registers
and control logic. Because each stage has its own register boundary, the clock network fans out
across a wide region of the diagram. The repeated square symbols in the figure represent flip-flops
that hold 32-bit values during each pipeline cycle. These registers are responsible for passing
instruction results forward while preventing backward data flow.

The large vertical portion in the middle is the instruction decode and register access region. This area
handles reading the source registers, extracting fields from the instruction, and preparing inputs for
execution. The reason it appears dense is because 32-bit register files include many simultaneous
connections. Each register output is not a single wire but a vector of 32 parallel lines, one for every
bit. When these lines fan out to the decoder and ALU, they create a visually complex bundle of
traces. These connections are not redundant; every bit of every register must be available to
downstream logic. The wider the datapath, the heavier the wiring density becomes.

One of the clearest features of the schematic is the branching network of multiplexers. Many of these
muxes are part of the hazard handling and forwarding logic. In a pipelined processor, values may
need to bypass normal paths to avoid pipeline stalls. For example, when an instruction produces a
value in the execution stage and the next instruction needs that value in the same cycle, the
forwarding unit routes it directly rather than waiting for the write-back stage. These muxes detect
which output should be selected at each stage. That is why multiple lines converge into the same
junctions. These are conditional paths that depend on control signals generated by the hazard unit.

Another noticeable cluster on the right edge corresponds to the memory interface and write-back logic.
These buses connect the ALU output, memory data, and destination register input. Based on
instruction type, the processor either forwards ALU results or memory data to the register file. This
decision is controlled by the control unit, and the schematic reflects that through multiplexer chains.
Memory instructions such as LW or SW require 32-bit address inputs and data buses. These
contribute additional wiring complexity. Even though the logic may look dense, each group of wires
represents a clean and predictable transfer of data from one functional module to another.

The lower region of the schematic includes pipeline registers. Every stage boundary is enforced by a
block of flip-flops that hold all necessary control and datapath signals. These include the immediate
field, register indices, ALU operation codes, and pipeline enable signals. The schematic displays
these storage elements as repetitive blocks. The repetition is expected because all stages must
preserve a snapshot of the instruction as it flows through the processor. Without these registers, the
Page 22 of
36
 logic would collapse into combinational chaos and timing would be violated. The pipeline registers
are what turn the design into a true multi-instruction hardware pipeline.

This output also serves as an indirect verification of modularity. Each functional block that was designed
separately in Verilog now appears integrated into a unified processor. The ALU, register file, MUX
layers, and pipeline registers do not float independently; they form a continuous datapath allowed by
the control unit. The existence of this schematic means the HDL was syntactically correct, free of
unresolved signals, and structurally complete. If there were missing assignments or mismatched
widths, the tool would not produce a schematic of this depth.

Another important observation relates to timing and scale. The diagram visually demonstrates how wide
the implementation becomes when the datapath is 32 bits. For every logic operation, the hardware
must operate on each bit simultaneously. Software designers write ADDI as a single instruction, but
in hardware it is 32 separate additions happening in parallel, coordinated by a single carry chain.
Each wire carries one bit of information, so a single operand bus equals 32 distinct lines. When buses
are duplicated, pipelined, and forwarded, they multiply into dense clusters of parallel traces. This is a
natural and unavoidable characteristic of digital hardware design.

Although the schematic is visually overwhelming, it provides important insight. It confirms that the
abstract architecture was translated into real hardware components. It provides a way to trace signals,
diagnose bugs, and verify pipeline correctness. Designers use this schematic to ensure there are no
unintended combinational loops, no missing resets, and no unconnected ports. It also helps confirm
that each instruction path is implemented as intended. When a designer selects a particular signal and
follows its fan-out through the wiring, they can see the exact destinations and transformations applied
by the hardware.

In summary, the schematic shown is the expected output for a full 32-bit pipelined RISC-V processor. It
captures register file wiring, ALU datapath, hazard bypass networks, pipeline register chains,
memory interfaces, and global control connections. It demonstrates that the processor is fully
elaborated, with no missing logic, and ready for simulation or synthesis. While complex in
appearance, every line corresponds to a necessary hardware process. The figure therefore represents
the physical manifestation of the processor’s core design, and confirms that the RTL architecture has
been constructed correctly at the gate-level.

Page 23 of
36
The schematic shown in the figure represents the fully elaborated internal layout of the 32-bit five-stage
pipelined RISC-V processor. This is the output produced by a synthesis or elaboration tool once the
HDL modules have been interpreted into structural netlists. In this view, the design is not shown as
modular Verilog blocks, but instead as wires, nets, paths and gate-level logic connections. It is
essentially a visual translation of the RTL description into physical connectivity. Each green line
corresponds to an electrical signal that connects different parts of the datapath. The dense vertical
bands represent clusters of parallel wires, such as 32-bit buses, register outputs, immediate paths,
and control signals. The fact that the processor appears as a single highly compact block is normal
because all logical units are tightly interconnected and the synthesis tool groups components based
on functional proximity and timing requirements.

At a high level, the schematic is dominated by the datapath wiring. This arrangement arises from
representing every instruction word and every data bus individually. A processor with a 32-bit
architecture must manage data and instructions at the bit level. What appears as a single ADD
instruction in code is executed by 32 individual wires carrying the result of each bit operation from
the ALU. The register file reads and writes 32 independent bit lines for each of its two read ports and
one write port. When these bit lines are expanded in a schematic tool, they form dense walls of
connections. In a pipelined design, these lines do not stop at a single stage. They are repeatedly
latched and forwarded, splitting into multiple parallel paths across the pipeline registers. Every time
a value crosses a stage boundary, it is re-stored in a bank of flip-flops. This explains why many areas
of the schematic appear as repeating horizontal bundles. Each bundle corresponds to one pipeline
stage snapshot of a 32-bit value.

The schematic also reflects how the tool handles hierarchical HDL modules. During design, the processor
is created in reusable components: the register file, ALU, immediate generator, instruction decode,
hazard detection unit, pipeline registers, and memory interface. Each of these modules is logically
Page 24 of
36
 separate in the Verilog code. However, once elaborated at the RTL level, hierarchical boundaries
collapse into simple nets, logical primitives, and synthesis blocks. The tool flattens the design unless
explicitly instructed not to. This flattening makes the final schematic visually dense but technically
accurate. The result is a dense sheet of nodes and connections that reveal how tightly integrated the
design is. Instead of seeing named blocks like “EX stage” or “MEM stage,” you see the individual
combinational and sequential elements that implement those functions. The long sweeping arcs of
wiring visible in the middle of the schematic represent cross-module interconnects such as ALU
output forwarding, branch target computation, or register write data buses that span several parts of
the machine.

Another important aspect of the schematic is its scale. The tool displays a summary at the top showing
the design contains more than three thousand logic cells and over six thousand nets. This is a realistic
number for a full five-stage processor. Even though the design may appear simple when expressed
in behavioral Verilog, translating high-level behavior into actual logical primitives generates many
more hardware elements. A single register file module can account for hundreds of nets because each
read port, write port, index value, and write enable bit has its own wiring footprint. Pipeline stages
multiply this effect because they must store not only register values but also control flags, immediate
fields, destination identifiers, program counter values, and hazard control signals. The schematic
shows this expansion clearly. The processor is not one block with a few connections; it is a wide
network of signals that must all coordinate on every cycle to maintain instruction correctness.

The bundling of wires is also evidence of clocked synchronization. The dense horizontal bands likely
represent banks of flip-flops forming the IF/ID, ID/EX, EX/MEM, and MEM/WB registers. These
banks must capture every relevant signal at the same moment, which means that the hardware tool
groups their nets together. The clustering is not random. It is shaped by architecture. Pipelining forces
rigid stage transitions, and synthesis tools preserve these barriers because they improve timing
predictability. Every instruction snapshot is isolated from the next, creating a waterfall of sequential
elements. This view confirms that the pipeline is implemented correctly at the RTL level: the
processor is not a single combinational block but a staged synchronous design with clear temporal
boundaries.

When observing the mid-section of the schematic, the sweeping curves of interconnect form a shape that
resembles multiple arcs. These curves are generated by the wire routing algorithm used by the tool.
They show where the design has long-distance dependencies. Forwarding logic, branch calculations,
register write paths, and memory outputs often must bypass several pipeline stages. These long wires
connect later pipeline stages back to earlier ones to avoid stalling or to redirect control flow. The tool
renders these paths as thick, curved bundles. In a real chip layout, these wires would be topological
highways spanning silicon, running over or under other signals. At the RTL schematic level, they
simply appear as arcs that stretch across the page. Their existence is proof that the design implements
true hazard forwarding and branch resolution logic.

An additional layer of interpretation comes from comparing the visual density on the left and right sides
of the image. One side normally represents input-heavy components such as register reads,
instruction decode, or immediate extraction. These modules deal with splitting and interpreting large
chunks of instruction bits. The other side tends to be output-driven: write-back results, memory data
feedback, or ALU result propagation. The region where both meet is often the execution cluster,
where arithmetic, shifting, branch comparison, and memory addressing take place. That central zone
is visually chaotic because many independent lines converge at that location. It is where computation
Page 25 of
36
 happens, and thus where signal mixing is inevitable. The complexity of this region shows a realistic
processor datapath, not a toy design. You are seeing a live proof that your RISC-V pipeline contains
the necessary arithmetic and control hardware to support real workloads.

The schematic is also a validation artifact. If there were logical breaks in the design, such as unconnected
wires, missing assignments, or zero-driver signals, the tool would not generate this view. The
existence of thousands of nets indicates that every module has been successfully integrated. This
means that the Verilog code compiled without structure errors, unresolved references, or broken
pipeline boundaries. In educational or experimental projects, this schematic is one of the strongest
confirmations that the HDL matches the designer’s architecture. It is not meant to be readable
functionally; it is meant to prove that the datapath exists in hardware form. Engineers do not trace
this view manually. Instead, they use it to verify fan-out, inspect critical paths, and ensure stage
separation. In this sense, the schematic represents both the complexity and the correctness of the
processor.

In summary, the displayed schematic is an expected and natural outcome of synthesizing a complete
pipelined RISC-V processor. The enormous concentration of wires reflects the parallel nature of
digital hardware, the width of the datapath, and the architectural discipline imposed by pipeline
staging. The flattened structure shows how modules such as the ALU, hazard detection, register file,
and pipeline registers become merged into a single connected network. The number of nets and logic
cells confirms the design’s architectural depth. The swirling arcs of interconnect prove that
forwarding paths and pipeline logic operate across multiple stages. What appears as a dense mesh is
actually a faithful hardware representation of your HDL design. It demonstrates that abstract
software-level concepts like “instructions” and “pipelines” have been successfully realized as
thousands of synchronized electrical signals, forming a functional RISC-V processor architecture.

The successful completion of this project will yield a fully verified and functional Register-Transfer Level
(RTL) model of the 32-bit, 5-stage pipelined RISC-V processor. The specific deliverables are tangible
assets that collectively represent the project's outcome and are detailed as follows:
1. Complete Verilog HDL Source Code: A collection of clean, well-commented, and modular
Verilog files that constitute the entire processor design. This includes the individual modules for
the datapath components (ALU, Register File, PC), the Control Unit, the Hazard Detection Unit
(Forwarding and Stalling logic), and the pipeline registers, all integrated under a single top-level
processor module. The code will be structured for readability and future extensibility.
2. Comprehensive Verification Suite: A robust testing environment designed to rigorously validate
the processor's functionality. This suite will comprise:
o A set of RISC-V assembly language programs, ranging from simple instruction tests to
more complex sequences designed to specifically trigger data and control hazards.
o A self-checking Verilog testbench that initializes the instruction memory, drives the
processor, and automatically compares the final register and memory states against
expected values to report a pass or fail status.
3. Demonstrative Simulation Results: A set of simulation outputs that provide concrete evidence of
the processor's correct operation. These will include:
o Log files from the simulation runs, showing the execution trace and the final state of the
registers.
o Waveform diagrams (e.g., from GTKWave) that visually illustrate the flow of instructions

Page 26 of
36
 through the pipeline, the values on key internal buses, and the activation of control signals.
These waveforms are crucial for demonstrating the correct handling of hazards, showing
forwarding paths being activated, stalls being inserted, and pipelines being flushed on taken
branches.

4. Final Project Report: This comprehensive document, serving as the definitive record of the project.
It details the project's motivation, theoretical background, design methodology, implementation
specifics, and verification strategy, providing a complete guide to understanding and replicating
the work.

5. The successful completion of this project results in a fully verified and functional Register-
Transfer Level model of a 32-bit, five-stage pipelined RISC-V processor. The outcome of the work
is represented through a collection of technical deliverables that together show the design,
verification, and validation of the architecture. The core result is a complete set of Verilog HDL
modules that form the processor. The hardware description is organized in a clean and modular
structure, allowing ease of debugging and future expansion. Individual files implement key
datapath blocks such as the arithmetic logic unit, register file, program counter, instruction decode
logic, and pipeline registers. A dedicated control subsystem generates control signals for each
stage, while the hazard detection logic manages forwarding paths and stalls to maintain pipeline
correctness. These blocks are combined in a top-level processor module that integrates instruction
flow, data movement, and control sequencing.

6. Verification is another major outcome of the project. A structured simulation framework is created
to test the processor at functional, pipeline, and corner-case levels. The environment includes
RISC-V assembly programs that exercise a broad range of instructions. Some programs verify
simple execution such as arithmetic, memory access, and branching. Others are intentionally
designed to trigger pipeline hazards, forcing the processor to handle data dependencies, read-after-
write conflicts, and branch resolution. A self-checking Verilog testbench automates the process. It
loads test programs into instruction memory, runs the pipeline, observes the final state of registers
and memory, and compares them with pre-computed expected results to produce a pass or fail
judgment. This approach ensures that the verification does not rely on manual inspection and that
errors are reported consistently.

Page 27 of
36
7. The project also produces simulation evidence that demonstrates processor correctness and
pipeline behavior. Simulation log outputs provide a chronological trace of instruction execution,
showing how operations propagate from one stage to the next. These logs confirm that results are
computed as expected and that memory writes are performed at the correct time. In addition,
waveform diagrams generated using tools such as GTKWave visually present internal processor
signals. The diagrams show how instructions enter and exit each pipeline stage, how register values
are forwarded to avoid unnecessary stalls, when pipeline bubbles are inserted, and how the pipeline
flushes instructions after a taken branch. These visual records are especially valuable for
explaining how hazards are resolved and how control logic affects timing.

8. A final written report completes the set of project outputs. It presents the context and motivation
behind selecting a RISC-V pipeline design and introduces the theoretical aspects of the instruction
set and pipeline structure. The document explains how each module is implemented, how
architectural choices were made, and how the hazard resolution methods were selected. It describes
the simulation setup, the verification approach, and the results obtained during testing. The report
serves as a reference that enables others to understand, reproduce, or extend the processor.
Together, the codebase, verification suite, simulation traces, and final documentation form a
complete technical package that reflects the success of the project and supports future
development.

Page 28 of
36
 8.1 Explanation of the Pipelined Datapath Table

The table on the left illustrates how a set of RISC-V instructions move through a five-stage pipeline across
clock cycles. The five stages of the processor are Instruction Fetch (IF), Instruction Decode and register
read (ID), Execute (EX), Memory access (MEM), and Write Back (WB). Each row in the table
represents the progress of different instructions during each cycle.
The first row shows the very first instruction, ADDI X1, X0, 10, entering the pipeline. In the first cycle it
is fetched from instruction memory. In the next cycle it moves into the decode stage while the next
instruction is fetched. The pipeline fills up over time because each stage works in parallel, allowing
multiple instructions to be processed at once. Once the pipeline is full, five different instructions are in
five different stages during the same clock cycle, increasing throughput.
The second instruction, ADDI X2, X0, 20, appears in the ID stage during the second cycle. At this point
instruction one is in EX and begins its arithmetic computation. On the third cycle both previous
instructions shift to the next stages and the third instruction is fetched. This continues until the pipeline
reaches a steady state. Each new instruction follows the same flow: fetch, decode, execute, memory,
then write back.
Page 29 of
36
At cycle I+3, the first instruction reaches the MEM stage. It has already completed the addition and is
transferring its result through the pipeline register. At the same time, the second instruction is executing
its addition while the third is being decoded and the fourth instruction is being fetched. This snapshot
demonstrates why pipelining increases performance; the processor does not wait for each instruction
to complete before starting the next one.
The relevant hazard behavior can also be seen. The third instruction, ADD X3, X2, X5, uses the result of
the second instruction. That value is not yet stored in the register file during the decode stage. The table
shows that this dependency is resolved through forwarding in later cycles. When the result becomes
available at the EX or MEM stage, it is passed forward to the next instruction so the pipeline does not
stall unnecessarily.
The HALT instruction appears at I+5. It enters the IF stage when the pipeline is already busy. Unlike
arithmetic instructions, HALT does not require memory access or writeback. It moves forward while
previous instructions complete their updates. The final few rows show how the pipeline drains once no
new instructions are fetched. Existing instructions keep moving forward until all stages are empty.
The table makes two things clear. First, pipelining overlaps multiple instruction stages to improve
throughput. Second, dependencies between instructions do not automatically stop the pipeline. Instead,
hazard-handling units either forward values or introduce controlled stalls to maintain correctness. The
visual arrangement makes it easier to understand how many instructions are “in flight” at any given
moment.

Page 30 of
36
8.2 Explanation of the Waveform Simulation
The waveform shown on the right provides real hardware simulation evidence that the pipeline is working.
The top signal is the system clock. It oscillates to drive the sequential behavior of the pipeline registers.
Every rising edge causes data in each pipeline stage to move one step forward. By observing the clock
transitions you can understand which instruction is advancing at each cycle.
The data lines below the clock represent internal processor states. In the figure, one of the signals is the
program counter. It shows how the pipeline fetches one instruction per cycle under normal conditions.
Each increment corresponds to a new instruction in the IF stage. When the pipeline becomes full, the
program counter still advances because previous stages are busy with already issued instructions. If the
design included a branch or hazard stall, you would see the counter pause or jump to a new location.
In the middle of the waveform, a value appears and remains visible for several cycles. This could be an
ALU result, register output, or memory data. The width of the signal segment corresponds to how long
it remains valid inside the pipeline. For example, an ALU result generated in the EX stage appears,
travels through the MEM stage, and finally enters WB. That propagation is visible in real time as the
value continues across cycles.
The waveform is useful for confirming that different instructions are active at the same time. While the
first instruction is in the MEM or WB stage, the next instruction is in EX, and another one is in ID.
When examining processor correctness, you check that values change only during the correct cycles,
and that no instruction overwrites data too early. The waveform also shows when forwarding or stall
logic activates. If forwarding occurs, values enter the execution input earlier than they would through
the register file. If a stall occurs, the pipeline holds values for one cycle and the next instruction does
not advance.
Taken together, the table and the waveform provide both conceptual and hardware-level views of the
pipelined design. The table shows stage movement step by step, while the waveform confirms that the
design behaves as expected under simulation. They demonstrate how multiple instructions are executed
simultaneously, how hazard logic protects correctness, and how the pipeline drains cleanly when no
more instructions are fetched.

Page 31 of
36
9.0 Other Relevant Information

The execution of this project did not require a dedicated financial budget, institutional grant, or corporate
sponsorship. All stages, from architectural planning to implementation and verification, were carried
out using free and open-source resources. Choosing open technologies helped maintain cost efficiency
while allowing full ownership and flexibility of the work. The use of the RISC-V instruction set
architecture played an important role in this approach. RISC-V is an open standard, so there are no
licensing fees or proprietary restrictions associated with using or implementing it. This allowed the
processor design to evolve naturally, without any licensing barriers or financial obligations often found
when working with closed hardware ecosystems.
The design and simulation environment relied on free digital design tools. The processor was implemented
in Verilog HDL, and all simulations were performed using Icarus Verilog, a widely used open-source
compiler suitable for academic and experimental development. Its command-line workflow enabled
iterative testing without software cost. For waveform inspection and debugging, GTKWave was used.
This tool helped visualize pipeline behavior, control signals, internal datapath values, and hazard
resolution mechanisms. Both tools worked together to deliver a complete verification setup at no
expense.
The project benefited from community resources as well. Public documentation, open RISC-V
specifications, and online educational material provided technical guidance. Because these resources
are freely accessible, they removed the need for paid textbooks, commercial libraries, or professional
software licenses. This aligns well with the broader philosophy behind RISC-V and open hardware
research, where transparent standards enable independent development.
No paid intellectual property cores or proprietary simulation models were involved. Each module,
including the ALU, register file, forwarding logic, pipeline registers, and control paths, was designed
in-house. This ensured complete clarity of the design process and avoided the need to purchase third-
party cores or toolchains. Likewise, there were no fabrication or prototyping expenses, as the processor
was tested entirely in a simulation workflow rather than being synthesized to an FPGA or ASIC.
Overall, the financial footprint of this project was effectively zero. The choice of open-source ISA and
freely available toolchains made it possible to achieve a full pipelined processor design without
monetary barriers. This demonstrates that advanced hardware projects can be executed in academic or
personal environments without heavy investment. The outcome shows that open ecosystems lower
entry barriers, allowing researchers and students to focus on learning, experimentation, and innovation
rather than cost.

Page 32 of
36
10.1 Design Improvements
The initial version of the pipelined RISC-V processor focused on implementing the basic datapath and
ensuring that each instruction moved through the five stages without functional errors. While this
approach was successful, several improvements were made throughout the project to increase
reliability, efficiency, and usability. These enhancements were driven by issues discovered during
simulation, analysis of instruction dependencies, and observations from waveform debugging. The goal
of each improvement was to build a processor that behaves predictably under real workloads and
handles hazards in a structured way.
One of the most important improvements was the refinement of the control logic. Early versions used a
direct decode scheme that assigned control signals only based on instruction type. This worked for
isolated instructions but failed when different operations overlapped in the pipeline. The improved
control unit introduced structured control signal sequencing and stage-aware decision making. This
ensured that execution, memory, and write-back stages received correct signals even when the
instruction decoder had already moved on to the next instruction. The design became more robust and
easier to debug because each stage operated under well-defined conditions.
The forwarding mechanism was another area where meaningful improvements occurred. Without
forwarding, almost every dependent instruction had to wait for the previous one to finish writing results
back to the register file. This created frequent stalls and poor throughput. The forwarding unit was
redesigned to compare destination register identifiers with source fields in the following instructions
across both EX/MEM and MEM/WB pipeline registers. If a match was detected, the processor routed
the most recent available result directly to the ALU inputs. This eliminated many unnecessary bubbles
and made the pipeline operate at near full capacity. The revised forwarding logic was modular and
reusable so that additional execution units could be accommodated in the future.
Stalling logic also received attention. During early testing, conditions that involved load-use hazards were
not handled properly. A load instruction produces valid data only after the memory stage, which means
the next instruction cannot safely use it during the execution stage. The improved hazard detection unit
examines the opcode and register identifiers to determine if such a dependency exists. If a conflict is
detected, the pipeline automatically inserts a bubble and freezes updates to the program counter and
IF/ID register. This guarantees that no instruction moves forward until the necessary data becomes
available. The number of cycles lost to stalls was minimized because the system only paused when
required to maintain correctness.
Pipeline register organization was another meaningful upgrade. In early iterations, the registers were
implemented as plain latch structures with minimal signal tracking. Debugging internal behavior was
difficult because key signals were not exposed or preserved in simulation. In the improved version,
each interstage register holds all relevant control bits, ALU outputs, register identifiers, immediate
values, and memory addresses. This approach increased clarity and made the datapath more consistent.
Each stage now receives a complete snapshot of the instruction context, which reduces misalignment
and supports clean modifications later.
The project also benefited from improvements in simulation strategy. Rather than testing instructions
manually, a structured test methodology was introduced. Instruction groups were designed to target
specific pipeline scenarios, such as independent arithmetic operations, sequences that force forwarding,

Page 33 of
36
 and back-to-back loads that trigger stalls. This systematic approach enabled early detection of design
flaws. Self-checking testbenches were implemented, reducing dependence on visual inspection. Clear
pass and fail outputs increased confidence in design correctness and eliminated ambiguity in validation
results.
Another improvement focused on code structure. Modules were broken down into smaller blocks that
handle well-defined tasks, such as ALU operations, register file access, pipeline transfers, and hazard
evaluation. Each block could be verified independently and reused across experiments. This modular
approach made the project easier to manage and laid a foundation for future extensions such as branch
prediction, cache integration, or multi-cycle execution units. Better naming conventions and signal
grouping also helped reduce confusion when reading the code or examining waveforms.
The general efficiency of the pipeline improved as the project progressed. Early versions treated every
instruction identically, even those that did not require full stage execution. The updated design
considers the nature of each instruction, allowing unused stages to pass through without affecting the
next instruction. For example, instructions that do not access memory or update registers pass through
the MEM or WB stage without enabling their control lines. This reduces switching activity, prevents
accidental writes, and saves hardware effort in real implementations. Although the system targets
simulation rather than silicon fabrication, these improvements reflect good architectural practice.
Finally, the project benefited from lessons learned during debugging. Observing the waveform revealed
timing mismatches, unnecessary stalls, and misrouted values. Each error led to an incremental
correction and a more refined processor. The design process gradually transitioned from a minimal
pipeline to a disciplined architecture that handles hazards gracefully. These improvements are not
cosmetic; they represent the difference between a basic educational design and a processor that can
scale, adapt, and remain stable under complex execution flows.

During the initial implementation of the Multi-Stage RISC-V Processor, several issues were identified,
especially related to pipeline control and hazard management. The early version of the design showed
incorrect data forwarding and control flow due to missing or incomplete logic in the hazard detection
unit. These issues led to incorrect instruction execution and timing mismatches between pipeline stages.
To address this, the hazard unit was carefully redesigned to handle both data hazards and control
hazards efficiently.
The improved hazard unit introduces proper data forwarding (bypassing) between the EX, MEM, and WB
stages, ensuring that dependent instructions can execute without unnecessary stalls. Additionally, a
pipeline stall mechanism was added for load-use hazards, allowing the next instruction to wait until
valid data is available. For branch hazards, control logic was refined to flush incorrect instructions in
the pipeline whenever a branch is taken, preventing erroneous execution.
These refinements significantly improved the correctness and stability of the pipeline. Simulation results
confirmed accurate instruction sequencing and reduced pipeline stalls, leading to a smoother and more
efficient execution flow. Overall, the improved hazard handling enhanced both the performance and
reliability of the Multi-Stage RISC-V Processor.

Page 34 of
36
CANDIDATES

Name: [Link] Vardan Reg. No: 2210049149

Signature: ……………………… Date: …………

Name: [Link] Venkata Ramana Reg. No:2210049154

Signature: ……………………… Date: …………

Name:[Link] Kiran Reddy Reg. No: 2210049156

Signature: ……………………… Date: …………

Page 35 of
36
SUPERVISOR

1. Comments by Supervisor:

………………………………………………………………………………………………………

……………………………………………..…………………………..……………………………

………………………………………………………………………………………………………

……………............................................

Date: ……............ Name: ……....……….…………..

Signature: .…………………........

Page 36 of
36