Der Hardware-Architektur-Post dieser Serie hat die drei HW-Varianten (externe/integrierte PHYs) gezeigt, der Hardware Deep Dive die externen PCB-Schnittstellen. Beide Posts blieben bewusst außerhalb der Chip-Grenze. Dieser Post geht — analog zum EthTrcv-PHY-Architektur-Post — tatsächlich ins Silizium: Was passiert intern, wenn ein Frame den Switch durchläuft?
Die interne Mikroarchitektur eines Switch-Chips ist — anders als die AUTOSAR-APIs in den übrigen Posts dieser Serie — nicht Gegenstand der AUTOSAR SWS. Sie ist Vendor-IP. Dieser Post beschreibt daher allgemein gültige, aus der Netzwerktechnik bekannte Architekturprinzipien, wie sie in praktisch jedem automotive Switch-Chip in irgendeiner Form vorkommen — ohne Anspruch, einen bestimmten Chip exakt nachzubilden. |
Blockübersicht
Switch-Fabric-Architekturen im Überblick
| Architektur | Grundidee |
|---|---|
Shared-Memory-Switching | Alle Ports teilen sich einen gemeinsamen, schnellen Speicherblock. Eingehende Frames werden einmal in den Speicher geschrieben, die Lookup-Entscheidung bestimmt nur noch, von wo die Egress-Logik liest. Einfacher zu bauen, aber der gemeinsame Speicher wird bei steigender Portzahl/Bandbreite zum Flaschenhals |
Crossbar-Switching | Eine Matrix aus Schaltern verbindet jeden Eingang direkt mit jedem Ausgang. Höherer Durchsatz möglich, da parallele Pfade existieren, aber komplexere Ansteuerung und mehr Silizium-Fläche |
Viele automotive Switch-Chips mit überschaubarer Portanzahl (4–8 Ports) setzen aus Kostengründen auf Shared-Memory-Architekturen; höherportige oder Multi-Gigabit-Chips für Backbone-Anwendungen tendieren eher zu Crossbar- oder hybriden Ansätzen.
Der Lookup-Pfad eines Frames im Silizium
Ingress-MAC — empfängt das Frame elektrisch/physikalisch vom Port (siehe Hardware-Deep-Dive-Post)
Parser/Classifier — extrahiert Header-Felder (Ziel-MAC, VLAN-Tag, EtherType, ggf. IP-Header) für die nachfolgende Lookup-Stufe
Lookup-Engine — an anderer Stelle in dieser Serie (z. B. im Hardware-Architektur-Post) informell auch "Forwarding-Engine" genannt — schlägt die Ziel-MAC-Adresse in einer CAM/TCAM-artigen Speicherstruktur nach (die Software-Sicht darauf ist die ARL-Tabelle, siehe ARL-Tabelle-Post), prüft die VLAN-Zugehörigkeit und wendet ggf. Stream-Filterregeln an (siehe TSN-Stream-Post)
Puffer — das Frame wird zwischengespeichert, bis die Egress-Logik es abholt
CAM (Content Addressable Memory) und TCAM (Ternary CAM) sind Speichertypen, die "rückwärts" adressiert werden: Man gibt einen Wert (z. B. eine MAC-Adresse) hinein und bekommt die Speicheradresse (bzw. direkt den zugehörigen Datensatz wie Port-Nummer) heraus — in einem einzigen Taktzyklus, unabhängig von der Tabellengröße. Genau das macht Line-Rate-Lookup bei Millionen Frames pro Sekunde überhaupt erst möglich. |
Puffer-Architektur und Head-of-Line-Blocking
Ein naiver Ansatz — eine einzige FIFO-Warteschlange pro Eingangsport — leidet unter Head-of-Line-Blocking: Steht das vorderste Frame in der Schlange auf einen ausgelasteten Ausgangsport, blockiert es alle dahinterliegenden Frames, selbst wenn deren Zielports frei wären.
Die gängige Abhilfe ist Virtual Output Queuing (VOQ): Statt einer Warteschlange pro Eingang wird gedanklich eine Warteschlange pro Eingang-Ausgang-Paar geführt. Ein blockierter Ausgangsport verzögert dann nur die Frames, die tatsächlich zu ihm wollen — nicht die gesamte Eingangsschlange.
Die in Teil 3/4 dieser Serie beschriebenen |
Queues und Scheduler als Silizium-Blöcke
Die Egress-Queues sind in Hardware als eigene Speicherbereiche mit zugehöriger Scheduling-Logik realisiert — pro Ausgangsport typischerweise mehrere Queues (eine je Traffic-Klasse), gesteuert vom Egress-Scheduler. Genau diese Blöcke sind es, die im TSN-Post dieser Serie als kaskadierbare Port-Scheduler mit CBS/ETS-Algorithmen beschrieben werden.
Der eingebettete Management-Core
Viele automotive Switch-Chips enthalten einen kleinen eingebetteten CPU-Kern (häufig ein ARM-Cortex-M-artiger Mikrocontroller), der:
SPI- bzw. SMI-Registerzugriffe von außen entgegennimmt und intern auf die eigentliche Fabric-Hardware abbildet (siehe SPI-Post und SMI-Post)
die Konfiguration beim Boot aus einem externen EEPROM/Flash lädt, bevor der Host überhaupt mit
EthSwt_Initbeginntbei manchen Chip-Familien das in der SWS erwähnte Software-MAC-Learning (siehe ARL-Tabelle-Post) tatsächlich ausführt, statt es der reinen Hardware-Lookup-Engine zu überlassen
Dieser Management-Core ist kein AUTOSAR-Konzept — er ist reine
Chip-Interna und für den |
Per-Port-MAC-Blöcke
Jeder Port besitzt einen eigenen MAC-Block, der die Layer-2-Framing-Logik
(Präambel, FCS-Prüfung, Inter-Packet-Gap) implementiert — unabhängig
davon, ob dahinter ein eingebetteter PHY oder ein externer, über MII/MDIO
angebundener EthTrcv-Chip sitzt (siehe
Hardware-Architektur-Post
für die drei HW-Varianten).
Zusammenfassung
| Aspekt | Kernaussage |
|---|---|
Fabric-Architektur | Shared-Memory (einfacher, portzahl-limitiert) vs. Crossbar (höherer Durchsatz, mehr Silizium-Aufwand) |
Lookup-Engine | CAM/TCAM-artige Hardware für Line-Rate-Adress-/VLAN-/Stream-Lookup in einem Taktzyklus |
Puffer | Virtual Output Queuing als Standardlösung gegen Head-of-Line-Blocking |
Management-Core | Kein AUTOSAR-Konzept, aber oft die reale Instanz hinter
|