October 17
29
t
ooLs
& s
oFtwArE
Those applications which are executing dis-
tributed across several cores and have to
cope with high real-time demands are often
the most challenging for debugging, test and
system analysis. The typically existing large
dependencies between the tasks running on
different cores have a considerable influence
on run-mode debugging or also known as
stop-go debugging. It might be quite dan-
gerous to break a single core while the others
are kept running. In the worst case, the whole
application would end up in chaos or crashes.
Sometimes the other cores and also the
peripherals have to be halted as well in order
that the application does not get into an unde-
fined state. The point is that heterogeneous
cores with different clocking and execution
pipelines do not allow a real synchronous stop.
In practice, we will always have a delay. There
is a complete opposite case; if for instance
another, completely independent application
is running in parallel on the same processor
but using different cores, then it might be
dangerous to halt the complete multi-core
system. These scenarios show the importance
of a flexible, synchronous run-control in a
multi-core debug infrastructure.
A second, not less important aspect is the anal-
ysis of the run-time behavior without influ-
encing it at the same time. This non-intrusive
system observation plays an important role
not only for real-time critical applications but
also for profiling tasks or monitoring commu-
nication between cores. Often it is desirable to
read out the system state from the target by
means of the debugger at a certain point in
time. However, if we halt the application for
that purpose the system behavior would be
fundamentally changed and has nothing to do
anymore with the behavior of the application
running later without an attached debugger.
As a consequence, for an efficient non-intru-
sive system observation trace is indispensable.
Before we take a deeper look into trace fea-
tures we will first come back to aspects dealing
with synchronous run-control. Synchronous
run-control necessarily requires short signal
paths between the cores which can only be
realized by on-chip debug hardware. Signal-
ing of stop and go requests from the outside,
for example from the debug probe via the
debug interface, takes too much time, in par-
ticular for the high clock rates we have nowa-
days. And once the complete system is stopped
finally the states of the individual tasks have
lost their coherence completely.
All silicon vendors provide their own on-chip
debug solution. There is no real standard at all
in that area. Infineon for example is calling its
solution OCDS (on-chip debug support). The
central component of OCDS for run-control
is a trigger switch, which propagates halt and
Figure 1. AURIX multi-core architecture (source: Infineon)
Figure 2. OCDS trigger switch of Infineon AURIX
Figure 3. ARM CoreSight debug and trace infrastructure with cross-triggering
