Current trends in processor technology such as reconfigurable cores, multicore devices and customized system-on-chip (SoC) are creating interesting dilemmas for those tasked with writing and debugging code targeted for these devices. These developments also create interesting challenges for embedded tool developers.
As microcontrollers are introduced with more on-board RAM, Flash and peripherals, the necessity for external buses is diminishing. The demand for more on-board peripherals and lower pin counts is making it hard for chip manufacturers to justify "wasting" pin allotment on external data and address buses.
The silicon vendors are not totally heartless towards software developers. Many are dedicating a small number of pins for debug purposes. Methods such as BDM, JTAG (IEEE 1149.1) and ONCE (on-chip emulation) are being utilized by more and more devices to provide fast access to on-chip debug information. In lieu of dedicated signals some devices allow the programming of specific pins to provide similar functionality.
Typically an intermediate piece of hardware is used to buffer on-chip data and control to the debug environment. TASKING's open debug interface, GDI, to the CrossView Pro debugger provides a mechanism that facilitates the interface of this intermediate hardware (ICE, BDM pods, etc) to the debugger. We will continue to support and improve this interface in our future products. We are working closely with the ICE and POD manufacturers to insure that CrossView Pro and future products deliver the performance expectations of our customers.
Multi-core debugging
TASKING's strong partnership with the world's leading microprocessor and microcontroller manufacturers puts us on the forefront of silicon technology. With the help of these partners, TASKING is also closely monitoring two other trends in silicon - the integration of multiple cores and the integration of multiple communications peripherals on a single device.
To support multi-core debugging, TASKING will be introducing a debugger architecture that supports multiple processes. From the debugger's point of view, a process is a piece of software that runs on a unique processor core. This core could be a unique device or part of a multi-core architecture. Since multiple processes can run concurrently on a single core ( i.e., a multi-threaded environment managed by an RTOS), TASKING's new debugger will be able to present process context workspaces for multiple software processes running on multiple processors (multi-core or discreet devices). A context presentation would include source, register, stack and data information. If a real-time operating system is in use, the context workspace could be extended to include task-related windows. This environment also presents the opportunity for complex breakpoints that will allow for triggering across processes.
Remote debugging
Since network connectivity is a design goal of most devices under design today, a reasonable expectation of our customers will be the ability to debug their product remotely. As The Embedded Communications Company, TASKING is very sensitive to this expectation.
The new TASKING debugger will include facilities that support remote debugging over a network. Included in this capability is a debug server that could run as a task on the target under debug. The debug server will handle communication to and from the TASKING debugger over a communications channel that the embedded system designer chooses. In addition, the core and the GUI of the TASKING debugger will be configurable and customizable. This will permit users to create unique debug capabilities they can build into their product to address specific market needs.
In newer embedded designs the need for connectivity often goes hand in hand with the desire for remote reprogrammability. The complete TASKING tool chain will shortly support this kind of functionality. Product features like support for flash programming and dynamic linking and locating will be integral to TASKING's next generation tools.
Another natural extension to the debugging of networked devices is the presentation of communication performance data to the debugger. TASKING's next generation debugger will provide facilities that can report network statistical data (a MIB for instance) kept at the target. Correlating this data with code execution will give designers additional insight on the performance of their application.