Controlling a Cache with a Finite-State Machine

A cache does not just store data passively; hardware control logic must sequence through several distinct steps to handle a miss correctly. This article explains how a finite-state machine models this control logic, walks through the states involved in handling a cache hit and a cache miss, and shows why this formal model makes cache controller design easier to reason about.

Finite-State MachineCache ControllerCache Control Logic

~3 min read · Updated Sep 6, 2026

Why a Cache Needs More Than Just Storage Circuits

The cache concepts discussed earlier in this series, tags, indices, and hit or miss detection, describe what data the cache holds and how it is located. But handling an actual request, especially a miss that requires fetching data from a slower level of the memory hierarchy, requires a sequence of coordinated steps over multiple clock cycles, not just a single combinational lookup. This sequencing is handled by a Cache Controller.

What a Finite-State Machine Is

A Finite-State Machine (FSM) is a model of sequential logic, introduced conceptually earlier in this series when discussing combinational and sequential circuits, that exists in exactly one of a limited number of defined States at any given time, transitioning between states based on inputs and the current state, and producing outputs based on which state it is currently in.

Modeling Cache Control as an FSM

A simplified cache controller can be modeled with a small number of states representing the stages of handling a memory request.

State: Idle
  → waiting for a memory request from the processor

State: Compare Tag
  → checking whether the requested address is a hit or miss

State: Allocate (on a miss)
  → sending a request to the next memory level to fetch the block

State: Write Cache Block (on a miss)
  → writing the newly fetched block into the cache once it arrives

State: Return to Idle
  → request satisfied, ready for the next request

Tracing a Cache Hit Through the FSM

On a hit, the controller moves from Idle to Compare Tag, confirms the tag matches, immediately returns the requested data to the processor, and transitions back to Idle — a short sequence completed in very few cycles.

Tracing a Cache Miss Through the FSM

On a miss, the controller moves from Idle to Compare Tag, detects the mismatch, then transitions into the Allocate state, waiting however many cycles are required for the slower memory level to supply the missing block. Once the data arrives, the controller moves to Write Cache Block to store it, updates the relevant tag, and only then returns to Idle, finally supplying the requested data to the processor.

Why Modeling Control This Way Is Useful

Describing cache control as an explicit finite-state machine makes the design far easier to verify correctness for. Every possible situation the controller might encounter corresponds to a specific, well-defined state and set of transitions, which prevents the kind of ambiguous or incompletely specified behavior that can arise from writing control logic in a less formal, ad hoc manner.

Why This Concept Extends Beyond Simple Caches

This same finite-state machine approach to control extends naturally to far more complex controllers throughout a processor, including the pipeline control logic discussed earlier in this series and the more advanced cache controllers found in real multi-level, multi-core cache hierarchies, where correctly sequencing many possible situations is essential to avoiding subtle hardware bugs.

Written & researched by Dr. Shahin Siami

Related Articles

A Unified Framework for Understanding Every Memory Hierarchy Level

Caches and virtual memory appear at first glance to be very different systems, yet both are answering the exact same four fundamental questions. This article shows how those four questions unify block placement, block identification, block replacement, and write handling across every level of the memory hierarchy, from tiny caches to disk-backed virtual memory.

Continue

Virtual Memory: Giving Every Program Its Own Private Address Space

Programs behave as if they have access to a huge, private block of memory, even though physical RAM is limited and shared among many running processes. This article explains how virtual memory creates this illusion through address translation, how page tables and the TLB make translation fast, and what happens when needed data is not currently in physical memory.

Continue

Virtual Machines: Running Multiple Isolated Systems on One Computer

A single physical computer can appear to run several completely separate operating systems at once, each unaware of the others' existence. This article explains what a virtual machine actually is, how a hypervisor manages this illusion, and why this technology matters for both server consolidation and system security.

Continue

Dependable Memory: How Hardware Detects and Corrects Data Errors

Memory hardware is not perfectly reliable; electrical noise and physical defects can silently flip stored bits. This article explains how error detection and correction codes let hardware notice, and in many cases automatically fix, these corrupted values before they cause incorrect program behavior.

Continue

Measuring and Improving Cache Performance

Not all cache misses are the same, and understanding their causes is the first step toward improving performance. This article covers how to calculate the real performance impact of caching using miss rate and miss penalty, classifies the three common causes of cache misses, and explains practical strategies for reducing each type.

Continue

Cache Fundamentals: How Small, Fast Memory Predicts What You Need Next

A cache works because programs tend to access the same or nearby data repeatedly rather than randomly. This article explains the principle of locality that makes caching effective, how a direct-mapped cache locates data using an address, and what happens on a cache hit versus a cache miss.

Continue