Clocking & Timing for Automotive ECUs (CAN-FD, Ethernet, PLLs)

← Back to: Automotive Electronics Assemblies

This page helps you turn “I just need some clocks” into a clear clocking concept for your ECUs: how to split timing domains, build clock trees, choose oscillators and RTCs, control jitter and EMC, and map everything to real automotive parts and BOM fields.

Role of Clocking & Timing in Automotive ECUs

Clocking and timing have quietly moved from a background utility to a central design concern in modern vehicles. Higher CAN-FD bit rates, Ethernet backbones and tightly coordinated camera and radar sensors all depend on stable, well-synchronized clocks. Timing now affects not only signal integrity but also data freshness and fusion quality.

In traditional powertrain ECUs, most functions relied on local timers and on-chip PLLs. As long as the engine speed, injection timing and ignition windows were correct within a single ECU, small absolute time errors rarely surfaced. Today, the same vehicle may host dozens of networked ECUs that must share a common sense of time.

New gateway and domain controller architectures introduce cross-ECU and cross-domain synchronization. Autonomous driving and ADAS features depend on consistent time-stamping across camera, radar, LiDAR and inertial sensors so that software can line up events and trajectories correctly. Time has effectively become a shared resource inside the vehicle, with explicit accuracy and jitter budgets.

This page focuses on how to plan clock trees and timing architectures for these use cases: when internal PLLs are sufficient, when dedicated automotive clock generators are required, how CAN-FD and Ethernet synchronization drive reference clock requirements, and how to turn timing decisions into concrete BOM fields for sourcing timing ICs.

System-Level Timing Requirements & Timing Domains

System-level timing requirements come from several overlapping domains. Network time is driven by CAN-FD and Ethernet TSN synchronization, where gPTP or similar mechanisms align clocks across ECUs. Compute time is driven by MCU and SoC clocking, DDR interfaces and on-chip buses that need low jitter and deterministic latency.

Sensor and actuator timing covers ADC and DAC sampling, PWM generation, position feedback and drive waveforms. These functions often rely on tightly coupled timers or synchronous sampling across multiple channels. Finally, always-on and RTC domains maintain a long-term sense of time across key-off intervals, supporting logs, billing, telematics and scheduled wake-ups from low-power states.

In many architectures a central gateway or compute node acts as a time master, distributing network time to other ECUs while each ECU still maintains its own local clock tree. Some domains may only need local precision, while others require alignment to a global time within microseconds. Accuracy, precision, jitter, skew and wander form the vocabulary for budgeting these requirements.

Network and compute domains mainly stress jitter and skew budgets, whereas sensor domains emphasize deterministic sampling intervals and phase alignment between channels. The RTC and always-on domain contributes long-term accuracy and drift behaviour. Understanding how these domains interact is the first step in choosing clock sources, PLLs and timing ICs that match the real use cases of your ECUs.

CAN-FD & Ethernet Synchronization in Practice

Designing CAN-FD and automotive Ethernet links always starts with timing. For CAN-FD, bus timing, the sample point position, oscillator accuracy and the overall tolerance budget determine how much margin is left before frame errors appear. For Ethernet links such as 100BASE-T1 and 1000BASE-T1, reference clock quality and PHY jitter directly influence eye diagrams and bit error rates.

At the protocol level, time synchronization mechanisms such as gPTP or related TSN profiles align timestamps across ECUs. In hardware, this is realized as limits on oscillator stability, recovered clock quality and timestamp resolution. Each ECU must balance the precision of its local clock against the correction capability and update interval of the network time synchronization scheme.

There are two broad strategies for building a time-aligned network. One uses a local crystal or oscillator in each ECU and relies on protocol-level synchronization to correct frequency and phase differences over time. The other distributes one or more centralized reference clocks, using PLLs and phase alignment so that key ECUs share a tightly controlled timing source with less drift between them.

When reading CAN-FD and Ethernet standards, note the allowed bit-rate tolerance, sampling windows and time-sync accuracy targets instead of hunting for part numbers. From these, derive oscillator accuracy in ppm, acceptable jitter for PHY reference clocks in tens of picoseconds, and the timing error budget per hop. These values can then be written directly into clock and oscillator requirements in your ECU specifications and BOM.

Automotive Clock Sources: Oscillators, PLLs & Jitter Cleaners

Automotive clock trees are built from a small set of building blocks: crystal or MEMS-based oscillators that provide a stable base frequency, PLL-based clock generators that create multiple rails from a single reference, and jitter cleaners or fan-out buffers that redistribute clean clocks to several devices. Real-time clock oscillators add a low-frequency, always-on time base for logging and wake-up functions.

External crystals or oscillators must maintain their frequency accuracy across -40 to 125 or 150 °C, survive automotive shock and vibration and meet long lifetime requirements. PLL clock generators translate one reference into several domain-specific clocks for SoC cores, DDR, Ethernet PHYs or SerDes, while respecting jitter, phase noise and power-up sequencing constraints specific to the ECU.

Jitter cleaners and fan-out buffers become important when clocks are recovered from networks or high-speed links and need to be reconditioned before driving sensitive PHYs or ADCs. They can filter high-frequency jitter and provide multiple outputs with controlled skew. RTC oscillators, often at 32.768 kHz, focus on ultra-low power and long-term drift instead of very low jitter, so they are optimised and specified differently from high-speed clock sources.

In automotive designs, all of these devices must satisfy AEC-Q qualification, EMC limits and cold-crank behaviour. Gateway and domain controller ECUs frequently combine one high-quality XO with a multi-output clock generator, while many body ECUs rely on a single oscillator feeding the MCU’s internal PLLs. The key is to match the clock source architecture to the timing domains and jitter budgets identified earlier, instead of treating clocking as an afterthought.

Real-Time Clock (RTC) & Always-On Domains

Real-time clock and always-on domains provide the long-term sense of time in an automotive system. They support timestamping events, recording mileage and usage for fleet and billing, keeping diagnostic logs ordered and scheduling wake-up events when the rest of the ECU is powered down. Unlike high-speed clock sources, RTCs focus on calendar time and drift over months and years, not picosecond jitter.

Many simple ECUs rely on an internal RC oscillator for coarse timing, but its accuracy and temperature drift are usually insufficient for long-term logging or billing. A 32.768 kHz crystal or MEMS-based RTC oscillator offers much better stability over -40 to 125 or 150 °C and can be calibrated to reduce long-term error. The trade-off is extra BOM cost, layout care and startup time, which must be weighed against project requirements.

The RTC typically lives in an always-on power domain that remains supplied when the main ECU rails are off. This can be powered by a coin cell, a supercapacitor or a keep-alive rail derived from the vehicle battery. Backup domain current in the nanoamp to microamp range directly sets how long the RTC can retain valid time across parking and storage intervals.

On power-up, the main clock tree ramps, and the MCU or SoC reads the RTC to restore system time if the backup domain remained valid. If the RTC has lost power or drifted beyond limits, the ECU must re-establish time from telematics, backend services or driver input and flag the logs accordingly. When selecting RTC devices, calendar support, alarm count and flexibility, I²C/SPI interfaces, operating and backup voltage ranges, current consumption and AEC-Q qualification are all key parameters that should be written explicitly into the ECU specification and BOM.

Designing Clock Trees for Different ECU Types

Once timing domains are understood, clock trees must be tailored to the type of ECU. Gateways and central compute nodes concentrate network traffic and often act as time masters, so they need structured clock distribution for SoC cores, DDR, TSN Ethernet PHYs and high-speed links. ADAS domain controllers combine heavy compute with high-bandwidth sensor interfaces, which pushes clock tree design toward low jitter and flexible expansion.

Infotainment head units mix application processors, memory, display timing, audio clocks and connectivity modules. Their clock trees must balance signal integrity with EMC and mechanical constraints while leaving room for future screen or interface upgrades. In contrast, body control modules and other simple ECUs typically use a single oscillator feeding an MCU PLL, meeting CAN-FD timing and local control needs without the complexity of a full clock generator.

For each ECU type, it is useful to list the required clock domains: CPU and SoC cores, DDR and memory interfaces, high-speed serial links such as PCIe and SerDes, CAN-FD and Ethernet PHY domains, low-speed peripherals and the RTC or always-on domain. From there, designers can decide how many frequencies must be generated externally, how much can rely on internal PLLs and how many spare outputs should be reserved for later variants.

Gateways, ADAS controllers and head units are strong candidates for a unified clock generator architecture: one high-quality oscillator feeding a multi-output PLL tree. Simple body and comfort ECUs can often remain on a “one XO plus MCU PLL” scheme. Many real projects end up with a hybrid approach where critical high-speed and timing-sensitive domains share a common clock generator, while less critical subsystems use local oscillators for cost and layout simplicity.

Jitter, Phase Noise, Skew & EMC Considerations

Clock quality matters most where it shows up as visible errors. In CAN-FD networks, jitter and phase noise reduce the effective sampling window and eat into the tolerance budget, so frames may need to retransmit more often under worst-case temperature and voltage conditions. In Ethernet links, reference clock jitter and phase noise shrink the eye diagram margin and increase bit error rates at the PHY.

High-speed SerDes links such as GMSL and FPD-Link are particularly sensitive to deterministic jitter, which reduces timing margin and can lead to visible camera artifacts, dropped frames or link re-training. For multi-channel ADCs and DACs, skew and trace length mismatch between channels translate directly into phase errors between signals and distortion in reconstructed waveforms or sensor fusion results.

Display systems that stitch multiple panels or drive complex timing also rely on controlled skew and jitter. Row and column sync signals must stay aligned across cables and boards, otherwise tearing and intermittent jumps become visible to the driver. In all of these cases, the relevant jitter and skew numbers are not abstract: they tie back to link margin, eye openings and system-level performance.

From an EMC perspective, faster clock edges tend to increase radiated and conducted emissions, but simply slowing edges can break timing budgets and worsen jitter. Spread-spectrum techniques can reduce EMI peaks but introduce additional deterministic jitter that must be considered for sensitive PHYs and SerDes links. Layout filters and EMI measures therefore need to be coordinated with clock tree design, while the detailed filter and shield strategy remains with the dedicated EMC and EMI subsystem.

Functional Safety, Diagnostics & Redundancy Hooks

In safety-related ECUs, clock sources are not just convenience components: a faulty oscillator or PLL can cause otherwise healthy software to misbehave. Safety standards treat clocks as safety-related hardware elements whose failures must be detected, contained and reported. Undetected clock faults can create bad-but-valid outputs that are more dangerous than a clean shutdown.

At minimum, safety architectures should include mechanisms to detect missing clocks, out-of-range frequencies and loss of PLL lock. Frequency window monitors and missing-clock detectors help identify crystals that have stopped oscillating or drifted far beyond their specified ppm range. PLL lock status flags provide the SoC or safety microcontroller with a simple indication that the internal phase alignment is no longer guaranteed.

Redundancy is often implemented by pairing an external crystal with an internal RC oscillator or by providing two clock paths, such as a primary PLL and a backup oscillator chain. On fault detection, the safety logic can switch to the backup clock and enter a degraded or limp-home mode while still keeping essential functions alive. Watchdog timers, ECC on memories and controlled reset paths complete the response, ensuring that clock faults do not leave the system in an undefined state.

Diagnostic hooks must be visible both locally and to higher-level diagnostic systems. Clock monitors and PLLs should expose lock and fault status via pins or registers to the MCU or safety controller. Clock-related errors, aging indicators and failover events should be logged as diagnostic trouble codes with timestamps so that fleet and service tools can spot patterns over time. Redundant clocking, clear status reporting and well-defined fault reactions together form the basis of a clocking concept that can be integrated into the overall functional safety and FMEDA process.

Vendor & IC Type Mapping (7 Key Suppliers & IC Types)

This section gives engineers and procurement teams a map of where to look for clocking and timing devices, rather than a list of specific part numbers. The goal is to connect the clocking roles described on this page with the main automotive product lines offered by the major vendors, so that shortlists can be built efficiently.

Clocking and Timing IC Types

Clocking devices can be grouped into a few functional categories. Each category maps to dedicated automotive product lines at the major vendors.

• AEC-Q graded oscillators and MEMS oscillators – Primary frequency sources for 25 MHz, 40 MHz and other reference clocks, plus 32.768 kHz timekeeping oscillators. These devices must offer automotive temperature ranges, startup guarantees and long-term frequency stability.
• AEC-Q clock generators, PLLs, jitter cleaners and fan-out buffers – Multi-output clock devices that take one reference and generate several frequencies for SoC cores, DDR, Ethernet PHYs, SerDes and other timing domains. Jitter cleaners and fan-out buffers recondition and distribute clocks to sensitive links.
• RTC ICs and PMICs with integrated RTC – Dedicated real-time clock devices or power-management ICs that embed RTC blocks. They provide calendar time, alarms and backup supply handling for always-on domains.
• System basis chips (SBCs) with watchdog and clock features – SBC families that integrate watchdog functions, voltage regulators and basic timing resources such as low-accuracy oscillators for safety supervision. Detailed power and SBC selection is handled on the Power / SBC pages.

Roles of the Seven Major Vendors

The following overview does not list specific device numbers. Instead, it highlights how each vendor positions its automotive clocking and timing product lines so that you know which catalog sections to search.

• TI – Automotive clock generator, jitter cleaner and timing solution families for high-speed interfaces, including reference clocking for Ethernet PHYs, SerDes and PCIe. Often used in gateways, ADAS domain controllers and infotainment head units where multiple low-jitter outputs are required.
• ST, NXP, Renesas – Broad portfolios of automotive MCUs and SoCs with integrated PLLs and RTC blocks, plus system basis chips that combine regulators, watchdogs and basic clocking. Clock resources are frequently bundled inside MCU, SoC and SBC product lines rather than sold only as standalone timing ICs.
• onsemi, Microchip, Melexis – Mixed-signal and sensor-focused vendors with automotive-grade oscillators, clock generators, RTCs and timing functions integrated into power, interface and sensor front-end devices. These are good sources for general-purpose oscillators and clock devices as well as sensor-related timing solutions.

If your system has a separate “Clock & Timing Solutions” overview page, this section should link to it as the global catalog. Otherwise, treat this mapping as a local map for the Clocking & Timing topic and rely on the individual ECU and application pages for more specific guidance.

BOM & Procurement Checklist

Before approaching suppliers or building RFQ templates, it is helpful to collect all clocking requirements into a structured checklist. The fields below can be translated directly into BOM columns or inquiry paragraphs so that vendors understand the intended use cases and performance targets without guessing.

Clock Generator and PLL Requirements

• Input reference frequency – Nominal reference frequency (for example 25 MHz or 40 MHz) and whether it comes from a separate oscillator, crystal or upstream clock source.
• Output frequencies and channel count – List of required output frequencies and how many channels are needed for each domain (SoC core and bus, DDR / LPDDR, Ethernet or TSN PHYs, SerDes or PCIe, display links, peripheral domains).
• Jitter budget per output – Target RMS or phase jitter limits for each domain, especially for SerDes and PHY reference clocks. These values should align with link margin and eye diagram assumptions.
• Phase noise expectations – Qualitative or quantitative limits where relevant, such as phase noise masks for RF-sensitive links or low phase noise requirements for high-speed converters.
• Configuration and control interface – Whether the device is configured by I²C, SPI or pin-straps, and the need for programmable profiles or one-time factory configuration.
• Startup and lock time – Maximum allowed time from power-on or enable to valid clocks, including PLL lock, to meet ECU boot and diagnostic timing requirements.
• Spread-spectrum options – Whether spread-spectrum clocking is required or must be optional, and in which domains it may be enabled without violating timing budgets.
• Supply voltage and power consumption – Operating voltage range, typical and worst-case power consumption and any sequencing constraints relevant for the ECU power tree.
• Package and layout constraints – Preferred package types, pinout restrictions and any mechanical limits for placement near sensitive analog or RF blocks.
• AEC-Q grade and temperature range – Required AEC-Q qualification level and operating temperature range to match the ECU’s environmental class.

Oscillator, Crystal and MEMS Requirements

• Frequency – Target frequency for each oscillator or crystal, including main reference clocks and low-frequency timekeeping oscillators.
• Initial accuracy – Allowed initial frequency tolerance at 25 °C, typically expressed in ppm.
• Temperature stability – Maximum frequency drift over the required temperature range (for example -40…125 or -40…150 °C).
• Aging – Expected frequency drift per year and over the ECU lifetime, used to plan long-term accuracy for RTCs and reference clocks.
• Load capacitance and drive level – Required load capacitance for crystals and drive strength limits to ensure reliable oscillation with the selected MCU, SoC or PLL inputs.
• Startup time – Time for oscillation to stabilize, particularly under cold-crank and low-voltage conditions.
• Mechanical robustness – Shock and vibration capabilities and automotive qualification where relevant to the mounting location.
• Crystal or MEMS preference – Any preference or restriction between quartz and MEMS oscillators, for example due to mechanical stress, EMI or lifecycle considerations.

RTC Requirements

• Backup supply voltage range – Allowed voltage range and type of backup source (coin cell, supercap or always-on rail) for the RTC domain.
• Backup domain current – Typical and maximum current consumption in backup mode, which determines how long time can be kept across parking and storage intervals.
• Main operating voltage range – Supply range when the ECU is powered and the RTC is accessed from the host.
• Calendar and timekeeping features – Whether the RTC provides full calendar support (year, month, day, weekday) or only counters, and how leap years and daylight saving time are handled.
• Number and type of alarms – Count of alarm channels and whether they support one-shot or periodic wake-up, and with what resolution (seconds, minutes).
• Timekeeping accuracy and calibration – Expected accuracy over temperature and lifetime, and the availability of factory trim or software calibration mechanisms.
• Digital interface – I²C or SPI interface requirements, address constraints and timing parameters.
• AEC-Q grade and temperature range – Required qualification level and operating temperature range for the RTC device or PMIC with integrated RTC.

System-Level Timing Specification

• Time master definition – Identification of the ECU or module that acts as the time master for the vehicle or a given domain (for example gateway, ADAS domain controller or telematics unit).
• Allowed network time error – Target synchronization accuracy across the network, such as permitted time error in microseconds over a given number of hops.
• CAN-FD timing summary – Planned nominal and data phase bit-rates, target sample point position and the overall tolerance budget that clocks and layout must respect.
• Ethernet and TSN timing summary – Required precision for time-sensitive networking, including the expected gPTP or TSN time accuracy and which ports or ECUs must participate.
• High-speed link jitter assumptions – Design assumptions for reference clock jitter on SerDes, camera, display and other high-speed links, expressed in the same metrics that will be used to select clock generators and jitter cleaners.

These fields can be reused directly in BOM tables, RFQ forms and inquiry emails. By stating the clock generator, oscillator, RTC and system-level timing requirements explicitly, you reduce ambiguity, focus supplier responses on suitable automotive product lines and shorten iteration cycles on clocking and timing design.

Recommended topics you might also need

• In-Vehicle Networking (IVN)
• ADAS Domain Controller
• Infotainment Head Unit

FAQs – Clocking & Timing in Automotive ECUs

These twelve questions collect the real decisions you face when planning automotive clocking and timing: when to move from MCU PLLs to dedicated clock ICs, how precise your oscillators must be, how to handle TSN and safety, and what to tell suppliers so they can quote suitable automotive-grade devices.