������������ ������� ���������������������� ������������

���� �����������

The early yearsBack in 1979 Lothar Lauterbachfounded his one-man operationLauterbach Datentechnik. Initially heearned his living as a contractor. Hiswork required a debugger and sincethere was no good, reasonablypriced product on the market he de-cided to develop his own. The out-come was the first in-house softwareproduct, that could run on CPM sys-tems, the TRACE80 debugger forthe Z80. In 1982 his younger brotherStephan Lauterbach joined the com-pany. In the beginning as a compu-ter science major doing his intern-ship, but soon as full-time employeedoing his studies on the side. Thefruits of their work was the first realTRACE80 in-circuit emulator de-veloped for the Z80. In those daysthe leading edge CAD tool of their choice was adhe-sive crepe tape, which they used for PCB layout ona 10:1 scale. In 1984 the first employees were re-cruited and the company moved into two subletrooms at MBB in Ottobrunn near Munich. Now num-bering a total of 5 employees they set about thefurther development, production and marketing oftheir tools. Adhesive tape was replaced by the com-pany’s first real CAD system, allowing more efficientPCB development. The existing emulators weremodified for use with the 8085, the NSC800 and alsothe HD64180. Lauterbach also offered suitable hostcomputers in the form of the Commander desktopcomputer and portable SCOUT model which wasmore or less a predecessor of the first laptops. Bothcomputers were based on the Z80 microprocessorand the CPM operating system the mainstream OS

at the time. For the first timethese products were presentedto a wide audience at the 1985Hanover Fair. The high-level lan-guage debugger for C and PLMwas applauded by the fairgoersas a real sensation. TRACE80quickly became the company’scash cow generating annual rev-enues of about $ 3 million in theyears 1985/86.

The next challengeThe foundation was laid for thenext major milestone, the devel-opment of a universal in-circuitemulator. This emulator wasbased on a modular design,which allowed support of a largevariety of 8 to 32-bit microcon-trollers and at the same time of-fering ground-breaking new tech-

nical features. In consequence it lead to the devel-opment of the TRACE32-ICE for Motorola’s legen-dary MC68000. In 1986 the new challenges and op-portunities required further growth of the company.Additional employees were hired to strengthen thedevelopment team and a semidetached house wasrented in Neubiberg near Munich to provide extraoffice space. Stephan Lauterbach developed his firstflexible Window interface under CPM and MS-DOSin the “children’s room” while Lothar sat at his PC inthe “bedroom” designing a universal hardware con-cept.

It followed the most challenging, but also the mostexciting time in the company’s history. The develop-ment of the new emulator dragged on longer than

����������

�������� � ������������������

����

������������������� ��!"�#!��"!����$#!�"���!$

First product advertisment publishedin Germany 1985

��

������������������� ��!"�#!��"!����$#!�"���!$ planned. At the same time Lauterbach was now

entering a market segment where it had tocompete against well established brand-namecompetitors.

TRACE32-ICE becomes establishedIn autumn 1987 thecompany moved into itsown building at thepresent location inHofolding. In order to fi-nance this expansionthe company was effec-tively under pressure tosucceed. The leanestyears in the company’shistory followed. Never-

theless, it succeeded in winning customers oneby one against the “big” players under thesedifficult conditions. Lauterbach had only onesales argument: better technology. Buyingmotives such as “long proven”, “customer suc-cess stories” or “well established producer” werethe monopoly of competition. All these at-tributes now apply to Lauterbach as well, buttechnology and quality are still the company’smost important objectives.

After this difficult period TRACE32-ICE at lastbecame an established best seller at the be-ginning of the 1990s. First-class technology,

quality and the prompt roll-out of newemulator modules keeping up withnew microcontroller derivatives finallywon customers’ confidence.

On-chip debugging with TRACE32-ICD and PowerToolsIn 1994 the company’s revenuescame exclusively from sales of clas-sic in-circuit emulators. That yearLothar Lauterbach set the course forthe company’s continued success in the future by initiat-ing the development of the first BDM debugger. TheTRACE32-ICD in-circuit debugger was born targetingMotorola’s 68332. The company soon followed up withdebuggers for many other microcontrollers and hasachieved an excellent track record in terms of units sold.In 2001 the total number of TRACE32-ICD debuggersshipped passed the 10,000 mark. In 2004 Lauterbach ex-pects to increase the total number of systems shippedto be beyond 25,000. Sales growth over the past fewyears had averaged over 25% per annum.

Global presenceBecoming a global player has become an important partof the company’s development. At the beginning of the1990s Lauterbach teamed up with sales partners in Eu-rope and the U.S.A. In the mid-1990s sales activities wereexpanded to cover the Panasian market as well. In 1995the first own sales office was established in the U.S.,followed by sales offices in England (2001) and Japan

(2002). Together with its world-wide sales partners Lauterbachis thus ideally positioned to dealwith the challenges of the yearsto come.

25-year anniversaryFirst things first: to all our ex-isting customers a big “thankyou” for your support over thelast 25 years. To those new toLauterbach products a warmwelcome and we hope our tech-nology can help bring yourprojects to a swift and success-ful conclusion.

Lothar Lauterbach

Stephan Lauterbach

All Lauterbach products at a glance:Emulators - TRACE80 (1984), TRACE32-ICE (1991), TRACE32-FIRE (1997),Debuggers - TRACE32-ICD (1995), PowerTrace (2001), PowerIntegrator (2003)

%

�&��%�'(�

��)�� *��+(��

�������������������

In 2003 the main emphasis with new processorarchitectures supported by the TRACE32-ICD in-cir-cuit debugger was on digital signal processors.

Data-intensive applications such as image transmissionor the Internet browser in mobile phones require increas-ingly powerful processor architectures. The large volumesof data occurring in these applications are generally pro-cessed quickly and efficiently by digital signal proces-sors. Two trends are currently observable for embeddeddesigns in the communications industry:

• The use of multicore SoCs whereby a RISC processorcontrols the system and a number of signal proces-sors are responsible for the data processing.

• Integration of several signal processors on one SoCfor efficient data processing.

At the beginning of 2003, for the first time ever, Lauterbachmade debugging of a RISC and a DSP possible with jointdebugger hardware by supporting the OMAP from TexasInstruments. The OMAP contains both a TMS320C55xDSP and an ARM925/926 core. Both cores can be startedand stopped synchronously.In response to growing demand Lauterbach has added anumber of other DSPs to its product range. DSPs aresupported both as self-contained microcontrollers and aslicensed cores which are usually integrated into a multicore

SoC. See also Table 1.Work is currently in progress on the development of adebugger for Motorola’s MSC81xx architecture. This ar-chitecture is based on a licensed DSP produced byStarCore LLC. Initially the MSC8101 will be supported.Support for the MSC8102 will soon follow and for the firsttime Lauterbach will provide a debugging environment inwhich a processor containing four DSP cores can betested.

New JTAG debuggers

MRA eroC01MRA

eroC11MRA

won

won

MBI XG057CPP,XF057CPP won

spilihP xx12CPL

)desabIMDT7MRA(

won

alorotoM 80SCM

xx55CPM,0025CPM

xx47CPM

xx58CPM

won

won

won

won

Table 2: Standard processor architectures now supported

In 2003 Lauterbach also increased the number of stan-dard processor architectures supported by the TRACE32-ICD in-circuit debugger.The ETM trace and the support for the onchip Embed-ded Trace Buffer is also already available for the ARM11.Support packages are already offered for the Power-Integrator for tracing the program and data flow of thePowerQUICC III MPC8560.

New NEXUS debuggers

cigoLISL PSZ won

alorotoM E00865PSD won

saxeTstnemurtsnI

x55C023SMT

PAMOnix55C023SMT

won

won

AVEC htiwserocdesnecilllaecafretnIGATJMAJ

etiLkaeT

kaeT

kaeTtrepX

won

40/1Q

40/1Q

CLLeroCratS

alorotoM

serocdesnecillla

1018CSM

2018CSM

40/1Q

40/2Q

Table 1: DSP processor architectures now supported

alorotoM xx17CAM

0055CPM

won

won

Table 3: NEXUS debuggers now supported

Lauterbach has now added the MAC71xx/MPC5500 pro-cessors to the list of Motorola processors with NEXUStechnology that it supports. This further extends Lauter-bach’s market-leading position in this sector.

�

������������������� ��!"�#!��"!����$#!�"���!$

the open and intuitive

user interface

the open and intuitive

user interface

TRACE32-

PowerViewPowerView

TRACE32-

At the Embedded Systems Conference 2004in San Francisco Lauterbach is presenting itsnew PDF-based online Help function. The mainnew features are as follows:

• The online Help is matched to the specificdevelopment tool in use, to the processorarchitecture of the target system and alsothe RTOS employed. The entire online Helpcan also be used unfiltered if required.

• A complete Tooltip text system providesimportant information aboutthe input windows and com-mands easily and clearly.

• The complete training docu-ments are integrated into theonline Help so that TRACE32users can familiarize them-selves with specific individualsystem functions by means ofexamples.

• The individual parts of theonline Help are interlinked via

cross references. TRACE32 users can quickly obtainan overview of similar or supplementary commands inthis way.

• After an automatic update check the latest version ofthe Help files can be downloaded via the Internet.

The new PDF-based online Help offers the same “lookand feel” for Windows, LINUX and all the many workstationtypes we support. Further information is available on theInternet at:

www.lauterbach.com/help.html

�������������

,

�&��%�')�����(��

��������&�����&*���

��� ������������������������������������������

Application debugging under Linux, QNX andWindowsCETesting user processes with a hardware debuggerpresents a real challenge for the debugger as well as forthe developer. If an application is started, for example inLinux, a process is first generated; the corresponding ap-plication is then loaded from the operating system andlinked, and finally started automatically. Since the de-bugger (and the developer) do not know the load addressfor the process before the application is started, no sym-bols can be loaded in advance. But without the symbolinformation it is not possible to set breakpoints. The ap-plication therefore starts up without any checks, possi-bly even running into the first bug. This problem is com-pounded by the fact that the operating systems alsoreprogram the MMU when generating and starting theprocess. This reprogramming of the MMU has to be cor-rectly followed by the debugger in order for it to be able tofollow and debug the new process correctly.

Because of these adverse factors in order to be able todebug a process, until recently, it was necessary, to en-ter a complicated sequence of commands either manu-ally or under the control of a script.

1.) First of all a breakpoint was required in the kernel ofthe operating system to ensure that the programstopped whenever a process was generated.

2.) After the program run had stopped at the breakpoint itwas then necessary to check whether the process justgenerated was the one that was to be debugged. Ifnot, the program could be restarted without any fur-ther actions.

3.) When the breakpoint located the required process thedebugger would then be able to ascertain the destina-tion to which the process had been loaded. This thenmade it possible to load the matching symbol infor-mation into the debugger and to set a breakpoint tomain().

4.) At this point a “Go” would start the process whichwould then stop at main(). After this it was still neces-sary to scan the MMUs for the process. Debugging ofthe process could then begin.

Although this method works it is extremely awkward toimplement. To simplify the debugging of processesLauterbach has now implemented a Process Watch Sys-tem for a number of different operating systems and pro-cessors. This system recognizes whether a process thatis required for debugging is present in the system, whetherit has just started or has already finished. It automati-cally loads and deletesthe relevant symbolinformation and theMMU tables. The userneed only specify thename of the wantedprocesses and doesnot need to carry outany further actions.

Although the Process Watch System can monitor up toten processes it is recommended that the number shouldbe restricted to a far lower figure to avoid having a detri-mental effect on the reaction speed of the debugger. AsFigure 1 shows, the Process Watch System can be acti-vated in order to observe a process simply by selectingfrom the menu (Linux in the example). It is then possibleto add further processes by using the same selectionprocedure. Figure 2 depicts an activated Process WatchSystem with three processes.

The Process Watch System operates as follows: whenthe debugger is stopped, it searches the target for theselected processes. If a matching process is found, thedebugger automatically loads the symbol information andthe corresponding MMU entries. If the process is notcurrently in the target, the symbols and MMU tables thathad already been loaded may possibly be cleared fromFigure 1: Activating the Process Watch System

Figure 2: The Process Watch Systemmonitoring 3 processes

-

������������������� ��!"�#!��"!����$#!�"���!$

the open and intuitive

user interface

the open and intuitive

user interface

TRACE32-

PowerViewPowerView

TRACE32-

the debugger. If the loading address for theprocess has changed (possibly because it wasterminated or restarted), the debugger recog-nizes this and initiates reloading of the sym-bols and scanning of the MMUs in order tooperate according to the new conditions.

If necessary the debugger can detect the gen-eration of a new process and stop the processat its entry point at main(). This makes it pos-sible to debug the process from the beginning.Since this Process Watch System uses abreakpoint for recognizing the generation of aprocess, this can be deactivated to avoid in-fluencing the real time response ofthe target system. When the auto-matic stop is disabled during pro-cess generation the new symbol in-formation will still be loaded after thenext manual break.

Figure 3 illustrates the situation af-ter the process has been started inthe console. The debugger hasstopped the process at main(). At thenext stop after termination of theprocess the symbols are then re-moved again from the debugger (Fig-ure 4). If the process is restarted thedebugger stops again at main(), and

the developer can process a newdebug cycle.The Process Watch System is al-ready available on various proces-sors for Linux, QNX and Windows-CE.

Figure 3: Start of a process

Real-time cores now supported• DSP/BIOS for TMS320C55x and OMAP• Jaluna C5 for PowerPC• OS21 for ST40• OSEck for TMS320C55x and OMAP• RTXC Quadros for ColdFire, also planned for ARM

and StarCore• ThreadX now also planned for StarCore• Windows CE.net for ARM and XScale, also

planned for SH4 and MIPS

3rd party tool integration• Windows CE Platform Builder eXDI, planned

Monitor solutions• OSE SDM run mode debugger for PowerPC• GDB front end debugger for Linux, planned

Figure 4: Process ended

.

�&��%�')������+�

��)�� *��+(��

����������������� !�"�!

One of the most regular questions our customers askis “do we have any tips on the optimum use and con-figuration for the ARM-ETM”. The purpose of thisarticle is to try and summarize the most importantoptions for users of the ETM on the ARM7 and theARM9, and to provide a preview of the ARM11.The ETM (Embedded Trace Macrocell) is an on-chip realtime trace module for the ARM architectures. This tracemodule provides the following functions:

• Output of the entire program and data flow via a spe-cial trace port

• Triggers and filters for controlling this output

This trace output can be recorded and analyzed with theTRACE32 PowerTrace from Lauterbach, a developmenttool consisting of a fully featured JTAG debug systemand a 512-Mframe deep trace memory.

The trace portThe ETM configuration first of all defines a physical traceport, see Figure 1.

TRACECLK: The ETM is normally set to operate at thesame frequency as the ARM processor.

PIPESTAT: In each clock cycle the ETM outputs detailsof events in the instruction pipeline of the processor (e.g.instruction taken, branch taken etc.) via the pipeline sta-tus pins (3 pins for the ARM7 or 4 pins for the ARM9)

TRACEPKT: The program flow is always presented viaTRACEPKT (4/8 or 16 pins). For this purpose the com-pressed branch destination address is output in a tracepacket for each indirect branch. In these packets the term“indirect branch” is used in a very wide sense as it meansall program branches for which the branch destination isnot defined prior to the program run time (i.e. loads/addsto the PC and exceptions, but not branch instructions

themselves). With the aid of the source code and thisinformation the entire program flow can be reconstructed.For data accesses the ETM user can personally decidewhether they want to make only the data address, onlythe data contents or both available via the trace port.Whereas program only trace is very low bandwidth andcan be traced through a 4-bit port, when data trace isenabled the amount of trace bandwidth required increasesrapidly. Since the entire address and data informationhas to be output via the 4/8 or 16 pins of TRACEPKT, itis obvious that this data flow can possibly overload thetrace port. This is most likely to occur when several dataaccesses are carried out in quick succession. In order toprevent overloading of the trace port a FIFO is connectedupstream of TRACEPKT. This provides intermediate stor-age for all trace packets that cannot be output viaTRACEPKT immediately.

Dimensioning of the ETMARM Limited now offers a number of standard configura-tions for the ARM-ETM. From our experience a port widthof 8 or 16 pins for TRACEPKT and a FIFO size of atleast 45 bytes has proved viable in practice (known asMediumplus or Large). For ETM ports with lower specifi-cations you should be aware of the possible limitations,especially with the data flow output, as this can veryquickly result in an overflow of the FIFO.

FIFO overflowA FIFO overflow occurs whenever there are so manytrace packets queuing to be output that the FIFO con-nected upstream of TRACEPKT is no longer able to pro-vide intermediate storage for all of them. The result isthat important trace packets can be lost. There are twomethods available to prevent this highly undesirable situ-ation.

1.) FIFOFULL logicMost ARM-ETM standard configurations containFIFOFULL logic. With the aid of this logic it is possible tostop program execution (STALL) whenever the FIFOthreatens to overflow. This strategy does, however, havethe disadvantage that it slows down the program run time.An additional disadvantage is that the ARM-ETM itselfdoes not provide any facility for determining later, during

Figure 1: ETM trace port for ARM7/ARM9

TRACE32-ICD

PowerTools

TRACE32-ICD

PowerToolsthe complete solution

for system on-chip designs

the complete solution

for system on-chip designs

/

������������������� ��!"�#!��"!����$#!�"���!$

NEXUS AdapterAMP40NS

NEXUS AdapterAMP50

NEXUS AdapterGlenair51

the trace analysis, how high the run time lossactually was.

2.) Reduction of the trace packetsAnother way of preventing a FIFO overflow isby reducing the number of trace packets pro-duced by the data accesses. An option wouldbe to limit the output of the data accesses towrite cycles. This already makes a FIFO over-flow considerably less likely. However if onewishes to see the entire data flow for effectivedebugging, Lauterbach recommends limitingthe output of the trace packets for the dataaccesses to read cycles. The TRACE32-Power-Trace can reconstruct all write cycles on thebasis of the read cycles by means of specialalgorithms. See alsowww.lauterbach.com/cts.gif.If these strategies for reducing the trace pack-ets are not sufficient to prevent a FIFO over-flow it is possible to utilize the filters of theARM-ETM to further reduce the data flow. Thefirst recommendation is to filter out the stackarea from the data flow as the stack opera-tions in particular often result in a FIFO over-flow when changing functions. Another veryobvious idea is to program the trace filters sothat only data accesses to selected variables/memory areas are recorded.

Smart TraceWhen using TRACE32-PowerTrace even a largenumber of gaps in the trace due to overflow ofthe FIFO is not necessarily a problem. A spe-cial process - Smart Trace – makes it possibleto fill in most of these gaps in the trace. Ex-ceptions and read accesses to ports are theonly things that cannot always be reconstructedcompletely. See also figure 2 andwww.lauterbach.com/smarttrace.html.

Tips for the hardware designIn order to achieve optimum recording of thetrace information by TRACE32-PowerTrace, thefollowing points should be taken into account

for the design of the destination hardware:

• Lines for the ETM signals should be as short as possi-ble and of equal length

• 3 ns setup and 1 ns hold time• Destination system should be capable of driving a 50-

ohm parallel termination

ETM for ARM11The ETM for the ARM11 offers three key new features.

1.) Higher compression ratesProgram trace is improved seven fold. Data trace, whichmatters most for overflow considerations, is improvedon average 25% through leading zero removal.

2.) Decoupling of the trace clock from the processorclockThe trace information, specifically the pipeline status in-formation, is no longer output synchronized to the pro-cessor clock. Instead the pipeline status information isincluded in the trace packet as the header.

3.) Suppression of the data packets in the case ofFIFO overflowInstead of stopping program execution if the FIFO threat-ens to overflow, the output of the data flow is suppressed.

Figure 3: ETM trace port for ARM11

Figure 2: Filling the trace gaps by reconstructing the programand data flow with SmartTrace

0

�&��%�')������+�

��)�� *��+(��

#��� ���� ���������������������

Today microcontrollers that output trace information viathe trace port at frequencies beyond 200 MHz are nolonger unusual. The time window for sampling the validdata is thus becoming ever narrower. Consequently smallrun time differences between the trace channels or otherminor faults in the target hardware can easily become asource of errors for the trace recording. As a result finetuning of the sampling instant is becoming an increas-ingly important factor. For this reason Lauterbach is roll-ing out a new generation of preprocessors and NEXUSadapters in mid-2004 that will have an autofocus capabil-ity. Autofocus supports the automatic setting of the opti-mum sampling instant as well as automatic setup of otherhardware features through FPGA-based hardware.One of the main functions of a preprocessor/NEXUSadapter is to receive high speed data from the trace portof the target systems’ microcontroller and transfer it atlower speed into the trace memory. At high frequenciesthe quality of the trace signals can be impaired by a numberof different factors including line length, resonances,cross-talk from other signals, tolerances of the compo-nents, and so forth. If the sampling instant for the tracedata is not optimally selected the error rate in the record-ing of the program and data flow increases.Up until now the sampling instant had to be correct bydesign and only the setting of the reference voltage hasbeen automatic on most preprocessors/NEXUS adapt-ers. The reference voltage could be adjusted manually toreduce the error rate and it was possible to switch on a

termination voltage to improve the signal amplitude. How-ever, this concept might not be sufficient at high frequen-cies beyond 200 MHz. A considerably more complex pro-cedure has been developed to assure signal integrity atthose frequencies.

Assuring signal integrity takes place in two steps:

1. Hardware adjustmentAs soon as the microcontroller outputs data via the traceport the preprocessor/NEXUS adapter determines thefollowing data via FPGA-based hardware:

• the ideal termination voltage• the ideal reference voltage separately for all clock and

data channels• the ideal clock delay, and• the ideal delay for every single data line

2. Testing the trace channelsFor testing the trace channels the microcontroller mustthen output a fixed data pattern via the trace port. Thisdata is then transferred to the trace memory by the pre-processor/NEXUS adapter and can be verified by theTRACE32 software. That way it is possible to verify thatthe automatic hardware adjustment was successful.Ifnecessary the fine tuning of the sampling instant can bere-adjusted for individual trace channels.

The first NEXUS adapter equipped with autofocus func-tionality will be the NEXUS adapter for the Super10, fol-lowed by the preprocessor for the ARM-ETM.

Flex extensionsSince mid-2003 Lau-terbach has offered arange of “Flex Exten-sions” for the variousdifferent preproces-sors/NEXUS adapt-ers. These extensionsguarantee good trans-mission quality, evenat high frequencies,between the destina-tion system and the TRACE32 development tool. Seealsowww.lauterbach.com/adflex.html

Mictor flex extension, 55 mm, verti-cal to vertical

1�

$� ���%�����������

������������������� ��!"�#!��"!����$#!�"���!$ Anyone who has struggled with complex error

scenarios or random system crashes duringsoftware integration will appreciate the advan-tages of an efficient trigger unit. The benefitsinclude:

• planned, systematic troubleshooting• stopping the trace recording or program ex-

ecution at specific points• optimal utilization of the trace memory• selective recording and analysis of informa-

tion• improved run time monitoring of the entire

systemThe efficient use of a trigger unit also calls fora good knowledge of the hardware and soft-ware of the destination system as this is thebasis for developing suitable trigger strategies.However, the work invested in this preparationis always more than compensated by substan-tial time savings in the debugging process.In order to provide the developer with moreeffective support in tracing difficult systemfaults the following Lauterbach developmenttools have been equipped since November2003 with a “complex trigger unit”:

• PowerTrace• PowerProbe• PowerIntegratorWe will now review the trigger and filter func-tions of this “complex trigger unit” as it appliesto the various members of the PowerTools fam-ily.

PowerTraceAlthough the complex trigger unit is a perma-nent component of the PowerTrace hardware,different software is needed for each of theindividual processor architectures.

1. Bus trace systemsArchitectures that visualize the entire programand data flow on the external address and databus are easiest to work with. An example ofthis type of architecture is the Infineon EGOLD.

If, for example, you only want to record the cycles of aparticular function or only the write accesses to a spe-cific variable, the address visible on the address bus canbe used as the input event for the complex trigger unit.See also Figure 1.

2. FlowTrace systemsProcessor architectures that output the program and dataflow via a special trace port usually operate by usinghighly compressed trace data. This compression allowsthe entire program and data flow to be accessed via anarrow trace port even at high frequencies.In order to be able to use this highly compressed data forthe complex trigger unit it is necessary to reconstructthe complete program and data addresses out of the com-pressed data in real-time. At the time of writing the onlyarchitecture that allows a problem free implementation ofsuch a reconstruction is the SH4 family from RenesasTechnology. All other architectures still rely upon the fil-ter and trigger options that the semiconductor manufac-turer has implemented.

3. NEXUS systemsWith architectures that have a NEXUS interface it is notpossible to undertake a runtime reconstruction of the pro-gram addresses. But it is normally possible to carry out areconstruction of the data addresses.The NEXUS protocol does, however, have a number ofmessage types that can be used effectively as inputevents for the complex trigger unit:

• Watchpoint hit messages• Ownership trace messages• Hardware event messages, etc.

As an example the NEXUS interface can indicate that aspecific function has written a defined data value to a

TRACE32-ICD

PowerTools

TRACE32-ICD

PowerToolsthe complete solution

for system on-chip designs

the complete solution

for system on-chip designs

Figure 1: Selective data trace for a bus trace (Infineon EGOLD)

11

�&��%�')������+�

��)�� *��+(��

variable via a “watchpoint hit message” . This watchpointhit message can then be used by the complex triggerunit to record a specific number of cycles in the traceand stop the program after that. Figure 2 illustrates anexample of the use of the complex trigger unit for NEXUS.

After the processor architecture has been configured forthe PowerTrace the complex trigger unit offers the follow-ing options:

• Filtering of the trace information• Definition of complex trigger conditions that can lead

to termination of the trace recording or program ex-ecution

• Time supervision of individual program sections• Generation of a trigger signal for an external device

The complex trigger unit has the following resources atits disposal:

• At least 2 address/data comparators• 3 x 45-bit time and event counters• 4 trigger levels• 2 trigger flags• 2 trace markers

PowerProbeWith the Lauterbach PowerProbe the developer can inte-grate signals from port lines, communication interfacesand external interrupts into the debug environment. ThePowerProbe supports 64 input channels with a samplingrate up to 100 MHz or 32 input channels with a samplingrate up to 200 MHz or 16 input channels with a samplingrate up to 400 MHz. The trace has a memory depth of

256K entries.The complex trigger unit includes 8 data selectors whichgenerate trigger events. Each data selector can beconfigured to trigger on a freely definable data patternover all 64 input pins.

Together with three 45-bit time/event counters, 4 triggerlevels, etc. complex trigger conditions can now be de-fined which:

• filter the trace information• interrupt recording to the trace memory• start the pattern generator• generate trigger signals for external devices• or ensure that the debugger stops program execution

Figure 3 shows an example in which the states of inputchannels x.0-x.2 are only recorded in the trace memoryas long as input channel x.3 is active.

PowerIntegratorIn summer 2003 the PowerIntegrator was added to thePowerTools product family to provide a universal bus traceand further extend the product family. The PowerIntegratorcan be connected to the target system via standardprobes to recordbus trace data. Arange of supportpackages providea quick and simplemeans of transfer-ring the recordedinput signals into aprogram and dataflow trace. Thetrace contents pro-cessed in this waycan then be dis-

Figure 2: Changing the trigger level after writing 1 to flags[2](STMicroelectronics NEXUS Super10)

Figure 3: Selective recording of x.0-x.2 as long as x.3 is active

Figure 4: TRACE32-ICD in-circuit debug-ger and PowerIntegrator on a Power-QUICC III evaluation board

������������������� ��!"�#!��"!����$#!�"���!$

TRACE32-ICD

PowerTools

TRACE32-ICD

PowerToolsthe complete solution

for system on-chip designs

the complete solution

for system on-chip designs

played and evaluated together with the debuginformation.The PowerIntegrator has 204 freely configurabledata channels, of which 12 have the option ofbeing used as clock inputs. The following sam-pling rates are possible via active probes:

• 500 MHz in timing mode• 200 MHz in state modeThe sampling threshold for the signals can beselected optionally in a range from 0 to 5 V.The PowerIntegrator has a trace memory depthof 512 KFrames. Each entry in the tracememory is provided with a time stamp. Thetime stamp has a width of 48 bits and oper-ates at a resolution of 4 ns.In a similar way as the PowerProbe, the inputevents for the complex trigger unit can be sig-nals from individual data channels or datachannels can be combined to form a triggerword (max. 204 Bit). When using the Power-Integrator the most important trigger words willbe on the address and data bus. Both triggerwords are already predefined by the supportpackage and are thus available directly.

The time monitoring of a function provides an example ofthe use of the complex trigger unit when using thePowerIntegrator. One trigger word is defined for the entryaddress and another for the exit address of the function.By setting up the filtering only the entry and exit addressof the function are then recorded in the trace memory.The result can also be evaluated statistically by thePowerIntegrator. See also Figure 5.

Figure 5: Time monitoring of a function through selective re-cording of the function entries and exits

Sender:

Name _________________________________________________

Company _________________________________________________

Address _________________________________________________

Phone _________________________________________________

email _________________________________________________

Phone: (508) 303 6812 FAX: (508) 303 6813

We use the following processors:

___________________________

I am interested in the followingdevelopment tools:

� �TRACE32-ICD

� �TRACE32- PowerTrace

� �TRACE32- PowerIntegrator

Please send me information on:

email: info_us@lauterbach.com