EthTrcv von der Hardwareseite — PHY-Architektur für Software-Entwickler

Dieser Post baut auf der EthTrcv-Serie auf und knüpft direkt an den vorherigen Post zur Migration an. Dort ging es darum, was sich beim Wechsel von 100BASE-TX zu 100BASE-T1 auf Protokoll- und Konfigurationsebene ändert. Dieser Post geht einen Schritt weiter in Richtung Hardware — aber bewusst nur bis zu der Tiefe, die ein Software-Entwickler braucht, der EthTrcv_Init aufruft und verstehen will, was auf der anderen Seite dieses Aufrufs eigentlich passiert.

Wer die volle elektrische Tiefe sucht — Leitungspegel, PCB-Timing, EMV, Power Sequencing bis auf die Pin-Ebene — findet das im abschließenden Hardware Deep Dive dieser Serie. Dieser Post hier ist die Brücke dorthin: konzeptionell, funktional, ohne Oszilloskop.

Dieser Post beantwortet die Frage „Was tut der PHY-Chip funktional?" — nicht „Wie sieht das Signal auf dem Kabel elektrisch aus?". Für Letzteres ist der Hardware-Deep-Dive-Post am Ende der Serie da.

PHY-Architektur im Überblick

Ein Ethernet-PHY ist kein monolithischer Chip, der einfach „irgendwie" Bits in Signale verwandelt. Intern gliedert er sich in drei funktionale Blöcke, die IEEE 802.3 sauber voneinander trennt: PCS, PMA und MDI.

                         PHY-Chip
   ┌───────────────────────────────────────────────────┐
   │                                                     │
   │   MAC-seitig            PHY-intern                 │
   │  ┌─────────┐    ┌─────────────┐    ┌─────────┐     │
   │  │  MII/    │    │             │    │         │     │
   │  │  RMII/   │───►│     PCS     │───►│   PMA   │───┐ │
   │  │  RGMII   │◄───│ (Coding &   │◄───│(Line    │◄──┤ │
   │  │ Interface│    │  Framing)   │    │ Coupling)│  │ │
   │  └─────────┘    └─────────────┘    └─────────┘  │ │
   │       ▲                 ▲                        │ │
   │       │            ┌─────────┐                   ▼ │
   │       │            │Register-│              ┌─────────┐
   │       │            │  Bank   │              │   MDI   │──► Kabel
   │       │            │(via     │              └─────────┘
   │       │            │ MDIO)   │
   │       │            └─────────┘
   │       │                 ▲
   └───────┼─────────────────┼─────────────────────────┘
           │                 │
      Datenpfad         Management-Pfad
      (Frames)          (MDC/MDIO — Steuerung & Status)

Diese drei Blöcke im Überblick:

Block	Aufgabe
PCS (Physical Coding Sublayer)	Übersetzt zwischen den digitalen Frame-Bits, die von der MAC kommen, und dem Leitungscode, den die Übertragungstechnik verlangt. Übernimmt Scrambling, Bit-Encoding und Framing der Übertragungsblöcke.
PMA (Physical Medium Attachment)	Wandelt die codierten Bits des PCS in physikalische Symbole um (z. B. Spannungspegel) und umgekehrt. Enthält bei 100BASE-T1 auch die Echo-Cancellation-Logik für den bidirektionalen Betrieb auf einem einzelnen Aderpaar.
MDI (Medium Dependent Interface)	Der eigentliche physikalische Anschlusspunkt ans Kabel. Alles, was mediumspezifisch ist — Impedanz, Kopplung, Filterung — sitzt konzeptionell hier.

Block

Aufgabe

PCS (Physical Coding Sublayer)

Übersetzt zwischen den digitalen Frame-Bits, die von der MAC kommen, und dem Leitungscode, den die Übertragungstechnik verlangt. Übernimmt Scrambling, Bit-Encoding und Framing der Übertragungsblöcke.

PMA (Physical Medium Attachment)

Wandelt die codierten Bits des PCS in physikalische Symbole um (z. B. Spannungspegel) und umgekehrt. Enthält bei 100BASE-T1 auch die Echo-Cancellation-Logik für den bidirektionalen Betrieb auf einem einzelnen Aderpaar.

MDI (Medium Dependent Interface)

Der eigentliche physikalische Anschlusspunkt ans Kabel. Alles, was mediumspezifisch ist — Impedanz, Kopplung, Filterung — sitzt konzeptionell hier.

Diese Dreiteilung ist mehr als akademische Schichtenlehre. Wenn ein PHY-Datenblatt Register für „PCS Status" von Registern für „PMA/PMD Status" trennt (typisch bei Clause-45-PHYs), spiegelt das genau diese Architektur wider. Wer weiß, welcher Block wofür zuständig ist, findet im Datenblatt schneller das richtige Register für ein bestimmtes Symptom.

Dazu kommt die Register-Bank — ein Satz von Kontroll- und Statusregistern, die über den MDIO-Bus von außen lesbar und teilweise beschreibbar sind. Sie ist kein eigener Signalpfad, sondern die Schnittstelle, über die Software (also letztlich EthTrcv) den PHY konfiguriert und seinen Zustand ausliest.

Was passiert bei `EthTrcv_Init`?

Aus Software-Sicht ist EthTrcv_Init ein einzelner Funktionsaufruf mit einem Konfigurationszeiger. Aus PHY-Sicht löst dieser Aufruf eine mehrstufige Sequenz aus, die deutlich länger dauert als der Funktionsaufruf selbst — ein Großteil davon läuft asynchron weiter, nachdem EthTrcv_Init bereits zurückgekehrt ist.

EthTrcv_Init(config)
   │
   ├─► 1. Hardware-Reset auslösen
   │      RST_N-Pin für definierte Zeit low ziehen (oder Soft-Reset-Bit via MDIO)
   │      → PHY verwirft internen Zustand, alle Register auf Power-On-Defaults
   │
   ├─► 2. PHY-Boot abwarten
   │      Interner Power-On-Self-Test, PLL-Einschwingzeit, interne Kalibrierung
   │      der analogen Blöcke (Referenzspannungen, Terminierungswiderstände)
   │      → typisch < 1 ms bis wenige ms, herstellerabhängig
   │
   ├─► 3. PHY-Identifikation prüfen
   │      PHY-ID-Register über MDIO lesen, gegen erwartete ID aus Konfiguration
   │      vergleichen (siehe Teil 2 der Serie)
   │
   ├─► 4. Statische Konfiguration programmieren
   │      Interface-Modus (RGMII/RMII/...), Auto-Negotiation-Advertisement,
   │      Master/Slave-Rolle bei 100BASE-T1, herstellerspezifische Strap-Register
   │
   ├─► 5. Zustand: UNINIT → INIT
   │      EthTrcv_Init() kehrt zurück — aber der PHY ist noch nicht "im Link"
   │
   ── ab hier läuft es asynchron weiter, erst nach SetTransceiverMode(ACTIVE) ──
   │
   ├─► 6. Interne Kalibrierung des Leitungstreibers
   │      Der analoge Frontend-Verstärker kalibriert sich auf die tatsächliche
   │      Leitungsimpedanz — bei 100BASE-T1 Teil der Voraussetzung für
   │      funktionierende Echo-Cancellation
   │
   └─► 7. Link-Training beginnt
          (siehe eigener Abschnitt weiter unten)

Schritt 2 — die Boot- und Kalibrierungszeit — ist der Grund, warum manche Implementierungen nach EthTrcv_Init ein kurzes, definiertes Delay einbauen, bevor der erste MDIO-Zugriff erfolgt. Greift die Software zu früh zu, antwortet der PHY entweder gar nicht oder liefert Werte aus einem noch nicht vollständig initialisierten Register — ein klassischer, schwer reproduzierbarer Bringup-Fehler.

Wichtig für das mentale Modell: EthTrcv_Init konfiguriert den PHY, es erzeugt keinen Link. Der Link entsteht erst durch Link-Training, das erst beginnt, nachdem der Transceiver über EthTrcv_SetTransceiverMode(ACTIVE) aktiviert wurde — und selbst dann kann es je nach Technologie eine spürbare Zeit dauern, bis der Link tatsächlich steht (dazu gleich mehr).

Der MDIO-Bus — kurz zusammengefasst

Der gesamte Ablauf oben — Register lesen, Register schreiben, PHY-ID prüfen — läuft über den MDIO-Bus. Konzeptionell reicht an dieser Stelle:

SoC ── MDC (Takt) ──────────────► PHY
    ── MDIO (Daten, bidirektional) ─► PHY

MDIO ist ein einfacher, serieller Zweidraht-Bus, über den die Software Register im PHY adressiert, liest und schreibt — ähnlich im Prinzip wie I2C, aber mit eigenem Frame-Format. Es gibt zwei Frame-Varianten (Clause 22 für einfachere PHYs, Clause 45 für PHYs mit mehr Registerraum, etwa alle 1000BASE-T1-PHYs), und mehrere PHYs können sich denselben Bus über unterschiedliche PHY-Adressen teilen.

Register-Layout, Clause-22-vs-45-Unterschiede, elektrische Spezifikation (Pull-up-Widerstände, Timing, Taktfrequenz) und typische Diagnose-Register sind Thema eines eigenen Posts: MDIO-Post. Wer bereits weiß, dass EthTrcv_Init "irgendwie über MDIO" mit dem PHY spricht, und nur verstehen will, was die Register-Zugriffe fachlich bewirken, ist damit für diesen Post ausreichend ausgestattet.

Signalverarbeitung im PHY

Zwischen „Bits von der MAC" und „Signal auf dem Kabel" liegt eine ganze Kette an Signalverarbeitungsschritten, die vollständig im PHY-Chip stattfindet und für Software unsichtbar bleibt — aber das Verständnis dieser Kette erklärt, warum PHY-Chips so komplex sind und warum bestimmte Fehlerbilder überhaupt entstehen können.

Frame-Bits (von der MAC)
     │
     ▼
┌───────────┐   verhindert lange Folgen gleicher Bits
│ Scrambling│   (DC-Balance, spektrale Formung)
└─────┬─────┘
      ▼
┌───────────┐   bildet Bitgruppen auf Übertragungssymbole ab
│  Encoding │   (z. B. PAM3 bei 100BASE-T1)
└─────┬─────┘
      ▼
┌───────────┐   fügt Redundanz hinzu, damit Empfangsfehler
│  Forward   │   korrigiert werden können, ohne erneut zu senden
│Error       │
│Correction  │
└─────┬─────┘
      ▼
┌───────────┐   bei Single-Pair: eigenes Sendesignal vom
│   Echo-    │   Empfangssignal abziehen
│Cancellation│
└─────┬─────┘
      ▼
   Signal auf der Leitung

Scrambling sorgt dafür, dass auf der Leitung keine langen Folgen gleicher Bits auftreten — ein Kabel, das dauerhaft „high" oder „low" hält, erzeugt ungünstige Gleichanteile und erschwert dem Empfänger die Taktrückgewinnung. Scrambling ist reversibel und verändert nicht die Dateninformation, nur ihre Darstellung auf der Leitung.

Encoding bildet Bitgruppen auf Übertragungssymbole ab. Bei 100BASE-T1 kommt PAM3 zum Einsatz — statt nur zweier Spannungspegel (klassisch: 0/1) werden drei Pegel verwendet, wodurch pro Symbol mehr Information übertragen werden kann. Das Ergebnis: höhere Datenrate bei niedrigerer Symbolrate auf dem Kabel, was wiederum die Anforderungen an Kabel und EMV senkt.

Fehlerkorrektur (Forward Error Correction, FEC) fügt kontrollierte Redundanz hinzu, sodass der Empfänger einen gewissen Anteil an Bitfehlern selbst korrigieren kann, ohne dass eine erneute Übertragung nötig wird. Das ist besonders für automotive Umgebungen relevant, wo elektromagnetische Störungen auf der Leitung nicht vollständig auszuschließen sind.

Für Software-Entwickler ist die genaue Funktionsweise dieser Kette selten handlungsrelevant — sie läuft komplett im PHY und ist nicht per API sichtbar. Relevant ist eher das Wissen, dass sie existiert: Wenn ein PHY-Statusregister eine steigende Fehlerkorrekturrate meldet, ist das ein Frühwarnzeichen für eine sich verschlechternde Leitungsqualität — lange bevor der Link komplett ausfällt.

Link-Training bei 100BASE-T1 — warum das dauern kann

Ein Punkt, der in der Praxis für Verwirrung sorgt: Nach EthTrcv_Init und EthTrcv_SetTransceiverMode(ACTIVE) steht der Link nicht sofort. Bei 100BASE-T1 kann der erste Link-Aufbau spürbar länger dauern als klassisches Ethernet-Nutzer erwarten würden — und das ist kein Fehler, sondern Funktionsprinzip.

SetTransceiverMode(ACTIVE)
   │
   ├─► Master/Slave-Rolle ist bereits konfiguriert
   │   (bei 100BASE-T1 kein Auto-Negotiation-Wettlauf wie bei TX,
   │    sondern statisch per Konfiguration festgelegt)
   │
   ├─► Silence-Detection
   │      Beide Seiten "hören" zunächst auf die Leitung
   │
   ├─► Signal-Detection
   │      Master beginnt zu senden, Slave erkennt die Präsenz eines Signals
   │
   ├─► Link-Training-Phase
   │      Adaptive Filter im PMA gleichen sich an die tatsächliche
   │      Leitungscharakteristik an: Echo-Cancellation-Koeffizienten,
   │      Entzerrer-Filter, Timing-Recovery
   │      → dieser Schritt braucht Zeit, da die Filter iterativ konvergieren
   │
   ├─► Descrambler-Synchronisation
   │      Sender und Empfänger synchronisieren ihre Scrambler-Zustände
   │
   └─► Link Up
          EthTrcv_GetLinkState() liefert ETHTRCV_LINK_STATE_ACTIVE

Die Größenordnung: Wo klassisches 100BASE-TX den Link häufig in deutlich unter einer Sekunde etabliert, kann der erste Link-Aufbau bei 100BASE-T1 — abhängig von PHY-Chip, Leitungslänge und Umgebungsbedingungen — mehrere hundert Millisekunden bis wenige Sekunden dauern. Grund ist die iterative Filteradaption beim Link-Training, die bei einer neuen oder gestörten Verbindung mehrere Anläufe brauchen kann.

Für die Applikationsschicht bedeutet das: Wer nach SetTransceiverMode(ACTIVE) sofort ein Timeout von wenigen hundert Millisekunden auf EthTrcv_GetLinkState setzt, riskiert falsch-negative Link-Fehler direkt beim Bringup — obwohl der PHY korrekt arbeitet und schlicht noch trainiert.

Ein wiederholtes, aber letztlich erfolgreiches Link-Training (mehrere Trainingsversuche, bevor der Link steht) ist bei 100BASE-T1 nicht per se ein Hardwarefehler. Erst wenn der Link dauerhaft nicht zustande kommt oder im laufenden Betrieb wiederholt abbricht und neu trainiert, ist das ein Signal für ein tatsächliches Problem — Kabel, Steckverbinder, EMV-Störquelle oder Konfigurationsfehler bei Master/Slave-Rolle.

Nach dem ersten erfolgreichen Training bleiben die gewonnenen Filterkoeffizienten typischerweise erhalten, solange der Link nicht komplett verloren geht — ein Re-Link nach kurzzeitigem Signalverlust ist deshalb oft schneller als der initiale Bringup.

Die MAC-PHY-Schnittstelle — MII, RMII, RGMII im Überblick

Auf der MAC-seitigen Interfaces trifft man in ARXML-Konfigurationen regelmäßig auf Kürzel wie MII, RMII oder RGMII — welche Variante konkret verbaut ist, ergibt sich implizit aus der Hardware- und Treiberanbindung und nicht aus einem eigenen, explizit wählbaren ARXML-Parameter. Für das konzeptionelle Verständnis genügt an dieser Stelle:

Interface	Kurzcharakteristik	Wo im Fahrzeug typisch
MII	Ursprüngliches, breites paralleles Interface (viele Leitungen). Heute in neuen automotive Designs kaum noch verbaut.	Ältere / einfache Steuergeräte, Legacy-Designs
RMII	Reduzierte Variante mit weniger Leitungen, geteilter Referenztakt zwischen MAC und PHY.	Kleinere Steuergeräte mit begrenzten GPIO-Ressourcen
RGMII	Reduziertes Interface für Gigabit-fähige Verbindungen, nutzt beide Taktflanken zur Datenübertragung.	Application-SoCs, Gateways, ADAS-Domänen mit 1000BASE-T1

Interface

Kurzcharakteristik

Wo im Fahrzeug typisch

MII

Ursprüngliches, breites paralleles Interface (viele Leitungen). Heute in neuen automotive Designs kaum noch verbaut.

Ältere / einfache Steuergeräte, Legacy-Designs

RMII

Reduzierte Variante mit weniger Leitungen, geteilter Referenztakt zwischen MAC und PHY.

Kleinere Steuergeräte mit begrenzten GPIO-Ressourcen

RGMII

Reduziertes Interface für Gigabit-fähige Verbindungen, nutzt beide Taktflanken zur Datenübertragung.

Application-SoCs, Gateways, ADAS-Domänen mit 1000BASE-T1

Die vollständige elektrische Beschreibung dieser Interfaces — exakte Signal-Timings, Leitungsanzahl im Detail, RGMII-Delay-Problematik und wie sich diese Wahl im PCB-Layout niederschlägt — ist Teil des Hardware Deep Dive-Posts. Für die tägliche EthTrcv-Konfiguration reicht meist das Wissen: Die Wahl des Interfaces ist eine Hardware-Entscheidung, die sich in einem Konfigurationsparameter niederschlägt — nicht umgekehrt.

Interrupt vs. Polling — wie der PHY den Stack informiert

Der PHY kennt seinen eigenen Link-Zustand jederzeit — die Frage ist, wie diese Information zur Software gelangt. Zwei Mechanismen sind in der Praxis verbreitet, und viele Serienprojekte kombinieren beide.

Ansatz 1: Polling
─────────────────
   Task (10-100ms Zyklus)
      │
      └─► EthTrcv_GetLinkState() ── liest Link-Status-Register via MDIO
             │
             └─► Änderung erst beim nächsten Poll-Zyklus sichtbar


Ansatz 2: Interrupt-gestützt
─────────────────────────────
   PHY erkennt Link-Änderung intern
      │
      └─► zieht dedizierten IRQ-Pin aktiv
             │
             └─► ISR im SoC ── setzt Flag / triggert Event
                    │
                    └─► Task-Kontext ruft EthTrcv_GetLinkState()
                        zeitnah zur eigentlichen Änderung auf

Ansatz	Vorteil	Nachteil
Polling	Einfach, kein zusätzlicher Pin nötig, deterministisches Timing	Erkennungslatenz = Poll-Intervall; MDIO-Bus wird auch ohne Änderung belastet
Interrupt	Geringe Latenz bei Link-Verlust, MDIO-Bus wird nur bei Bedarf belastet	Zusätzlicher Hardware-Pin, ISR-Handling, nicht jeder PHY/jedes Board unterstützt es

Ansatz

Vorteil

Nachteil

Polling

Einfach, kein zusätzlicher Pin nötig, deterministisches Timing

Erkennungslatenz = Poll-Intervall; MDIO-Bus wird auch ohne Änderung belastet

Interrupt

Geringe Latenz bei Link-Verlust, MDIO-Bus wird nur bei Bedarf belastet

Zusätzlicher Hardware-Pin, ISR-Handling, nicht jeder PHY/jedes Board unterstützt es

Auch beim Interrupt-Ansatz liest die Software den tatsächlichen Link-Zustand letztlich über EthTrcv_GetLinkState (also via MDIO) aus — der Interrupt sagt nur dass sich etwas geändert hat, nicht was genau. Der IRQ-Pin ersetzt also nicht den MDIO-Zugriff, er beschleunigt nur den Zeitpunkt, zu dem er ausgelöst wird.

Ein bewährtes Muster in Serienprojekten: Interrupt für die schnelle Reaktion auf sicherheitsrelevante Link-Verluste (z. B. Backbone-Verbindungen zu zentralen Steuergeräten), zusätzliches, niederfrequentes Polling als Fallback für den Fall, dass der Interrupt-Pfad aus irgendeinem Grund ein Event verpasst — etwa durch einen kurzzeitigen Interrupt-Controller-Overload.

Energiezustände — vom PHY-Chip zu AUTOSAR-Modi

Ein moderner Automotive-PHY kennt intern mehr als nur „an" und „aus". Diese PHY-internen Energiezustände sind die Hardware-Grundlage für das, was auf AUTOSAR-Ebene als Eth_ModeType (der Modus-Typ, der auch von EthTrcv_SetTransceiverMode verwendet wird) und Sleep-Handling sichtbar wird.

PHY-interne Energiezustände          AUTOSAR-Sicht (vereinfacht)
────────────────────────────         ──────────────────────────
┌───────────────┐
│    Normal      │  Link aktiv,      ┌─────────────────────┐
│  (Full Power)  │  Übertragung läuft│ ETH_MODE_ACTIVE      │
└───────┬────────┘                   └─────────────────────┘
        │ kein Datenverkehr,
        │ Link bleibt bestehen
        ▼
┌───────────────┐                    ┌─────────────────────┐
│  Standby /     │  Link gehalten,   │ ETH_MODE_ACTIVE      │
│  Low-Power-Idle│  reduzierter      │ (mit reduzierter     │
│                │  Energieverbrauch │  interner Aktivität) │
└───────┬────────┘                   └─────────────────────┘
        │ Sleep-Request
        │ (EcuM Sleep-Sequenz)
        ▼
┌───────────────┐                    ┌─────────────────────┐
│    Sleep       │  Link inaktiv,    │ ETH_MODE_DOWN /      │
│                │  PHY wartet auf   │ Sleep-Zustand über   │
│                │  WakeUp-Ereignis  │ herstellerspez. API  │
└───────┬────────┘                   └─────────────────────┘
        │ WakeUp-Impuls auf Leitung
        ▼
┌───────────────┐                    ┌─────────────────────┐
│  Wake-Up /     │  PHY fährt hoch,  │ EthTrcv_CheckWakeup()│
│  Boot          │  Register-Zugriff │ → EcuM-WakeUp-Kette  │
│                │  wieder möglich   │                      │
└────────────────┘                   └─────────────────────┘

PHY-Zustand Bedeutung

PHY-Zustand	Bedeutung
Normal (Full Power)	Alle analogen und digitalen Blöcke aktiv, PHY überträgt und empfängt mit voller Leistungsaufnahme. Entspricht `ETH_MODE_ACTIVE` mit stehendem Link.
Standby / Low-Power-Idle	Der Link bleibt physikalisch bestehen, aber Sende-/Empfangsschaltungen reduzieren ihre Aktivität, solange kein Datenverkehr ansteht. Für Software weiterhin als aktiver Link sichtbar — die Energieeinsparung passiert transparent im PHY.
Sleep	Der PHY reduziert seinen Energieverbrauch drastisch, der Link ist nicht mehr aktiv. Der PHY überwacht weiterhin die Leitung auf ein definiertes WakeUp-Signal. Entspricht auf AUTOSAR-Seite typischerweise dem Übergang in `ETH_MODE_DOWN` in Kombination mit einer herstellerspezifischen Sleep-Anforderung über MDIO-Register.
Wake-Up / Boot	Übergangszustand, in dem der PHY wieder hochfährt, nachdem ein WakeUp-Ereignis erkannt wurde. Software-seitig wird dieser Übergang über `EthTrcv_CheckWakeup` in die EcuM-WakeUp-Behandlung eingebunden.

Normal (Full Power)

Alle analogen und digitalen Blöcke aktiv, PHY überträgt und empfängt mit voller Leistungsaufnahme. Entspricht ETH_MODE_ACTIVE mit stehendem Link.

Standby / Low-Power-Idle

Der Link bleibt physikalisch bestehen, aber Sende-/Empfangsschaltungen reduzieren ihre Aktivität, solange kein Datenverkehr ansteht. Für Software weiterhin als aktiver Link sichtbar — die Energieeinsparung passiert transparent im PHY.

Sleep

Der PHY reduziert seinen Energieverbrauch drastisch, der Link ist nicht mehr aktiv. Der PHY überwacht weiterhin die Leitung auf ein definiertes WakeUp-Signal. Entspricht auf AUTOSAR-Seite typischerweise dem Übergang in ETH_MODE_DOWN in Kombination mit einer herstellerspezifischen Sleep-Anforderung über MDIO-Register.

Wake-Up / Boot

Übergangszustand, in dem der PHY wieder hochfährt, nachdem ein WakeUp-Ereignis erkannt wurde. Software-seitig wird dieser Übergang über EthTrcv_CheckWakeup in die EcuM-WakeUp-Behandlung eingebunden.

Der Übergang zwischen diesen PHY-internen Energiezuständen und den AUTOSAR-Modi ist nicht 1:1 spezifiziert, sondern herstellerspezifisch über MDIO-Register realisiert. Eth_ModeType kennt in der SWS die Werte ETH_MODE_DOWN, ETH_MODE_ACTIVE und ETH_MODE_ACTIVE_WITH_WAKEUP_REQUEST — aber wie ein echter Low-Power-Sleep mit WakeUp-Fähigkeit auf PHY-Registerebene konkret aussieht, läuft in vielen Implementierungen über zusätzliche, nicht standardisierte Funktionen des PHY-Treibers oder direkt über konfigurierte Register-Sequenzen im ARXML.

Die WakeUp-Erkennung selbst — welches Signalmuster auf der Leitung als gültiger WakeUp zählt, wie der PHY das dem SoC über den INH-Pin signalisiert — ist wieder ein Thema, das an der Grenze zur Elektronik liegt und im Hardware-Deep-Dive-Post im Detail behandelt wird.

Zusammenfassung

Thema Kernaussage für Software-Entwickler

Thema	Kernaussage für Software-Entwickler
PHY-Architektur	PCS (Coding), PMA (Signalumsetzung) und MDI (physikalischer Anschluss) sind drei getrennte funktionale Blöcke — spiegelt sich oft im Register-Layout des Datenblatts
`EthTrcv_Init`	Löst eine mehrstufige Sequenz aus (Reset, Boot, ID-Check, Konfiguration), die teils asynchron weiterläuft — der Funktionsaufruf selbst erzeugt noch keinen Link
MDIO	Steuerbus zum PHY, Register-Details siehe eigener MDIO-Post
Signalverarbeitung	Scrambling, Encoding (z. B. PAM3), Fehlerkorrektur und Echo-Cancellation laufen vollständig im PHY — für Software nur indirekt über Statusregister sichtbar
Link-Training (100BASE-T1)	Iterative Filteradaption kann den ersten Link-Aufbau mehrere hundert Millisekunden bis Sekunden dauern lassen — kein Fehler, sondern Funktionsprinzip
MAC-PHY-Interface	MII/RMII/RGMII sind Hardware-Entscheidungen, die sich in Konfigurationsparametern niederschlagen; volle elektrische Details siehe Hardware Deep Dive
Interrupt vs. Polling	Beide Ansätze lesen den Link-Zustand letztlich über MDIO aus; Interrupt beschleunigt nur den Zeitpunkt der Abfrage
Energiezustände	PHY-interne Zustände (Normal, Standby, Sleep) sind nur teilweise 1:1 auf `Eth_ModeType` abgebildet — Sleep/WakeUp läuft oft über herstellerspezifische Mechanismen

PHY-Architektur

PCS (Coding), PMA (Signalumsetzung) und MDI (physikalischer Anschluss) sind drei getrennte funktionale Blöcke — spiegelt sich oft im Register-Layout des Datenblatts

EthTrcv_Init

Löst eine mehrstufige Sequenz aus (Reset, Boot, ID-Check, Konfiguration), die teils asynchron weiterläuft — der Funktionsaufruf selbst erzeugt noch keinen Link

MDIO

Steuerbus zum PHY, Register-Details siehe eigener MDIO-Post

Signalverarbeitung

Scrambling, Encoding (z. B. PAM3), Fehlerkorrektur und Echo-Cancellation laufen vollständig im PHY — für Software nur indirekt über Statusregister sichtbar

Link-Training (100BASE-T1)

Iterative Filteradaption kann den ersten Link-Aufbau mehrere hundert Millisekunden bis Sekunden dauern lassen — kein Fehler, sondern Funktionsprinzip

MAC-PHY-Interface

MII/RMII/RGMII sind Hardware-Entscheidungen, die sich in Konfigurationsparametern niederschlagen; volle elektrische Details siehe Hardware Deep Dive

Interrupt vs. Polling

Beide Ansätze lesen den Link-Zustand letztlich über MDIO aus; Interrupt beschleunigt nur den Zeitpunkt der Abfrage

Energiezustände

PHY-interne Zustände (Normal, Standby, Sleep) sind nur teilweise 1:1 auf Eth_ModeType abgebildet — Sleep/WakeUp läuft oft über herstellerspezifische Mechanismen

Weiter in der EthTrcv-Serie: EthTrcv Hardware Deep Dive — Die physikalischen Interfaces des PHY-Chips

PHY-Architektur im Überblick#

Was passiert bei EthTrcv_Init?#

Der MDIO-Bus — kurz zusammengefasst#

Signalverarbeitung im PHY#

Link-Training bei 100BASE-T1 — warum das dauern kann#

Die MAC-PHY-Schnittstelle — MII, RMII, RGMII im Überblick#

Interrupt vs. Polling — wie der PHY den Stack informiert#

Energiezustände — vom PHY-Chip zu AUTOSAR-Modi#

Zusammenfassung#

PHY-Architektur im Überblick

Was passiert bei `EthTrcv_Init`?

Der MDIO-Bus — kurz zusammengefasst

Signalverarbeitung im PHY

Link-Training bei 100BASE-T1 — warum das dauern kann

Die MAC-PHY-Schnittstelle — MII, RMII, RGMII im Überblick

Interrupt vs. Polling — wie der PHY den Stack informiert

Energiezustände — vom PHY-Chip zu AUTOSAR-Modi

Zusammenfassung