🤖 AI

MADAR: An Address-Free Processor

MADAR führt eine neuartige adressfreie Prozessorarchitektur ein, die traditionelle Speicherhierarchien und das Operand-Abrufen durch kreisende Ringe von Slots und Kompilierzeit-Scheduling ersetzt, wodurch der Energie- und Flächenoverhead für vorhersehbare Arbeitslasten wie KI-Beschleunigung erheblich reduziert wird.

Ursprüngliche Autoren: Mohamed Amine Bergach

Veröffentlicht 2026-06-16

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Mohamed Amine Bergach

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich einen modernen Computerprozessor als einen geschäftigen, chaotischen Flughafen vor.

In einem Standardcomputer (wie dem in Ihrem Telefon oder Laptop) werden die „Daten“ (Passagiere) und die „Instruktionen“ (Flugpläne) in einem riesigen, statischen Terminal gespeichert. Um etwas zu erledigen, muss der Computer:

Den Passagier im Terminal finden (Adressierung).
Den Ausweis gegen eine Liste prüfen (Tags).
Entscheiden, zu welchem Gate er gehen soll (Arbitrierung).
Ihn durch die Sicherheitskontrolle und zum Flugzeug leiten (Bypass-Netzwerke).

Das Paper argumentiert, dass 90 % der Energie und des Platzes in einem modernen Computer für diesen „Such- und Transportprozess“ verschwendet werden. Die eigentliche Mathematik (der Flug selbst) ist günstig und nimmt nur sehr wenig Platz ein.

MADAR ist ein neues Design, das das gesamte Flughafenterminal über Bord wirft. Anstatt eines statischen Gebäudes ist MADAR ein riesiges, sich bewegendes Karussell.

So funktioniert es, unter Verwendung einfacher Analogien:

1. Das bewegliche Karussell (Zirkulierender Speicher)

Anstatt Daten an festen Stellen zu speichern, legt MADAR alles auf einen riesigen Ring, der bei jedem Takt eines Prozessors einen Schritt weiterdreht.

Keine Adressen: Sie sagen nicht: „Gehe zu Sitzplatz 42.“ Sie sagen: „Gehe zu dem Sitz, der sich gerade 3 Positionen vor mir befindet.“
Kein Abrufen (Fetching): Die Daten warten nicht darauf, abgerufen zu werden. Sie drehen sich einfach weiter. Wenn die Daten an einem Arbeiter vorbeiziehen, greift dieser sie sich.

2. Der Zug aus Waggons (Ko-Zirkulation)

In einem normalen Computer befinden sich die „Instruktion“ (was zu tun ist) und die „Daten“ (womit es zu tun ist) an unterschiedlichen Orten. In MADAR befinden sie sich auf demselben Zugwaggon.

Stellen Sie sich einen Zug vor, bei dem jeder Waggon einen Passagier und ein Ticket transportiert. Während der Zug um die Strecke kreist, kommen der Passagier und das Ticket gleichzeitig am Bahnhof an. Sie sind von einander nicht zu unterscheiden; sie fahren einfach gemeinsam.

3. Die feststehenden Arbeiter (Kollisionsausführung)

Stellen Sie sich eine Fabrikhalle mit einem Förderband (dem Ring) vor, das vorbeidreht.

Feste Stationen: Es gibt Arbeiter (ALUs, Multiplizierer), die an spezifischen Punkten stehen. Sie bewegen sich nie.
Die Kollision: Wenn ein Zugwaggon (der eine Instruktion und ihre Daten enthält) an einem Arbeiter vorbeizieht, erledigt der Arbeiter sofort die Mathematik.
Kein Warten: Der Arbeiter wartet nicht auf ein Signal, dass er „bereit“ ist. Er führt die Rechnung in dem Moment durch, in dem der Waggon vorbeizieht. Wenn der Waggon nicht da ist, tut der Arbeiter nichts. Wenn er da ist, findet die Berechnung statt. Dies wird als „Kollisionsausführung“ bezeichnet.

4. Die Geschwindigkeitsspuren (Die Speicherhierarchie)

Dies ist der cleverste Teil. MADAR besitzt Ringe unterschiedlicher Größe, vergleichbar mit Fahrspuren auf einer Rennstrecke.

Der innere Ring (Schnell): Ein kleiner, schneller Ring (wie eine 16-Schritte-Schleife). Dieser ist für Daten gedacht, die Sie jetzt sofort benötigen. Er dreht sich sehr schnell.
Der äußere Ring (Langsam): Ein riesiger, langsamer Ring (wie eine 64.000-Schritte-Schleife). Dieser ist für Daten gedacht, die Sie später benötigen. Er dreht sich langsam.
Der Transfer: Anstatt eines „Cache Miss“ (bei dem der Computer in Panik gerät und nach Daten sucht), plant der Compiler (die Person, die den Code schreibt) exakt, wann ein Passagier vom langsamen äußeren Ring in den schnellen inneren Ring versetzt wird. Es ist wie eine geplante Aufzugfahrt. Es gibt keine Überraschungen; alles ist geplant, bevor die Maschine überhaupt startet.

Warum ist das eine große Sache?

Das Paper behauptet, dass MADAR durch das Entfernen des „Flughafenterminals“ (des komplexen Adressierungssystems) eine enorme Menge an Energie spart.

Die Kosten: Die einzige Kostenstelle ist die Energie, um das Karussell in Bewegung zu halten.
Der Gewinn: Für Aufgaben, bei denen die Bewegung vorhersehbar ist (wie KI-Berechnungen oder Videoverarbeitung), ist die Energie, die durch das Nicht-Suchen nach Daten gespart wird, viel größer als die Energie, die für das Drehen des Rings aufgewendet wird.

Der „Sweet Spot“

Das Paper nutzt dazu ein spezifisches Beispiel: KI-Inferenz (das Ausführen eines neuronalen Netzes).

Bei KI führen Sie immer wieder dieselbe Mathematik aus (Multiplikation von Zahlen und Addition derselben).
In einem normalen Computer rufen Sie diese Zahlen ständig aus dem Speicher ab, was langsam und energiehungrig ist.
In MADAR laden Sie die Zahlen einmal auf den Ring. Sie drehen sich einfach weiter. Jedes Mal, wenn sie einen Mathematik-Arbeiter passieren, führt der Arbeiter die Berechnung durch. Die Energiekosten bleiben flach, egal wie viele Zahlen Sie verarbeiten müssen, weil Sie niemals anhalten müssen, um nach ihnen zu „suchen“.

Was MADAR NICHT ist

Das Paper ist sich seiner Grenzen sehr bewusst:

Es ist nicht für alles: Wenn Sie etwas Unvorhersehbares tun, wie das Folgen eines zufälligen Links auf einer Website oder das Spielen eines Videospiels, bei dem sich der Spieler zufällig bewegt, hat MADAR Schwierigkeiten. Es muss den Pfad vorher kennen.
Es ist keine Magie: Wenn der Ring zu groß für die Aufgabe ist, wird der Energieaufwand für das Drehen des leeren Raums zu hoch, und es verliert gegen einen normalen Computer.

Zusammenfassung

MADAR ist ein Prozessor, der das „Suchen und Abrufen“-Modell durch ein „Drehen und Kollidieren“-Modell ersetzt. Er behandelt den Computer wie ein rotierendes Karussell, auf dem Instruktionen und Daten gemeinsam reisen und die Mathematik automatisch stattfindet, sobald sie feste Arbeiter passieren. Er tauscht die Komplexität des Findens gegen die Einfachheit der Rotation ein, was ihn unglaublich effizient für vorhersehbare, repetitive Aufgaben wie KI macht.

Technisches Resümee: MADAR – Ein adressfreier Prozessor

Problemstellung

Moderne Prozessoren widmen den Großteil ihrer Fläche und Energie der Adressierung statt der Arithmetik. Die Mechanik, die erforderlich ist, um Operanden aus Registern und Caches zu bewegen – einschließlich Tag-Arrays, Miss-Queues, Bypass-Netzwerken und Multi-Port-Registern – macht bei bestimmten Arbeitslasten über 90 % des Energieaufwands eines Kerns aus, während die Funktionseinheiten weniger als 6 % verbrauchen. Dieser Overhead resultiert aus dem grundlegenden Spannungsverhältnis der Von-Neumann-Architektur: Der Datenpfad streamt Operanden, aber das Speichersystem muss Werte an festen Orten stoppen, um ihnen Adressen für den bedarfsgerechten Abruf zuzuweisen.

Methodik und Architektur

Das Paper schlägt MADAR (Arabisch für „Orbit“) vor, eine Prozessorarchitektur, die das Konzept einer Adresse vollständig abschafft. Anstatt auf statischer Speicherung basiert MADAR auf Rotation. Die Architektur wird durch vier konjunktive Eigenschaften definiert:

Zirkulierender Speicher: Der gesamte Zustand befindet sich in Ringstrukturen von Slots ( $R_0 \dots R_n$ ), die pro Taktzyklus um eine Position vorrücken. Ein Wert wird nicht durch eine Adresse, sondern durch eine $(Ring, Phase)$-Koordinate identifiziert. Die physische Implementierung nutzt echte Schieberegister für kleine, schnelle Ringe und Single-Port-SRAM-Banks, die von einem rotierenden Pointer abgetastet werden, für große, langsame Ringe.
Ko-Zirkulation: Instruktionen und Daten belegen dieselben Slots und zirkulieren gemeinsam. Sie unterscheiden sich lediglich durch ein „Kind“-Feld im Paketheader.
Kollisions-Ausführung: Recheneinheiten (ALU, Multiplizierer etc.) sind an spezifischen Positionen auf den Ringen fixiert. Eine Instruktion wird ausgeführt, wenn sie eine Station passiert. Operanden werden durch ihren Rotations-Offset benannt (eine Position innerhalb eines festen Fensters, z. B. $W=8$ Slots voraus) statt durch eine Adresse. Die Ausführung ist statisch und zur Kompilierzeit geplant; es gibt keine dynamische Übereinstimmung, kein Scoreboarding oder Wakeup-Logik.
Perioden-Hierarchie als Speicherhierarchie: Ringe mit geometrisch zunehmender Periode (z. B. 16, 256, 4K, 64K Slots) ersetzen die traditionelle Cache-Hierarchie. Transfers zwischen den Ringen werden zur Kompilierzeit geplant und nicht durch Cache-Misses ausgelöst. Eine Promotion zu einem kürzeren Ring fungiert als Cache-Fill; eine Demotion zu einem längeren Ring als Eviction.

Kontrollfluss und Datentransfer:

Steuerung (Steering): Der Kontrollfluss wird durch „Steer“-Stationen verwaltet, die Prädikate auswerten. Wenn eine Bedingung erfüllt ist, entfernt die Station spezifische Instruktionspakete aus dem Ring und verwandelt deren Slots in Blasen (Bubbles).
Transfer: Der Datentransfer zwischen den Ringen wird durch Transfer-Stationen zu geplanten Phasen gehandhabt.
Relais: Wenn ein Produzent und ein Konsument weiter als das Operand-Fenster ( $W$ ) voneinander entfernt sind, fügt der Compiler explizite „Copy Relay“-Instruktionen ein, um die Lücke zu überbrücken, was die Ringkapazität beansprucht.
Rendezvous: Für datenabhängige Zugriffe, bei denen die Zielphase zur Kompilierzeit unbekannt ist, erfasst eine Rendezvous-Station einen Wert, wenn ein frei laufender Phasen-Zähler einen angeforderten Wert erreicht; dies verursacht eine Lanzenz-Strafe von etwa der Hälfte einer Rotation.

Zentrale Beiträge

Das Paper leistet sechs spezifische Beiträge:

Definition des Ausführungsmodells: Eine präzise Definition des MADAR-Modells, einschließlich der Invariante der Adressierung, die die Korrektheit gewährleistet.
Kontextualisierung: Ein detaillierter Vergleich mit vorangegangenen Circulating-Store-, Temporal-Addressing- und Dataflow-Architekturen (z. B. Pilot ACE, Mill, Groq), der zeigt, dass MADAR die erste ist, die alle vier definierenden Eigenschaften kombiniert.
Validierung: Eine zyklusgenaue Register-Transfer-Level (RTL)-Implementierung in SystemVerilog (simuliert mit Verilator), die die Ausführungssemantik validiert.
Konstruktiver Scheduler: Ein Compiler, der automatisch Sitzungsanordnungen (Seating Arrangements) und Transferpläne für Kernel (Straight-Line-Code und gezählte Schleifen) ohne manuelles Eingreifen generiert. Jedes emittierte Programm wird gegen das RTL-Modell geprüft.
Energie-Kostenmodell: Ein First-Order-Energiemodell, das den Trade-off zwischen den Kosten der Rotation und den Einsparungen durch die entfernte Adressierungsmechanik quantifiziert.
Fallstudie: Eine Analyse von Streaming-KI-Inferenz, die demonstriert, wie die Architektur dichte lineare Algebra handhabt.

Ergebnisse

Korrektheit: Die RTL-Implementierung bestätigte, dass Rotation als Speicherung, Kollision als Ausführung und Steering als Branching fungiert. Manuell gesetzte und vom Compiler generierte Programme lieferten korrekte Ergebnisse (z. B. eine gezählte Summen-Schleife, die $0+1+\dots+(R-1)$ akkumuliert).
Energie-Crossover: Das Energiemodell identifiziert einen „Crossover-Punkt“, an dem MADAR effizienter ist als eine einfache In-Order-Baseline (angenommen bei 70 pJ/Instruktion).
- Gewinn-Regime: Kernel, die in kleine Ringe passen (z. B. 16-Slot-Ring) und wenige oder keine Relays benötigen (wie Multiply-Accumulate-Schleifen und FIR-Taps), zeigen Crossover-Punkte zwischen 26–63 pJ/Instruktion und übertreffen die Baseline signifikant.
- Verlust-Regime: Kernel, die große Ringe oder viele Relays erfordern (z. B. tiefe Akkumulationsketten oder Polynome 5. Grades), leiden unter den Energiekosten des Verschiebens vieler lebender Pakete. Diese zeigen Crossover-Punkte zwischen 126–205 pJ/Instruktion, was sie weniger effizient als die Baseline macht.
KI-Inferenz Fallstudie:
- Flache Reduktionen: Ein flacher Dot-Product-Baum ist ineffizient, da die Ringgröße mit der Reduktionslänge wachsen muss, was zu übermäßiger Rotationsenergie führt.
- Streaming Inner Product: Durch das Streaming von Operanden aus langen Ringen zu einem festen Compute-Ring via geplanter Transfers bleibt die Energie pro Multiply-Accumulate konstant, unabhängig von der Reduktionslänge.
- Operand-Reuse: Der effizienteste Dataflow für Matrizenmultiplikation leitet die Operand-Wiederverwendung durch die Perioden-Hierarchie: Promotion geteilter Operanden von großen, SRAM-gestützten Ringen zu kleinen Schieberegister-Ringen. Dieser Ansatz erreichte 86 pJ/Multiply-Accumulate für ein 8x8 Matrix-Vektor-Produkt und übertraf damit sowohl Fused-Tile- als auch Single-Stream-Ansätze.

Bedeutung und Ansprüche

Das Paper behauptet, dass MADAR einen neuen Designpunkt für Berechnungen darstellt, bei denen der Datentransport vor der Ausführung statisch bekannt ist. Die Bedeutung liegt in:

Eliminierung des Adressierungs-Overheads: Durch die Entfernung von Tags, Zufallszugriffs-Decodern und Miss-Status-Registern zielt die Architektur auf die primäre Quelle der Energieverschwendung moderner Kerne ab.
Deterministisches Timing: Da der Zeitplan zur Kompilierzeit feststeht, gibt es keine reaktiven Stalls oder Cache-Misses, was die Architektur für Hard-Real-Time und Constant-Time-Kryptographie geeignet macht.
Effizienz in Streaming-Workloads: Das Paper argumentiert, dass für KI-Inferenz und Streaming-DSP die „Speicherhierarchie“ effektiv durch eine „Perioden-Hierarchie“ ersetzt wird, in der die Rotation der Daten die Arbeit des Caching übernimmt.

Einschränkungen und Umfang:
Die Autoren sind bescheiden hinsichtlich des Umfangs. MADAR ist kein universeller Ersatz für Random-Access-Maschinen. Es ist ungeeignet für Pointer-Chasing, irreguläre Graph-Traversierung oder Arbeitslasten mit unvorhersehbaren Datenabhängigkeiten, die einen erheblichen Latenz-Penalty verursweisen. Zudem behandelt der aktuelle Scheduler nur Straight-Line-Ketten und Schleifen, aber keine beliebigen Reduktionsbäume oder komplexen Reorderings. Die Energie-Claims basieren auf einem First-Order-Modell; die Autoren räumen ein, dass ein Synthese-basierter Vergleich erforderlich ist, um den energetischen Vorteil gegenüber State-of-the-Art-statischen Schedulern wie Groq definitiv zu beweisen.

Zusammenfassend zeigt MADAR, dass für eine spezifische Klasse von statisch planbaren Streaming-Workloads die Kosten der Rotation von Daten niedriger sein können als die Kosten der Adressierung statischer Daten, was einen fundamental anderen Trade-off zwischen Bewegung und Stillstand im Prozessordesign bietet.