Trace and Triggering Combination: As powerful as triggering and trace are by themselves, they have weaknesses. For instance, what if a write that corrupts memory is detected with a trigger, while the sequence of events leading up to the bad write isn’t visible? Why the write happened may not be obvious.
Trace without filters has weaknesses as well. The main problem here is that the information volume can overwhelm either temporary buffers on chip, or humans trying to interpret the volumes of data. A combination of triggers and trace makes it possible to look at program flow and associated memory references on very specific conditions, thereby reducing the amount of exported data to a manageable level.
Triggers on failures can stop trace recording. Triggers can also use a multilevel state machine to detect a complex sequence of events that involve either hardware or software misbehavior. Such flexibility proves especially useful late in the design cycle when complex or intermittent problem sequences arise. The co-location of debug triggers and critical system buses/signals determines whether information is important or not, in real time. Such a capability lets a developer pinpoint the origin of code problems in hours instead of months.
Data I/O: As stated previously, there are two forms of data I/O: DMA-driven data transfers through the scan interface (JTAG), and high-speed versions with a DMA-driven bidirectional serial port. In both cases, the chip vendor supplies a driver with one or both of these capabilities standard fare and encapsulated with the CPU core.
Pin management: Although trace, triggering, and some forms of data I/O all require pins to operate, not all capabilities are needed at once. A pin manager is included to distribute the available debug pins to the capabilities that need them the most, with trace being especially pin-hungry.
The number of pins used for trace export is very important. Each pin dedicated to trace must be operated at the highest bandwidth possible. Even with selective triggering and data compression, trace takes between 4 and 20 times as many pins as data I/O, which requires just one pin. You can consider the CPU frequency as a multiplier of the pin needs because the debug information increases proportionally to the CPU frequency. Also, the quality of the debug architecture affects the pin count. Less efficient encoding and compression schemes certainly use more pins, and all trace protocols aren’t created equal.
Pins are precious, so gates are spent to improve the encoding and compression, thus reducing pin consumption. Leading technologies use single-ended I/Os to export trace data at the highest rate practical per pin, with the number of pins required directly proportional to the encoded and compressed information volume. They also allow for the addition of trace pins in small increments, with debug port pins programmable as trace, data export, or other functions (e.g., input or output triggers).
What The Future Holds
Unquestionably, the "chip-cost-is-everything" era has ended. The plight of software developers and missed project deadlines has awakened program managers. They’re now aware of the need for a stronger toolset. On top of that, hardware developers must relinquish some of their control over the chip features.
Fortunately, shrinking geometries and low-cost packaging technologies are making it ever more affordable to include on-chip debugging capability. Consequently, this required technology is becoming more palatable for everyone. Today’s combined triggering and trace solutions consume 100 to 200 kgates. This certainly makes the technology affordable compared to months of schedule delays. We all know that "if you can’t see it, you can’t fix it." A few encounters with this law of nature secure the case for on-chip debug.
In the not-too-distant future, it should be possible to obtain continuous real-time trace with no gaps by using a clock or two, roughly a pin per 100 MHz of CPU clock frequency, and employing conventional single-ended I/O buffers for trace-export transmission. Some technology in development today may deliver continuous visibility well into the several-gigahertz clock range. Given that trace export generally transmits the data through the target board, the emulation header, and as much as 6 to 12 inches of cable to get to the emulator, these numbers are truly impressive.
Now that you know what the benchmark is, you know what your competitors have at their disposal. Deciding how much debug to deploy is like purchasing insurance. You never know for sure in advance how much you'll need. But the penalty for not having enough can range from annoying to disastrous.
How much are you willing to invest in chip and debug tools to ensure your project will be successful? Using an emulator-friendly data-exchange port on the chip incurs the lowest hardware cost, essentially the minimal "insurance" policy. But it doesn't do much to tackle system crashes and timing problems. The more expensive, higher-performance coverage, triggering, and trace technology may be needed for the right visibility to find your subtle, annoying bugs, providing better "insurance" protection for successful product development. Always remember too, regarding product bugs, if you can't find them, you can't fix them!