October 17
28
t
ooLs
& s
oFtwArE
Basics and tools for
multi-core debugging
By Jens Braunes,
PLS
In the past, debugging meant
seeking for variables written
with wrong values. These days,
it’s completely different:
for the multi-core systems used
nowadays in automotive control
units, debugging means managing
deadlocks, resource conflicts or timing
issues of real-time applications.
The paradigm shift and the dramatic
increase of complexity represent a big chal-
lenge for silicon vendors as well as for tool
providers. And they can only master it
together. The reason for this is because
on-chip debug functions integrated by silicon
vendors get fully effective only with powerful
software tools which are able to completely
utilize them and open a door for the develop-
ers for efficient use. If we look at the consumer
market, multi-core systems have become
mainstream since more than 10 years. But in
deeply embedded systems, like motor con-
trol, the technology shift towards multi-core
took place only in recent years and that often
faint-heartedly. One reason is certainly the
high demands on safety, reliability and real-
time, and this has for sure the highest priority
in the whole area of automotive applications.
Another one is due to the existing huge port-
folio of reinforced and well tested software
modules for single-core systems whose port-
ing to multiple heterogeneous cores would
require a significant effort.
If we look at the world of PCs or consumer
electronics dominated by Windows, Linux
or Android operating systems then the CPUs
used are based on homogeneous multi-core
architectures. Identical cores with identical
instruction sets, performance and intercon-
nect to the other on-chip units allow exe-
cuting any OS task or process by any core.
Task creation and core allocation take place
dynamically at run-time in order to balance
the load and optimize the run-time behavior.
In the world of automotive control applica-
tions the multi-core approach is completely
different. In general, tasks have dedicated
processing times and slots, and must guaran-
tee response within a specific time limit. And
the tasks are heterogeneous. They have many
different demands on performance, commu-
nication resources and instruction set features.
For this reason, mostly heterogeneous multi-
core architectures with several different cores,
tailored to the needs of specific tasks are used.
One example of such a microcontroller is
the AURIX from Infineon. This is a complete
device family of multi-core controllers that
are widely used in engine control units nowa-
days. Although the main cores all come from
the TriCore architecture family, they differ in
details. In some AURIX devices different fla-
vors of the core architecture are implemented,
e.g. performance cores (P-cores) and econ-
omy cores (E-cores). Some of the cores fea-
ture additional lockstep cores, enabling them
to fulfill higher safety requirements stipulated
by ISO26262, for example. The lockstep cores
are based on the same core architecture and
execute the same code. The results of both the
actual computational core and the lockstep
core are compared to each other and the reli-
ability of the code execution and calculations
checked permanently. If a deviation arises, the
whole system has to be reset into a save state.
Optimized algorithms for advanced timing
control, as needed for PWMs for electrical
and hybrid drives, or for complex signal pro-
cessing are supported by an additional core
of AURIX, namely the GTM (Generic Timer
Module), an intellectual property (IP) from
Bosch. The GTM is completely different from
the other TriCore-based cores. It has a lot
of units dedicated for signal generation and
processing as well as a number of processing
units which can be programmed in a RISC-
like manner.
The tasks executed by GTM are executed
loosely coupled to the other TriCore tasks
but can communicate using a kind of shared
memory. It is quite obvious that the task
allocation to the different cores is not only
a question of load balancing. It is rather a
question of which core is the most appropri-
ate one for executing the task. That decision
can hardly be made by an operation system
during run-time. As a consequence, it has
to be determined already during the design
phase of the software which core will take
over which task.
