Source-linked AI summary
PEEK: Heterogeneous Parallelism for Privileged Error Detection in Safety-Critical Processors
Tinglue Wang, Zhenghui Guo, Bing Guo, Jiapeng Guan, Renshuang Jiang, Jie Zhang, Jing Li, Xin Si, Sam Ainsworth, Zhe Jiang
TL;DR
Earlier heterogeneous parallel error detection architectures lacked privileged-mode protection for real-world OoO processors. PEEK redesigns the verification pipeline for privileged execution and reports full privileged-mode coverage with negligible performance impact and microsecond-level detection.
Problem
Earlier HPED architectures lacked privileged protection for real-world OoO processors.
Source: §1 · p. 2, §8 · p. 12Method
Results
PEEK achieves full privileged-mode coverage with negligible performance impact, microsecond-level error detection, and minimal hardware overhead.
Source: §8 · p. 12Takeaways & Limitations
PEEK advances HPED from simulation-only research to full-system implementation and silicon tapeout.
Source: §8 · p. 12Software-level trap customization may require hundreds of lines of low-level OS and firmware changes, making it infeasible for closed-source systems.
Source: §3.3 · p. 4
Abstract
from arXiv · showhide
Heterogeneous parallel error detection architecture has been widely studied for safeguarding OoO superscalar processors in safetycritical systems, as it achieves significantly lower hardware overhead compared to traditional LockStep, by exploiting the parallelism that exists in a secondary execution. However, previous works do not cover the protection of privileged-mode execution, impeding their effectiveness in real-world deployment. Moreover, naive extension to privileged-mode can cause a litany of issues, from abysmal performance due to high synchronization costs, to full deadlocks. Here, we present PEEK, the first privileged parallel error detection architecture. Based on a deep analysis of privileged execution, we redesign the verification pipeline, addressing all the bottlenecks and bugs identified in privileged-mode protection. Evaluated using various metrics on an RTL-level full system running Linux, PEEK achieves full-privilege protection on Linux with negligible performance slowdown and affordable hardware overhead. PEEK has been taped out using a 28nm process, and its source is available at https://anonymous.4open.science/r/PEEK-3000.
1 Introduction
Safety-critical OoO processors need error detection that avoids LockStep’s substantial area and power costs, and HPED offers a lower-overhead alternative. Prior HPED work did not protect privileged execution, while naive extensions caused severe slowdowns and deadlocks; PEEK redesigns the verification pipeline for privileged protection.
Motivation
- LockStep duplicates the processor and compares outputs every cycle, providing strong assurance but costing more than twice a single core’s area and power.Those costs become more pronounced as safety-critical systems demand OoO superscalar throughput.Source: §1 · p. 1
Overview
- Two little cores suffice to keep up with the big core in the illustrated PEEK example, whereas prior works [2, 49] require a third.Source: Figure 1 · p. 1
Background
- Prior HPED reduced hardware overhead relative to LockStep, but its evaluations used abstract simulations or minimal prototypes and did not protect privileged execution.The prior reported 1.02× slowdown and 24% area overhead came from syscall-emulation simulations.Source: §1 · p. 1
Challenges
- Naively replaying privileged execution caused severe slowdown and system deadlocks because privileged code interacts with CSRs, asynchronous events, and shared OS locks.Full-context snapshots increase back-pressure, native trap handlers add preamble work, and lock contention can create deadlocks.Source: §1 · p. 2
Contributions
- PEEK is the first privileged HPED architecture, reporting full privilege-mode coverage with 1.02× slowdown and area overheads of 1.8% on the big core and 3.8% on little cores.The design was implemented on FPGA, booted Linux v6.7, and was taped out in a smaller configuration.Source: §1 · p. 2
- PEEK reduces privileged-state replication overhead, uses hardware-assisted privileged replay, and proactively resolves resource contention.The design uses partial snapshots and avoids unnecessary trap preambles.Source: §1 · p. 2
2 Background
Safety-critical systems need timely error detection, but LockStep’s hardware duplication and signal-level comparison are costly for OoO superscalar processors. HPED instead re-executes checkpointed segments asynchronously on smaller cores and checks their state and memory results.
2.1 Detection is Key
- Error detection lets a system transition to a safe state and initiate corrective action before faults escalate into hazardous failures.Safety standards require mitigation within a fault-tolerance time interval on the order of milliseconds.Source: §2.1 · p. 2
- LockStep provides full hardware redundancy, but duplicating OoO cores is prohibitively expensive and cycle-by-cycle pin comparisons complicate physical design and timing closure.Software-based alternatives also face limited fault coverage, limited multithreading support, or substantial performance degradation.Source: §2.1 · p. 2
2.2 Heterogeneous Parallel Error Detection
- HPED divides big-core execution into checkpointed segments, replays them asynchronously on little cores, and checks end state and logged memory against the original execution.Matching segment end and next-start checkpoints provides a proof-by-induction of equivalence.Source: §2.2 · p. 2
- MEEK provides a full-RTL HPED microarchitecture but remains a user-mode prototype, ignoring privileged code and restarting checks on return to user mode.Source: §2.2 · p. 2
3 Motivation
User-only HPED leaves privileged execution unprotected even though it contains safety-related OS functions. Extending verification to privileged mode creates snapshot, replay-overhead, and deadlock challenges that require targeted mechanisms.
3.1 Privileged Gaps Threaten System Safety
- Without privileged-mode protection, HPED misses safety-related kernel functions and falls short of ASIL-C coverage on PARSEC and ASIL-B coverage on nearly all MiBench workloads.The authors conclude user-only HPED can satisfy only ASIL-A, suitable for non-critical functions such as infotainment.Source: §3.1 · p. 3
3.2 Snapshot Explosion Disrupts Verification
- Capturing every CSR alongside architectural registers increases snapshot size 5.4×, and naive full-system protection causes 1.91× geomean slowdown despite privileged execution being only 4.98% of computation time.Over 60% of CSRs are unused in any workload, but accesses vary across instances of the same trap, motivating dynamic selective snapshots.Source: §3.2 · p. 3
3.3 Native Traps Limit Privileged Replay
- Native trap handlers spend over 2,000 cycles per trigger on preambles, which consume 34.6% of little-core execution time per check and peak at 52.9%.Customizing handlers still leaves much of the standard sequence for architectural compliance and can require intrusive OS and firmware changes.Source: §3.3 · p. 4
3.4 Resource Dependency Induces Deadlocks
- Little-core trap handling can deadlock when it needs a shared resource locked by the stalled big core, while the big core waits for LSL space held by the little core.The proposed intervention preempts the little core’s futile spin-wait and switches out the LSL to free space and let checking proceed.Source: §3.4 · p. 4
4 PEEK: At a Glance
PEEK protects privileged execution by selectively extracting and synchronizing state, then replaying checking segments on little cores. Its design also addresses replay overhead, deadlocks, and code that lacks direct redundancy.
4 PEEK: At a Glance
- PEEK uses dynamic snapshots to omit unnecessary CSR bits and synchronization, while a generalized solution handles cross-core deadlocks caused by shared-resource contention.These mechanisms are intended to minimize RCP size and support continuous system operation.Source: §4 · p. 4
- New code that does not run on the big core has no redundant execution and is not directly checked for errors.If an error affects correct execution, it can produce a state mismatch in later checked code.Source: §4 · p. 4
- The big core extracts execution and verification data, processes CSRs, and sends the required data through a forwarding fabric for little-core replication and comparison.Extraction includes on-demand LSQ data, checkpointed PRF data, and CSR data selected by static bit filtering and dynamic access monitoring.Source: Figure 7 · p. 5, §4 · p. 5
- Little cores mirror privileged state in shadow registers and use hardware-assisted context switching to redirect replay directly to each checking segment.The context switching unit manages state and instruction redirection; decoupled memory and CSR channels avoid access conflicts.Source: §4 · p. 5
- A deadlock handler detects and resolves deadlocks; the little-core intervention preempts spin-wait so verification can free the load-store log.The CSU also functions as the deadlock handler.Source: §4 · pp. 5–6, Figure 7 · p. 5
5 The Microarchitecture
PEEK combines CSR classification and selective extraction with little-core state mirroring and hardware-assisted replay. The microarchitecture is implemented on Rocket Chip as a case study for heterogeneous SoCs.
5 The Microarchitecture
- The microarchitecture is built on Rocket Chip with BOOM and Rocket cores, presented as a case study of applicability to heterogeneous SoCs.The passage names ARM big.LITTLE and Intel P- and E-class cores as other examples.Source: §5 · p. 6
5.1 CSR Taxonomy
- CSR handling depends on each register’s role in context establishment and fault observability, distinguishing on-demand extraction from checkpointed state and full replacement from instruction-level simulation.Static identifiers and hardware counters are extracted on demand; trap-related and environmental-control CSRs enter RCPs, with environmental controls fully replaced on little cores.Source: §5.1 · p. 6
5.2 OoO Superscalar Core (The Big Core)
- The big core’s CSR controller tracks dirty registers until all little cores are updated, then filters undefined or fixed-zero bits before forwarding relevant values.The parameterized filter can accommodate processor-specific field definitions; on-demand CSRs are read at retirement and sent through the on-demand path.Source: §5.2 · pp. 6–7
5.3 In-order Scalar Core (The Little Core)
- Little cores use shadow CSRs and a context-switching unit to mirror privileged state and redirect replay to the checking segment’s starting PC.Separate load-store and CSR channels avoid access conflicts; shadow CSR mirroring is reported at 2% area overhead, compared with 15% for copying a complete architectural-register set.Source: §5.3 · pp. 7–8, Figure 9 · p. 7, Figure 8 · p. 7
6 Deadlock Handling
PEEK detects a deadlock when every little core is spin-waiting and the big core stalls because no little core is available. It preempts the waiters to complete pending verification, release the shared resource, and restore normal execution.
6 Deadlock Handling
- Deadlock detection requires both all little cores to be spin-waiting and the big core to be stalled without available little cores.Little-core retired lock-checking loops trigger status flags after a configurable threshold; the big-core scheduling engine makes the final determination to avoid mistaking ordinary lock waits for deadlock.Source: §6 · p. 8
- After detection, the scheduling engine signals the little cores to preempt spin-wait and replay pending checks, freeing the load-store log so the big core can proceed.Once a little core reacquires the contested lock, the CSU restores its context and resumes its original trap handling; the scheduling FSM resets.Source: §6 · pp. 8–9
7 Evaluation
On Linux workloads, PEEK adds privileged protection with low slowdown relative to full-protection and comparison baselines. Fault-injection results report broad divergence detection and short detection latency in the evaluated setup.
7.1 Experimental Setup
- The RTL implementation ran Linux v6.7 on an FPGA-based Rocket Chip system with one BOOM core and four Rocket cores; fault injection sampled internal sites in selected units.Fault campaigns injected 50,000–100,000 random faults per workload into gate-level netlists; target units represented over 80% of BOOM core area excluding branch predictors.Source: §7.1 · p. 9, §7.3 · p. 9
7.2 Performance Slowdown
- 1.016×, 1.026×, and 1.023× geomean slowdown in SPECint, PARSEC, and MiBench, respectively, is below full protection’s 2.02×, 1.96×, and 1.99×.PEEK’s slowdown is slightly above user-only protection and significantly below full protection; the reported comparison uses baseline results normalized to standard LockStep.Source: §7.2 · p. 9
7.3 Detection Capability
- More than 65% of injected faults were exposed through divergence at architectural registers, CSRs, or load/store, while less than 2% caused system crashes before explicit detection.Around 30% were masked by hardware; the authors describe crashes as system-visible and handleable through existing system-level recovery mechanisms.Source: §7.3 · p. 9
- Most detection latencies were concentrated between 1 μs and 2 μs, and PEEK stayed below 4 μs in most cases, covering over 99% of hardware faults.The maximum reported latency in freqmine peaked at 4 μs; the passage compares these results with the millisecond-level FTTI requirement for ASIL-D compliance.Source: §7.3 · p. 9
7.4 Performance-Coverage-Area (PCA)
The section compares PEEK and baselines using a unified performance-coverage-area (PCA) metric, normalized to standard LockStep. PEEK provides the best overall balance, though its lead narrows on workloads with shorter privileged execution.
7.4 Performance-Coverage-Area (PCA)
- The PCA evaluation uses privilege-intensive MiBench to reflect coverage differences and excludes EA-LockStep because its area and fault coverage match PEEK.A PCA comparison with EA-LockStep would therefore reflect only performance differences already evaluated.Source: §7.4 · p. 9
- PEEK’s PCA significantly outperforms other comparators on most MiBench workloads, with a narrow lead only in bitcount and blowfish.The shorter privileged execution times in those two workloads limit PEEK’s coverage benefit.Source: §7.4 · p. 10, Figure 14 · p. 10
- nZDC has the lowest area but the lowest PCA because of its high slowdown.The section defines PCA as IPC × Coverage ÷ Area and normalizes values to standard LockStep.Source: §7.4 · pp. 9–10
7.5 Scalability
PEEK’s slowdown on PARSEC falls as the number of little cores increases. Six little cores bring the geomean slowdown to 1.005×, with every workload below 1.01×.
7.5 Scalability
- The measured slowdown trend on PARSEC improves as PEEK uses more little cores for verification.The authors describe the observed scaling trend as superlinear and say additional little cores can support more complex workloads and larger big cores.Source: §7.5 · pp. 10–11
- 1.005× geomean slowdown with six little cores, with all workloads below 1.01×.With four little cores, geomean slowdown is 1.026×; with two, it is 1.61×.Source: §7.5 · pp. 10–11
7.6 Hardware Overhead
PEEK’s four-Rocket configuration adds area and power over an unsafe baseline, but its overhead remains below LockStep’s. The dynamic CSR snapshot mechanism improves performance by reducing slowdown and shifting the bottleneck toward computation.
7.6 Hardware Overhead
- 27.3% area overhead and 29.4% power overhead versus an unsafe baseline, below LockStep’s more than 100% overhead.The four-Rocket PEEK build adds 1.08mm2 and 124mW; individual components add 1.8% and 3.8% area relative to user-only MEEK, and SCSR/CSU and DEU/CEC integration add 7.29% and 4.38% power overhead, respectively.Source: §7.6 · p. 11
7.7 Improvement of CSR-Specific Snapshot
- The PBF and CRC together deliver a 32.54% performance improvement, with dynamic CRC reducing slowdown and shifting the bottleneck from data forwarding to computation.PBF brings limited optimization because it is static and does not account for runtime CSR characteristics; performance then depends on the little cores’ combined computing power.Source: §7.7 · p. 11
7.8 Little-Core Utilization
PEEK’s hardware-assisted replay raises little-core utilization compared with the OS-native method, allowing four little cores to keep up with the big core. A minimal two-Rocket TinyPEEK tapeout remains smaller and lower-power than LockStep.
7.8 Little-Core Utilization
- Around 60% little-core utilization lets four cores keep up with the big core, versus about 30% with OS-native replay, which would require approximately eight.In PEEK, the remaining 40% goes to state transitions, handling little-core traps, and waiting for verification.Source: §7.8 · p. 11
7.9 TinyPEEK Die
- TinyPEEK, a minimal PEEK configuration with a 2-width BOOM and two Rockets taped out in SMIC 28nm, occupies 48% less area and consumes 42% less power than LockStep.Within TinyPEEK, the two Rockets account for 52% of BOOM area and 58% of BOOM power.Source: §7.9 · p. 11
8 Conclusion
PEEK provides full privileged-mode coverage with negligible performance impact, microsecond-level error detection, and minimal hardware overhead, advancing HPED to full-system implementation and silicon tapeout.
8 Conclusion
- Full privileged-mode coverage comes with negligible performance impact, microsecond-level error detection, and minimal hardware overhead.The implementation also addresses practical physical-design challenges, including clock-domain crossing and timing convergence.Source: §8 · p. 12
- PEEK rethinks the verification pipeline to address slowdown from full-state synchronization, privileged segment replay cost, and deadlock.The design uses a privilege-aware approach to resolve the challenges uncovered during implementation.Source: §8 · p. 12
- PEEK advances HPED from simulation-only research to full-system implementation and silicon tapeout for real-world OoO superscalar processors.Source: §8 · p. 12