English
NoC Silicon IP for RISC-V based chips supporting the TileLink protocol
Techniques for debugging an asymmetric multi-core application: Part 2
By Julien Carreno, Intel Corp.
Mar 11 2007 (11:15 AM), Embedded.com
URL: http://www.embedded.com/showArticle.jhtml?articleID=197800001
In Part 1 in this series, we covered what an asymmetric multi-core application is, and what are the typical problems that can be encountered in such a system. Now that we have an understanding of those issues, we can cover what tools and methodologies available to us to debug systems with these problems.
Analyzing the issue
In an asymmetric multi-core type of scenario, the first step for debugging any issue is to isolate the core at the source of the issue.
With access limited to the main core debug interface (serial port for example), analyzing the secondary core to find a potential issue there can be a difficult endeavor.
To do so, first we must determine the circumstances under which the issue occurred: we must characterize all incoming and outgoing activities on the secondary core, with special emphasis on using specific techniques depending on the type of issue encountered. Keeping in mind that, in most cases, we must not alter the timing in the system, counters in memory are the optimal means of characterizing input/outputs.
In cases where the issue investigated is timing-related, any change to the code like adding counters could completely alter the behavior of the system; hardware counters will typically have a minimal performance impact on the system hence they should be used whenever possible.
Mar 11 2007 (11:15 AM), Embedded.com
URL: http://www.embedded.com/showArticle.jhtml?articleID=197800001
In Part 1 in this series, we covered what an asymmetric multi-core application is, and what are the typical problems that can be encountered in such a system. Now that we have an understanding of those issues, we can cover what tools and methodologies available to us to debug systems with these problems.
Analyzing the issue
In an asymmetric multi-core type of scenario, the first step for debugging any issue is to isolate the core at the source of the issue.
With access limited to the main core debug interface (serial port for example), analyzing the secondary core to find a potential issue there can be a difficult endeavor.
To do so, first we must determine the circumstances under which the issue occurred: we must characterize all incoming and outgoing activities on the secondary core, with special emphasis on using specific techniques depending on the type of issue encountered. Keeping in mind that, in most cases, we must not alter the timing in the system, counters in memory are the optimal means of characterizing input/outputs.
In cases where the issue investigated is timing-related, any change to the code like adding counters could completely alter the behavior of the system; hardware counters will typically have a minimal performance impact on the system hence they should be used whenever possible.
|
E-mail This Article | 
|
|
Printer-Friendly Page |
Related Articles
- Evaluating the performance of multi-core processors - Part 2
- Debugging a Shared Memory Problem in a multi-core design with virtual hardware
- Using sub-RISC processors in next generation customizable multi-core designs: Part 1
- Achieving multicore performance in a single core SoC design using a multi-threaded virtual multiprocessor: Part 2
- Multi-core multi-threaded SoCs pose debugging hurdles
New Articles
Most Popular
- System Verilog Assertions Simplified
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- Synthesis Methodology & Netlist Qualification
- Enhancing VLSI Design Efficiency: Tackling Congestion and Shorts with Practical Approaches and PnR Tool (ICC2)
- Demystifying MIPI C-PHY / DPHY Subsystem