Ein On-Chip-Netzwerk löst ein sehr konkretes Problem: Sobald mehrere IP-Kerne, Speicherblöcke und Beschleuniger auf einem SoC gleichzeitig kommunizieren, wird eine einfache Sammelschiene schnell zum Flaschenhals. Ich ordne deshalb die Architektur technisch ein und zeige, warum sich Leistung, Latenz, Energiebedarf und Skalierbarkeit gegenseitig beeinflussen. Außerdem geht es um die Topologien, die in moderner Elektronik tatsächlich funktionieren, und um die Fehler, die ein gutes Design unnötig teuer machen.
Die wichtigsten Punkte in Kürze
- NoC steht für eine skalierbare Kommunikationsarchitektur zwischen IP-Kernen auf einem Chip.
- Der Ansatz lohnt sich vor allem dann, wenn viele Blöcke gleichzeitig Daten austauschen und ein Bus zu stark belastet wäre.
- Die 2D-Mesh-Topologie ist oft der pragmatische Startpunkt, aber nicht automatisch die beste Endlösung.
- Latenz, Bandbreite, Jitter, QoS und Thermik zählen in der Praxis mehr als das Schlagwort selbst.
- Für kleine SoCs kann eine Bus- oder Crossbar-Lösung weiterhin sinnvoller sein.
Warum klassische Busse an ihre Grenzen kommen
Der entscheidende Punkt ist nicht, dass ein Bus „langsam“ wäre. Er ist nur für kleine, überschaubare Systeme gebaut: wenige Teilnehmer, wenige Zugriffe, wenig Konflikt. Wenn aber mehrere Master gleichzeitig Daten ziehen, steigt der Arbitration-Aufwand, und die Wartezeiten wachsen oft schneller, als man es im Architekturdiagramm vermutet.
Genau deshalb setzt man in komplexeren SoCs auf ein verteiltes Kommunikationsnetz. Statt alles über eine einzige Leitung zu quetschen, werden Transfers in kleine Einheiten zerlegt und über Router verteilt. Das macht die Architektur komplexer, aber eben auch skalierbarer. Im nächsten Schritt lohnt sich daher ein Blick auf die Bausteine, aus denen so ein Netz besteht.
So ist ein NoC intern aufgebaut
Die TU München beschreibt das Netzwerk-Interface treffend als Gateway zwischen Verarbeitungskern und Kommunikationsnetz. Genau diese Übersetzungsschicht ist wichtig, weil ein Kern intern anders arbeitet als das Netz: Im Kern werden Befehle und Datenströme verarbeitet, im Netz werden Transfers adressiert, gepackt und weitergeleitet.
Netzwerk-Interfaces
Das Interface nimmt Anfragen aus dem Kern auf, verpackt sie und kümmert sich um den Übergang zwischen Kernlogik und Netzlogik. Ohne diese Schicht müsste jeder IP-Block das Kommunikationsprotokoll selbst sprechen, und genau das würde die Plattform unwartbar machen.
Lesen Sie auch: Gleichtaktfilter - Störungsfrei durch Telekommunikation
Router, Flits und virtuelle Kanäle
Ein Router entscheidet, wohin ein Paketfragment als Nächstes läuft. Die kleinste sinnvolle Transporteinheit heißt Flit - also eine Portion eines Pakets, die sich einzeln weiterleiten lässt. Virtuelle Kanäle teilen einen physischen Link logisch auf mehrere Fahrspuren auf; das hilft gegen Verklemmungen und kann Prioritäten sauberer abbilden.
Technisch wirkt das unscheinbar, praktisch ist es der Punkt, an dem ein NoC entweder robust oder chaotisch wird. Von hier aus führt der Blick direkt zu der Frage, welche Topologie diese Bausteine am sinnvollsten verbindet.
Welche Topologien sich in der Praxis bewähren
In der Praxis sehe ich drei Grundmuster immer wieder. Das 2D-Mesh ist beliebt, weil es sich regelmäßig layouten lässt und bei vielen Kernen gut kontrollierbar bleibt. Andere Topologien drücken die Anzahl der Hops, kosten dafür aber oft mehr Fläche, mehr Entwurfsaufwand oder mehr Verifikationszeit.
| Topologie | Stärken | Grenzen | Sinnvoll wenn |
|---|---|---|---|
| 2D-Mesh | Regelmäßig, gut zu platzieren, gut skalierbar | Mehr Hops bei weit entfernten Kernen | Viele Blöcke und ein klarer Floorplan vorliegen |
| Torus | Kürzere Wege durch Wraparound-Links | Komplexere Verdrahtung und Testbarkeit | Der Fernverkehr hoch ist und Latenz zählt |
| Tree oder Butterfly | Weniger Hops, gute Durchsatzwerte | Hotspots nahe am Zentrum möglich | Hierarchische oder stark zentrale Traffic-Muster dominieren |
| Hybrid Mesh-Crossbar | Lokal sehr schnell, flexibel kombinierbar | Mehr Designaufwand und oft mehr Fläche | Clustern viel interner Verkehr bewegt wird |
Wenn ich einen Entwurf bewerte, ist die Faustregel einfach: Je besser sich das Verkehrsprofil vorhersagen lässt, desto stärker kann man Richtung spezialisierter Topologien gehen. Je gemischter und unruhiger der Verkehr ist, desto lieber nehme ich eine robuste, gut verstandene Struktur wie das Mesh - notfalls ergänzt um Lokalisierung und kürzere Sonderpfade. Genau daraus ergibt sich dann die nächste Frage: Was bringt das gegenüber Bus und Crossbar wirklich?
Warum bessere Skalierung nicht automatisch bessere Performance bedeutet
Ein NoC ist kein Freifahrtschein für hohe Leistung. Es kann nur dann glänzen, wenn Lastverteilung, Routing und Pufferung zur Workload passen. Auch ein gutes Netz kann einen schlechten Speicherzugriff nicht wegzaubern.
| Architektur | Latenz | Skalierung | Fläche und Energie | Meine Einordnung |
|---|---|---|---|---|
| Bus | Gut bei wenig Traffic, schlecht bei Konflikten | Schwach | Einfach, aber bei Last ineffizient | Für kleine SoCs noch absolut vernünftig |
| Crossbar | Sehr niedrig bei kurzen Wegen | Mittel bis schwach | Wächst mit jeder zusätzlichen Portzahl spürbar | Gut, solange die Zahl der Teilnehmer begrenzt bleibt |
| NoC | Stabiler unter Last | Gut bis sehr gut | Router kosten Fläche, sparen aber oft bei großen Systemen | Die richtige Wahl für komplexe SoCs mit vielen Blöcken |
Für Echtzeit- und Telekommunikationssysteme ist außerdem Jitter wichtig, also die Schwankung der Antwortzeit. Eine Architektur kann auf dem Papier genug Bandbreite haben und im Produkt trotzdem schwach wirken, wenn Stau und Wartezeiten ungleichmäßig verteilt sind. Genau hier spielt ein gut konfiguriertes NoC seine Stärke aus - nicht nur durch Durchsatz, sondern durch planbarere Latenzen.
Welche Entwurfsfehler ich am häufigsten sehe
Ich sehe in frühen Architekturentwürfen immer wieder dieselben Denkfehler: Der Verkehr wird zu optimistisch geschätzt, die Lastspitzen werden unterschätzt, und QoS wird erst dann diskutiert, wenn die ersten Engpässe schon fest eingebaut sind. Das ist teuer, weil man solche Probleme später nur mit zusätzlichen Puffern, komplexerer Routinglogik oder Taktkompromissen bezahlt.
- Die Traffic-Matrix ist zu grob geraten. Wer nur Mittelwerte betrachtet, übersieht Peaks und Burst-Verhalten.
- QoS und Prioritäten fehlen. Ohne klare Dienstklassen konkurrieren unkritische und zeitkritische Daten unnötig miteinander.
- Verklemmung wurde nicht sauber geprüft. Routing, Puffer und virtuelle Kanäle müssen zusammenpassen, sonst entsteht ein stilles Blockadeproblem.
- Thermische Hotspots wurden ignoriert. Ein dichtes Netz kann in der Praxis lokal sehr heiß werden und den Takt begrenzen.
- Die Verifikation startet zu spät. Dann entdeckt man Schwächen erst im Layout oder im Silizium, nicht mehr im Modell.
- Verschiedene Taktdomänen wurden unterschätzt. Wenn Blöcke mit unterschiedlichen Takten sprechen, braucht die Übergabe saubere Synchronisation.
Je früher ich mit realistischen Lastprofilen arbeite, desto weniger Überraschungen gibt es später im Layout und im Silizium. Das spart nicht nur Zeit, sondern oft auch Taktfrequenz, weil man weniger Sicherheitsreserven verbraten muss. Genau deshalb wird das Thema in modernen Anwendungen wieder wichtiger.
Wo die Technik für moderne Elektronik besonders wichtig ist
Besonders wichtig wird das Thema überall dort, wo viele Funktionsblöcke dicht beieinander arbeiten: in Anwendungsprozessoren, KI-Beschleunigern, Bild- und Videosignalpfaden, Automotive-SoCs, Netzwerkchips und industriellen Edge-Systemen. Gerade in Geräten für Telekommunikation und Infrastruktur - also auch dort, wo robuste Konnektivität im Vordergrund steht - zählt nicht nur Spitzenleistung, sondern auch, wie stabil die Kommunikation unter Dauerlast bleibt.
Arteris beschreibt NoC-Interconnect-IP inzwischen genau in diesem Umfeld, also dort, wo SoCs mit wachsender Blockzahl und klarer Skalierungslogik entworfen werden. Für kompakte Infrastrukturhardware, die wenig Platz, wenig Energie und oft enge thermische Reserven hat, ist das ein sehr realistischer Ansatz - besonders dann, wenn mehrere Datenpfade parallel aktiv sind.
Mit Chiplets verschiebt sich die Grenze allerdings nach außen: Innerhalb eines Dies kann ein On-Chip-Netzwerk die IP-Kerne sauber verbinden, aber zwischen Diesen sprechen wir über andere physische und logische Links. Für 2026 ist das wichtig, weil die Interconnect-Frage immer öfter schon auf Systemebene gedacht wird und nicht erst beim letzten Floorplan.
Worauf ich 2026 bei einem NoC zuerst schaue
Wenn ich ein On-Chip-Netzwerk für eine neue Elektronik-Plattform bewerte, prüfe ich zuerst ein paar nüchterne Fragen statt gleich über die Topologie zu diskutieren. Die Erfahrung ist simpel: Die beste Architektur ist die, die zum Verkehr passt, nicht die, die auf dem Papier am elegantesten aussieht.
- Wie viele aktive Teilnehmer gibt es wirklich? Bei 2 bis 4 dominanten Blöcken reicht oft noch eine kleine Crossbar oder sogar ein sauberer Bus; ab etwa 8 bis 16 aktiven Blöcken kippt die Lage meist sichtbar.
- Wie sieht die Traffic-Matrix aus? Lokaler, vorhersehbarer Verkehr lässt sich gut planen; stark gemischte Last braucht mehr Puffer und klarere Prioritäten.
- Welche Daten sind zeitkritisch? Wenn Audio, Funk, Sensorik oder Steuerpfade harte Antwortzeiten brauchen, muss QoS von Anfang an mitdesigned werden.
- Wie wird Verklemmung vermieden? Routing, Pufferung und virtuelle Kanäle müssen zusammenpassen, sonst baut man sich ein elegantes, aber blockierbares Netz.
- Wie heiß wird das Ganze? Ein schönes Interconnect auf dem Schaltplan hilft wenig, wenn sich im realen Betrieb Hotspots bilden und den Takt begrenzen.
- Was kostet die Komplexität? Jede zusätzliche Funktion im Netz erhöht Verifikationsaufwand, Debugging-Zeit und meist auch den Druck auf Fläche und Energie.
Mein praktischer Schluss ist klar: Ein gutes NoC ist kein Selbstzweck, sondern die Kommunikationsschicht, die zur Last, zur Fläche und zum Energiebudget des Chips passen muss. Wer zuerst den Verkehr versteht und erst danach die Topologie wählt, kommt in der Regel zu deutlich saubereren SoCs als jemand, der nur nach dem schnellsten Diagramm entscheidet.
