Not a hardware design guide, but a comprehension post: what’s actually behind what EthSwt_Init configures? The SWS itself describes three explicit hardware variants for how the switch and PHY interact in chapter 7.1 — a distinction many EthSwt introductions skip, even though it directly affects which drivers (EthTrcv, EthSwt, possibly Spi) even interact with each other in a given project.

Three hardware variants per the SWS

HW variant 1: external PHYs from different vendors
──────────────────────────────────────────────────────────────
  ┌──────────────────────┐
  │      Microcontroller   │
  │  ┌──────────────────┐ │        MII/MDIO       ┌─────────┐
  │  │  Switch (internal)  │◄───────────────────────►│PHY (external)│
  │  └──────────────────┘ │        (per port)       │ Vendor A │
  └──────────────────────┘                          └─────────┘
  The switch is part of the MCU/SoC, PHYs are separate external
  components, possibly from different vendors per port.

HW variant 2: switch with integrated PHYs
──────────────────────────────────────────────────────────────
  ┌────────────────────────────────────────┐
  │              Switch chip                  │
  │   ┌────────────┐  ┌────────────┐         │
  │   │PHY (internal)│  │PHY (internal)│  ...   │
  │   └────────────┘  └────────────┘         │
  └────────────────────────────────────────┘
  All PHYs are part of the switch chip itself — no separate EthTrcv chip
  per port needed.

HW variant 3: MCU controls switch via MDIO/SPI, 3 external PHYs
──────────────────────────────────────────────────────────────
  ┌──────────────────┐   MDIO/SPI    ┌───────────────────────┐
  │   Microcontroller  │◄────────────►│       Switch chip        │
  └──────────────────┘               │   (3 external PHYs       │
                                      │    controllable via MDIO) │
                                      └───┬─────────┬───────┬───┘
                                        MDIO       MDIO    MDIO
                                          │           │       │
                                     ┌────▼───┐  ┌────▼───┐┌──▼─────┐
                                     │  PHY 0  │  │  PHY 1  ││  PHY 2  │
                                     └────────┘  └────────┘└────────┘
  Different EthTrcv drivers per port are possible, since the three PHYs
  could come from different vendors.

The SWS explicitly emphasizes: these three variants are alternative setups, not combination options for the same project. Which variant applies is decided at chip-design time — but the software architecture (EthSwt + n × EthTrcv) stays the same across all three variants, because EthSwt cleanly encapsulates the separation between switch and PHY control.

Practical consequence for the ARXML configuration (see Part 3 of this series): whether EthSwtPortTrcvRef is set or left empty depends exactly on this hardware variant. In variant 2 (integrated PHYs) there’s often no standalone EthTrcv container at all, because PHY access happens entirely inside the switch via EthSwt_ReadTrcvRegister/WriteTrcvRegister.

Access paths to the switch

Per the SWS introduction (chapter 1), access for switch-specific configuration or functions happens via an SPI or MII/MDIO hardware interface, mediated either through the Eth driver or directly through the Spi driver. That’s the hardware basis for the generic register-access APIs (EthSwt_GetSwitchReg/SetSwitchReg), covered in more depth in this series' dedicated SPI and SMI posts.

The forwarding engine (functional, not modeled in AUTOSAR)

A crucial sentence from chapter 7.1 of the SWS that’s easy to miss when writing ARXML: "the functional behavior of the ingress and egress port of a switch is implemented in hardware in the switch devices" — parts of the configuration from chapter 10 therefore have to be written directly to the switch device, rather than being purely represented in the AUTOSAR software stack. Practically, that means a good chunk of the "actual" switch logic (lookup tables, VLAN table, prioritization) lives in silicon, not in the driver’s generated C code — EthSwt configures this hardware logic, but doesn’t implement it itself.

Example chips in practice

Vendor / chipPorts (typical)Notes

NXP SJA1105

5 (4× external + 1 host port)

Widely used automotive switch, SPI- and MII-based configuration, its own management-frame mechanisms (see the corresponding post)

NXP SJA1110

up to 11

Successor family with integrated PHYs (variant 2) and security features

Marvell 88Q5050

8 (4× fixed 100BASE-T1 + 4× configurable)

Secure automotive switch family for zonal architectures, integrated ARM Cortex-M7 management core

Marvell 88Q6113

11

Higher throughput for backbone applications — 2× XFI SerDes at up to 10 Gbit/s per port, integrated L3 hardware acceleration

Summary

AspectKey takeaway

Hardware variants

Three alternative setups per the SWS: external PHYs (1), integrated PHYs (2), MCU-controlled switch with 3 external PHYs (3)

Access paths

SPI or MII/MDIO, mediated via the Eth or Spi driver

Forwarding logic

Lives largely in switch hardware, not in the AUTOSAR driver itself

Next step

The hardware deep-dive post covers the physical interfaces at the PCB level in detail