🤖 AI

MADAR: An Address-Free Processor

MADAR introduces a novel address-free processor architecture that replaces traditional memory hierarchies and operand fetching with circulating rings of slots and compile-time scheduling, significantly reducing energy and area overheads for predictable workloads like AI acceleration.

Original authors: Mohamed Amine Bergach

Published 2026-06-16

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Mohamed Amine Bergach

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine a modern computer processor as a busy, chaotic airport.

In a standard computer (like the one in your phone or laptop), the "data" (passengers) and the "instructions" (flight plans) are stored in a giant, static terminal. To get anything done, the computer has to:

Find the passenger in the terminal (addressing).
Check their ID against a list (tags).
Decide which gate they go to (arbitration).
Run them through security and to the plane (bypass networks).

The paper argues that 90% of the energy and space in a modern computer is wasted on this "finding and moving" process. The actual math (the flight itself) is cheap and takes up very little space.

MADAR is a new design that throws out the airport terminal entirely. Instead of a static building, MADAR is a giant, moving carousel.

Here is how it works, using simple analogies:

1. The Moving Carousel (Circulating Storage)

Instead of storing data in fixed spots, MADAR puts everything on a giant ring that spins one step every clock tick.

No Addresses: You don't say, "Go to Seat 42." You say, "Go to the seat that is currently 3 steps ahead of me."
No Fetching: The data doesn't wait to be fetched. It just keeps spinning. When the data spins past a worker, the worker grabs it.

2. The Train of Cars (Co-circulation)

In a normal computer, the "instruction" (what to do) and the "data" (what to do it to) are in different places. In MADAR, they are on the same train car.

Imagine a train where every car carries a passenger and a ticket. As the train spins around the track, the passenger and the ticket arrive at the station together. They are indistinguishable from each other; they just ride together.

3. The Fixed Workers (Collision Execution)

Imagine a factory floor with a conveyor belt (the ring) spinning past.

Fixed Stations: There are workers (ALUs, multipliers) standing at specific spots on the floor. They never move.
The Collision: When a train car (containing an instruction and its data) spins past a worker, the worker instantly does the math.
No Waiting: The worker doesn't wait for a signal saying "I'm ready." They just do the math the moment the car passes. If the car isn't there, the worker does nothing. If it is there, the math happens. This is called "collision execution."

4. The Speed Lanes (The Memory Hierarchy)

This is the cleverest part. MADAR has rings of different sizes, like lanes on a racetrack.

The Inner Ring (Fast): A small, fast ring (like a 16-step loop). This is for data you need right now. It spins very quickly.
The Outer Ring (Slow): A huge, slow ring (like a 64,000-step loop). This is for data you need later. It spins slowly.
The Transfer: Instead of a "cache miss" (where the computer panics and goes looking for data), the compiler (the person writing the code) plans exactly when to move a passenger from the slow outer ring to the fast inner ring. It's like a scheduled elevator ride. There are no surprises; everything is planned before the machine even starts.

Why is this a big deal?

The paper claims that by removing the "airport terminal" (the complex addressing system), MADAR saves a massive amount of energy.

The Cost: The only cost is the energy to keep the carousel spinning.
The Payoff: For tasks where the movement is predictable (like AI calculations or video processing), the energy saved by not having to search for data is much bigger than the energy spent spinning the ring.

The "Sweet Spot"

The paper uses a specific example: AI Inference (running a neural network).

In AI, you do the same math over and over again (multiplying numbers and adding them up).
In a normal computer, you constantly fetch these numbers from memory, which is slow and energy-hungry.
In MADAR, you load the numbers onto the ring once. They just spin around. Every time they pass the math worker, the worker does the calculation. The energy cost stays flat, no matter how many numbers you have to process, because you never stop to "look" for them.

What MADAR is NOT

The paper is very clear about the limits:

It's not for everything: If you are doing something unpredictable, like following a random link on a website or playing a video game where the player moves randomly, MADAR struggles. It needs to know the path before it starts.
It's not magic: If the ring is too big for the job, the energy cost of spinning the empty space becomes too high, and it loses to a normal computer.

Summary

MADAR is a processor that replaces the "search and fetch" model with a "spin and collide" model. It treats the computer like a spinning carousel where the instructions and data ride together, and the math happens automatically as they pass fixed workers. It trades the complexity of finding things for the simplicity of rotation, making it incredibly efficient for predictable, repetitive tasks like AI.

Technical Summary: MADAR – An Address-Free Processor

Problem Statement

Modern processors dedicate the vast majority of their area and energy to addressing rather than arithmetic. The machinery required to move operands to and from register files and caches—including tag arrays, miss queues, bypass networks, and multi-port register files—accounts for over 90% of a core's energy overhead in certain workloads, while functional units consume less than 6%. This overhead stems from the fundamental tension of the von Neumann architecture: the datapath streams operands, but the memory system must stop values at fixed locations to assign them addresses for on-demand retrieval.

Methodology and Architecture

The paper proposes MADAR (Arabic for "orbit"), a processor architecture that abolishes the concept of an address entirely. Instead of static storage, MADAR relies on rotation. The architecture is defined by four conjunctive properties:

Circulating Storage: All state resides in rings of slots ( $R_0 \dots R_n$ ) that advance one position per clock cycle. A value is identified not by an address, but by a $(ring, phase)$ coordinate. The physical implementation uses literal shift registers for small, fast rings and single-port SRAM banks swept by a rotating pointer for large, slow rings.
Co-circulation: Instructions and data occupy the same slots and circulate together. They are distinguished only by a "kind" field in the packet header.
Collision Execution: Compute stations (ALU, multiplier, etc.) are fixed at specific positions on the rings. An instruction executes when it sweeps past its station. Operands are named by their rotational offset (a position within a fixed window, e.g., $W=8$ slots ahead) rather than by address. Execution is static and scheduled at compile time; there is no dynamic matching, scoreboard, or wakeup logic.
Period Hierarchy as Memory Hierarchy: Rings of geometrically increasing period (e.g., 16, 256, 4K, 64K slots) replace the traditional cache hierarchy. Transfers between rings are scheduled at compile time rather than triggered by cache misses. Promotion to a shorter ring acts as a cache fill; demotion to a longer ring acts as eviction.

Control Flow and Data Movement:

Steering: Control flow is managed by "steer" stations that evaluate predicates. If a condition is met, the station removes (kills) specific instruction packets from the ring, turning their slots into bubbles.
Transfer: Inter-ring data movement is handled by transfer stations at scheduled phases.
Relays: If a producer and consumer are separated by more than the operand window ( $W$ ), the compiler inserts explicit "copy relay" instructions to bridge the gap, consuming ring capacity.
Rendezvous: For data-dependent accesses where the target phase is unknown at compile time, a rendezvous station captures a value when a free-running phase counter matches a requested value, incurring a latency penalty of approximately half a rotation.

Key Contributions

The paper makes six specific contributions:

Execution Model Definition: A precise definition of the MADAR model, including the addressing invariant that ensures correctness.
Contextualization: A detailed comparison with prior circulating-store, temporal-addressing, and dataflow architectures (e.g., Pilot ACE, Mill, Groq), demonstrating that MADAR is the first to combine all four defining properties.
Validation: A cycle-accurate register-transfer-level (RTL) implementation in SystemVerilog (simulated with Verilator) that validates the execution semantics.
Constructive Scheduler: A compiler that automatically generates seating arrangements and transfer schedules for kernels (straight-line code and counted loops) without manual intervention. Every emitted program is cross-checked against the RTL model.
Energy Cost Model: A first-order energy model that quantifies the trade-off between the cost of rotation and the savings from deleted addressing machinery.
Case Study: An analysis of streaming AI inference, demonstrating how the architecture handles dense linear algebra.

Results

Correctness: The RTL implementation confirmed that rotation acts as storage, collision acts as execution, and steering replaces branching. Hand-seated and compiler-generated programs produced correct results (e.g., a counted sum loop accumulating $0+1+\dots+(R-1)$ ).
Energy Crossover: The energy model identifies a "crossover point" where MADAR becomes more efficient than a simple in-order baseline (assumed at 70 pJ/instruction).
- Winning Regime: Kernels that fit within small rings (e.g., a 16-slot ring) with few or no relays, such as multiply-accumulate loops and FIR taps, show crossover points between 26–63 pJ/instruction, significantly outperforming the baseline.
- Losing Regime: Kernels requiring large rings or many relays (e.g., deep accumulation chains or degree-5 polynomials) suffer from the energy cost of shifting many live packets. These show crossover points between 126–205 pJ/instruction, making them less efficient than the baseline.
AI Inference Case Study:
- Flat Reductions: A flat dot product tree is inefficient because the ring size must grow with the reduction length, causing excessive rotation energy.
- Streaming Inner Product: By streaming operands from long rings to a fixed-size compute ring via scheduled transfers, the energy per multiply-accumulate remains constant regardless of the reduction length.
- Operand Reuse: The most efficient dataflow for matrix multiplication routes operand reuse through the period hierarchy: promoting shared operands from large SRAM-backed rings to small shift-register rings. This approach achieved 86 pJ/multiply-accumulate for an 8x8 matrix-vector product, outperforming both fused-tile and single-stream approaches.

Significance and Claims

The paper claims MADAR represents a new design point for computations where data movement is known statically before execution. Its significance lies in:

Eliminating Addressing Overhead: By removing the need for tags, random access decoders, and miss-status registers, the architecture targets the primary source of energy waste in modern cores.
Deterministic Timing: Because the schedule is fixed at compile time, there are no reactive stalls or cache misses, making the architecture suitable for hard real-time and constant-time cryptography.
Efficiency in Streaming Workloads: The paper argues that for AI inference and streaming DSP, the "memory hierarchy" is effectively replaced by a "period hierarchy," where the rotation of data performs the work of caching.

Limitations and Scope:
The authors are modest about the scope. MADAR is not a universal replacement for random-access machines. It is ill-suited for pointer-chasing, irregular graph traversal, or workloads with unpredictable data dependencies, which incur a significant latency penalty. Furthermore, the current scheduler handles straight-line chains and loops but not arbitrary reduction trees or complex reordering. The energy claims are based on a first-order model; the authors acknowledge that a full synthesis-based comparison is required to definitively prove the energy advantage over state-of-the-art static schedulers like Groq.

In conclusion, MADAR demonstrates that for a specific class of statically schedulable, streaming workloads, the cost of rotating data can be lower than the cost of addressing static data, offering a fundamentally different trade-off between motion and stillness in processor design.