Embedded Systems Design Europe - October 2007 - (Page 20)

debug make system-level tradeoffs by measuring elapsed cycles, branches, pipeline stalls (critical to memory design), cache hits and misses (good to detect code thrashing and for determining the minimum required cache size), interrupts, DMA interrupts, and other events. After the designer sets the trigger, runs the code and an event occurs, the debug unit triggers and starts storing program addresses, timestamps, and optionally the read/write addresses and data values. It can even correlate the data access to the program counter. The storage continues until the trigger detects a predeﬁned condition. Additionally, the data memory can be set as a circular buffer, where the program runs continuously and the debug unit overwrites old data until the event of interest happens, the system fails, or designer physically stops the recording. The data is stored in a compressed format to make the best use of memory. Thus, the length of the data capture in real time varies with which information is stored as well as the nature of the program. For instance, an FIR ﬁlter program has a large number of loops so it compresses very well; in contrast, programs that jump around in memory don’t compress well. To provide a rough indication of what’s typically possible, consider a DSP program controlling a GSM voice codec. The CPU runs at 1 GHz and the debug memory can hold one million samples. That corresponds to 1 ms of actual operating time, which in most cases, is sufﬁcient to provide the information about the event leading to the failure. Having this data doesn’t help immediately. The program needs to be examined from an integrated development environment (IDE). A simple way is to attach a 60-pin connector from the CPU to the emulation hardware. The link supports a data rate as high as 333 MHz using a 167-MHz dual-edge clock. It converts the data into a form usable by the IDE and then sends the data to a PC over a USB 2.0 host-port interface running at 480 Mbits/s. With the IDE, the user sets up the 20 chip-based triggering and then evaluates results in a trace display. It shows the program address and data, source and disassembly data, and even timestamps. In addition, it can show parallel cycles, identify pipeline stalls, and correlate data read/writes to the program address. It’s thus possible to walk through a program line by line, looking at past events that might have led to the problem. Other functions perform code proﬁling and code coverage or give histograms that show, for instance, the percentage of time spent in each program function. Now let’s look at how a trace display can help debug difﬁcult problems. As shown in Figure 2, a programmer can see exactly where the program terminates. By scrolling through the trace data, the history of calls the application made are listed, making it easy to track through the events that led to the error condition. Also, when an instruction in the code is selected, the source-code window displays. Further, the trace display can prove helpful in program optimization. For instance, the trace debugging tool can automatically identify a pipeline stall. Programmers know that a stall of just two cycles can degrade system performance, especially if the stall appears in a frequently used loop. And if such a stall contains multiple cycles, performance suffers even more. Finding these stalls with conventional tools is difﬁcult and eliminating them can bring great performance beneﬁts. SPREADSHEETS AND TEXT PROCESSORS The display of trace information in the IDE can help uncover many problems. However, in some cases, alternate views of this information can speed up debug or improve system performance. For instance, Excel is good at graphing and charting. Program lines can be plotted and executed over time to get a quick visual overview of where the program is spending most of its time or if it fails to reach certain sections of code. This spreadsheet program, though, has limited text processing as well as an intrinsic limit of 65,536 lines. OCTOBER 2007 | embedded systems design europe | www.embedded.com/europe 017-018-020-021_ESDE.indd 20 9/10/07 15:23:37 http://www.embedded.com/europe

Table of Contents Feed for the Digital Edition of Embedded Systems Design Europe - October 2007

Embedded Systems Design Europe - October 2007 Contents Linux Set to Dominate Torvalds Updates Linux Kernel ARM Establishes Smart Card Foundry Program Emerson Buys Motorola's Embedded Comms Group LynuxWroks and TTTech to Cooperate on Avionics MontaVista CEO Looks for Acquisitions in Europe Ready: Multiprocessing Technology Provides Opportunity Automotive to Drive MCU Market New Supporters Join COM Express Group Analyst Weighs TI Versus Xilinx Versus PicoChip Cover Feature: Embedded Systems Security Has Moved to the Forefront Trace Exposes the Toughest Real-Time Bugs Employ a Secure Flavor of Linux Use an MCU's Low-Power Modes in Foreground/Background Systems Transporting Video Over Wireless Networks New Products Advertising Contacts

Embedded Systems Design Europe - October 2007

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.