Two-Level Cache System in Verilog

A Verilog implementation of a two-level cache hierarchy with a direct-mapped L1 cache, a 2-way set-associative L2 cache, a centralized FSM controller, latency modeling, and a simulation testbench.

This project was developed for a Computer Architecture course to model cache lookup behavior, associativity, replacement metadata, promotion/demotion between cache levels, write policies, and access latency.

Overview

The design models a two-level cache hierarchy:

• L1 Cache: direct-mapped cache with 8 lines
• L2 Cache: 2-way set-associative cache with 16 sets
• Controller: centralized FSM that manages requests, latency counters, hit/miss handling, promotion, demotion, invalidation, and completion signaling
• Memory: modeled only through latency; no actual memory data array is required

Only cache metadata is modeled: tags, valid bits, and LRU bits. The project does not model real cache data payloads.

Cache Organization

Component	Organization	Index Bits	Tag Bits	Notes
L1 Cache	Direct-mapped, 8 lines	address[6:4]	address[31:7]	Fastest cache level
L2 Cache	2-way set-associative, 16 sets	address[7:4]	address[31:8]	Uses one LRU bit per set
Memory	Latency-only model	N/A	N/A	No data payload modeled

Features

• Direct-mapped L1 cache
• 2-way set-associative L2 cache
• Valid-bit and tag-based hit detection
• LRU replacement metadata for L2
• Centralized FSM controller
• Read hit, read miss, promotion, and demotion behavior
• Write-through and no-write-allocate policy
• Write-hit invalidation
• Latency modeling for L1, L2, and memory
• Simulation testbench with multiple cache scenarios
• Waveform dump support through VCD output

Main Modules

Module	Description
L1.v	Implements the direct-mapped L1 cache with tag storage, valid bits, hit detection, installation, and invalidation.
L2.v	Implements the 2-way set-associative L2 cache with two tag arrays, valid bits, LRU metadata, hit detection, installation, and invalidation.
top_module.v	Contains the centralized FSM controller and connects L1, L2, request handling, latency counters, promotion/demotion, and done signaling.
testbench.v	Runs simulation scenarios for read/write hits and misses and generates a VCD waveform file.

Access Policies

Read Policy

• L1 hit: complete after L1 latency.
• L2 hit: promote the requested block to L1 and demote the L1 victim to L2 if the victim is valid.
• Miss in both caches: wait for memory latency, install the requested block into L1, and demote the L1 victim to L2 if valid.

Write Policy

• Write hit in L1 or L2: invalidate the hit cache line.
• Write miss: no-write-allocate; the request completes without installing a new cache line.

Latency Model

Access Level	Latency
L1	1 cycle
L2	5 cycles
Memory	20 cycles

The controller checks L1 first. If L1 misses, it checks L2. If L2 also misses, memory latency is modeled before installing the block into L1.

FSM Controller

The controller in top_module.v uses the following states:

State	Purpose
S_IDLE	Waits for a new request.
S_L1_WAIT	Models L1 latency and checks the L1 hit result.
S_L2_WAIT	Models L2 latency and checks the L2 hit result.
S_MEM_WAIT	Models memory latency on a read miss.
S_PROMOTE	Promotes an L2 hit into L1 and demotes the L1 victim to L2 if valid.
S_INSTALL	Installs a memory-fetched block into L1 and demotes the L1 victim if valid.
S_WRITE_INV	Invalidates the cache line on a write hit.
S_DONE	Raises the done signal and reports hit information.

Documentation

For a more detailed explanation of the cache hierarchy, FSM behavior, tag/index layout, promotion/demotion logic, LRU handling, and testbench scenarios, see:

Architecture Documentation

Simulation

Running in Vivado

1. Open Xilinx Vivado.
2. Create a new RTL project.
3. Add all Verilog files from the src/ directory.
4. Add sim/testbench.v as the simulation source.
5. Set testbench as the simulation top module.
6. Run behavioral simulation.
7. Inspect the console output and waveform signals.

Simulation Screenshots

Console Output

Waveform Overview

Testbench Scenarios

The testbench covers the required cache behaviors:

1. Read miss
2. Read hit in L1
3. Read miss with L1 victim demotion to L2
4. Read hit in L2 with promotion back to L1
5. Additional L1 hit after promotion
6. L2 way installation behavior
7. L2 hit behavior
8. Write hit in L1 with invalidation
9. Write hit in L2 with invalidation
10. Write miss with no-write-allocate behavior

Useful Signals to Inspect

When viewing the waveform, useful signals include:

• clk
• rst
• req
• memWrite
• address
• l1_hit
• l2_hit
• done
• l1_valid
• l2_valid
• state
• cycle_counter
• l1_install
• l2_install
• l1_invalidate
• l2_invalidate

Project Limitations

This project is an educational cache simulation and does not implement a complete memory system.

Current limitations include:

• Cache data payloads are not modeled.
• Main memory contents are not modeled.
• Only one outstanding request is supported at a time.
• The design is intended for simulation rather than FPGA deployment.
• Replacement behavior is simplified for educational clarity.
• No processor core is connected to the cache hierarchy.

Future Improvements

• Add actual cache data storage.
• Add a memory module with data payloads.
• Add separate module-level testbenches for L1, L2, and the controller.
• Add a diagram of the cache hierarchy and FSM.
• Add support for configurable cache sizes and latencies.

License

This project is intended for educational and portfolio purposes.