SoC Trace Data Reconstruction via CRC Checksums
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The increasing complexity of System-on-Chip (SoC) devices poses challenges in tracing internal data processing due to high logic density and limited pin-to-feature ratios, requiring a method that provides detailed insights with minimal external pin usage, low overhead, and flexibility in tracing modes without interfering with the system's operation.
Innovation Solution
A method using cyclic redundancy check (CRC) checksums to compress and reconstruct trace data streams, allowing for non-intrusive, low-bandwidth tracing by logging start addresses and checksums for each interval, and employing post-processing to infer the actual execution path, which can adaptively adjust logging intervals based on interrupts and jumps.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Loss of information
If explicit trace commands are inserted in embedded code to provide detailed tracing information, then tracing flexibility and information completeness are improved, but code size increases consuming valuable embedded RAM and execution time is added impacting system timing behavior
Solution Approach 1:
The invention extracts the tracing functionality from the embedded code by implementing a separate hardware trace unit that independently monitors and records execution events. This separation removes trace commands from the code, preventing code size increase and avoiding any impact on execution timing, while still providing comprehensive tracing information through the hardware unit's event capture capabilities.
Solution Approach 2:
The invention introduces a hardware trace unit as an intermediary between the embedded code and the tracing system. This intermediary unit monitors program counters and execution events without being part of the critical execution path, thereby capturing detailed timing information without introducing the delays that would result from inserting software trace commands throughout the code.
2Device complexity
If hardware monitoring is added to automatically generate trace data without adding code, then code size is maintained and switching between trace and non-trace scenarios is simplified, but trace bandwidth requirements increase significantly
Solution Approach 1:
The invention extracts only the essential execution event data (program counter values and event types) from the full trace stream, separating the critical path information from detailed data. This extraction approach maintains low trace bandwidth requirements by transmitting only the minimum necessary information to reconstruct execution flow, while still providing comprehensive tracing capability without increasing code complexity.
3Loss of information
If tracing is implemented to provide detailed insight into internal data processing, then debugging and profiling capabilities are improved, but the number of external pins required increases which is problematic for pin-limited SoC devices
Solution Approach 1:
The invention merges the trace data with instruction fetch operations by capturing program counter values that are already being accessed during normal execution. This merging approach allows tracing of internal data processing using the same bus interfaces already present for instruction fetching, eliminating the need for additional external pins while maintaining detailed visibility into execution flow and internal processing.
4Adaptability or versatility
If trace commands are explicitly programmed into code to provide flexible tracing, then tracing adaptability is improved, but switching between trace and non-trace scenarios requires code recompilation or additional conditional logic
Solution Approach 1:
The invention extracts tracing control from the software domain to the hardware domain, implementing a dedicated trace unit that can be independently enabled or disabled through hardware control registers. This extraction allows tracing to be activated or deactivated without any code modification, compilation, or conditional logic changes, providing full tracing adaptability while maintaining code deployment simplicity. The hardware unit responds to control signals to enable/disable tracing operation without affecting the embedded code.
Data Source
Figure 1~2
Figure 3~4
Figure 5a~5b
AI summary
The invention discloses a method for tracing data in a system on chip with a static structure for evaluating an actual data stream, and an apparatus for post-processing tracing data using the method. The objective to provide a novel approach that can address the ever-increasing complexity of systems-on-chips and which offers the possibility to profile the system and optimizing the processing efficiency of that system is solved by loading an event representation file of a static program code, requesting a trace datagram of a trace group from a trace storage, post-processing the trace datagram by calculating a hypothetic checksum of a potential stream of events of the event representation file, comparing the hypothetic checksum with a checksum of the trace datagram, if the checksums mismatch, backtracking systematically a next event of the stream of events of the event representation file by calculating a new hypothetic checksum and compare it with the checksum of the requested trace datagram, continuing backtracking until they match, if the checksums match, requesting a next trace datagram of the trace group and perform the post-processing of the next trace datagram, continuing until all trace datagrams of the trace group have been checked, whereas the result represents the reconstructed trace of the data stream.