Multi-Core Safety Architectures
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.
- Chapters
- 12
- Chapters
- Self-Test Types
- 3
- Self-Test Types
- ASIL D SPFM Target
- 99%
- ASIL D SPFM Target
- Diagrams
- 6
- Diagrams
Quick answers
- What is multi-core safety in ISO 26262?
- Multi-core safety covers the architectures and analyses that let multicore silicon detect its own random hardware faults well enough to carry high-ASIL functions. A single core cannot reach ASIL D alone - it has single-point faults with no independent checker, and diagnostic coverage sets the ceiling on its claims. ISO 26262-5 defines the hardware architectural metrics that quantify the answer: for ASIL D, a single-point fault metric (SPFM) of at least 99%, a latent fault metric (LFM) of at least 90%, and a PMHF budget. Architectures such as dual-core lockstep, split-lock, monitored cores, and safety islands exist precisely to reach those numbers, with Part 11 providing semiconductor-specific guidance.
- What is dual-core lockstep and how does split-lock differ?
- Delayed dual-core lockstep (DCLS) runs two identical cores executing the same instruction stream with a small temporal offset, feeding a comparator that flags any divergence - achieving near 100 percent diagnostic coverage of core faults, since a random fault is extremely unlikely to corrupt both cores identically at different times. The cost is silicon: two cores deliver one core's performance. Split-lock architectures make the trade configurable - the pair can run locked for ASIL D work or split into two independent performance cores - and the course maps the mode transitions and what each mode can honestly claim.
Why it pays for itself
From architecture to ASIL claim
Follow the full chain from lockstep, split-lock, monitored cores, and safety islands to the SPFM, LFM, and PMHF roll-up that turns detection hardware into a defensible ASIL D claim.
Right-size the redundancy
Compare delayed lockstep, asymmetric monitoring, and safety islands on diagnostic coverage, silicon area, and performance - so you meet the 99% SPFM ASIL D target without over-building the SoC.
Interference analysis that holds up
Shared caches, buses, and DRAM let a QM core disturb a safety core. Learn the MPU regions, bandwidth budgets, and QoS regulators - and the WCET re-measurement - that close the argument.
What you’ll be able to do
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.
Prove freedom from interference
Use MPU regions, bandwidth budgets, and QoS regulators so a QM core cannot disturb a safety core.
Bound worst-case timing under contention
Estimate WCET with worst-case shared-resource interference so scheduling holds under load.
Chapter by chapter
- 01
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.
- Single-point faults with no independent checker
- SPFM, LFM, and diagnostic coverage as the ceiling
- Why 90 to 99 percent coverage needs redundancy
- 02
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.
- Transient upsets versus permanent silicon defects
- FIT-rate budgets for cores, memory, and logic
- Where ECC catches faults and where it cannot
- 03
The Redundancy Toolbox
The building blocks of hardware redundancy, from comparators and voters to temporal and spatial diversity, and where each belongs.
- Comparators, voters, and majority logic
- Temporal versus spatial redundancy
- Matching a technique to the target ASIL
- 04
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.
- Delayed lockstep with comparator and temporal offset
- Near 100 percent core diagnostic coverage
- Split-lock: ASIL D safety versus performance cores
- 05
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.
- Watchdogs and asymmetric monitoring cores
- Silicon-area cost versus a full lockstep pair
- Coverage limits of monitored approaches
- 06
Safety Islands
How large application SoCs isolate a dedicated safety island to carry the safety function among many QM performance cores.
- A dedicated safety island on a big SoC
- Isolation from QM cores, DRAM, and interconnect
- Where the safety function really lives
- 07
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.
- SBST software self-test on the core pipeline
- LBIST for logic and MBIST for on-chip memory
- How self-tests lift SPFM and LFM
- 08
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.
- Interference channels: shared cache, bus, DRAM
- MPU regions and bandwidth budgeting
- QoS regulators that stop a QM core starving a safety core
- 09
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.
- SPFM at least 99 percent, LFM at least 90 percent for ASIL D
- PMHF and FIT-rate roll-up across the SoC
- Matching architecture to ASIL and performance need
- 10
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.
- Unbudgeted shared-resource contention
- WCET measured without worst-case interference
- A checklist across coverage, timing, and isolation
Not just text: the visual toolkit
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
Unlock the full interference matrix with every channel, mitigation, and residual argument
Who this guide is for
- SoC and ECU architects selecting between lockstep, split-lock, and safety islands
- Hardware safety engineers rolling up SPFM, LFM, and PMHF across a multicore SoC
- Software engineers mapping ASIL and QM workloads onto shared cores
- Anyone whose WCET numbers were measured without worst-case interference
Frequently Asked Questions
Common questions about Multi-Core Safety Architectures
Start the course today
A free account unlocks one full concept guide, 3 work product templates, 1 guided process, the Markov simulator, and 5 practice exams per month. The Pro and Expert plans unlock more of the 78-guide library. No credit card required.