Multi-core: A new challenge for debugging
(10/14/2008 9:59 AM EDT)
A customer story
In a huge software project for an embedded application, a function behaved in a strange fashion. A variable, which must not be changed while the function is executed, was changed. The function itself did not write the variable, but rather an illegal write was caused from an-other process, an interrupt service routine or the DMA controller. To identify the culprit the source code of the function was instrumented by a costly monitoring approach. Monitor code was inserted every few lines and near branches to find the point of time the variable was overwritten. In addition, the actual challenge was to check all system activities at or right be-fore the illegal write access to find the writing process. Not a trivial task in a complex system of several cores, busses and bus masters etc. It took one week to identify the problem -- an incorrectly configured DMA controller. Other company projects based on a different hard-ware platform make use of an on-chip multi-core debug system to provide visibility to cores and bus transactions. "If we had a hardware debug system available for our project the prob-lem would have isolated within minutes" the customer told us.
What have we learned from this story? Development of complex systems with powerful hard-ware on one side and ambitious applications on the other side, benefits from on system-spanning on-chip support for debugging. In complex SoCs, just to observe and control a sin-gle core is insufficient. Rather the interactions of multiple cores, busses, and peripherals com-prising the SoC are needed when you want to detect, trace, and eliminate software problems or to profile system behavior for performance optimization.
Before determining an on-chip debug system suitable for multi-core systems , it is important to understand the user requirements.
Must each core and bus must be observable? Being able to see or reconstruct the program flow of each single core independently as well as the data flow on the system busses is critical to drawing conclusions about optimizations, interactions, bus accessing, and performance in other modes of operation.
Is it crucial for system analysis to recognize events that arise from interactions between the cores and busses? Single core operation is often insufficient, with events coming from several cores having to be considered. To address this challenge, cross triggers must be used, which combine events from different sources and make them available system-wide.
E-mail This Article | Printer-Friendly Page |
Related Articles
- Debugging a Shared Memory Problem in a multi-core design with virtual hardware
- Techniques for debugging an asymmetric multi-core application: Part 2
- Multi-core multi-threaded SoCs pose debugging hurdles
- Partitioning to optimize AI inference for multi-core platforms
- Optimizing Communication and Data Sharing in Multi-Core SoC Designs
New Articles
- Quantum Readiness Considerations for Suppliers and Manufacturers
- A Rad Hard ASIC Design Approach: Triple Modular Redundancy (TMR)
- Early Interactive Short Isolation for Faster SoC Verification
- The Ideal Crypto Coprocessor with Root of Trust to Support Customer Complete Full Chip Evaluation: PUFcc gained SESIP and PSA Certified™ Level 3 RoT Component Certification
- Advanced Packaging and Chiplets Can Be for Everyone
Most Popular
- System Verilog Assertions Simplified
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- UPF Constraint coding for SoC - A Case Study
- Dynamic Memory Allocation and Fragmentation in C and C++
- Enhancing VLSI Design Efficiency: Tackling Congestion and Shorts with Practical Approaches and PnR Tool (ICC2)