Independent Reset Circuitry Preserving Trace Data During Functional Resets
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing processing systems face challenges in generating separate reset signals for functional and trace/debug logic, leading to loss of trace data and hindered debugging capabilities during system resets, particularly due to shared reset signals affecting both domains.
Innovation Solution
The implementation of independent reset circuitry that generates separate trace and debug reset signals, allowing trace and debug logic to continue operating during processing system resets, except for power supply-related events, enabling continued data recording and debugging functionality.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Device complexity
If the same reset signal is used for both functional and trace/debug logic, then the system reset is simple to implement, but the trace data is lost and debugging capabilities are hindered during system resets
Solution Approach 1:
The reset signal generation is segmented into two independent paths: one for functional logic and one for trace/debug logic. The reset circuitry generates separate reset signals (reset_functional and reset_debug) from a single reset input, allowing each domain to be reset independently. This segmentation preserves trace data in the debug domain while still performing functional resets when needed.
Solution Approach 2:
The reset circuitry acts as an intermediary between the single reset input and the two separate reset outputs. It mediates the reset signal distribution by conditionally routing the reset signal to either the functional logic, the debug logic, or both, based on control signals. This intermediary function enables selective resetting without direct connection between the reset source and both domains.
2Loss of information
If separate reset signals are generated for functional and trace/debug logic, then trace data is preserved during system resets, but the reset circuitry complexity increases
Solution Approach 1:
The reset circuitry is segmented into distinct functional blocks: a reset generator that creates the base reset signal, control logic that determines routing based on control signals, and separate output paths for functional and debug reset signals. This modular segmentation manages complexity by organizing the circuitry into manageable, independent sections with clear responsibilities.
Solution Approach 2:
The reset circuitry is designed as a universal block that can handle multiple reset scenarios: resetting only functional logic, resetting only debug logic, or resetting both simultaneously. By implementing a single multi-functional reset circuitry that responds to different control signal combinations, the design avoids the need for multiple separate reset generation circuits, thereby managing complexity while providing versatile reset control.
3Ease of operation
If a single reset signal resets both functional and debug logic simultaneously, then the reset operation is simple to control, but debugging operations are halted during system resets
Solution Approach 1:
The reset control is segmented into independent control paths that allow selective resetting. The control circuitry receives the reset input and generates different reset outputs based on control signals, enabling the functional logic to be reset while the debug logic continues operating. This segmentation allows debugging operations to proceed independently of functional resets, maintaining productivity during system resets.
Solution Approach 2:
The reset circuitry implements dynamic control where the routing of the reset signal changes based on control signals. The circuit can adapt its behavior in real-time: when debugging is active, it routes resets away from debug logic; when debugging is inactive, it can reset both domains. This dynamic responsiveness allows the system to maintain debugging operations during resets when needed, while still providing simple simultaneous reset control when debugging is not required.
Data Source
AI summary
In general, trace and debug logic should not be affected by all functional or destructive resets of a processing system. However, certain events, such as power supply related events may be utilized to reset the trace and debug logic since the trace and debug logic may cease correct operation if the provided power supply is insufficient. In addition, it may be beneficial for a debugger to initiate requests to reset trace and debug logic. Further, fault triggers from critical path monitors may be candidates as a source of reset for the trace and debug circuitry. For example, when critical path monitors trigger a fault, the fault may be from the logic associated with either trace and debug logic or the logic which is being debugged or traced. As such, in some instances both trace and debug circuitry and the processing system may be inoperable and may need to be reset.