This post builds on the previous post on MDIO access — that one covered how software can read and write registers inside the PHY chip in the first place. This time we use exactly that access path for a single, but timing-critical, feature: timestamping Ethernet frames for IEEE 802.1AS, better known as gPTP (generalized Precision Time Protocol).
Anyone working with Ethernet switches in the vehicle should also know the EthSwt post — gPTP only works if the switches in the network also forward the protocol messages correctly and account for their own residence time in the message.
Why Time Synchronization Matters in the Vehicle Network
A modern vehicle is not a single computer with a few sensors attached — it is a distributed system of dozens of ECUs that must agree on a shared notion of "now." Three examples of why that matters:
ADAS sensor fusion: A radar sensor delivers an object list, a camera delivers bounding boxes, a lidar delivers a point cloud. For fusion to attribute these three data sources to the same physical object, the timestamps from all three sensors need to sit on the same time grid. At 130 km/h a vehicle covers 36 mm per millisecond — a time offset of a few hundred microseconds between two sensors already produces a visible shift in the fusion result.
Audio/Video Bridging (AVB/TSN): When audio is distributed over Ethernet (e.g. for sound systems or hands-free microphones), all endpoints must play back or sample against the same clock — otherwise you get audible clicks or timing drift between speaker channels.
Diagnostic and logging timestamps: Events from different ECUs (fault memory entries, tachograph-relevant events, black-box logs for accident reconstruction) must fit into a shared timeline. Without a synchronized clock there is no way to reconstruct which event happened first.
All three use cases share the same underlying requirement: it is not the absolute accuracy of the clock that matters (that can come from a GNSS source or run free), but the relative synchronicity between the ECUs on the network. |
IEEE 802.1AS (gPTP) Fundamentals
IEEE 802.1AS is a profile of the Precision Time Protocol (PTP, IEEE 1588), tailored for Ethernet-based real-time networks. In automotive it is commonly referred to as gPTP (generalized PTP).
Master/Slave Hierarchy
gPTP builds a tree of time sources. At the root sits the grandmaster,
typically an ECU with a particularly stable clock (a high-quality oscillator,
sometimes disciplined by a GNSS time signal). The Best Master Clock Algorithm
(BMCA) automatically determines which device in the network takes this role,
based on criteria such as clock quality (clockClass, clockAccuracy) and priority.
┌───────────────┐
│ Grandmaster │ (e.g. gateway ECU with GNSS reference)
└───────┬───────┘
│ Sync
┌───────────┴───────────┐
┌─────▼─────┐ ┌─────▼─────┐
│ EthSwt A │ │ EthSwt B │
└─────┬─────┘ └─────┬─────┘
┌─────────┴────────┐ │
┌────▼───┐ ┌────▼───┐ ┌────▼───┐
│ ADAS ECU│ │ Zonal ECU│ │ Audio ECU│
└────────┘ └────────┘ └────────┘Every ECU between the grandmaster and a leaf node is either a pure slave (accepting time), a pure master (propagating time), or — in the case of multi-port switches — both at the same time, on different ports.
Sync and Follow_Up — Distributing the Time
The master periodically distributes its time (typically every 125 ms to 1 s)
using two messages: Sync and Follow_Up.
Master Slave
│ │
│── Sync ──────────────────────────────────────────►│ t2 = ingress timestamp
│ (send time t1 is NOT carried in the Sync │ (hardware-captured)
│ packet itself — "two-step clock") │
│ │
│── Follow_Up ──────────────────────────────────────►│
│ (carries t1 from the egress timestamp │
│ + accumulated correctionField │
│ from every switch traversed) │
│ │
│ Offset = t2 − t1 − link delay − residence timeThe reason for the two-message scheme (two-step clock): the exact send time
t1 is only known after the Sync packet has left the PHY — it can no
longer be written into that same packet in time. So it is delivered
retroactively via the Follow_Up message. (One-step clocks that patch t1
into the outgoing packet on the fly also exist, but are less common in
automotive ECUs than two-step implementations.)
Pdelay — Measuring the Link Delay
Sync/Follow_Up alone is not enough, because there is a cable run with its
own propagation delay between master and slave that must be compensated for.
gPTP measures this peer delay — per physical link, independent of the
master/slave role — with its own message pair:
Requestor Responder
│ │
│── Pdelay_Req ─────────────────────────────────────►│ t2 = ingress timestamp
│ t1 = egress timestamp │ (hardware-captured)
│ (hardware-captured) │
│ │
│◄── Pdelay_Resp ─────────────────────────────────────│ t3 = egress timestamp
│ (carries t2, coarse timing) │ (hardware-captured)
│ │
│◄── Pdelay_Resp_Follow_Up ────────────────────────────│
│ (carries exact t3) │
│ │
│ t4 = ingress timestamp (hardware-captured) │
│ │
│ Link delay = ((t4 − t1) − (t3 − t2)) / 2 │The formula eliminates the unknown clock offset between the two devices,
because it only uses time differences measured on the same local clock
(t4 − t1 on the requestor’s clock, t3 − t2 on the responder’s clock).
Assuming: forward and return paths are symmetric — an assumption that holds
well in practice for 100BASE-T1/1000BASE-T1 (single-pair, bidirectional).
Residence Time and correctionField
When a message crosses several switches (see the tree above), each switch
adds its own dwell time inside the chip (residence time) and the measured
peer delay of the outgoing port into the correctionField of the Follow_Up
message. The slave at the end of the chain thereby receives the sum of all
delays and does not need to know how many hops lay in between.
Every switch in the path must itself be gPTP-capable and measure residence time precisely — otherwise the error accumulates over multiple hops. This is one of the reasons EthSwt chips in the vehicle need their own timestamp hardware, just like EthTrcv PHYs. More on this in the EthSwt post. |
The Role of the PHY in gPTP
This is where the PHY chip comes in — and why this post belongs in the EthTrcv series rather than a pure protocol series.
Why Software Timestamping Is Not Precise Enough
The obvious idea: set the timestamp as soon as the software (interrupt service routine or task) sees the frame. The problem: by that point the frame has already traveled a long, variable path.
Cable → MDI → PMA → PCS → RGMII → MAC FIFO → DMA → interrupt → ISR → task
└──────────────── variable latency ─────────────────────────┘
(100 ns to several tens of microseconds)We already know from the previous hardware post: just the path through PCS and PMA inside the PHY chip costs 150–500 ns — and this value is not constant. It depends on temperature, supply voltage, chip-to-chip variation, and even current traffic on the bus. Add interrupt latency, DMA queuing, and OS scheduling jitter on top of that, and software timestamps quickly end up with 10–100 µs of uncertainty — far too imprecise for gPTP, which targets sub-microsecond accuracy.
Hardware timestamping is not primarily about minimizing delay — a constant offset can easily be calculated out. What matters is the variance (jitter) of that delay. That variance is high for software timestamping and low for hardware timestamping. |
Where in the Signal Path the Timestamp Must Originate
The solution: capture the timestamp as close as possible to the physical signal — inside the PHY chip itself, right at the detection of the Start Frame Delimiter (SFD) on the wire, before PCS decoding, RGMII transfer, and the MAC FIFO introduce additional, variable jitter.
Cable → MDI → [SFD detection + timestamp capture] → PMA → PCS → RGMII → MAC
▲
this is where the timestamp originates — using a local,
high-resolution clock inside the PHY chip (usually PLL-based,
derived from the reference clock)Hardware Timestamping Inside the PHY Chip
Ingress and Egress Timestamp Units
Modern automotive PHYs for 100BASE-T1/1000BASE-T1 integrate two dedicated hardware blocks for this:
┌─────────────────────────────────────────────────────────┐
│ PHY Chip │
│ │
│ MDI ──►[SFD Detect]──►[Ingress Timestamp Unit (ITU)]───┐ │
│ │ │
│ Local time base (free-running │
│ counter, usually ns resolution, │ │
│ fed by the PHY reference clock) │ │
│ │ │
│ MDI ◄──[SFD Insert]◄──[Egress Timestamp Unit (ETU)]────┘ │
│ │
└──────────────────────┬─────────────────────────────────┘
│ MDIO (register access, see MDIO post)
▼
EthTrcv / Eth driverThe Ingress Timestamp Unit (ITU) captures the receive time when the SFD is detected on the wire. The Egress Timestamp Unit (ETU) analogously captures the moment the SFD is actually put onto the wire — not when the software issued the transmit command. Both values are stored in timestamp registers that are read out over MDIO (typically Clause 45, see the previous post).
Chip Examples: NXP TJA1102 and Marvell 88Q2122
| Chip | Interface | Timestamping Characteristics |
|---|---|---|
NXP TJA1102 | Dual 100BASE-T1 | Integrated timestamp unit with typ. ±8 ns resolution, SFD-based capture, timestamps readable via MMD registers (Clause 45), supports IEEE 802.1AS directly in silicon |
Marvell 88Q2122 | 1000BASE-T1 / 100BASE-T1 | Ingress/egress timestamp units with sub-10 ns resolution, configurable interrupt notification on new timestamps, on-chip PTP hardware clock (PHC) |
Both chip families are examples — the specific register addresses and resolution figures vary by silicon revision and must always be checked against the current datasheet. The underlying principle (ITU/ETU close to SFD detection) is essentially identical across all automotive PHYs with gPTP support. |
AUTOSAR StbM & EthTrcv — The Path of the Timestamp
The timestamp now exists as a register value inside the PHY. Before it becomes a synchronized system time that application software can actually use, it passes through several AUTOSAR basic software layers.
From PHY Register to StbM_BusSetGlobalTime
PHY chip (ITU/ETU registers)
│
│ MDIO access (Clause 45, vendor-specific MMD registers)
▼
EthTrcv
│ Vendor API enables/configures the timestamp unit inside the PHY
│ (not part of the standardized AUTOSAR EthTrcv API,
│ but a vendor extension analogous to EthTrcv_VendorSpecific functions)
▼
Eth (Ethernet driver)
│ Eth_GetIngressTimeStamp() / Eth_GetEgressTimeStamp()
│ standardized AUTOSAR interface for reading out the timestamps
▼
EthTSyn (Ethernet Time Synchronization)
│ implements the gPTP protocol itself:
│ sending/receiving Sync/Follow_Up, the Pdelay mechanism,
│ offset and link-delay calculation, BMCA
▼
StbM_BusSetGlobalTime()
│ reports the computed global time to the time-base manager
▼
StbM (Synchronized Time-Base Manager)
│ maintains the synchronized time base, exposes it to other
│ modules via StbM_GetCurrentTime()
▼
Consumers: Dcm (diagnostic timestamps), data logging,
ADAS SWCs (sensor fusion), Com (timestamped signals)Module Responsibilities at a Glance
| Module | Responsibility in the gPTP Context |
|---|---|
EthTrcv | Configures and enables the timestamp hardware inside the PHY via MDIO (vendor extension); fundamentally reports link status, not the timestamps themselves |
Eth | Standardized interface for reading the ingress/egress timestamps
( |
EthTSyn | Implements IEEE 802.1AS: sends/receives Sync, Follow_Up, Pdelay_Req/Resp, evaluates BMCA, computes offset and link delay |
StbM | Manages one or more synchronized time bases, makes them available application-wide through a uniform API |
|
Configuration
Enabling Timestamping on the PHY Side
At the register level (a simplified, chip-typical example over a vendor-specific MMD — see the MDIO post for the Clause 45 fundamentals):
MMD address (DEVAD): 30 (Vendor Specific 1, chip-dependent)
Register: PTP_CONFIG (example address 0x0834)
Bit 0 TS_EN — enable timestamp unit
Bit 1 TS_SFD_MODE — capture at SFD instead of at end of frame
Bit 4 TS_INT_EN — enable interrupt on new timestamp
Register: PTP_STATUS (example address 0x0836)
Bit 0 TS_VALID — new timestamp available
Bit 1 TS_OVERFLOW — timestamp not collected in time
|
StbM Configuration on the AUTOSAR Side
On the AUTOSAR side, the following configuration elements become relevant:
StbMSynchronizedTimeBase
StbMTimeBaseId — unique ID of the time base (e.g. 0 = gPTP domain 0)
StbMOffsetTimeBase — false (global, not locally-relative time base)
StbMEthSyncClient / StbMEthGlobalTimeMaster (depending on role in the network)
StbMSyncFrameTimeout — max. time without a valid Sync message before "not synchronized"
StbMSyncInterval — expected Sync send interval (e.g. 125 ms)
EthTSynGlobalTimeDomain
EthTSynPdelayReqInterval — send interval of Pdelay_Req messages
EthTSynSyncInterval — send interval of Sync messages (master only)
EthTSynPortRole — MASTER_PORT / SLAVE_PORT per Ethernet port
|
Accuracy in Practice
The decisive comparison — what hardware timestamping actually buys you:
| Timestamp Method | Typical Accuracy | Main Source of Uncertainty |
|---|---|---|
Software (task level) | 10–100 µs | OS scheduling, IP stack processing, task priority |
Software (interrupt/ISR level) | 1–10 µs | Interrupt latency, DMA queuing |
MAC timestamping (SoC-integrated, no PHY unit) | 100 ns – 1 µs | Variable PCS/PMA pipeline delay in the PHY (150–500 ns, temperature- and part-dependent) |
Hardware timestamping in the PHY (ITU/ETU at SFD detection) | < 100 ns (often 8–40 ns per datasheet) | Only jitter from the local PLL/reference clock source |
For the use cases introduced at the start, this means concretely: IEEE 802.1AS combined with PHY hardware timestamping achieves end-to-end synchronization accuracy in well-configured automotive networks in the range of a few hundred nanoseconds to low microseconds across multiple hops — sufficient for ADAS sensor fusion and AVB audio streaming. Pure software timestamping, by contrast, is typically one to two orders of magnitude worse and falls short for these use cases.
The accuracy of the overall system is only as good as the weakest link in the chain. A PHY with ±8 ns timestamp resolution does little good if a switch port in between lacks hardware timestamping and only roughly estimates residence time instead of measuring it. |
Summary
| Topic | Key Takeaway for Software Developers |
|---|---|
Why time sync matters | Sensor fusion, AVB, and diagnostic logging all need a shared timeline across multiple ECUs |
gPTP core mechanics | Sync/Follow_Up distributes the time, Pdelay_Req/Resp measures link delay independent of the master/slave role |
PHY’s role | Software timestamping carries too much jitter; hardware timestamping captures the timestamp right at SFD detection on the wire |
AUTOSAR module chain | EthTrcv configures the PHY timestamp hardware, Eth reads it out, EthTSyn implements gPTP, StbM manages the global time base |
Configuration pitfalls |
|
Accuracy | Hardware timestamping delivers < 100 ns instead of > 1 µs — an order of magnitude that genuinely matters for ADAS and AVB |
Next in the EthTrcv series: EthTrcv & Functional Safety — ASIL Requirements and Fault Detection Mechanisms