Co-Design for SOCs -> Software debug shifts to forefront of design cycle

CodeTest Native and CodeTest-SW-In-Circuit were built in direct response to the need of customers for help in meeting new demands in the embedded market."One common complaint was that with the increasing short time-to-market, time devoted to debugging code was also shrinking," said Jay Gould, senior product engineering manager for the company's software analysis tools. "And, with more powerful processors, the size and complexity of the code was also increasing."

As a result, developers are looking for ways to do more code debugging and do it earlier in the process. "Before they even got to the stage at which they would employ the original CodeTest hardware, in many cases, they had gone through at least two additional code- debug iterations," Gould said. "One was on a host system in the engineer's office computer, using any of a number of software-debug tools designed for the PC or workstation, and next on the target, using some early prototype board using a target-based utility supplied by the vendor whose RTOS they were using."

Using codesign techniques, Applied Microsystems' Jay Gould is pursuing a unified approach to testing code on target systems. By testing software before hardware is built, potential snags are anticipated, shortening product development.

However, Gould pointed out that this meant they had to go through the process of selecting and learning how to use three separate debugging tools, each of which might use different metrics, test methodologies and user interfaces. "Not only does this cost them some of the time in the already-shrinking development cycle," he said, but "it also introduces additional sources of error in the code because of differences in the way each tool performs its functions and because of errors that might be introduced converting one set of metrics to another."

Also, early in the development process, developers said they did not want to make a decision on which processor to use, which they would be forced to do if they used a hardware-based methodology with a logic analyzer, in-circuit emulator or a probe such as CodeTest.

When Gould and his design team sat down and evaluated customer comments, they determined they had a solution and a new market opportunity: software implementations of its CodeTest hardware probes based on the same source-level instrumentation methodology. "The reality of the customer-development cycle is that it includes more than the narrowly defined embedded debug and test cycle," noted Gould. "Another reality is that each of its phases consists of different test needs, subsequent tool-learning curves and new data files. At each phase, these renewing sets of challenges play a major role in the shortage of time and expertise required to generate quality software as quickly and efficiently as possible."

The two software-only versions of CodeTest are targeted at solving the debug problem at two critical stages early in the development process. One is at product definition, where desktop tools are most appropriate, because, typically, no target hardware is available. "Indeed, a decision may not have been made yet as to which processor to use," said Gould.

The other point at which a software-only version would be useful is still early in the development process, but begins with the arrival of the first hardware, where the first attempts at hardware and software integration must begin. At that point, the first impulse of developers is to use hardware tools, such as logic analyzers, in-circuit emulators and probes to figure out why the system is not working properly. "Often there is a struggle for engineering time on the target hardware because there are few systems built," he said, and if probe hardware is prohibited during that period due to expense, mechanical-connection issues, physical restrictions or chip support, the customer must find some other type of tool for the job.

Software-only RTOS tools and utilities are often used to understand the system at that stage, said Gould. While they are not necessarily detailed or accurate, they are better than native tools, since they are running in the real hardware, he said. Often software-only tools that run in the hardware system degrade the system while they capture, tabulate and communicate the information to a graphical user interface (GUI) on some local workstation.

Using the same source-level instrumentation techniques employed in the hardware version, the software-only CodeTest-Native and CodeTest-SW-In-Ckt were designed to be used a t those two early stages. At the earliest stages, before hardware is available, the native version is used on the desktop or workstation host. While the instrumentation measurements are not real-time target metrics, they are the best available without target hardware, noted Gould. "The developer can improve code-testing coverage, search for and analyze memory leaks and use deep trace to validate the correct software operation," he said.

Once target hardware is ready, the developer uses the SW-In-Ckt version to move from desktop-simulated measurements to target hardware run-time measurements. The instrumentation, file formats for scripts and data and the user interface are all preserved from the native environment for use in that phase. "There is no learning curve or difference in instrumentation strategy in moving from native to software in-circuit technologies," said Gould. It is only when the project goes to system test or validation, that the traditional hardware versions of CodeTest would be used .

The native software version, which employs the same software modules used on the hardware version of CodeTest, supports modules for software trace, memory analysis, decision and statement coverage and modified condition decision coverage (MCDC). The SW-In-Ckt version also supports numerous RTOSes for views in the trace module. The software-only versions of CodeTest require some dedicated memory on the host and on the target, on the order of about 200 kbytes.