[Product Innovation]
Eradicate Hardware And Software Bugs On Multicore SoCs
Able to debug complex SoC designs, this powerful emulator leverages a common JTAG port to diagnose software running in multiple deeply embedded processors.
System-on-a-chip (SoC) designs have emerged as system-critical solutions to reduce size, complexity, power, and cost. Additionally, technology improvements over the last few years have allowed SoC solutions to grow more complex. Relatively straightforward combinations of a single CPU, some memory, and some custom functions have become highly complex SoCs with hundreds of processor blocks. As designers craft these ever more complex single-chip systems with multiple processor cores, debugging the software for these embedded processors becomes increasingly more difficult.
Monitoring one core at a time provides little insight when multiple cores must interact. Designers need a debugging capability that lets them concurrently monitor multiple software streams that execute on multiple, disparate processor cores--CPUs, DSPs, custom functions, and so on. Moreover, the tool must be scalable to permit the debugging of literally hundreds of cores that can now reside on a single chip.
Embedded Performance Inc. (EPI) has developed such a debugging system. It provides support for a wide range of processor types, as well as the ability to scale up to handle ever-increasing numbers of cores on-chip. Known as Multidimensional Scaling Support (MDS2), the technology addresses the ongoing multidimensional scaling of SoC designs.
The basic system consists of a host computer that runs the debugging software, a serial or Ethernet interface to the MAJIC pod, which measures just 2 by 6.5 by 7.5 in., and the JTAG interface to the SoC under scrutiny (Fig. 1a). The MAJIC pod is an intelligent debug probe that incorporates the MDS2 technology (Fig. 1b). In the MAJIC pod is a microcontroller with its own local SRAM, Flash memory, JTAG control engine, trigger logic, and Ethernet interface. The MDS2 software supports multitap devices, multicore chips, multiarchitecture environments, multisession debugging, multicontext CPUs, and on-chip trace buffers.
To support complex designs, engineers at EPI crafted a combination of software tools and a multiprocessor advanced JTAG interface controller, the MAJICMX. Together, they form a powerful and scalable solution for multicore SoC debugging. The tools will work with various debug software solutions, most notably, EPI's own EDB host-based debugging software. However, the tools will also integrate well with other debug software that follows industry-standard application programming interfaces (APIs). Some of those interfaces include MDI, RDI, Tornado, and the Microsoft platform builder (Fig. 2).
In addition to handling multiple processor cores, the tools let designers debug multithreaded software by supporting hundreds of multiple-context operations. Multisession support lets designers run multiple debug sessions concurrently using the same MAJICMX and debug interface to the SoC. This feature can be used to support debugging multicore and/or multiarchitecture applications.
Multiple debuggers can employ the same MAJICMX probe to concurrently communicate with individual cores on the JTAG chain. Each debugger can target a different core and simultaneously communicate with the selected cores. The debuggers could even reside on multiple host computers and connect to the probe via the Ethernet port.
With the MDS2 software, designers will be able to nonintrusively and selectively communicate with the on-chip cores through a JTAG interface. For most on-chip debug facilities, the MDS2 won't use any target memory, so it requires no porting to the target system. Each processor family that the tools support comes with its own configuration kit that provides the architecture-specific information necessary for the tools to complete processor control. This way, designers can start, stop, and single-step each core. Additionally, they can read and write to registers, memory, and system I/O lines, as well as download code to target RAM.
To use the MDS2 technology, cores in the SoC must include some circuitry that lets the external probe access the CPU, DSP, or other core logic and registers. This includes support for traditional debug tasks typically associated with an old-fashioned target monitor. Luckily, when they're delivered from the intellectual-property suppliers, the cores already contain much of what's required.
The on-chip debug access and control circuitry must allow access to the target memories, caches (both on- and off-chip, if applicable), internal registers, coprocessor registers, and other processor status bits, like program counter and call stack. Ideally, the debug circuitry would also include DMA to target memory. This will facilitate the downloading of programs prior to testing.
The debug circuitry should also allow the setting and management of breakpoints. In the optimal case, the core would support hardware breakpoints, as well as traditional software breakpoints and a single-step capability. A number of good standard on-chip debug specifications are already available, which the MDS2 tools can leverage--EJTAG, Nexus, EmbeddedTrace, N-Wire, and others. Of these, the EJTAG 2.0 specification provides a good, basic guideline for access and control capabilities.
Beyond the access and control functions, the SoC must include some type of communication port that's independent from the I/O ports used by the application program. Most digital SoCs now incorporate JTAG for boundary-scan testing. Therefore, that port can be used to access the on-chip debug logic. Lastly, the core blocks must include some type of on-chip trace circuitry because it's impractical to bring out all of the signals needed for tracing each processor's execution flow. The on-chip circuits must encode the trace information into a manageable number of signals and then bring the data off-chip at a manageable data rate.
Reprints
