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

debug PERL is a better option when extra text processing is required. PERL is a public-domain text processing language originally written for UNIX, has no line limits, and is available for most operating systems. Thus, it can programmatically determine how to handle things in the trace-data ﬁle such as pipeline stalls or gaps in the data. To see PERL in action, consider the following example of an L2 cache stall, something that’s nearly impossible to ﬁnd without using trace data. The example deals with a multichannel application with multiple processing threads that interacts with peripherals such as audio codecs. Trace is ﬁrst set up to start when the desired channel processing begins. Conﬁgure it for “Stop on buffer full” and run the program. Set the source directory so the C source code for functions outside the main application directory can be correlated. When the program stops running, go to the trace ﬁle and operate on it with some other tools. Start with OFD, an object ﬁle display utility, to create an XML ﬁle that contains information such as function addresses. Then use a PERL script (func_info. pl, available on www.embedded.com/ code/2007code.htm) to parse the XML output to provide just the function information. It produces a listing of all functions ranges and sizes in CSV format. Basically, it shows each function, the C/Assembly ﬁle it came from, its function range (start -> end PC) and its size (end - start). It’s fairly fast because it strips out unneeded elements of the XML ﬁle before processing it. Run a second PERL script (posted online at www.embedded.com/code/ 2007code.htm) on those results. The code searches the saved trace CSV ﬁle for pipeline stalls that are above a user-deﬁned threshold, here set to 20. By running this script, warnings about functions in which most pipeline stalls will appear. This way, developers can take a closer look at those functions and take the necessary steps to remove the bottlenecks, such as placing the functions in internal memory or by changing the linker command ﬁle. Lines of interest can also be correlated to the function and ﬁle names. The result of this script is another CSV ﬁle, called rf5-threshold-20.csv, which consists of a table whose columns are program counter, access count, average stall cycles, maximum stall cycles, function name, and ﬁle, as shown in Figure 3. By using Excel, the stall information can be easily processed in the CSV ﬁle. In particular, summing up all the average stall cycles by function will show which one is the greatest contributor. In this case, it’s a function named FIR_TI_ﬁlter. Take a closer look at the trace in- formation associated with FIR_TI_ﬁlter and locate the lines of code that seem to be causing pipeline stalls. In Figure 3, there are 144 stall cycles between program address 0000589C and 000058A0. Return to the trace display on the IDE and get more information about why the stall at PC 0x589C is occurring. It seems to be due to a load instruction, likely making it an L2 stall. In addition, 0x58A0 is also a load and again likely an L2 stall. Further analysis eventually reveals that the function handle is in external memory, and this is the cause of the stall. Further processing of the CSV ﬁle, however, reveals other stall issues. While FIR_TI_ﬁlter had the largest pipeline stall, there are other functions with smaller stalls, but they occur more frequently. To compare the effect of all the stalls, one technique is to multiply the number of accesses by the average stall cycles and use a spreadsheet sort to ﬁnd the highest value. In this case, the comparison reveals that the function CLK_F_getshtime is accessed 1,499 times. Even though it has only 38 stall cycles, its total impact using this metric is 56,962 within a total impact value of 73,639. This would represent another area where the developer could spend some time to optimize system operation. Stephen Lau (s-lau2@ti.com )is a product manager for emulation products and technology at Texas Instruments. 21 www.embedded.com/europe | embedded systems design europe | OCTOBER 2007 017-018-020-021_ESDE.indd 21 9/10/07 15:23:52 http://www.embedded.com/code/2007code.htm http://www.embedded.com/code/2007code.htm http://www.embedded.com/code/2007code.htm http://www.embedded.com/code/2007code.htm 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.