Kein Hardware-Design-Guide, sondern ein Verständnis-Post: Was steckt eigentlich hinter dem, was EthSwt_Init konfiguriert? Die SWS selbst beschreibt in Kapitel 7.1 drei explizite Hardware-Varianten für das Zusammenspiel von Switch und PHY — eine Unterscheidung, die viele EthSwt-Einführungen nicht erwähnen, obwohl sie direkt beeinflusst, welche Treiber (EthTrcv, EthSwt, ggf. Spi) im konkreten Projekt überhaupt zusammenspielen.

Drei Hardware-Varianten laut SWS

HW-Variante 1: Externe PHYs unterschiedlicher Hersteller
──────────────────────────────────────────────────────────────
  ┌──────────────────────┐
  │   Mikrocontroller      │
  │  ┌──────────────────┐ │        MII/MDIO       ┌─────────┐
  │  │   Switch (intern)  │◄───────────────────────►│ PHY (extern) │
  │  └──────────────────┘ │        (pro Port)      │ Vendor A │
  └──────────────────────┘                          └─────────┘
  Switch ist Teil des MCU/SoC, PHYs sind separate externe Bausteine,
  ggf. von unterschiedlichen Herstellern je Port.

HW-Variante 2: Switch mit integrierten PHYs
──────────────────────────────────────────────────────────────
  ┌────────────────────────────────────────┐
  │              Switch-Chip                 │
  │   ┌────────────┐  ┌────────────┐         │
  │   │ PHY (intern) │  │ PHY (intern) │  ...   │
  │   └────────────┘  └────────────┘         │
  └────────────────────────────────────────┘
  Alle PHYs sind Bestandteil des Switch-Chips selbst — kein separater
  EthTrcv-Chip pro Port nötig.

HW-Variante 3: MCU steuert Switch via MDIO/SPI, 3 externe PHYs
──────────────────────────────────────────────────────────────
  ┌──────────────────┐   MDIO/SPI    ┌───────────────────────┐
  │  Mikrocontroller   │◄────────────►│      Switch-Chip        │
  └──────────────────┘               │  (3 externe PHYs via    │
                                      │   MDIO ansteuerbar)      │
                                      └───┬─────────┬───────┬───┘
                                        MDIO       MDIO    MDIO
                                          │           │       │
                                     ┌────▼───┐  ┌────▼───┐┌──▼─────┐
                                     │  PHY 0  │  │  PHY 1  ││  PHY 2  │
                                     └────────┘  └────────┘└────────┘
  Unterschiedliche EthTrcv-Treiber je Port möglich, da die drei PHYs
  potenziell von unterschiedlichen Herstellern stammen können.

Die SWS betont ausdrücklich: Diese drei Varianten sind alternative Setups, keine Kombinationsoptionen für dasselbe Projekt. Welche Variante vorliegt, entscheidet sich beim Chip-Design — die Software-Architektur (EthSwt + n × EthTrcv) bleibt aber über alle drei Varianten hinweg gleich, weil EthSwt die Trennung zwischen Switch- und PHY-Ansteuerung sauber kapselt.

Praktische Konsequenz für die ARXML-Konfiguration (siehe Teil 3 dieser Serie): Ob EthSwtPortTrcvRef gesetzt ist oder leer bleibt, hängt genau von dieser Hardware-Variante ab. Bei Variante 2 (integrierte PHYs) gibt es oft gar keinen eigenständigen EthTrcv-Container, weil der PHY-Zugriff vollständig switch-intern via EthSwt_ReadTrcvRegister/WriteTrcvRegister erfolgt.

Zugriffswege auf den Switch

Laut Einleitung der SWS (Kapitel 1) erfolgt der Zugriff für switch-spezifische Konfiguration oder Funktionen über ein SPI- oder MII/MDIO-Hardware-Interface, vermittelt entweder über den Eth-Treiber oder direkt über den Spi-Treiber. Das ist die Hardware-Grundlage für die generischen Registerzugriffs-APIs (EthSwt_GetSwitchReg/SetSwitchReg), die in den separaten SPI- und SMI-Posts dieser Serie vertieft werden.

Forwarding-Engine (funktional, nicht in AUTOSAR modelliert)

Ein entscheidender Satz aus Kapitel 7.1 der SWS, den man beim ARXML-Schreiben leicht übersieht: "das funktionale Verhalten von Ingress- und Egress-Port eines Switches ist in Hardware im Switch-Gerät implementiert" — die Konfiguration aus Kapitel 10 muss daher in Teilen direkt an das Switch-Gerät geschrieben werden, statt rein im AUTOSAR-Software-Stack abgebildet zu sein. Praktisch bedeutet das: Ein gutes Stück der "eigentlichen" Switch-Logik (Lookup-Tabellen, VLAN-Tabelle, Priorisierung) lebt in Silizium, nicht im generierten C-Code des Treibers — EthSwt konfiguriert diese Hardware-Logik, implementiert sie aber nicht selbst.

Beispielchips in der Praxis

Hersteller / ChipPorts (typisch)Bemerkung

NXP SJA1105

5 (4× extern + 1 Host-Port)

Verbreiteter Automotive-Switch, SPI- und MII-basierte Konfiguration, eigene Management-Frame-Mechanismen (siehe entsprechenden Post)

NXP SJA1110

bis zu 11

Nachfolgefamilie mit integrierten PHYs (Variante 2) und Security-Funktionen

Marvell 88Q5050

8 (4× fest 100BASE-T1 + 4× konfigurierbar)

Secure-Automotive-Switch-Familie für Zonal-Architekturen, integrierter ARM-Cortex-M7-Management-Core

Marvell 88Q6113

11

Höherer Durchsatz für Backbone-Anwendungen — 2× XFI-SerDes mit bis zu 10 Gbit/s je Port, integrierte L3-Hardwarebeschleunigung

Zusammenfassung

AspektKernaussage

Hardware-Varianten

Drei alternative Setups laut SWS: externe PHYs (1), integrierte PHYs (2), MCU-gesteuerter Switch mit 3 externen PHYs (3)

Zugriffswege

SPI oder MII/MDIO, vermittelt über Eth- oder Spi-Treiber

Forwarding-Logik

Lebt größtenteils in Switch-Hardware, nicht im AUTOSAR-Treiber selbst

Nächster Schritt

Der Hardware-Deep-Dive-Post zeigt die physikalischen Interfaces auf PCB-Ebene im Detail