Channels ▼
RSS

C/C++

Multi-Core Debugging for Atom Processors


Homogeneous and Heterogeneous Multi-Core Environments

Thus far, debugging in a multi-core environment with a multi-core–aware debugger seems fairly straightforward. A heterogeneous multi-core processor, where the individual processor cores differ in terms of ISA, adds another layer of complexity. Some of the processor cores may simply be microengines dedicated to encoding or decoding specific data streams. Other systems, for example a handheld device may house dedicated communication processors for voice and data transmission. These accelerators are then tied to the general purpose processor, which typically coordinates the processing. These complicated heterogeneous multi-core designs are typical of designs based on the Intel Atom processor Z6xx or on the Intel Atom processor CE4100. Figure 2 shows the component processor cores comprising an Intel Atom processor CE4100. For the embedded application level developer the behavior of a debugger on a heterogeneous multi-core system is still very similar to that of an application running on a standalone general purpose processor. The only difference is that there is a defined software API that handles the information exchange with the other processor cores. Its functionality is however implemented on the device driver and system level and thus completely hidden from the application developer. System developers engaging in debugging are not so lucky and need to understand the impact of these other processor cores.

[Click image to view at full size]
Figure 2: Intel Atom processor CE4100.

The first and obvious question for the embedded system developer is what is the initialization or boot sequence of these different cores? Usually, one of the processor cores on the chip is assigned the task to power up first prepares the memory layout for the other processor cores that then power up in a carefully orchestrated sequence. There may be several different JTAG interfaces or debug agents involved for each of the processor cores. This makes debugging considerably more difficult. In addition, if a breakpoint is reached and execution halted on one processor core, this does not imply that the other processor cores will stop at the same time. If there is no breakpoint monitoring and synchronization unit on the chipset that triggers an interrupt for the other processor cores as soon as the first one is halted, these other processor cores may have executed several hundreds of instructions before halting execution. This synchronization issue makes true heterogeneous multi-core debugging complicated.

Furthermore, on these designs the different processor cores tend to have their own execution space and memory. They execute as mostly autonomous systems. There will however, be some shared memory to upload data and runtime code from the general purpose processor core to a secondary processor core. This data or assembly code usually only makes sense as seen from one of these processors. One processor sees it as write-only and the other one as read-only memory.

This complex setup, which by design offers very limited visibility into the data streams exchanged between the different processor cores, makes platform bus signal monitors and debug tools like SVEN (System Visible Event Nexus) desirable. Such a tool can fill in the gaps about how all of the different data streams and platform events are communicated and processed.

A heterogeneous multi-core-aware debugger may be sufficient to cover debugging the main general purpose processor, the data initialization processor, the security processor, and perhaps the communication processor on a handheld device. Hardware-assisted execution control synchronization may enable the debugger to handle breakpoints correctly. The debugger may be able to monitor the shared memory between those processors. However, this is the limit of a debugger. In order to provide a full comprehensive debug view of complex systems with multiple I/O processors and microengines, it is desirable to monitor the data bus and actively debug the data streams or what is termed transactional memory. These concepts are even gaining popularity for homogeneous multi-core systems.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video