This post opens the EthTrcv series and builds on the AUTOSAR basics post. It is aimed at software developers encountering EthTrcv for the first time on an ECU project — whether while reading an ARXML split, debugging a link problem, or simply because "Ethernet integration" landed on next sprint’s ticket board.

Before the later parts get into API calls, initialization sequences, and ARXML parameters, this post answers the basic question: what exactly is an Ethernet transceiver, where does it sit in the AUTOSAR stack, and why are there two separate drivers (Eth and EthTrcv) for something that at first glance looks like a single job?

What Is an Ethernet Transceiver?

The term "transceiver" is a portmanteau of trans*mitter and re*ceiver — a component that can both send and receive. In an Ethernet context it refers specifically to the PHY chip (Physical Layer Device): the component that sits between the digital Ethernet controller in the microcontroller and the analog signal on the cable.

In the OSI reference model, the PHY covers exactly Layer 1:

OSI Layer                Task                              AUTOSAR module
─────────────────────────────────────────────────────────────────────────
Layer 2 (Data Link)      Framing, MAC addressing            Eth
Layer 1 (Physical)        Bit transmission, line coding,     EthTrcv
                          auto-negotiation, link status,
                          power-saving modes

The PHY chip handles several concrete tasks that are often invisible to software developers, but without which no transmission would be possible:

  • Line coding — converting digital bit sequences into a physical signal (e.g. PAM3 for 100BASE-T1) and back

  • Auto-negotiation / link establishment — negotiating speed and duplex mode with the PHY on the other end of the wire (automotive PHYs typically use fixed configuration rather than classic auto-negotiation)

  • Link status monitoring — detecting whether a working connection exists at all, and exposing that state via MDIO

  • Power management — sleep modes, WakeUp detection, standby — essential in the vehicle, where the ECU spends most of its time in a resting state

  • Signal conditioning — equalization, noise suppression, echo cancellation on bidirectional single-pair lines

A PHY chip is pure hardware — a standalone IC, or an IP block integrated into the microcontroller. EthTrcv is the software that configures and monitors this chip over a control bus (usually MDIO). The PHY itself has no notion of AUTOSAR — it only knows its registers.

It is important to distinguish the PHY from the Ethernet controller (MAC — Media Access Control), which sits on Layer 2 and assembles frames, checks addresses, and computes checksums. The MAC does not "talk" to the cable directly — it hands its bits to the PHY over a digital parallel or serial interface (MII, RMII, RGMII, SGMII). This interplay is the core of the next sections.

Classification in the AUTOSAR Layered Architecture Model

AUTOSAR Classic Platform organizes basic software into clearly separated layers. For Ethernet communication, three modules are relevant, together covering the complete Layer 1 / Layer 2 access:

                     ┌─────────────────────────────┐
                     │   Communication Services     │
                     │   (SoAd, TcpIp, ...)          │
                     └──────────────┬────────────────┘
                                    │
                     ┌──────────────▼────────────────┐
                     │            EthIf                │
                     │   (Ethernet Interface module)   │
                     │   State handling, multiplexing, │
                     │   unified API upward             │
                     └────────┬─────────────┬──────────┘
                              │             │
              ┌───────────────▼──┐     ┌────▼────────────────┐
              │        Eth         │     │      EthTrcv        │
              │ (Controller Driver) │     │ (Transceiver Driver) │
              │  Frame TX/RX,       │     │  PHY configuration,   │
              │  descriptors,       │     │  link status,          │
              │  interrupts         │     │  WakeUp, MDIO access   │
              └───────────┬─────────┘     └──────────┬─────────────┘
                          │                            │
                  ┌───────▼────────┐          ┌────────▼────────┐
                  │  Eth controller  │          │    PHY chip      │
                  │  (in the MCU/SoC) │◄─MII/────►│  (external IC     │
                  │                  │  RGMII    │   or IP block)     │
                  └──────────────────┘          └───────┬──────────┘
                                                          │ MDIO
                                                  (control bus between
                                                   Eth and EthTrcv,
                                                   not pictured —
                                                   see the hardware post)

EthIf forms the unifying layer above both: it knows Eth and EthTrcv alike, consolidates their states into one consistent picture ("is the channel operational?"), and offers a single, hardware-independent API to the modules above it — chiefly TcpIp via SoAd. Without EthIf, every higher module would have to know exactly which concrete Eth and EthTrcv driver is fitted in the ECU — precisely what the AUTOSAR layered architecture is meant to prevent.

A handy mnemonic: Eth takes care of the bits in the frame, EthTrcv takes care of the bits on the wire. Both need each other, but neither module can take over the other’s job.

Distinction: Eth vs. EthTrcv vs. EthIf — Who Does What?

In practice, confusing these three modules is one of the most common stumbling blocks for newcomers. The table below compares their responsibilities, typical API calls, and the direction each one faces.

ModuleResponsibilityTypical tasksFaces

Eth (Ethernet Driver)

Driving the MAC controller inside the microcontroller

Send/receive frames, manage descriptor rings, handle interrupts, maintain statistics counters

"Inward" — toward the MAC hardware in the SoC

EthTrcv (Ethernet Transceiver Driver)

Driving the PHY chip over MDIO

Initialize the PHY, poll link status, switch modes (active/sleep), detect WakeUp

"Outward" — toward the PHY chip and the cable

EthIf (Ethernet Interface)

Unifying Eth and EthTrcv for the layers above

Consolidate states, map controller indices to driver instances, forward the TX/RX API

"Upward" — toward TcpIp/SoAd and other BSW modules

PHY chip (hardware, not an AUTOSAR module)

Physical signal conversion

Line coding, auto-negotiation, signal conditioning

Pure hardware — addressed by EthTrcv via MDIO

A concrete example makes the difference tangible: when an ECU wakes up from sleep because a WakeUp pulse appears on the Ethernet line, it is EthTrcv that detects this condition via EthTrcv_CheckWakeup and reports it upward. Eth has nothing to do with this event — at that point the MAC controller is often not even initialized yet. Conversely, when a frame with a corrupted checksum gets dropped, that is exclusively Eth’s business — `EthTrcv never sees it, since it only reaches up to Layer 1.

EthTrcv and Eth are deliberately modeled in AUTOSAR as separate modules with separate configuration containers, even when an SoC vendor integrates both functions (MAC + PHY) into a single chip. The ARXML defines EthTrcvConfigSet and EthConfigSet as independent structures — even when the real MAC and the real PHY physically live on the same piece of silicon.

Typical PHY Chips in Practice

Automotive Ethernet PHYs differ significantly from consumer PHYs (the kind fitted in routers or PCs). They must meet extended temperature ranges (typically −40 °C to +125 °C or +150 °C depending on grade), AEC-Q100 qualification, and vehicle EMC requirements — and they almost exclusively speak single-pair standards, because every extra wire pair in the harness means added weight and cost.

100BASE-T1

Today’s most widespread automotive Ethernet standard (originally developed by Broadcom under the name "OABR" / BroadR-Reach, standardized as IEEE 802.3bw since 2015). 100 Mbit/s over a single twisted pair, bidirectional via echo cancellation in the PHY. Signal coding details (PAM3) and the exact PCB-level setup are covered in this series' separate hardware deep dive.

Typical use cases: camera connections, sensors, simple ECUs on the periphery of a zonal or domain controller.

1000BASE-T1

Same basic idea as 100BASE-T1, but at 1 Gbit/s over a single-pair cable (IEEE 802.3bp, standardized in 2016). Higher symbol rate, shorter maximum cable length, but enough bandwidth for backbone links between zonal controllers, domain controllers, and central gateways — exactly where a zonal vehicle architecture needs to aggregate large volumes of data (raw camera feeds, sensor fusion, diagnostic traffic).

Example Chips

Vendor / chipStandardInterface (MAC-side)Note

NXP TJA1100

100BASE-T1

RMII

Widely deployed "classic" in many production vehicles, one of the first 100BASE-T1 PHYs used at high volume

NXP TJA1101

100BASE-T1

RMII

Successor/variant of the TJA1100 with extended diagnostic capabilities

Marvell 88Q2112

1000BASE-T1

RGMII

Common 1000BASE-T1 PHY for backbone and gateway applications

Broadcom BCM89811

1000BASE-T1

RGMII

Alternative for gigabit applications, sometimes paired with an integrated switch portfolio

Marvell 88Q2110 / 88Q2220

100BASE-T1 / multi-gig

RMII / RGMII / SGMII

Product family spanning several speed tiers, depending on variant

The exact PHY chip is rarely "visible" to the EthTrcv driver as its own abstraction level — it is integrated through the vendor-specific EthTrcv driver and its ARXML parametrization (chip variant, MDIO address, register set). Two projects using the same PHY chip can still end up with completely different EthTrcv configurations depending on the MCAL supplier.

The important point for the software side: the concrete chip determines the MDIO register layout inside the driver, but the AUTOSAR API stays identical across all chips. That is the entire point of the abstraction layer — Part 2 of this series shows exactly that API in detail.

Series Overview

This post lays the foundation. The parts that follow build on it and each dig into one aspect in depth:

PartTopic

1 (this post)

Basics & classification — what a transceiver is, where EthTrcv sits in the stack, which PHY chips exist

2 — API & Initialization Sequence

The concrete AUTOSAR function calls, the sequence from EthTrcv_Init to the first link-up, the driver’s state machine

3 — ARXML Configuration

The configuration containers in detail — EthTrcvConfigSet, EthTrcvConnNeg, EthTrcvMgmtInterface, and how they map to real hardware

4 — WakeUp Handling & Diagnostics

WakeUp detection, interplay with EcuM, diagnostic access to PHY registers, typical field failure patterns

For readers who also want to understand what happens at PCB level — the MDIO bus, MAC-side interfaces like RGMII, connectors, EMC — see the separate EthTrcv Hardware Deep Dive, which complements the series thematically but does not replace any of the numbered parts.

Summary

AspectKey takeaway

Ethernet transceiver

PHY chip, covers OSI Layer 1 — line coding, link status, power management

Position in the stack

EthTrcv sits alongside Eth beneath EthIf; both drivers connect to hardware via MDIO / the MII family, but not directly to each other

Eth vs. EthTrcv vs. EthIf

Eth = frames (Layer 2), EthTrcv = wire (Layer 1), EthIf = unification upward

PHY chips in practice

100BASE-T1 (e.g. NXP TJA1100/TJA1101) for peripheral ECUs, 1000BASE-T1 (e.g. Marvell 88Q2112) for backbone links

Next step

Part 2 walks through EthTrcv’s concrete API and initialization sequence

Next in the EthTrcv series: EthTrcv Part 2 — API & Initialization Sequence