|
Part three explains how emulators control programs on the DSP through functions such as breakpoints and single-stepping. Part five introduces the concepts of real-time data collection and data visualization. It also explains how compiler options affect the debugging process.
Emulation Capabilities
Emulation provides a standard set of operations for use during the integration and debug phase. A few of these capabilities are described below.
Breakpoints
One of the common capabilities supported by emulation technology is the breakpoint. A breakpoint will interrupt the DSP and allow the developer to examine data or registers on the target system. The breakpoint capability is controlled by the emulator. The emulator executes the protocols to stop the CPU at the earliest possible point in the execution stream, as well as enabling the developer to continue execution from the current location when necessary. Most breakpoints are synchronous in that the transition from a running state to a paused state happens immediately.
A software breakpoint is one form of synchronous breakpoint. A software breakpoint function will save the instruction at the specified breakpoint location and replace it with a different instruction which creates an exception condition. This transfers control to the controller which saves the context of the important DSP status registers. Control is transferred to the host debugger and the developer can then "peek and poke" at registers and variables while the CPU is paused. The reverse is done to allow the CPU to continue execution form the current location. These type of breakpoint is useful for target systems which contain RAM to allow the writing and replacing of instructions.
An additional form of breakpoint is called a hardware breakpoint. This form of breakpoint is implemented using custom hardware on the target device. It is useful for DSP devices that have complicated instruction fetch sequences and for setting breakpoints in systems with ROM where replacing instructions using the "software" breakpoint technique is not possible. The hardware logic is designed to monitor a set of address and status signals on the device and stop execution of the device when a code fetch is performed from a specified location.
Event Detectors
The event detectors in Figure 9 provide an advanced form of target visibility and execution interruption. The bus event and auxiliary event detection logic in Figure 4 provides emulation break capability on a complicated set of events occurring in the system. In addition to the code execution breakpoints provided by hardware and software breakpoints, the event detectors provide breakpoint capability due to data accesses and other combinations of address, data, and other system status. The event detectors in Figure 9 consist of a set of comparators and other logic. The user, from the debugger interface, can program these comparators to look for a specific pattern of events in the system. The comparators trigger other event logic to perform certain actions such as stop execution, increment a counter tracking a specified occurrence of an event, or generating a signal on a pin that can be used by some other piece of equipment to perform some other operation.
Figure 9 The developer can program the event counters and comparators from the user interface. The developer can program complicated scenarios and is limited only by the amount of logic on the device used for this capability. (Courtesty of Texas Instruments.)
Once programmed by the developer, the bus and auxiliary event system logic will monitor the running system for the conditions programmed into the logic. Once the condition is detected, the programmed response is generated. This may be a command to the emulator to halt execution or the setting of an output pin to inform another device or piece of test equipment. One of the advantages of on-chip logic like this is the ability to "see" what is going on inside the device. Using the external pins for visibility is limited to just those signals or conditions which the pins represent. DSP vendors have improved this capability by providing on-chip logic to provide visibility inside the DSP. This is key as DSPs and other embedded processors migrate to system on a chip (SoC) architectures which, by definition, limit the amount of visibility into the device.
Because these event triggering capabilities are built directly into the DSP processor, they have no overhead in terms of either CPU cycles or memory. Thus when activated via user control, the event triggering device logic detects all events nonintrusively, without stopping the CPU. This preserves the real-time behavior of the system and can reduce debug time because the developer does not have to set breakpoints on each individual event, and then step repeatedly until the next complex event occurs.
|
