Co-Design for SOCs -> On-chip support needed for SOC debug

On-chip support needed for SOC debug
By Richard York, ASIC Designer, John Sharp, Development Systems, Group Manager, ARM Ltd., Cambridge, U.K., EE Times
June 15, 1999 (12:02 p.m. EST)
URL: http://www.eetimes.com/story/OEG19990615S0024

The same functionality provided by traditional de-bug methods is needed for silicon-on-chip (SOC) solutions. The features provided by an ICE and supporting software can be broadly divided into five major categories:

The really difficult bugs to track down are those that occur in situations where there is an unforeseen an d hence unpredictable interaction between the application software and hardware. These bugs can be intermittent and usually only occur when the system is running at full speed; simply starting, stopping or stepping the processor does not expose the problem.

An historical nonintrusive trace of instruction flow and data accesses can provide the extra information needed to identify the bug. For example, an application crashes during an interrupt routine. The result of the crash is a memory-protection fault; the cause can not be found using breakpoints and single-stepping methods. The user sets up the trace filter facility to collect trace data only during the interrupt routine and the trigger to stop tracing when the protection fault occurs. The filter facility limits the amount of information that has been traced and analyzed.

The trigger ensures that the trace information around the bug has been captured and not overwritten. As trace buffer depths are finite, these features are important to ensure that the buffer is filled only with relevant information. They also save time by limiting the information that needs to be analyzed to find the bug. Trigger and filter conditions can be changed to refine what trace data is captured and when.

Another key feature is the ability to change a processor's registers or memory without stopping the system. This is very useful in electromechanical applications. For example, when debugging an engine-management system, the ability to change the control parameters of the engine without having to stop it will save time.

Many ICEs provide emulation memory that can be forcibly switched into a processor memory map. This is achieved by monitoring all processor accesses; when access is made to a region that has been designated to be emulation memory the access is rerouted. One of the major uses for this memory is the replacement of ROM during development, enabling the user to modify code that would normally be resident in ROM, allowing for shorter code- development cycles.

The most recent addition to the embedded-system developer's debug tool set is the use of code coverage and analysis tools, which provide users with several benefits including the ability to prove test coverage and reduce code size; improve code performance, and provide minimum and maximum execution times for an algorithm.

The code coverage and analysis tools are usually resident on the host controlling the ICE or logic analyzer; the information required is provided by the trace facility. These tools set the trace trigger and filter functions and then use the captured data to provide the user with the relevant information.

All these functions are features of current ICEs, which are now required in the SOC world if these systems are to be efficiently debugged. The ARM solution puts the real-time components of in-circuit emulation into the SOC. There are several advantages in using this approach. First, the debugging can be done at full processor speed and it can be d one on the final product. And, it is scalable for multiprocessor devices and allows the use of standard tools for all of ARM's core-based SOCs.

The methodology adopted for use in the various ARM architectures uses three techniques to provide this functionality: EmbeddedICE logic, real-time trace and a real-time monitor.

The EmbeddedICE logic, which is an integral part of an ARM, contains breakpoint registers that compare the value on the core address, data and control buses against values programmed into the registers. For example, the logic may be programmed to generate a breakpoint when an instruction is loaded from a particular address or a particular data value is stored to a given location. When a breakpoint occurs the processor will be stopped and will then enter debug state. Once the core is in this state memory and register contents can be examined or modified, images can be loaded, code can be stepped or execution restarted. This logic provides all the standard run-control debug fea tures.

The real-time trace subsystem used by all ARM cores embedded within an SOC is made up of three elements: an embedded trace macrocell, a trace port analyzer and trace debug tools. With them it is possible to trace instructions and data accesses in real-time.

Basically, the trace macrocell monitors the ARM core buses and passes compressed information via the trace port to the traceport analyzer, an external device that stores the information from the trace port. The trace information is compressed so that the analyzer does not need to capture data at the same bandwidth as an analyzer monitoring the core buses directly. This has the benefit of either lowering the cost or increasing the amount of processor activity that can be traced.

The debug tools retrieve the data from the analyzer and reconstruct an historical view of the processor's activity, with data accesses to memory interleaved. The trace display includes full symbol information and links to the source code being debug ged, allowing rapid understanding of the trace data. The trigger and filter logic, which is a part of the embedded trace macrocell, is configured via the JTAG port.

The real-time monitor was designed to provide two major functions with minimal intrusion on the application execution time: the debug of foreground tasks while interrupts continue and the ability to read and write memory without stopping the processor.

Using the on-chip EmbeddedICE logic, a breakpoint forced the processor into debug state and stopped the processor clock. However, with the recently announced ARM9E and ARM10 cores enhanced EmbeddedICE-RT logic allows a breakpoint to either stop the processor or generate an exception. If an exception is generated, the processor is vectored to a small monitor program that provides full debug functionality-less than 2 kbytes of code and data-resident in target memory.

Interrupts are still enabled, allowing application interrupt handlers to run and commands from the debugger to be received via JTAG. These commands provide full debugging of the foreground task: It can be stepped or restarted, further breakpoints can be set and memory can be read and written.

To read or write memory without stopping the processor, the user selects a memory location to be read or written, and the debugger sends commands via JTAG to the monitor program, which momentarily interrupts the application. The monitor program carries out the required operation; control is then returned to the application.

In SOCs the common use of flash memory and the execution of ROM code from faster on-chip RAM alleviate the need for emulation memory. Fast code download to the memory is necessary to reduce design cycles.

For example, using JTAG and the EmbeddedICE logic, ARM's Multi-ICE product achieves downloads of 120 kbytes/second, so a 1-Mbyte application can be downloaded to on-chip RAM in 8 seconds. Multi-ICE can also reprogram on-chip flash memory.

ARM's debug solution provides the fun ctionality of a traditional ICE for SOCs, with no external visibility of core signals running at frequencies in excess of 100 MHz.