What’s new at Embedded Systems Conference 2008
Working successfully behind the scenes
Embedded systems have shown rapid development embedded systems industry cannot imagine work in the last 15 years. There was a time when they without TRACE32. Whether in Europe, the USA, were only to be found in complex technical products or Asia, TRACE32 is recognized as the premier that were never used in the average household, but product and the world’s leading brand in micropro- now they are everywhere. The general public may cessor development tools, which is borne out by be unaware of them since they are embedded and some very impressive fi gures: In 2007 alone, over 7000 new workplaces worldwide were equipped with TRACE32! WinCE TRACE32 stands for continuity, but mainly for progress and inventive- UML CFI RTOS SMP ness. One or the other is always in the foreground, depending on the branch of industry. In this coming year, we Auto- Nexus DigRF intend to push ahead strongly in the TRACE32 Focus development of our products and in- vest in solid growth so that you can TI DSP continue to rely on Lauterbach as an Power Saving Combi Probe innovative partner. The past year, 2007, was of course not STM ITM a year of standing still. In this news- letter for 2008, we wish to show you the technological progress we have made during the last year. We would like to work behind the scenes, but we in the “embedded encourage you to try some of these new features community” know that every ordinary member of for your development to improve your effi ciency. society comes into contact with them every day. We will be presenting many of these innovations at Whether in the car, cell phone, MP3 player, home the ESC Silicon Valley, to which, as every year, we cinema, washing machine, or cooker – embedded cordially invite you. systems are in daily use in almost all technical de- vices, using one or more microcontrollers, digital signal processors, and of course their respective Contents software. And we, the “embedded community”, have to make sure that everything works perfectly Hardware debugging in UML 3 and without any fuss. New supported processors 8 TRACE32 – a premium product Debugging with power-saving modes 9 Lauterbach was founded 29 years ago in the pio- neering age of embedded systems. It has managed New debugging concept for SMP 13 to turn the challenges of this market into techno- systems logical and economic success by a mixture of the New preprocessors / NEXUS adapters 17 right know-how and enormous commitment. Just as we can no longer imagine items of daily use CombiProbe 18 without embedded systems, a developer in the
www.lauterbach.com NEWS 2008
DEBUGGER, REAL-TIME TRACE, LOGIC ANALYZER
TRACE32 for Virtual Prototypes
Virtual Prototypes PowerView Today, fast and effi cient software development is CoWare® CoWare ARM often the decisive factor in the launching of new Virtual Platform products. To avoid having to wait for the fi rst hard- ware prototypes at the start of the development PowerDebug Synopsys® Virtual Platform ARM phase, Virtual Prototypes (software models of the (formerly Virtio) XScale hardware) are becoming increasingly common. Virtual Prototype VaST ™ VaST ARM As soon as a is available for the PowerTrace target hardware, work can start on debugging the Virtual System OAK drivers, the operating system, and the application. Prototype PowerPC/eTPU So that we can offer our customers the profes- SH2A PowerProbe sional development environment TRACE32 in this StarCore early phase of their project, Lauterbach has been TeakLite supporting the debugging of software models TriCore/PCP since 2007. The debugging interface used here is Power- V850 the debugging API of the Virtual Prototype. Integrator TRACE32 as GDB front end
GDB front end Other innovations ARM Available In the 2007 Newsletter, Lauterbach announced I386 Available “Integrated run- & stop-mode debugging for em- MIPS32 Available bedded Linux applications”. This year this is fol- lowed by a new concept for debugging SMP Linux PowerPC Available (see page 13). SH4 Planned XScale Available TRACE32 GUI Since early 2007, the TRACE32 GUI can also be used for process debugging with GDB. The sup- Ethernet / RS-232 ported communication interfaces to the target Embedded LINUX hardware are Ethernet or RS-232. t32server Debugging application processes GDB GDB GDB To debug two or more application processes simul- server 1 server 2 server 3 taneously, Lauterbach provides its own debugging agent – t32server, which is started fi rst in the Linux terminal window. Subsequently via the TRACE32 Task Task Task GUI several GDB servers for testing application 1 2 3 processes can be started. The t32server service is then responsible for data exchange between the Fig. 1: The t32server service, enabling simultaneous debugging of TRACE32 GUI and the GDB servers (see Fig. 1). two or more application processes
2 www.lauterbach.com NEWS 2007 NEWS 2008
DEBUGGER, REAL-TIME TRACE, LOGIC ANALYZER
Integration, testing, and debugging of C code together with UML-generated sources PowerView Old C code At the outset, we have a fi nished project in C code. The following example uses a traffi c light system PowerDebug (which is a favorite of software designers due to its simplicity). There is a standard intersection with four sets of traffi c lights. The traffi c lights located opposite each other are controlled in parallel. The PowerTrace traffi c lights at the right angle to them are, of course, controlled complementary. The different traffi c light phases are: red – red and yellow – green – yellow – red. During the red phase of one set of traffi c lights, PowerProbe right of way switches to the opposite direction. As a result, there is a short period when the lights Fig. 2: Adding tram traffi c lights to a traffi c intersection facing in all directions are on red (this is important, Power- as we shall see later). Integrator Introduction This circuit is coded in C as a simple control (switch- It will soon no longer be possible to master the case) in a continuous loop (while (1)). This continu- growing complexity of software without the use of ous loop is found directly in the “main()” routine of CASE tools. UML, especially, has enabled the uni- the application, and is called immediately after ini- form design of modular software components, in- tialization (see Fig. 3). cluding automatic code generation, which prevents common coding errors right from the start. ... However many companies shy away from the per- int main (void) { ceived effort required for the changeover to these horizontal = vertical = red; new techniques. They have a code base that has state = closed_to_h; been built up over decades and although the soft- while (1) ware has been constantly extended and improved. { This has also led to the creation of more and more switch (state) “spaghetti code”. Millions of functioning lines of { case closed_to_h: code would need to be analyzed, re-programmed, wait (1); and fi nally re-tested. horizontal = yellowred; state = yellowred_h; In most cases these fears are unfounded. Existing break; C code can be transferred to a UML model element with almost no changes necessary. Future exten- case yellowred_h: wait (3); sions can then be written as UML models, gener- horizontal = green ated, and integrated with the “old” C code. As a state = green_h; result, an easy and progressive transition from C to break; UML is possible. The following example explains ... these procedures: Fig. 3: Existing C code for traffi c-light control; the “main()” routine 1. Transfer from “old” C code to UML. includes a continuous loop that contains the logic as a switch- case construct. 2. Integration of a new functionality coded in UML. 3. Uniform testing and debugging in UML, C++ New requirements and C. The street planners have decided that a tramline should cross the intersection in both directions 〉〉
www.lauterbach.com 3 NEWS 2008
DEBUGGER, REAL-TIME TRACE, LOGIC ANALYZER
(vertically as well as horizontally, refer to Fig. 2 on main() is already part of the framework and there- page 3). Therefore, the trams must be stopped at fore has to be omitted. Instead, “main()” is renamed PowerView the intersection by their own set of traffi c lights. At “processJunction()”, and this becomes our new the request of the tram driver, the intersection is starting point. The end point of the function will be blocked for cars at the next red light phase, and the the phase when all traffi c lights are on red. Now, if PowerDebug tram is given right of way. required, we can execute additional actions during this red phase (see Fig. 5). – And that’s it. UML wrapper for C code We could, of course, just “patch” these require- UML design for new requirements PowerTrace ments into our C code. But doing so would only Now we can take care of the design for the new make the function larger and more complicated, requirements. We build a class called “Junction”, which is exactly what we want to avoid. So instead which contains the old traffi c light controls, called PowerProbe of this, we will take a modular approach to the “CarJunction”, as well as two new tram traffi c lights problem and solve it with the help of UML. (Fig. 6). The design is now fi nished, and we can Firstly, we need to “trans- focus on the behavior of the extended intersection, Power- fer” the existing appli- using a state transition diagram. Integrator cation over to our UML model, which is easier than it sounds: We create one class, called “Car- Fig. 4: The “CarJunction” Junction”, which contains class, containing the com- the complete “old” appli- plete “old” application cation (see Fig. 4). The only thing that we need to adapt are the corre- sponding interfaces. The usual continuous loop in
void processJunction (void) { horizontal = vertical = red; state = closed_to_h;
do { switch (state) { Fig. 6: The new class, “Junction”, integrating the “old” traffi c-light case closed_to_h: switching and the two new traffi c lights for the tram wait (1); horizontal = yellowred state = yellowred_h; break; The old application is once again used as a starting /*...... */ point, and its whole behavior is incorporated into a case yellow_v: wait (3); single state of the new intersection (state: cars), see vertical = red; Fig. 7 on the opposite page. When the new model state = closed_to_h; break; has this state, it works in exactly the same way as the old application. Only when the new feature – the } // switch (state) tram driver requests right of way – is required, the old } while ((state != closed_to_h) && (state != closed_to_v)); code is left and the new model starts. The phases } // processJunction() and the transition of states for both tramlines are de- fi ned in the state diagram: request – wait – release – Fig. 5: Modifi ed C code that can be integrated in the UML tool wait (possibly a switch between tramlines). This in this form completes our model of the new requirements. 〉〉
4 www.lauterbach.com NEWS 2007 NEWS 2008
DEBUGGER, REAL-TIME TRACE, LOGIC ANALYZER
Code generation tool Rhapsody from Telelogic and the TRACE32 debugger from Lauterbach. This allows you, at the We can now generate the executable application. press of a button in the modeling tool, to load the PowerView For good UML tools this is all that is required for application to the target over the debug interface, generating the fi nished application for the above- and – if required – start it straight away. The com- mentioned model. However, now is the time to plete cycle of design – modeling – generation – run PowerDebug note a few points about integration. Our initial ap- is possible in one GUI. plication is written, and remains, in C. UML tools, however, normally generate C++ code, meaning Testing in C that our “CarJunction” is a wrapper class that ref- PowerTrace erences the C code. Here, the usual adaptations As was mentioned at the start, performing testing between C and C++ must be taken into account. and debugging in a heterogeneous environment pose certain requirements. It must be ensured that Typically, an RTOS is used to manage the model the whole application can be tested in its respec- and must be integrated as required. Once all this PowerProbe tive function and implementation. has been done, a simple press of a button gener- ates a ready-to-run application from the model. Although we are assuming that we already had a functioning application in C, debugging should still Power- Target run be possible. After all, the transfer of new features Integrator to the “old” code needs to be tested, and the old In the fi eld of embedded technology, the target source code maintained. At least for this part of the hardware is often different from the computers application any commercial debugger can be used, used for development. This means that we need to as it is now standard in the fi eld of embedded tech- load the generated application onto the so-called nology to debug C code. “target” and run it there. This can be done using any external tool that can install code on the target. Testing in C++ This is especially easy if the UML tool and the de- The process becomes more interesting when we bugger communicate over a common (software) begin testing the new features at source level. interface, such as the integration between the UML Most UML tools generate C++ code with all the 〉〉
Fig. 7: State diagram of new traffi c-light switching
www.lauterbach.com 5 NEWS 2008
DEBUGGER, REAL-TIME TRACE, LOGIC ANALYZER
characteristics that belong to it, such as templates, bug interface if there is no other interface available. polymorphism, and exception handling. It must be Direct debugging in the UML model is made pos- PowerView remembered that the debugger used must provide sible via “animation”. full support for the C++ dialect of the compiler. The TRACE32 debugger from Lauterbach supports all Integrated UML -> C++ -> C PowerDebug current C++ compilers, and so guarantees com- debugging fortable debugging of object-oriented C++ code. Now we have a situation spread over three levels: Testing in UML UML, C++, and C. When an error is found, espe- PowerTrace cially in C++ code, it is better to repair it in the mod- But of course, we didn’t write our code in C++, but el, and not in the generated C++ code itself. On the rather in UML. And what would make more sense than to carry out PowerProbe debugging on the modeling level? Rhapsody from Telelogic offers sev- eral options to serve this purpose. Power- If the behavior of the application is Integrator completely modeled in UML, the sequence can be simulated directly
Fig 8: The integration of TRACE32 and Rhapsody allows a debugging in UML, C++ and C.
other hand, the debugging of the implementa- tion of a model element is best carried out in the source, without having to search for it. from the model. For simple behavior analysis, the The integration of TRACE32 and Rhapsody offers actual target hardware is not required. As the tar- extensive functionality in order to link these levels get will have a different timing than the simulation, together (Fig. 8), such as the implementation of the application can also be run as an “animation” simple, interdependent navigation. A single mouse on the real target. The UML tool controls and vi- click on a model element in Rhapsody is enough sualizes the target process over a communication to display the corresponding source code in channel (serial or Ethernet). So it is possible to per- TRACE32. This then allows the extensive analysis form single steps through state charts or to induce of variables, function calls, and so on. It also works events. the other way around; with a simple click on a line In combination with a TRACE32 debugger, this of source code in the debugger, the accompany- communication can also take place over the de- ing model element is highlighted in the UML tool. 〉〉
6 www.lauterbach.com NEWS 2007 NEWS 2008
DEBUGGER, REAL-TIME TRACE, LOGIC ANALYZER
This is especially helpful if a problem is found with limits the effort required and allows to import the the debugger, which needs to be repaired in the existing software step by step into a modern and model. A lengthy search and navigation to the innovative CASE tool. PowerView relevant element thus becomes unnecessary. It is, of course, essential that the tools used in this Debugger breakpoints can also be defi ned in the process help and don’t hinder; the selection of the model and the target can be set into Go or Stop correct tools is an important factor. They should PowerDebug status. This enables you to set a breakpoint at a not just be able to perform these tasks, but should class and start the target, all from within the UML also encourage them. tool. The debugger stops the application as soon as Lauterbach and Telelogic have achieved just this the model element under examination is invoked. with the integration of their tools TRACE32 and PowerTrace Rhapsody. Both companies want to help their cus- Summary tomers keep software quality at high levels, despite A complete redesign is not always necessary. increasing complexity and ever more requirements. PowerProbe Particularly for projects where re-engineering is not Now nothing stands in the way of modernizing your possible due to time or organization constraints, a existing code bases with UML. step-by-step approach is often appropriate. This Power- Integrator Latest news in brief
CFI fl ash programming Serial fl ash / NAND fl ash Automatic generation of the fl ash declaration via Since September 2007, TRACE32 has supported the Common Flash Memory Interface – CFI – has the programming of NAND fl ash devices as well been supported since September 2007. as serial fl ash devices with a separate command (FLASHFILE). Code overlays Since December 2007, TRACE32 has support- ed the symbol management for code overlays in ELF fi les with the command sYmbol.OVERLAY. The ARC, ARM, and PowerPC architectures are cur- rently supported. Further architectures are planned for 2008. PCP debugger Since November 2007, a separate TRACE32 in- stance has to be started to debug the Peripheral Control Processor – PCP – of the Infi neon TriCore To program a fl ash, you always had to have detailed processor. This innovation was needed to enable knowledge about the exact type and organization the loading and testing of C code for the PCP. of the device. Thanks to the special query mode of Of course this instance is also used to confi gure CFI-conformant fl ash devices, TRACE32 can now the PCP trace and analyze the trace information. identify the parameters needed for programming The license for the PCP debugging and tracing is and use this data to create a fl ash declaration included in the scope of delivery of the TRACE32 automatically. debugger for TriCore.
www.lauterbach.com 7 NEWS 2008
DEBUGGER, REAL-TIME TRACE, LOGIC ANALYZER
New supported processors
New architectures PowerView PWRfi cient P.A. Semi PWRfi cient™ Q2/2008 The PA6T-1682M dual-core processor will be the fi rst 64-bit PowerPC of the PWRfi cient architecture PowerDebug Renesas H8SX Available supported by a Lauterbach debugger.
Tensilica Xtensa Available TMS320C28xx PowerTrace Processors With the debugger for the TMS320C28xx DSPs, Lauterbach is providing even more support for Texas TMS320™C28xx Available the TMS320 Processor Platform from Texas Instru- Instruments ments. PowerProbe
Power- Integrator New derivatives
AMCC PPC405 Freescale™ ARM11 / StarCore - PPC405EX / EXR (cont.) - MXC91321 PPC44x Infi neon C166S - PPC460EX - XC22xx / XC23xx / XC27xx ARC ARC - XE166 - ARC® 700 Core TriCore - ARCtangent-A4 - TC1736 - ARCtangent-A5 - TC1767 / TC1767ED - TC1797 / TC1797ED Freescale™ ColdFire - MCF52110 / MCF52100 Microchip MIPS32 - MCF5221x - PIC32™ - MCF523x / MCF532x - MCF5372 / MCF5373 NXP ARM9 - LPC3000 MPC5500 MIPS32 - MPC551x - PNX83xx / PNX85xx - MPC56xx MPC5200 STMicro- MPC5500 - MPC512x with electronics - SPC563Mxx AXE audio processor - SPC560Bxx / Pxx / Sxx Cortex-M PowerQUICC II - STM32 - MPC8377 PowerQUICC III Texas Cortex-A / DSP - MPC8572 Instruments - OMAP3430
8 www.lauterbach.com NEWS 2007 NEWS 2008
DEBUGGER, REAL-TIME TRACE, LOGIC ANALYZER
Debugging with power-saving modes for ARM cores PowerView In response to constantly rising demands for But why can debugging and use of energy-saving economical use of energy and long standby modes lead to problems? In the fi rst part of this times, modern cores often have various differ- article, we look at single-core chips: How does ent energy-saving mechanisms. These allow the switching off (core) power or clock affect debug- PowerDebug software, whenever possible, either to reduce ging? Next, we look at multi-core chips. From the the core frequency or to switch off the core com- large number of possible challenges, we concen- pletely. However, these so-called energy-saving trate on the effect that switching off the clock of modes can adversely affect communication be- a single core has on the debugging of the entire PowerTrace tween the debugger and the core. In the follow- chip. ing, with the ARM architecture as an example, we show variants for problem-free debugging Switching off power of programs using energy-saving modes. PowerProbe At the VTREF pin (target voltage reference pin) of Ignoring energy-saving modes the JTAG connector, the debugger can detect a powerdown. If the user confi gures the debugger to Power- Of course, the fi rst and easiest way is to tell the use this energy-saving method, the debugger can Integrator core to ignore energy-saving modes during de- wait until power-up instead of issuing an error mes- bugging. For example, ARM11 has a so-called sage (StandBy mode). Powerdown Disable Bit. When this bit is set, the core activates a line that informs the external pow- er and clock management about the debugging. Up (StandBy) If then the program tries to activate an energy- Power is Power is saving mode, the power and clock management switched on switched off can simply ignore it to avoid problems during de- bugging. Setting the Powerdown Disable Bit is one StandBy of the basic settings of the TRACE32 debugger for ARM11, Cortex-A, and Cortex-M. Fig. 10: Instead of issuing an error message, the debugger waits If developers want to test for power-up following a powerdown. the behavior of the design with regard to energy-saving modes, they can of course In practice, the debugger can be in one of the two reset the Powerdown Disable following states: Bit with a debugger option • Up (StandBy): the processor has power and (SYStem.Option PWRDWN there is communication between the debugger ON, see Fig. 9). and the processor. However, there are many ARM- • StandBy: power is off and the debugger keeps based chips that do not have the ARM processor in reset over the SRST line. a Powerdown Disable Bit. In The debugger waits for power to be switched on this case, a special debug again (see Fig. 10). version of the software with- out instructions for activating When power is switched on again, the debugger energy-saving modes could releases the reset line and the processor runs as it be created. However, the dis- would after a power-up reset. Fig. 9: The PWRDWN advantage of this is that the However, the power-up reset of the ARM proces- option, defi ning whether debug version of the software sor resets the debug logic, the ETM/ETB logic, energy-saving modes are ignored or not dur- would be different from the and the assignment for the ETM pins. The settings ing debugging release version. that were active before powerdown are lost. 〉〉
www.lauterbach.com 9 NEWS 2008
DEBUGGER, REAL-TIME TRACE, LOGIC ANALYZER
Seamless continuation of debugging is possible VTREF only if the debugger manages to restore these set- nSRST / nTRST PowerView tings before the ARM processor starts executing the program. Core running shut down* running For the debugger to be able to carry out the neces- PowerDebug sary restore actions at power-up, the target hard- (* = reset) ware must meet some requirements. Fig. 12: Undesirable side effects resulting from a processor restart while the debugger is restoring the debug logic and the ETM/ETB The best case confi guration (red arrow) PowerTrace The best case is when the following requirements logic and the ETM/ETB confi guration. This can are met: have undesirable side effects. At the same time, 1. The debugger can keep the ARM processor in of course, the on-chip breakpoints and the trace PowerProbe reset over the SRST line. broadcasting are inactive in the restore phase. 2. The processor reset (SRST) and the reset for the debug logic (TRST) are separate lines. Switching off the clock Power- 3. Via the VTREF pin of the JTAG interface, the de- Integrator Switching off the processor clock is a completely bugger can quickly detect that power has been different challenge for the debugger. We are deal- switched off. ing here with the communication between the de- If these requirements are met, the debugger only bugger and the processor, or to be more precise, releases the reset for the debug logic when it the communication between the debugger and the detects power-up. The settings of the debug logic on-chip debug logic. This communication is almost and the ETM/ETB confi guration are now restored. always running, even when the ARM processor is Next, the processor reset is released and debug- processing the program. ging can be continued seamlessly, albeit somewhat As long as the debug logic is independent from the delayed (see Fig. 11). processor clock the communication works, even if the processor clock is switched off. For clocking VTREF the (as asynchronously standardized) debug logic, nSRST however, often a delayed and divided processor nTRST clock is used. You know this is the case if you have to use the command SYStem.JtagClock RTCK Core running shut down reset running when you confi gure the debugger.
Fig. 11: Following power-restore, fi rst the debug logic and the Switching off the processor clock can affect com- ETM/ETB confi guration are restored (green arrow). Only then does munication between the debugger and the on-chip the ARM processor start to execute the program. debug logic if two requirements are met: Since the I/O pins are confi gured via memory 1. The debug logic clock depends on the processor mapped registers, they cannot be restored for clock. the ETM trace port before the processor reset is 2. The processor clock is switched off during released and the program starts, so the program communication between the debugger and the itself has to activate the ETM port as fast as pos- on-chip debug logic. sible. Now, when the processor clock is switched off, the Other cases following happens: If requirements 1 and/or 2 are not met, the ARM 1. The ARM processor freezes its current state. processor starts up at power-up (see Fig. 12), while 2. The debug logic also freezes its current state the debugger simultaneously restores the debug since its clock depends on the processor clock. 〉〉
10 www.lauterbach.com NEWS 2007 NEWS 2008
DEBUGGER, REAL-TIME TRACE, LOGIC ANALYZER
3. The debugger breaks off communication with the Multi-core chips on-chip debug logic after some timeout since the on-chip debug logic no longer responds. Multi-core chips, which use only one JTAG inter- PowerView face for debugging daisy-chained cores, require When the processor clock is switched on again, additional measures if energy-saving modes are the debug logic resumes communication with the used for individual cores. Consider the following debugger at exactly the place where it was frozen, situation as an example: the clocking of the debug PowerDebug while the debugger has long since re-initialized logic depends on the core clock (RTCK) for core 2 communication since it received no response from and now the clock is switched off for only this core the debug logic. (Fig. 13). PowerTrace Since the debug logic of the ARM processor is con- trolled by the debugger, the debugger would have TDI TDO TDI TDO TDI TDO
to reset the debug logic in order to synchronize TDI Core 1 Core 2 Core 3
communication again. However, at least for a brief TMS TCK TMS RTCK TCK TMS TCK PowerProbe period during the program run, all on-chip break- points would be deleted. This is far from ideal. TMS
The following solutions have proved reliable for TCK Power- customers: Integrator RTCK
1. Checking the processor clock TDO
We recommend confi guring the debugger so that Fig. 13: Switching off the clock for core 2 blocks debugging for it checks whether the processor clock is running the whole chip. before starting communication with the on-chip As described in the section “Switching off the debug logic. For this the debugger puts the debug clock”, the debug logic of core 2 is frozen in this logic in Run Test/Idle mode at the end of each com- case. Since the chaining of the cores means that munication. In this mode, the processor clock can debug commands for core 1 / core 3 have to run be easily tested before resumed communication. through core 2, the debugging for the entire chip is 2. Reducing status queries now blocked. To be able to continue debugging without compli- While the ARM core is processing the program, the cations when the clock for core 2 is switched on debugger sends status queries to the debug log- again, we recommend confi guring the debugger ic 10 times a second. This way it checks whether for the individual cores so that a check is made on the program is still running or whether it has been whether the core clock is running, before commu- stopped. A next step is to reduce the frequency of nication with the debug logic starts. these status queries. We recommend a query every 2-3 seconds (SETUP.URATE 3.s). This solution is However, this is no solution to the problem that de- quite simple: fewer queries reduce the risk of com- bugging is blocked for the entire chip as soon as munication problems. the debug logic of a single core is frozen. Some good solutions exist for this problem today, but the 3. Increasing timeout chip manufacturers consider their solutions to be confi dential, so we cannot present them here. If the program switches off the processor clock We will therefore restrict ourselves in the following very often but always only very briefl y, the debug- to explaining how the CoreSight DAP technology ger can be confi gured so that it simply waits longer solves this problem. before breaking off communication with the debug logic (SYStem.POLLING SLOW). In certain circum- In the case of multi-core chips whose debug and stances, it might not even notice that the processor trace functionality is based on the CoreSight tech- clock was switched off. nology, the TRACE32 debugger no longer com- municates directly with the debug logic of the 〉〉
www.lauterbach.com 11 NEWS 2008
DEBUGGER, REAL-TIME TRACE, LOGIC ANALYZER
individual cores but with a so-called DAP (Debug Access Port) instead. The DAP’s task is to distri- PowerView TRACE32 bute the debug commands to the individual cores. CoreSight For debugging with energy-saving modes, the most DAP JTAG important innovation of the DAP technology is that PowerDebug the DAP has its own power and clock domain. This means that the DAP is unaffected by the energy- saving modes of the individual cores. At the same Memory access port to APB/AHB/AXI time, the cores are no longer daisy-chained under PowerTrace CoreSight. Instead, Memory mapped Memory mapped • Their debug logic is controlled by bus accesses debug register debug register if it is implemented via memory mapped debug PowerProbe registers. ARM core ARM core • Their debug logic is controlled over a JTAG ac- cess port if the core works with the traditional Power- debug logic. JTAG access port Integrator These new control mechanisms guarantee that JTAG JTAG the DAP can always address the individual cores directly and that no further debug commands are ARM core ARM core blocked by any frozen cores (see Fig. 14).
It can be generally said for multi-core chips that Fig. 14: The DAP can always address the debug logic of the in- if the debugging of energy-saving modes is par- dividual cores directly. This means it is no longer possible for the ticularly important in the development phase, you switching off of a clock for an individual core to block debugging should discuss this subject with the semiconduc- of the entire chip. tor manufacturer when choosing your chips. The experts of the Lauterbach team will be happy to and voltages at selected measurement points and advise you on this subject. correlates them with the program fl ow information output at the trace port. Analyzing energy consumption Lauterbach offers such a measuring arrangement since 2007. For this you need additionally to the For all ARM-based chips with ETM and an off-chip TRACE32 debugger: trace port, Lauterbach offers the option of analyz- • A real-time trace for the ETM ing whether the energy-saving modes really result in a maximum reduction of energy consumption for • An Analog Probe the design. To answer this question, a measuring • A Lauterbach logic analyzer; either the IProbe arrangement is required that records the currents Logic Analyzer in PowerTrace II or the TRACE32- PowerIntegrator Since in this measuring arrangement both the cur- rents and voltages as well as the program fl ow are synchronously timestamped by the TRACE32 soft- ware, the links between the control software fl ow and the current/power consumption can be easily displayed and analyzed. Fig. 15 shows as an ex- ample the absolute and percentage share of total energy consumption calculated for each function executed during the measurement time. In this way, Fig. 15: Graphic showing the connection between the program the important energy-consumption and standby- and the current/power consumption of the hardware time data can be verifi ed.
12 www.lauterbach.com NEWS 2008
DEBUGGER, REAL-TIME TRACE, LOGIC ANALYZER
New debugging concept for symmetric multiprocessing (SMP) PowerView Lauterbach, the leading manufacturer world- wide of high-quality debuggers and real-time SMP Linux & applications trace tools, is presenting its new debugging concept for SMP systems at the ESC 2008. SMP PowerDebug systems use an operating system to distribute processes dynamically to several cores or hard- ware threads. SMP Linux on a MIPS 34K will be Core 1 Core 2 demonstrated live at the fair. PowerTrace Hardware parallelization Hardware with a dual-core processor
To achieve higher processor performance for com- Fig. 16: SMP Linux on a dual-core processor PowerProbe plex applications and to save energy, more and more parallelization of tasks is used. The most cores with pipeline architecture: cache misses or popular method is to provide several identical data dependencies between the instructions mean Power- execution units that can all process the same task. that the pipelined instruction processing has to be Integrator To most readers, the term “identical execution units” stalled in order to wait for the availability of required means symmetric multi-core processors. It is easy data. The greater the difference between instruc- to imagine that the kernel of an operating system tion processing time and memory access time, the is running permanently on a core and ensures that higher the performance loss. the application processes are evenly distributed to Hardware multithreading deals with this situation all cores (see Fig. 16). by making the core process several mutually inde- However, for the parallelization of tasks not nec- pendent tasks quasi-simultaneously. In the case of essarily a multi-core processor is required. Hard- an operating system, “tasks” and “processes” are ware multithreading, for example, is an approach equivalent. that enables parallelization also for single-core In principle, this works as follows: As soon as a processors. Here, we deal with a basic problem of task can no longer be further processed because required data is not yet available, the processing of another task is continued. Processing on 3 cores with simple pipeline architecture Fig. 17 shows the processing of Task 1 load miss miss process update load miss miss miss 3 tasks on 3 cores with simple pipeline architecture (at the top) and then (at the bottom) shows the Task 2 miss load miss miss process update load process update execution on a multithreaded core. In order for hardware multithread- Task 3 miss miss process update load miss miss miss miss ing to work, fast switching between tasks must be possible. This can be done simply by giving each task a separate register set for its con- Processing on a multithreaded core text. With this method, it is easy to deduce that the number of register load load process update load process update load process sets provided by the core defi nes how many tasks can be processed Fig. 17: No more stalls in the pipeline, thanks to the quasi-simultaneous processing of in parallel. For the MIPS 34K the several tasks number is fi ve. In this way, one 〉〉
www.lauterbach.com 13 NEWS 2008
DEBUGGER, REAL-TIME TRACE, LOGIC ANALYZER
also worked perfectly for multi-core processors since these processors were also operated as SMP Linux & applications PowerView asymmetric multiprocessing systems (AMP). Asym- metric multiprocessing means: An independent instance of an operating system runs on each core. PowerDebug For AMP systems, this always statically defi nes which process is running on which core. In this Thread Thread Thread Thread Thread way, the debug information can also be uniquely 1 2 3 4 5 assigned to the corresponding core. PowerTrace In contrast, on SMP systems, the processes are Hardware with MIPS 34K not assigned to the cores or hardware threads until runtime. For this reason, it no longer makes sense Fig. 18: SMP Linux on a multithreaded core – here MIPS 34K to start a debugging instance specifi cally for the PowerProbe debugging of a selected core or hardware thread. “execution unit” (a so-called hardware thread) de- rives from each register set (see Fig. 18). System View Power- Core View SMP operating systems As an alternative to the , which works Integrator very well for AMP systems, there is now the System At the hardware level, the parallelization of pro- View for SMP systems. cesses is implemented by symmetric multi-core With the System View, only one instance of the processors or multithreaded cores. Now software TRACE32 debugger is started to debug all cores is needed to organize the parallelization. An operat- or hardware threads (see Fig. 19). Here too, root of ing system is normally used for this purpose. information display is one core or hardware thread. One variant, which is primarily suitable for hardware The new aspect here is that the information 〉〉 with identical execution units, is operating systems that implement symmetric multiprocessing (SMP). The central feature of SMP operating systems is the dynamic distribution of task/processes to the available cores or hardware threads at program runtime. Other features: • One instance of the operating system operates all cores or hardware threads. • Each application process can run on each core or hardware thread. As a rule, only the kernel is rigidly assigned to a core or hardware thread. SMP Linux & applications • All cores or hardware threads have equal rights to request and use resources (e.g.: memory, external interfaces, external devices). • The operating system provides the functions for distributing resources to the cores or hardware Thread Thread Thread Thread Thread threads. 1 2 3 4 5
New debug concept Hardware with MIPS 34K At present, the TRACE32 concept enables just one core to be debugged with one instance of the de- Fig. 19: Only one instance of the TRACE32 debugger is used for bugger (Core View). Up to now, this concept has debugging all cores or hardware threads.
14 www.lauterbach.com NEWS 2008
DEBUGGER, REAL-TIME TRACE, LOGIC ANALYZER
display can be switched by a command to another once, Linux (for example) loads the program code core or hardware thread. only once. Each instance of the application process thus sees the same program memory as well as the PowerView software breakpoints set there. To make sure that the program execution is stopped only in the de- sired application process, the TRACE32 debugger PowerDebug enables the setting of process-specifi c software breakpoints.
Summary PowerTrace The systematic extension of the TRACE32 concept Fig. 20: The TASK.DTASK window, showing the core or hardware enables Lauterbach to offer its customers simple thread to which SMP Linux has assigned a task/process debugging of embedded designs that use an SMP PowerProbe operating system for controlling several cores or Process debugging can now be done as follows: hardware threads. To be able to use this new con- 1. The current list of all active task/processes is cept for debugging SMP operating systems, you just need a TRACE32 debugger whose debug Power- used to identify the core or hardware thread on Integrator which a task/process is running (Fig. 20). Linux cable has not only a license for the processor uses here the term CPU instead of using core or architecture but also a second license such as a hardware thread. multi-core license. 2. A command is used to switch the information Following the support for the MIPS 34K, the de- displayed in the debugger to the required core or bugging of SMP systems for ARM and PowerPC hardware thread (Fig. 21). architectures is also planned for early 2008.
Common breakpoints The fact that an SMP operating system does not assign application processes to a core or hardware thread until runtime also has consequences for the setting of on-chip breakpoints. A simple example: The “sieve” process is to be stopped as soon as it writes to the variable “xyz”. In order for the debugger to be able to implement this request, it must program the break logic of all cores or hardware threads for this break condi- tion since it cannot know beforehand the core or hardware thread on which the “sieve” application process will run. This means that even if each core or hardware thread has its own break logic, the debugger programs the breakpoints for the user as if there were only one break logic shared by all. When setting of software breakpoints, for the im- plementation of which the original instruction in memory is temporarily overwritten by a break in- struction, there are no changes compared to AMP systems. Operating systems protect the address spaces of processes from each other. However, if Fig. 21: The TRACE32 window, which always shows only the the same application process is started more than context of a core or hardware thread. The number of the core or hardware thread is shown in the status line.
www.lauterbach.com 15 NEWS 2008
DEBUGGER, REAL-TIME TRACE, LOGIC ANALYZER
Further RTOS innovations
Windows CE 6.0 for ARM and SH4 Integration in the Windows CE PowerView TRACE32 now also supports Windows Embed- Platform Builder ded CE 6.0 for ARM and SH4 architecture. Since the beginning of 2007, Lauterbach debug- Since the end of 2006, developers have been able gers can be used as hardware debug back end PowerDebug to use the new version of Windows CE for their for the Windows CE Platform Builder. projects. Version 6.0 introduced some fundamen- To debug the kernel and application processes in tal changes in the kernel architecture. For exam- Windows CE, Lauterbach offers an eXDI2 driver ple, Windows CE now supports process address that permits control of a Lauterbach debugger PowerTrace spaces of 2 GB. For Version 5.0, these were limited through the internal debugger of the Windows CE to 32 MB. Platform Builder. Since late 2007, an updated version of TRACE32 By means of target device connectivity, the Windows CE Awareness has been available, so that PowerProbe TRACE32 eXDI2 driver is fi rst integrated into the a TRACE32 debugger can now be used to monitor platform builder (PB). As a result of this integration, and test all processes, threads and libraries simul- all debug commands of the PB debugger are now taneously. In combination with a real-time trace translated into TRACE32 commands in the back- Power- tool, a runtime analysis of Windows CE threads is ground and passed to the Lauterbach debugger. Integrator also possible. The confi guration of Windows CE The eXDI2 driver is available for Windows CE 5.0 Awareness has been simplifi ed: and 6.0 as well as for Windows Mobile Versions 5 • The debugger now supports automatic detec- and 6. tion of the kernel objects. This means that the symbol information for the kernel no longer has Extensions to be loaded explicitly. • Linux – Support for Xenomai Threads • The Windows CE Autoloader of the debugger simplifi es symbol management for the different • Linux – Symbol Autoloader processes and libraries. If the autoloader is con- • OSE – Support for 5.2 Load Modules sYmbol.AutoLOAD.CHECK- fi gured accordingly ( • PXROS – Redesign for C167 WINCE), the matching symbol information is auto- matically loaded to the debugger when needed.
New supported RTOS
DSP/BIOS for TMS320C28xx Available RX4000 for MIPS Available
eCOS for MIPS Available ThreadX for ARC and Blackfi n Available
FreeRTOS for ARM Available ThreadX for Xtensa Planned and MicroBlaze Windows CE 6.0 for ARM Available HI7000 for SH4 Available and SH4
Linux for ARC and MicroBlaze Planned μClinux for Blackfi n Planned
LynxOS-SE for PowerPC Planned μClinux for MicroBlaze Available
NetBSD for ARM and PowerPC Available μC/OS-II for V850 Available
OS/9 for ARM and PowerPC Available μC/OS-II for Xtensa Planned
16 www.lauterbach.com NEWS 2008
DEBUGGER, REAL-TIME TRACE, LOGIC ANALYZER
New preprocessors /NEXUS adapters
NEXUS adapter MPC5500 AF TRACE32-PowerTrace PowerView Program flow • NEXUS port width up to 16-bit MDO, Data flow CPU specific debug cable & 2-bit MSEO, EVTI, EVTO Trace port Trace CPU specific preprocessor Task ID PowerDebug • Data rate up to 200 MBit/s CPU specific NEXUS adapter • 200 MHz at SDR or 100 MHz at DDR • Voltage range 1.0 V to 5.0 V Many SoCs (system on-chip designs) now have a PowerTrace trace port that makes runtime information visible • Adapter for different variants of the off-chip. Such information can be the instructions NEXUS port executed by the program as well as data transfers. • AUTOFOCUS technology PowerProbe If an operating system is used, output of the cur- rent task ID can be helpful. The best-known trace ports are certainly ETM for the ARM architectures and NEXUS for the PowerPC architecture. Power- New AUTOFOCUS II preprocessors Integrator To record runtime information Lauterbach offers To enable preprocessors to handle trace port TRACE32-PowerTrace, a real-time trace tool. At AUTOFOCUS II the hardware level an architecture-specifi c prepro- frequencies of over 500 MHz, the cessor or NEXUS adapter receives the data from technology was developed in 2006. The most im- the trace port and transfers it to the trace memory portant feature of this technology is the automatic (up to 4 GB) of the PowerTrace hardware. This setting of the optimum sampling instant for trace recorded information serves the user as the basis data. Based on this technology, further prepro- for effi cient troubleshooting as well as for compre- cessors are now offered for a series of DSPs. hensive runtime analyses of his design. Lauterbach is now offering preprocessors and NEXUS adapters for more than 30 processor archi- New AUTOFOCUS II tectures. Many more will be supported in 2008. preprocessors
Preprocessor for Ceva-X Q1/2008 New NEXUS adapter for MPC5500 architecture Preprocessor for StarCore Q3/2008 From March 2008, the NEXUS adapter for the Preprocessor for TMS320C55x Q1/2008 MPC5500 architecture will be available in an im- and TMS320C64x proved version using an advanced technology. To respond fl exibly and quickly to new variants of the NEXUS port, this adapter supports a port width of up to 16-bit MDO and a voltage range of 1.0 V MicroBlaze to 5.0 V. Since November 2007, a preprocessor for the Lauterbach offers converters to adapt to the spe- MicroBlaze architecture has also been available. cifi c processors´ NEXUS port. Using a 22-pin wide trace port, the MicroBlaze To guarantee optimum sampling of trace signals at Trace Core makes program fl ow as well as (op- high trace port data rates, the new NEXUS adapter tionally) the data fl ow visible off-chip. Trace port also contains FPGAs for the automatic setting frequencies of over 100 MHz can now be handled of the optimum sampling instant (AUTOFOCUS by the preprocessor. technology).
www.lauterbach.com 17 NEWS 2008
DEBUGGER, REAL-TIME TRACE, LOGIC ANALYZER
CombiProbe
For fast output of important system informa- mapped register as- Software data tion at runtime, some cores now have simple signed to the ITM. PowerView trace ports. These ports enable an application 2. The ITM makes the in- 32-bit register program to make user-defi ned data visible off- formation visible either chip. For recording and processing this data, directly over the Serial Instrumentation Lauterbach offers a new tool option called Wire Output Trace PowerDebug (see Fig. 22) Macrocell CombiProbe. Here we describe the hardware or together with other and operation of this new product. trace data over the Co- reSight Trace Port Inter- PowerTrace Instrumentation face Unit (TPIU). Serial Wire Output (asynchronous) Most developers are familiar with test scenarios for Many mobile phone manu- Fig. 22: CoreSight Instru- which a simple printf() is the most effi cient imple- facturers are already wor- mentation Trace over Serial PowerProbe mentation. Typical examples are output of diag- king with similar propri- Wire Output nostic information or logging of important system etary solutions for their events, i.e., test scenarios where the application is chips. However, to save money, they are interested already working as intended, and now operational in a uniform standard for such a trace port. In May Power- tests have to be conducted. Usually, code instru- 2007 the “Test and Debug” workgroup of the MIPI Integrator mentation is used for these tests. Alliance specifi ed, under the name “System Trace”, Two steps are necessary to make important system a standard for a 4-bit trace port as well as a 34-pin information visible with instrumentation at program debug and trace connector. runtime: Along with the standard- Hardware data 1. Instructions are inserted in the application pro- ization, the functionality Software data gram to provide the necessary information. of the trace port was extended. Apart from 2. A way has to be found to make this information the system information visible. An external communication interface generated by the ap- Arbiter such as RS-232 or Ethernet is usually used for plication program, the this. System Trace can now The great advantage of instrumentation is that only output hardware infor- System the information of interest to the tester is made Trace mation too (see Fig. 23). Module visible. At the same time, however, large communi- A programmable bus cation overhead is created since, as a rule, a further watcher, e.g., can de- communication interface has to be operated by the tect and display specifi c operating system. If the interface is slow, consi- System Trace Port bus cycles, or a signal (4-bit data & 1 clock) derable runtime problems can result for the actual monitor can return the application. Fig. 23: System Trace specifi ed status of selected chip- by MIPI Alliance internal signals. System Trace The communication overhead created during in- CombiProbe hardware strumentation can be largely reduced if the core of- As a “Test and Debug” workgroup member, fers a separate trace port for the output of system Lauterbach took an active part in the System information generated by the application program. Trace specifi cation and at the same time in the As an IP provider, ARM offers such a solution as development of a suitable debug and trace op- part of its CoreSight technology. tion named “CombiProbe”. Since October 2007, The CoreSight Instrumentation Trace Macrocell Lauterbach has been marketing this new product. (ITM) basically works as follows: CombiProbe is a combination of a special debug 1. The application program writes the information cable and 128-MB of trace memory. It can, for ex- that has to be made visible to a 32-bit memory ample, be plugged into the universal Lauterbach 〉〉
18 www.lauterbach.com NEWS 2008
DEBUGGER, REAL-TIME TRACE, LOGIC ANALYZER
base hardware such as the POWER DEBUG However, the size of INTERFACE / USB 2 (see Fig. 24). As target system the trace memory in PowerView connection, the 34-pin debug and trace plug from CombiProbe limits the Instrumentation Trace Macrocell the MIPI Standard is used, comprising connec- recording time. tors for a JTAG port and a 4-bit System Trace Port. To implement longer ITM commands Lauterbach offers also adapters for other target recording intervals, Serial Wire Output / PowerDebug system connectors. we offer a PIPE mode via TPIU (4-bit) for the CombiProbe. In PIPE mode, the trace data is trans- PowerTrace ferred directly to the TRACE32- PowerDebug host. In this mode the trace memory in the CombiProbe & PowerProbe CombiProbe is used debug license SystemTrace SystemTrace commands only as a buffer. On the host, TRACE32 Fig. 25: ITM commands are used Power- can be confi gured to to confi gure the Instrumentation write the trace data Trace Macrocell. Integrator The System Trace commands en- immediately to a fi le. able recorded trace information to After recording, the be displayed and analyzed. system information Fig. 24: POWER DEBUG INTERFACE / USB 2 with a Combi- can also be formatted Probe and analyzed by an external application. Operating concept As an alternative, external analysis software can be confi gured to collect the trace data over the TRACE32 Additionally to the traditional debug functions FDX API and process it while recording (see Fig. 26). 〉〉 CombiProbe provides new confi guration com- mands as well as commands for displaying and analyzing recorded trace information. Confi guration commands are: • ITM.
• SystemTrace.
www.lauterbach.com 19 NEWS 2008
DEBUGGER, REAL-TIME TRACE, LOGIC ANALYZER
Summary 3G / DigRF report PowerView The CombiProbe is a new tool option for recording From the summer of 2007, Lauterbach has of- runtime information in the broad Lauterbach pro- fered a new set of probes for PowerIntegrator, duct range. For complex test cases, CombiProbe which allow the recording of data traffi c from a can also be used in conjunction with TRACE32- 3G / DigRF interface. PowerDebug PowerTrace. Since all Lauterbach tools share a common time base, important system information The following sampling rates are used for recording: can be placed in a direct chronological context with • 2 GigaSample /s for the RX / TX lines PowerTrace the program/data fl ow of the core. • 250 MegaSample /s for the SysClkEnable line A recording duration between 25.156 ms at full load CombiProbe data and up to several hours is possible, depending on the data traffi c on the lines. The high sensitivity PowerProbe of the probes and the very low load of the input • Debug cable and 128-MB of trace memory signals guarantee error-free recording. The measured data can be evaluated and analyzed Power- • JTAG support for ARM cores at protocol level as well as time-correlated with the Integrator - Standard JTAG - Serial Wire Debug Port from ARM program fl ow. - cJTAG (IEEE P1149.7), planned • Standard JTAG possible for other processor architectures • Trace port support for - MIPI System Trace - ITM over Serial Wire Output - ITM over 4-bit CoreSight TPIU - 4-Bit ETMv3 in continuous mode, planned • Bandwidth of 200 MBit /s per trace channel with up to 4 trace channels • Voltage range 0.3 V to 3.3 V, 5 V tolerant • 34-pin half-size connector to target hardware • Adapters also for 10- and 20-pin half-size connector
Please inform us:
If you would like us to remove your name from our mailing list or receive additional information, send an e-mail to: [email protected]
20 www.lauterbach.com