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
- 01Why One Core Is Not Safe Enough
- 02Random Hardware Faults in Silicon
- 03The Redundancy Toolbox
- 04Dual-Core Lockstep and Split-Lock
- 05Beyond Lockstep: Monitored Cores
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 77-guide library. No credit card required.