Title: Multi-Core Safety Architectures | ISO 26262 Academy URL: https://iso26262.academy/features/concepts/multi-core-safety Description: How automotive silicon catches its own random hardware faults: lockstep and split-lock cores, safety islands on big SoCs, and hardware and software self-tests. --- Concept guide · ISO 26262-5 + -11 · 12 chapters # 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. 12 Chapters 3 Self-Test Types 99% ASIL D SPFM Target 6 Diagrams Included in Expert [Start learning](https://iso26262.academy/register?plan=free&from=%2Fconcepts%2Fmulti-core-safety&utm_source=website&utm_medium=cta&utm_campaign=features_concepts) See the chapters Inside the course 1. 01 **Why One Core Is Not Safe Enough** 2. 02 **Random Hardware Faults in Silicon** 3. 03 **The Redundancy Toolbox** 4. 04 **Dual-Core Lockstep and Split-Lock** 5. 05 **Beyond Lockstep: Monitored Cores** The short version ## 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. Keep going, free - [Article · 6 min read Multi-Core Safety Architectures: An ISO 26262 Overview](https://iso26262.academy/blog/multi-core-safety-architectures-iso-26262-overview) - [Demo exam · no account Test yourself with 7 exam-style questions](https://iso26262.academy/demo-exam) Why this course · ISO 26262, Part 5 ## 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. After the course ## 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. The curriculum · 10 chapters ## Chapter by chapter 1. 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 2. 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 3. 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 4. 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 5. 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 6. 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 7. 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 8. 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 9. 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. 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 Diagrams & Visuals ## 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. Worked Example ## 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 Shared last-level cache: QM eviction of safety lines mitigated by cache partitioning and locked ways Unlock the full interference matrix with every channel, mitigation, and residual argument Built for ## 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 ISO 26262-5 sets the architectural metric targets: SPFM of at least 99% and LFM of at least 90% for ASIL D, with lower thresholds at ASIL B and C, alongside a PMHF budget for the residual random hardware failure rate. Reaching 99% SPFM effectively mandates redundancy on the compute path - lockstep or an equivalent checker - while LFM is typically lifted by built-in self-tests: SBST software self-tests on the core pipeline, LBIST for logic, and MBIST for on-chip memories at startup and runtime. The course's worked example rolls all three metrics up across a full SoC to confirm the ASIL D targets. Through interference channels: a QM core can evict a safety core's lines from a shared last-level cache, saturate the interconnect, or monopolize the DRAM controller - inflating the safety core's execution time until deadlines break, with no fault ever occurring. The mitigations are architectural: MPU regions blocking QM access to safety memory, cache partitioning or locked ways, and QoS regulators with bandwidth budgets. Critically, WCET must then be re-measured under worst-case contention - WCET blindness is one of the pitfalls the course flags as an argument-killer, alongside unbudgeted shared-resource contention. It builds up across 12 chapters, from why one core is not safe enough, through random fault physics and FIT budgets, the redundancy toolbox, lockstep and split-lock, monitored cores, safety islands, the 3 self-test types (SBST, LBIST, MBIST), shared-resource interference, and the metrics roll-up, ending in a pitfalls checklist. It includes 6 diagrams such as the lockstep datapath and the interference channel map, plus a worked example mapping an ASIL D brake function and QM infotainment onto one lockstep SoC. A free account starts you off, and the Pro and Expert plans unlock more of the library. ## 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. [Start learning](https://iso26262.academy/register?plan=free&from=%2Fconcepts%2Fmulti-core-safety&utm_source=website&utm_medium=cta&utm_campaign=features_concepts) [View Pricing Plans](https://iso26262.academy/pricing)