Multi-Core Safety Architectures
10 chapters You start from one vulnerable core and build up to lockstep, split-lock, monitored cores, and safety islands, learning how automotive silicon detects its own random hardware faults and how SPFM, LFM, and PMHF turn that detection into a defensible ASIL D claim.
How You Learn
Video and text stay in sync. As you scroll through the chapter, the video jumps to the matching explanation automatically.
Learning Objectives
Judge when redundancy is required
Read SPFM, LFM, and diagnostic coverage to decide when a single core can never reach the target ASIL.
Compare lockstep, split-lock, and monitored cores
Weigh delayed lockstep, split-lock, and monitored architectures on coverage, silicon area, and performance.
Design a safety island partition
Isolate a safety function on a big SoC and separate it from QM cores, DRAM, and interconnect traffic.
Deploy SBST, LBIST, and MBIST
Place software and hardware self-tests to lift latent-fault metrics for cores and on-chip memories.
Chapters
Why One Core Is Not Safe Enough
Why a single core can never carry an ASIL D function on its own, and how diagnostic coverage sets the ceiling on what one core can claim.
Random Hardware Faults in Silicon
What actually goes wrong inside an SoC: transient upsets and permanent defects, quantified as FIT rates you have to detect and control.
The Redundancy Toolbox
The building blocks of hardware redundancy, from comparators and voters to temporal and spatial diversity, and where each belongs.
Dual-Core Lockstep and Split-Lock
How delayed dual-core lockstep (DCLS) runs two cores in step with a temporal delay and comparator, and when split-lock trades that safety for performance.
Beyond Lockstep: Monitored Cores
Cheaper monitored architectures that use watchdogs and asymmetric checkers instead of doubling every core, and what coverage they can honestly claim.
Safety Islands
How large application SoCs isolate a dedicated safety island to carry the safety function among many QM performance cores.
Core Self-Tests: SBST, LBIST, MBIST
Software and hardware built-in self-tests that boost latent-fault metrics for cores and memories at startup and during runtime.
Shared Resources and Freedom From Interference
How shared caches, buses, DRAM, and memory controllers let a QM core disturb a safety core, and how MPUs and QoS regulators restore freedom from interference.
Putting Numbers On It and Choosing
Aggregating diagnostic coverage into SPFM, LFM, and PMHF, then choosing an architecture that meets the ASIL D targets without over-building.
Pitfalls and Checklist
The mistakes that break a multicore safety argument, from ignored interference to WCET blindness, with a review checklist for any architecture claim.
Diagrams & Visuals
Redundancy Toolbox Comparison
Lays out comparators, voters, and temporal versus spatial redundancy against the ASIL each can support.
Delayed Dual-Core Lockstep Datapath
Shows two cores running with a temporal offset into a comparator that flags any divergence.
Lockstep-to-Split-Lock Mode Machine
Maps the transitions between a locked ASIL D pair and two independent performance cores.
Shared-Resource Interference Channel Map
Traces how a QM core reaches a safety core through shared cache, bus, and DRAM paths.
WCET Inflation Under Contention
Illustrates how execution time stretches when a safety core competes for the interconnect and memory.
Comparator Mismatch Safe-State Reaction
Walks the flow from a lockstep miscompare to the SoC entering its defined safe state.
Mapping an ASIL D Brake Function and QM Infotainment onto One Lockstep SoC
An ASIL D electronic braking function must share a quad-core SoC with a QM infotainment stack, where two cores run in delayed dual-core lockstep and two run QM workloads. The example proves freedom from interference across the shared last-level cache, interconnect, and DRAM controller before the braking function can claim ASIL D.
- ASIL D braking mapped to the delayed lockstep pair, QM infotainment to the free cores
- Comparator on the lockstep pair drives the SoC to safe state on any miscompare
- MPU regions block the QM cores from touching braking code and data memory
- QoS regulators and bandwidth budgets stop the QM cores starving the safety core on DRAM
- WCET of the brake loop re-measured with worst-case cache and interconnect contention
- SPFM, LFM, and PMHF rolled up to confirm the ASIL D targets are met
Freedom-From-Interference Table: Brake ASIL D vs Infotainment QM
Master Multi-Core Safety From Lockstep to the ASIL Claim
Work through the full architecture toolbox, the self-tests, the interference analysis, and a completed worked example that mixes ASIL D and QM on one SoC.
Start Learning Now