Logic analyzers, debuggers and emulators are traditionally used in embedded designs to capture data values at a given location off the system data bus. This technique works as long as every access (read and/or write) occurs over the external data bus. Additionally, the visibility to the address bus is unrestricted with a sufficiently complex and expensive development tool.
However, once integration begins with caches, on-chip memory or even peripherals, visibility to the data becomes limited. A newly emerging standard, the Nexus 5001 specification, solves the traditional visibility issues of a highly integrated embedded processor, and provides embedded developers with several new capabilities for debugging.
One such capability is the tracing of data as it moves through the application or system. Today's debugging technique often tracks down a "bad" data value by starting to work on the instructions in reverse order of execution, until the real problem has been identified and fixed. The Nexus 5001 standard's ability to supply development tools with focused data values, in an organized and controlled fashion can provide a new and powerful tool for developing and debugging systems.
Formed in 1998 by a consortium of companies to overcome the issues with debugging real-time embedded control systems, under the code name "Nexus," this standardization effort aims to write a real-time debug interface specification and to bring it to the IEEE-ISTO as an emerging and open industry standard. The IEEE-ISTO Nexus 5001 consortium is currently composed of over 24 companies consisting of silicon vendors, hardware and software-development tools vendors from around the world.
The largest issue in the embedded controller market is the ever shortening development time, with small focused teams often developing several generations of products in parallel or rapid succession. To enable the engineering teams to hit the shorter design-cycle times and reduced development cost, a new tools methodology is required. Over the last decade the embedded controller market has seen a proliferation of new microcontrollers, from 8-bit MCUs to DSPs to high-performance RISC processors. Present development tools used to debug embedded-control applications can't provide non-intrusive visibility into the highly integrated embedded processors being deployed today. This problem is further complicated by the ever increasing frequency and complexity of high-performance 32-bit embedded processors.
Essentially, the Nexus 5001 standard will use a technique called branch trace messaging to perform instruction tracking. Branch trace messaging will send only change of flow information over the Nexus 5001 interface. This technique significantly reduces the transfer load of the interface and allows other information to be sent over the interface, such as data trace messages.
When the development tool has access to the source code, linked assembly code and the branch trace messages, the execution flow of the program can be reproduced with no loss of information to the development engineer. A typical C program will generate a change of flow or branch instruction about every 10 instructions. The branch trace message will send the development tool the number of instructions executed between messages to maintain synchronization. In the event no change-of-flow instructions are generated, a synchronization message will be sent every 255 instructions.
The development tools of the future will need to be more consistent from one architecture to another, reducing the learning curve for new embedded processors. The Nexus 5001 standard will be reinforced with a validation suite for the tools and silicon that can be reapplied to new embedded processors and development tools before end users see either.
The IEEE-ISTO Nexus 5001 feature set is a mixture of the best practices in debug interfaces from the past 10 years of industry experience. The difference occurs by bringing them all together in a single industry-standard debug interface to provide the industry with distinct advantages in software debug and calibration.
While many of those features have been deployed on microprocessors over the years, none has implemented all of them with a real-time debug. The IEEE-ISTO Nexus 5001 specification includes standard features for setting breakpoints and watchpoints on data, and instructions for the intrusive and non-intrusive run control debugging. The specification will deploy several unique features for tracking down the toughest bugs. Some of these new features include ownership trace messaging, data trace, memory subsystem, port replacement, program trace, overrun and error messaging.
The interface protocol and the physical pin interfaces are based on the JTAG pins for the most basic functions. To reduce the information being sent over the interface, three features were added. The features were designed to increase the performance of the debug interface without significantly affecting the system cost.
First, the optional auxiliary pins can be removed by the silicon vendor to minimize the cost of the interface when the interface can tolerate a performance impact. The lower pin-count implementation might be found on 8-bit and 16-bit devices or in market segments where real-time debugging is less critical. The JTAG interface is too slow for high-performance 32-bit microprocessors, so an optional auxiliary port has been added to the Nexus 5001 standard to address the high-performance and full-duplex needs of some applications.
Second, a packet-based messaging scheme has been developed to minimize the overhead of the information between the target microprocessor and the host debugging tool. The packet information is called a Transfer Code and is used with the auxiliary port pins.
The third method of reducing the information from the debug port to the host development tool is to limit transmissions in sending the required addresses to trace the instruction flow. For example, if the target processor does not have a change of flow, then the 32-bit address is not transmitted. When a change of flow such as an interrupt or branch occurs, the Nexus 5001 development interface would send the new beginning address. In that environment the source code and the linked code are required to be available to the host tool at the time of the debugging session. Also, if the debugging session must be real-time, then some information must be derived by the development tools. For instance, not all data values have to be visible at all times, so if the data trace option is used, only the data that the engineer is concerned about would be sent to the debug port during run-time.
Best practices
The Nexus 5001 feature set is a mixture of the best practices in debug interfaces from the past 15 years of industry experience. Each feature has proven its worth on one or more processors in the past. Implementing them into a single standard interface offers distinct advantages such as run control, real-time instruction and data trace information, RTOS support, memory substation, breakpoints and watch-points, to name just a few.
The philosophy was to maximize functionality while reducing the pin and silicon area that directly affects the cost of the interface to the end user. The natural migration to the integration of system memory on chip results in reduced visibility of the embedded processor. Higher clock and bus speeds are making traditional debug techniques, such as emulators, very expensive and limited in capabilities. The Nexus 5001 consortium is changing the debug methodology to simplify debugging for engineers.
One of the most important of those, data tracing, will open doors to many new development tools. When the silicon vendor implements the data trace feature on the silicon, the tools have visibility that exceeds any of the past. The data trace mode, for example, provides real-time data to internal registers, cache hits and internal memory such as flash, ROM and SRAM in real-time.
Other techniques such as OnCE, BDM and JTAG implementations could not provide the data in real-time or complete visibility of all internal accesses. Data trace messaging allows a development tool to trace the data as it flows through the application, even flag a data value when it's out of range or being accessed (read or write) by an inappropriate routine. Data trace messaging should be used sparingly when real-time is an issue. Tracing the CPU stack will use much of the throughput of the debug port.
On simple programs and projects, the software engineer might know the minimum and maximum ranges for all of the values. In a typical project, teams of software engineers expect that the incoming data values are always within specified ranges. Those accumulative data value errors might require many engineering hours to track down and eliminate. Development tools in the near future could offer this range-checking and data-tracking feature as a standard debugging technique.
The Nexus 5001 specification defines a standard protocol for data trace visibility of accesses to memory locations and memory-mapped, device-specific internal peripherals. The standard defines a minimum of two data trace range resources that can be controlled to emit data trace messages on reads, writes or both within a specified address range. The address information is compressed to reduce bandwidth requirements on the interface. Additionally, data trace can be globally enabled and disabled by using watchpoint features to further reduce required bandwidth.
A special mode of data trace is to create packets of data that are then sent to the development tool. These packets of associated data can be arbitrarily large. Due to the construction of the data messaging protocol, it is a much more efficiently packed message than data trace messages. A common usage of that feature would be for communicating with rapid prototyping tools commonly deployed in the automotive industry.
Specific conditions
The Nexus 5001 specification goes so far as to specify the error and overflow conditions. Once the internal buffer is full and can no longer transmit the information fast enough, an error condition will occur. Unlike many debug ports, the user has two options. The first option is to transmit the data while slowing the processor down. This will result in nonreal-time performance of the debug port, but no data will be lost and synchronization between the development tool and the processor is maintained.
The second option allows for loss of synchronization while not affecting the processor. The second option might at first glance seem less desirable. However, there are several points to consider. Once synchronization is lost, the development tool will be immediately notified and allowed to notify the user.
Another point related to the loss of synchronization between the development tool and the embedded processor is that if the information being sought after is not within the "blackout" time, it probably doesn't affect the debugging session. If the blackout does cause some concern to the development team, then reducing the amount of information over the debug port will allow the processor and development tools to remain synchronized.
For example, if a loss of synchronization does occur, then giving up trace on the stack pointer would significantly reduce the amount of information while maintaining synchronization.
The real distinction of the Nexus 5001 interface is that the user has several options when the amount of information requested exceeds the data transmission throughput of the development port interface. Additionally, synchronization is maintained so that a current execution address is sent every 255 instructions or sooner.
