Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
?
EE Times-Asia > Controls/MCUs
?
?
Controls/MCUs??

Perform efficient debug of multi-core MCUs

Posted: 12 Dec 2012 ?? ?Print Version ?Bookmark and Share

Keywords:multi-core? MCUs? Debug System?

In comparison with single-core based motor controls, the debugger can no longer survive without an appropriate on-chip debug support for multi-core based MCUs, because only then can synchronised run-control or non-intrusive observation of real parallel tasks be realised. From the debug tool perspective, the real challenge is the processing of the high quantity of debug information coming from all cores and its presentation in real-time on the developer's screen in a proper way.

Multi-core systems have been established for a long time in the area of consumer electronics and infotainment. The operating system distributes the individual, independent applications to the particular CPUs, which are typically all alike (homogenous). Depending on the current computing load of the cores, distribution of the application software, which in most cases is not aware of being executed on a multi-core system, is performed dynamically at runtime. This should ensure a high system performance paired with a CPU load that is as balanced as possible.

Multi-core systems in motor controls, on the other hand, are normally far from homogenous. In most cases, only some of the CPUs are designed for universal use and the other cores are intended for special tasks. The new AURIX multi-core controllers from Infineon (figure 1), for example, comprise a total of up to three TriCore CPUs and additionally a special purpose, powerful, programmable time module.

Figure 1: AURIX multi-core architecture for motor control units with four processor cores.

The latter represents the extremely heterogeneous part of the processor. Even the TriCore CPUs are not all identical, that means the TriCore part isn't homogenous as well. They differ not only in computing power and energy consumption but also in their safety features. Two out of the three CPUs are additionally equipped with so called lockstep cores. These execute the same operations on the same data in background as their master cores do. By comparing the results of both the master and the lockstep core, incorrect behaviour in real-life operation, caused by a hardware defect for example, can be detected and immediately corrected.

The challenge for software developers is to distribute the code, grown and matured over years, to the CPUs of the multi-core system. At the same time the correct functionality must still be guaranteed. In addition, when changing to a new computing platform it must always be examined whether boundary values such as latency, response time or energy consumption still comply with the specification. Usually with a new platform new features will also be added, utilising the more powerful computing resources of the multi-core system. However, the higher communication overhead between the CPUs may have a negative effect on the performance.

Changing over to multi-core is therefore not an easy task. The heterogeneity of multi-core controllers requires making the decision which software part has to be executed on which processor core in the development phase. In the end this decision is left to the software engineer, who must very carefully consider when, for example, full computing power is needed and when lower energy consumption is required. The task-to-core assignment is finally done at compile-time and not at run-time as it is for homogeneous multi-core systems.

Challenges when changing over to multi-core MCUs
Experience has shown that most developers will be confronted with one or another of the following issues when changing over from single-core to multi-core MCUs.

Very often in the past, the communication between individual tasks has been realised via global variables located in shared memory. While the tasks, which are alternately executed on the same CPU, always operate with a valid value of such a variable, this can be completely different on a multi-core system with distributed tasks. Core-local caches and write buffers can, under certain circumstances, delay the writing into the shared memory so variables seen from different cores may sometimes become inconsistent. At worst, tasks will proceed with the wrong value.

Figure 2: Deadlock situations are a typical issue when single-core applications are ported to multi-core systems.


1???2???3?Next Page?Last Page



Article Comments - Perform efficient debug of multi-cor...
Comments:??
*? You can enter [0] more charecters.
*Verify code:
?
?
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

?
?
Back to Top