October 17
30
t
ooLs
& s
oFtwArE
suspend signals via so-called trigger lines to
all cores and also to peripherals. The trigger
switch is configurable that individual cores as
well as peripherals can be stopped and stated
again at the same time and without having an
effect on the others. In addition to that, the
trigger lines can be connected to pins and
make them available to the outside world.
This offers interesting opportunities. For
example, signals can be connected to an oscil-
loscope or a break can be triggered externally.
Of course, besides the AURIX, a number of
other microcontroller architectures exist,
which are used for automotive applications.
Two other examples are the SoCs based on the
ARM Cortex-R architecture and the PowerAr-
chitecture based SPC5 from STMicroelectron-
ics. Both bring along an own implementation
of on-chip run-control support. On the ARM
side, it is called CoreSight. Let’s have a look
at this.
In CoreSight a so called cross-trigger matrix
(CTM) is used in order to propagate break and
go signals across the cores. The cores them-
selves can trigger such signals and respond to
them but not directly. A cross-trigger inter-
face (CTI) attached to each core takes care of
it. Up to four channels in a CTM broadcast
the signals to all attached CTIs. The CTIs can
be configured that way, for either passing the
run-control signals to the core or blocking
them. Thus, simply a core gets halted along
with others or not. Because of hand-shake
mechanisms, which are necessary between
different components, there is a little delay
of several clock cycles. The actual amount of
that delay highly depends on the implementa-
tion. In fact, avoiding it is technically not pos-
sible. One drawback of the ARM solution is
that CoreSight is in fact a set of components
and IP blocks from which silicon vendors can
choose. As a consequence, debug tool vendors
cannot rely on the existence of CTMs and
CTIs in a particular multi-core SoC.
As expected, the PowerArchitecture based
controllers of the SPC5 family support syn-
chronous run-control by means of hardware.
The unit in charge is called DCI (Debug and
Calibration Interface). The advantage com-
pared to the CoreSight is that, as we already
know from the trigger- switch of AURIX,
peripherals are also connected to the debug
signals. That allows halting the complete sys-
tem, not only the cores.
In real life developers don’t want to take care
of all these details. For this reason multi-
core debuggers like the Universal Debug
Engine® (UDE) from PLS make the com-
plex configuration of on-chip debug units
transparent to the users. The integrated
run-control management, for example,
easily allows creating run-control groups
containing all the cores which should be
stopped and started synchronously.
Especially when it comes to debugging and
system analysis of real-time applications,
on-chip trace is mandatory and is available
for almost all high-end microcontrollers like
the AURIX or SPC5. STMicroelectronics for
example implements Nexus class 3 for trac-
ing, for Infineon microcontrollers the on-chip
trace is called MCDS (Multi-Core-Debug
Solution) and for ARM trace hardware blocks
come from the already known CoreSight.
They all have in common that they are able
to capture trace data from different cores in
parallel. Timestamps allow a time correla-
tion between the data of the different trace
sources and thus we can reconstruct the exact
sequence of events. This allows us to detect
deadlocks and race conditions and communi-
cation bottlenecks can be found too.
Now, the most challenging task is transferring
the captured trace data off-chip in order to
analyze them by the debugger. From the cur-
rent trace systems we know two ways to do so.
Either the trace data is buffered in an on-chip
trace memory and transferred via the stan-
dard debug interface, or a high bandwidth
trace interface exists. The first allows a much
higher bandwidth between the trace sources
(CPUs, busses) and the trace sink, namely
the on-chip trace memory. The major draw-
back is the very limited capacity. The later
allows a theoretically unlimited observation
period, but the bandwidth is in fact the limit-
ing parameter. For both cases clever filter and
trigger mechanisms as part of the trace solu-
tions can help. These allow qualifying the cap-
tured trace data while they are created in order
to record only the really necessary data. With
it cross-triggering is also possible. Cross-trig-
gering allows, for example, starting the trace
recording for one core if a specific event arises
at another core. That function is helpful for
debugging of inter-core communication.
Experience has shown that for an effective
use of trace the user needs comprehensive
support by debug tools. That is true not
only for the analysis of the recorded data
but also for the definition of trace tasks and
the configuration of the filters and triggers.
UDE, for example, even provides a graphi-
cal tool for that purpose which allows man-
aging even complex cross-triggers easily.
Several tools help to analyze the recorded
trace: from visualization of parallel exe-
cution of cores, via profiling, to providing
code coverage information.
Figure 4. Multi-core run-control management of UDE
Product News
Green Hills: INTEGRITY-178 tuMP
selected by flight critical system
supplier
Green Hills Software has been selected
by a US supplier of guidance and naviga-
tion equipment for commercial and mili-
tary aircraft to provide its DO-178B Level
A-compliant real-time multicore operating
system for their next generation of equip-
ment based on the Xilinx Zynq Ultrascale+
MPSoC. The Ultrascale+ MPSoC includes
four Cortex-A53 64-bit cores which will
run Green Hills Software’s INTEGRITY-178
Time-Variant Unified Multi Processing
operating system.
