STL vs DCLS vs Split-Lock vs Hybrid Mode: Picking the Right Fault-Detection Strategy for Indian Safety Programmes

Editor’s note (2026-05-12): an earlier version of this post described Hybrid Mode as a per-task switchable feature on Cortex-R52+ targeting ASIL-D. That was wrong. Per Arm’s Functional Safety Solutions documentation, Hybrid Mode is positioned on the automotive Cortex-A AE cores Hunter-AE and Hayes-AE, is ASIL-B by default (with a 4-CPU variant reaching ASIL D), and is a steady-state configuration, not a per-task switch. What Cortex-R52 / R52+ provides is Split-Lock, configured statically by a pin under full reset. The post has been restructured around the correct positioning.

For Indian Tier-1 and Tier-2 automotive engineering teams designing ECU firmware on Arm Cortex-R or Cortex-A safety silicon, four fault-detection techniques cover four different parts of the ASIL spectrum: Software Test Library (STL), Dual-Core Lock-Step (DCLS), Split-Lock (Cortex-R52 / R52+), and Hybrid Mode (Hunter-AE / Hayes-AE Cortex-A AE). They are not interchangeable; picking the right one for a given safety integrity level and silicon target is a real decision with cost implications.

This is the decision framework GSAS Micro Systems walks Indian functional-safety architects through when they ask: “we’re targeting ASIL-D, DCLS, Split-Lock, Hybrid Mode, or can STL get us there?”

GSAS is Arm’s authorized partner in India for Arm Development Tools. The advice below is what we share in pre-sales engagements with Indian Tier-1 / Tier-2 automotive customers in Bengaluru, Hyderabad, Chennai, Pune, and Delhi NCR. Note: silicon selection is the SoC team’s call, GSAS provides the toolchain and qualified runtime, not the silicon IP itself.

The four techniques in one paragraph each

Software Test Library (STL)

STL is a software-only fault-detection technique, periodic in-application self-tests of the CPU core, MPU, cache, and on-chip peripherals running as a normal background task on a single core. The application code and the STL share the CPU; the STL runs at boot, periodically during operation, and at shutdown to confirm the silicon is still working as specified. Coverage of permanent faults is good; coverage of transient (single-event) faults is limited because the STL is not running continuously. Arm publishes its own STL portfolio (the Processor Safety Pack and STL Safety Pack), and silicon vendors typically ship vendor-specific STL libraries qualified for their parts. The combination of Arm STL + Processor Safety Pack + STL Safety Pack is positioned by Arm as ASIL-D-capable for the cores it covers, not only as an ASIL-B technique, refer to Arm’s published Functional Safety Solutions material for the specific core/coverage matrix.

Dual-Core Lock-Step (DCLS)

DCLS is a hardware fault-detection technique, two CPU cores execute the same instruction stream in parallel, with hardware-level comparison of every instruction’s outputs. A discrepancy triggers an immediate fault. DCLS catches single-event upsets within nanoseconds of occurrence and provides extremely high diagnostic coverage. The cost is silicon area, power, and per-unit BOM, DCLS effectively doubles the CPU footprint. Cortex-R52 and Cortex-R52+ support DCLS; Cortex-A65AE, A76AE, and A78AE offer DCLS for safety-critical workloads.

Split-Lock (Cortex-R52 / R52+ dual-core configuration)

Split-Lock is the Cortex-R52 / R52+ dual-core configuration option: at full reset, a hardware pin selects whether the two cores run in lock-step (one logical safety core with DCLS protection) or split (two independent cores for performance). The choice is set under full reset and held for the operating session, it is not switched per-task or per-application during normal operation. Many Cortex-R52 ECU designs ship with Split-Lock pin-strapped in lock-step for the safety boot mode and never change it.

Hybrid Mode (Hunter-AE / Hayes-AE Cortex-A AE)

Hybrid Mode is the technique published by Arm for the next-generation automotive Cortex-A AE cores, specifically Hunter-AE and Hayes-AE. The cores are configurable at the cluster level to operate in a mix of lock-step (for safety-critical workloads) and independent (for performance workloads) within one SoC. The headline configuration is ASIL-B (with the DSU-AE Distributed Safety Unit locked while CPUs operate independently); a four-CPU variant reaches ASIL D. Hybrid Mode is steady-state cluster configuration, set during system design, not per-task during execution.

Hybrid Mode is not a Cortex-R52 / R52+ feature; that family uses Split-Lock instead. Older Cortex-A AE cores (A65AE / A78AE) use DCLS without the Hybrid Mode plumbing.

When each one is the right answer

Scenario	Right technique	Why
ASIL-B or QM design, single Cortex-M / R core	STL	Coverage is sufficient for ASIL-B; no silicon-area cost; supplier-supplied qualified library is straightforward to integrate
ASIL-D design, dual Cortex-R52 / R52+ pin-strapped in lock-step	Split-Lock (lock-step at reset)	The Cortex-R52 family’s canonical ASIL-D configuration: two cores in DCLS, set under reset, held for the operating session
ASIL-D design with mixed safety + performance workloads on Cortex-R52 / R52+	Split-Lock in split mode + per-core safety architecture	Both cores run independently; the safety core gets its own STL / monitoring; the performance core handles QM workloads. Different cores, different safety claims.
ASIL-D design, Cortex-A65AE / A78AE in lock-step	DCLS	Established lock-step for application-class automotive AE cores
Mixed ASIL-B safety + QM performance on Hunter-AE / Hayes-AE cluster	Hybrid Mode	Steady-state cluster configuration: safety cores lock-step, performance cores independent. Headline target is ASIL-B; a four-CPU variant reaches ASIL D.
ASIL-D capability with STL portfolio	Arm STL + Processor Safety Pack + STL Safety Pack	Arm explicitly positions this combination as ASIL-D-capable for the cores it covers, refer to Arm’s safety package datasheets for the specific scope.
Legacy ECU upgrade, no silicon change planned	STL	Silicon is fixed; STL is the only available fault-detection technique without a silicon respin

The cost dimension Indian customers care about

Three cost axes the Indian functional-safety architect tracks during the technique decision:

Cost axis	STL	DCLS / Split-Lock	Hybrid Mode
Silicon BOM	No premium	~2× silicon area for safety cores	Premium silicon SKU (Cortex-A AE next-gen)
Power consumption	No premium	~1.5–2× active power on safety cores	Cluster-level: lock-step cores higher power, independent cores normal
Engineering effort	Integrate vendor + Arm STL library	Lower (silicon does the work)	Higher (cluster configuration, mixed-criticality scheduling)
Qualification kit complexity	Standard	Standard	Higher (mixed-mode safety case is newer)
Time-to-certification	Fastest	Standard	Slowest (Hybrid Mode less common in production audits today, next-gen Cortex-A AE silicon is still rolling out)

For Indian Tier-2 ECU programmes shipping volume products today, STL or Split-Lock on Cortex-R52 typically dominates. For premium-vehicle or HPC-platform programmes designing in next-generation automotive Cortex-A AE silicon, Hybrid Mode is on the architecture roadmap.

How the Arm tooling supports each technique

This is where GSAS’s authorized scope kicks in, the Arm tools that make each technique implementable in production firmware:

For STL: Arm STL portfolio + AC6 FuSa + FuSa RTS

The STL library (vendor-supplied or Arm-published) integrates under the AC6 FuSa compiler with the Arm FuSa RTS qualified runtime. The qualification trail flows: STL qualification + Arm compiler+runtime qualification → integrated firmware safety case. Indian Tier-2 ECU teams typically standardise on this stack.

For DCLS / Split-Lock: same toolchain, different silicon

DCLS and Cortex-R52 Split-Lock are silicon-level techniques, the toolchain is the same as STL (AC6 FuSa + FuSa RTS), but the firmware targets a Cortex-R52 / R52+ / A65AE / A76AE / A78AE pin-strapped or designed in lock-step. The qualified compiler and runtime qualify the firmware; the silicon’s lock-step implementation qualifies the hardware fault detection.

For Hybrid Mode: toolchain + cluster-level safety architecture

Hybrid Mode is the most complex case because the safety case must argue about a mixed-mode cluster, not a single CPU. The toolchain still flows through AC6 FuSa + FuSa RTS, but the safety architecture has to demonstrate that the lock-step cores meet their ASIL claim while the independent cores are properly isolated from the safety partition. This work is largely silicon-vendor-driven (using Arm’s Functional Safety Solutions reference patterns for Hunter-AE / Hayes-AE); the Arm Safety Qualification Kit covers the toolchain side.

For Indian customers specifically: this is where GSAS’s pre-sales engineering engagement matters. We walk through your specific silicon target, your safety case structure, and the toolchain-side qualification that fits your application, before procurement closes the loop on the toolchain spend.

ISO 26262 mapping by ASIL

ASIL	Typical fault-detection technique on Arm silicon
QM	None required (quality-managed but not safety-classified)
ASIL-A	Basic monitoring or STL
ASIL-B	STL with vendor-supplied qualified library, or Hybrid Mode (Hunter-AE / Hayes-AE baseline)
ASIL-C	STL with stronger coverage targets, or DCLS / Split-Lock depending on architecture
ASIL-D	DCLS / Split-Lock (single-fault tolerance) or Arm STL + Processor Safety Pack + STL Safety Pack (per Arm’s published positioning) or Hybrid Mode 4-CPU variant (per Arm’s Hunter-AE / Hayes-AE Hybrid Mode documentation)

This is the typical mapping. Specific safety cases can deviate. Most Indian ASIL-D Cortex-R52 programmes today use Split-Lock; the Arm-STL ASIL-D path is gaining traction as the Processor Safety Pack matures.

Five common Indian-customer questions

”Can we mix STL and DCLS / Split-Lock in the same ECU?”

Yes, increasingly common in vehicle-platform compute. The lock-step Cortex-R52 cores run the ASIL-D control loop; secondary Cortex-M / Cortex-R cores running STL handle ASIL-B / ASIL-C peripheral monitoring. The safety case is more complex but the cost-versus-coverage trade-off is usually favourable.

”What about software DCLS: can we get DCLS coverage without dual silicon?”

There are software emulations of DCLS-style coverage (running the same algorithm twice with different code paths and comparing outputs), but the diagnostic coverage is materially weaker than hardware DCLS, particularly for transient faults that affect both software runs identically. Software emulations are not equivalent to hardware DCLS for ASIL-D claims. Treat them as a distinct technique with its own coverage analysis. Arm’s STL + Processor Safety Pack + STL Safety Pack is a different category, a documented Arm-qualified ASIL-D-capable path.

”Does my Cortex-R52 design support Hybrid Mode?”

No, Hybrid Mode is positioned by Arm on the next-generation automotive Cortex-A AE cores (Hunter-AE / Hayes-AE). Cortex-R52 and R52+ provide Split-Lock instead, configured under full reset, not per-application. If the architecture team has been told “Cortex-R52+ adds per-task Hybrid Mode,” that is incorrect; ask Arm or the silicon vendor to clarify before designing the safety architecture around it.

”How long does ASIL-D certification take with each technique?”

The technique itself is not the long pole, the supporting safety case, V&V evidence, and qualification artefacts are. The duration varies considerably by team maturity, in-flight evidence reuse, notified-body throughput, and whether the team has done ASIL-D work before. We do not publish a fixed timetable here; talk to your TÜV / notified-body assessor early and price the safety case for your specific programme.

”When does Hybrid Mode pay off vs running two SoCs?”

The trade-off is a BOM-cost comparison: total cost of two SoCs (including PCB area, power, redundancy interconnect, and lock-step verification overhead) vs the premium of a single Hybrid-Mode-capable Cortex-A AE SoC. Indian Tier-2 programmes with high unit volume tend to favour an integrated cluster once the per-unit BOM saving multiplies out; lower-volume premium-vehicle programmes sometimes accept the two-SoC architecture for the simpler safety-architecture story. Run the BOM math against your specific volume forecast and silicon options, there is no universal threshold.

What to do this quarter

If you are an Indian Tier-1 / Tier-2 functional-safety architect making the technique decision:

1. Confirm your ASIL target for each safety function in the ECU. Different functions in the same ECU can have different ASILs.
2. Confirm your silicon target options. Cortex-R52 / R52+ → Split-Lock. Cortex-A65AE / A76AE / A78AE → DCLS. Hunter-AE / Hayes-AE → Hybrid Mode. STL is available on all of them.
3. Run the cost dimension table on your specific BOM and volume. Engineering effort vs silicon premium vs power budget.
4. Talk to GSAS about the Arm toolchain side: AC6 FuSa, FuSa RTS, Safety Qualification Kit. We don’t sell silicon, but we do sell the qualified compiler + runtime that turn whichever technique you pick into shippable firmware.

Talk to GSAS about your FuSa toolchain selection →

GSAS Micro Systems is Arm’s authorized engineering partner in India for the Arm tools family, across Bengaluru, Hyderabad, Chennai, Pune, Mumbai, Delhi NCR, and Visakhapatnam.