Comparator-Based Split-Lock Cores for Reboot-Free Safety Switching
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing multi-core processors require lengthy reboot and reinitialization processes to switch between split mode and lock mode, leading to increased processor downtime and decreased performance when handling safety-critical and non-safety-critical applications.
Innovation Solution
A multi-core processor architecture that allows dynamic switching between split and lock modes without rebooting by using a comparator to compare inputs from cores, saving data to memory, and configuring memory and comparator to enable lock mode execution, allowing parallel execution of safety-critical applications.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the core is reset and rebooted to switch between split mode and lock mode, then the mode switching is achieved, but the processor downtime increases and performance decreases
Solution Approach 1:
The system dynamically switches between split mode and lock mode by changing the operational state of cores without physical reset. The mode switch is achieved through dynamic reconfiguration of core states, allowing the system to adapt between safety-critical (lock mode) and non-safety-critical (split mode) operations in real-time without interruption.
Solution Approach 2:
The system performs preliminary actions by pre-configuring cores to be capable of operating in both split mode and lock mode. The necessary infrastructure (comparators, memory interfaces, state saving mechanisms) is prepared in advance, enabling rapid mode switching without the need for lengthy reboot sequences.
2Reliability
If the core is reset and rebooted to switch between split mode and lock mode, then the mode switching is achieved, but the overall performance and reliability decrease
Solution Approach 1:
The system maintains high productivity by enabling dynamic mode switching without performance degradation. Cores can transition between split mode (higher performance for non-critical tasks) and lock mode (safety-critical operations) on-the-fly, ensuring that the system meets both performance requirements and safety constraints without reboot penalties.
Solution Approach 2:
Each core is designed to be universal, capable of functioning in both split mode and lock mode. This multi-functionality allows the system to optimize performance for different workloads while maintaining the ability to switch to safety-critical mode when needed, without requiring dedicated hardware for each mode.
3Reliability
If separate processing units are dedicated to safety-critical and non-safety-critical applications, then safety requirements are met, but hardware resources are underutilized
Solution Approach 1:
The system dynamically assigns cores to different operational modes based on workload requirements. Cores can transition from split mode (independent execution for non-critical tasks) to lock mode (synchronized execution for safety-critical tasks), allowing the same hardware resources to serve multiple purposes while maintaining safety compliance when needed.
Solution Approach 2:
Processing cores are designed with universal functionality to handle both safety-critical and non-safety-critical applications. The same core can operate independently for general tasks or in synchronized lock mode for safety-critical operations, maximizing hardware utilization while meeting safety requirements through software-controlled mode switching.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
A multi-core processor comprising a first core, a second core and a comparator. Each core is capable of running both safety-critical and non-safety-critical applications and each core comprises a memory associated to it. The first core is configured to, on initiating a safety-critical application, send a request to the second core to enter into a lock mode to execute the safety-critical application in parallel with the first core. The comparator is configured to receive inputs from the first core and the second core, wherein the comparator compares the input from the first core and the second core. The second core is configured to perform, on receiving the request, the steps of: driving the comparator into a transition state; stopping execution of a first application running on the second core; saving data from of the second core to the memory associated with the second core; and sending an acknowledgment back to the first core in response to the request. The first core, in response to receiving the acknowledgement signal, is further configured to enable the execution of the safety-critical application by both cores in lock mode by configuring the memory and the comparator.