New trace sources are necessary
The current state-of-the-art technology for comprehensive system analysis and debugging is very clearly on-chip trace, in other words recording of executed machine commands (code trace) and data transfer between the cores, memories as well as the system buses (data trace). The method is now available for most microcontroller architectures; it is widely used for testing and performance measurements and all professional tool manufacturers offer appropriate support.
In order to take full advantage of the theoretical observation possibilities on the running system, in addition, signals of the peripheral units must additionally therefore also be used as a further trace source. It is ultimately these that make a deeper insight into the complex SoC architectures at all possible in the first place. The resulting additional testing and measurement capabilities can be best documented from the example of Infineon’s AURIX™ (AUtomotive Realtime Integrated neXt generation architecture) SoCs.
Signal trace
At present, the current AURIX™ family is undoubtedly one of the most powerful microcontroller systems in its market segment. With the up to three TriCore™ CPUs, optional lockstep mechanism, freely programmable active units for signal generation and processing, integrated tuning protection, powerful peripheral components and memory protection mechanisms — these highly complex automotive SoCs are ideally suited for use in both engine and transmission management with the highest performance and safety needs and in hybrid and electrical vehicles. However, as already mentioned at the beginning, debugging and analysis of such complex, high-performance systems requires completely new approaches regarding debugging support and trace.
The developers at Infineon were also aware of this right from the beginning, but how do you generate trace sources, which enable a comprehensive runtime analysis of the whole system? Well, as every system designer knows, integrated peripheral units such as DMA, CAN or FlexRay controllers have a significant influence on the real-time behavior of an application. Why not then integrate special debug information of such units into the trace stream (hereinafter referred to as signal trace)? Because such a debug tool allows a very detailed insight into the interaction between the main cores and the peripherals, it therefore appears ideally suited for a comprehensive analysis of the system behavior. After generation of several hundred single or multiple bit signals and adding them to the trace stream did not appear to be sufficiently expedient for such a purpose — since this approach would have severely limited the bandwidth of the trace task — the only remaining meaningful approach to a solution was the selective choice of peripheral signals according to the current measurement task or to the error case to be analyzed.
As current implementation, Infineon has expanded the On-Chip Debug System (OCDS) of the AURIX™ devices with a trigger switch (Figure 1).
Figure 1: Trigger switch of the AURIX™ Emulation Devices
This enables the targeted transfer of selected peripheral signals to other components of the debug system. One of these is the Multi-Core Debug Solution (MCDS) — the heart of on-chip trace at Infineon. The trigger switch is connected with several trigger buses, on which the peripheral units can transmit configurable function-specific data packets, so-called trigger sets. These are then recorded in the trace stream. The origin and content of these inserted data packages is not revealed. Only the debug tool, with which the chip was prepared for the pending measurement task, and that thus knows the selected trigger sets and their configuration, can carry out a decoding and visualization of the data packets.
Master the flood of data
So far so good. Unfortunately, additional trace sources also mean a further explosion in the already large amount of data, which is incurred with a multicore system with currently 200 to 300 MHz system clock. It is a big challenge to control this flood of data. So that the output of all available data does not ultimately fail due to the available bandwidth, both to the on-chip trace memory and to an external trace tool — but also, of course, for reasons of the analysis effort — a targeted selection and filtering of these, that will be recorded, is essential. With an enormous amount of data, the detection of errors or performance bottlenecks would otherwise become the proverbial search for a needle in a haystack for the tool and developer.
A comparatively simple selection and filtering of on-chip events for trace recording are made possible by special tools such as the Universal Emulation Configurator (UEC), part of the Universal Debug Engine (UDE) from PLS. It performs the configuration of complex trigger logic and filter logic by using a graphical description, which is based on joined signals and actions, also sequentially via state machines. The flexible concept of the UEC allows seamless combination of the new signal trace with the conventional code trace and data trace. An appropriate measurement task can thus be defined with a single tool, without having to differentiate between the new trigger switch and the MCDS that has already been supported for a long time.
The combination of several trace sources offers particular benefits when the interaction of various function units of the SoC needs to be examined thoroughly. One of the considerably simpler tasks to implement under these circumstances is, for example, measurement of time between reception of a CAN message until setting of an external port pin in response to this. The on-chip trace unit recognizes a specific CAN message, which can be filtered according to source (CAN ID) and type and then starts the trace recording.
Figure 2: Presentation of a trace measurement task in graphical block editor of the Universal Emulation Configurator (UEC)
Writing on a port pin can also be made visible in the trace stream and used as an event for stopping the recording. Figure 2 shows how such a measurement task is defined in the graphical block editor of the Universal Emulation Configurator (UEC). Besides the time measurement, the configuration shown also provides a complete code trace and data trace between the two events. For analysis of recorded data from the various trace sources, these are put together and presented in a combined view (Figure 3).
Figure 3: Time measurement between CAN message received and setting a port pin including complete code trace and data trace. For full resolution click here.
Will signal trace become a standard?
Signal trace not only represents a very interesting enhancement of debug functionality for many automotive applications, but also in the industrial sector. However, the increased effort comes at a price. Therefore, in order to keep additional hardware costs within bounds, Infineon has been successfully providing two different controller versions for many years: So-called Emulation Devices with complete additional on-chip hardware for debugging and trace in the high-end sector previously described as well as Production Devices with reduced basic debug functions, but nonetheless still very powerful compared to the market as a whole. Furthermore, the Multi-Core Debug Solution (MCDS) integrated in the Emulation Devices is so successful that in the meantime, Production Devices are also equipped with a subset (the so-called Mini-MCDS) of it.
As the AURIX™ example shows, the inclusion of the peripherals in the trace recording is definitely a significant step towards better testability of applications on complex multicore SoCs, since they expand system analysis beyond the cores. But, whether signal trace will establish itself, possibly even as a standard, still remains to be seen. In particular, this still requires even more innovative tools such as the Universal Emulation Configurator (UEC), which permit an effective use or the new capabilities and enable tailor-made trace and measurement tasks without any restrictions.
About the author:
Heiko Riessland (Dipl.-Ing.) studied information technology at the Dresden University of Technology (TU Dresden) in Germany. After the successful completion of his studies, he worked for 12 years in the design and sales of software development tools and emulators for 16-bit and 32-bit microcontrollers. For the past eight years, Heiko heads product marketing at PLS Programmierbare Logik & Systeme GmbH in Lauta, Germany.
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
