the ICE - An integrated solution

Chapter 8: The ICE — An Integrated
Solution
Overview
Chapter 6 introduced the three key capabilities necessary to hardware/software
(HW/SW) integration:
 Microprocessor run control
 Memory substitution
 Real-time trace
So far, you’ve learned how to address these capabilities using separate tools,
namely a debugging kernel, a ROM emulator, and a logic analyzer. In this chapter,
you’ll see what happens when you design a tool system that addresses these
needs in a more integrated fashion.
Traditionally, an in-circuit emulator (ICE) is a single-test instrument that integrates
all these functions and more. (Modern on-chip debugging support has changed this
somewhat, as the later sidebar “Distributed Emulators
” explains.) Emulators are
the premier tools for HW/SW integration. An emulator’s close coupling of run
control, memory substitution, and trace facilities generates a synergism that
significantly increases the power of each component.
Even so, the ICE is widely underused. Only about one-third of the embedded
system designers, principally firmware developers, use ICE tools. Hopefully, after
reading this and the next chapter
, you’ll appreciate how important the ICE is to
HW/SW integration.

Note
In the language of embedded systems, a firmware developer is someone who
writes the low-level driver code that interfaces the software directly to the
hardware. Because the ICE has been primarily designated as a HW/SW integration
tool, firmware designers have been the people most closely associated with it.

Bullet-Proof Run Control
In the most general case, an ICE uses a debug kernel for run-time control but with
a difference that eliminates dependence on the target’s untested
memory/processor interface. Instead of relying on the target’s processor and
memory, the ICE supplies its own processor and memory. A cable or special
connector (see the “Making the Connection
” sidebar on page 170) allows the ICE
processor to substitute for the target’s processor.
The target program remains in the target memory, but the debug kernel is hosted
in the ICE memory. When in normal run mode, the ICE processor reads
instructions from the target memory; however, when the debug kernel needs
control, the ICE switches to its own local memory. This arrangement ensures that
the ICE can maintain run control, even if the target memory is faulty, and also
protects the debug kernel from being damaged by bugs in the target.
Figure 8.1
shows a straightforward, generic implementation. The key blocks are
labeled:

Figure 8.1: General emulator design.
Schematic representation of the architecture of a run control system for a
general emulator design.
 NMI control logic
 Memory steering logic
 Shadow ROM and RAM
When the user or emulator decides to stop processing the user’s code and enter
the debugger, the NMI signal is asserted, and the NMI control logic responds as
follows:
 The NMI signal from the target system is blocked by the NMI control

logic, so that no further NMI-based interrupts are detected by the processor
while it’s executing the code in the debug kernel.
 The memory steering logic switches off the address and data bus
buffers to the target system and enables the emulator’s local, or “shadow,”
memory to connect to the processor. In effect, the context switch occurs by
swapping the memory space of the processor.
 The processor then takes the interrupt vector that directs it into the
debugger entry point, now located in the shadow ROM.
Thus, with this generic emulation system, the only requirement for processor
debug support is that the processor has an external NMI capability.

Note
Most processors have a processor input pin called a non-maskable interrupt (NMI).
This interrupt signal cannot be ignored (masked) by the processor. It differs from a
RESET signal in that the context of the processor can be saved with an NMI but is
lost with a RESET. What they have in common is that when either is asserted, the
processor must respond to it. In embedded systems, the NMI signal is reserved for
catastrophic events, such as a watchdog timer
time out or imminent power failure.

Why Emulators Aren’t Used More
In many labs, the entire lab has only one emulator. It sits on a mobile cart and has
a long, thin wooden pole attached to it. On the top of the pole is a blaze orange,
triangular flag that some engineer purchased in a bike shop for his kid’s bike a few
years ago. Whenever a gnarly problem arises, someone looks for the flag and
grabs the emulator. Next, they try to find Joe or Susan — the one or two engineers
in the place who actually know how to use it — and hope they can find and fix the
problem. The other engineers have been playing with this bug for a week now, and
they’ve finally thrown in the towel and want to bring in the big gun. Up to now,
they’ve resisted the urge to get the ICE because they figured it would take them

the better part of a morning to get it hooked up and running. They always had one
other quick-and-dirty test to try that would only take 20 minutes or so. This goes
on for a few days until the call goes out to send in the cavalry.
It isn’t always that bad. But I’ve heard that exact scenario enough times and seen
enough of those flags to know that I’m on to something. What are they really
saying?
 Emulators are hard to use. (They certainly can be.)
 Emulators are too fragile. (There is also some truth to this but not
universally.)
 Emulators are too expensive. (Compared to what? What did the lost
weeks cost in terms of engineering expenses and time-to-market?)
 Emulators won’t run in my target system. (This is rarely true but is an
excuse that usually covers up all kinds of system design flaws.)
 Emulators don’t fit in my process.
 I’ve been getting by without it, and, now that I really do need it, my
development process presents a much too closed environment for the ICE to
be used effectively. (This can certainly be the case.)
Because of these prevailing perceptions, for many embedded systems developers,
the ICE becomes the tool of last resort, rather than an integral part of the tool
suite. Unfortunately, that attitude just perpetuates a self-fulfilling prophecy: The
ICE isn’t used because it’s too hard to use, which means it will never be under
stood well enough to make it easy to use.


Real-Time Trace
After the generic emulator has been attached to the target, acquiring real- time
trace information is almost trivial. The emulator already has connections to the
necessary address, data, and status busses. To add real-time trace, you just
piggy-back a logic analyzer onto the same connection. Thus, without too much
additional complexity, you can use the same target system connection that you

used for the logic analyzer to concentrate both run control and trace in one target
connection instead of in two.
With your new emulation/trace tool, you can control the processor and observe its
behavior in real time. Wait, there’s more. Remember that logic analyzers have all
this complex circuitry to detect when to begin capturing a trace. Why not use this
trigger signal for more than just starting and stopping the trace? Why not also
connect it to the NMI control logic so that you can cause the processor to stop
program execution and enter the debug monitor program exactly at the place in
the code where the event of interest occurs?
Figure 8.2
shows this schematically. The logic analyzer has been added to show
how the system functions. The address, data, and status busses are connected to
the trace memory and to the trigger system. The trigger system determines when
the trace memory should start capturing a trace and when it should stop capturing
a trace. It also connects to the NMI control logic block so that you can define
trigger conditions that function independently of the trace system. These other
trigger conditions control when the processor stops executing user code and enters
the debug kernel (also called the monitor program).

Figure 8.2: Emulation control system.
Block diagram of the core of an emulation control system with real-time
trace.

Making the Connection
The emulator’s steering circuitry must be interposed between the pins of the
processor and the target system. This can be done in one of two ways:
 Remove the target microprocessor from the target (unplug it from its
socket)
 Disable it in a way that all the pins become open-circuited as far as the
target system is concerned (called tri-stated)

If the Target Can Be Socketed Easily
If the footprint of the socket matches the footprint of the microprocessor, it’s sim
ple to replace the microprocessor with the appropriate socket and then plug the
replacement system into the socket. Of course, the replacement “emulator” must
also have some kind of communication port on the board so you can communi cate
with your emulation debug kernel, but this is easy to implement. Thus, you can
easily add a simple RS232 port to this board and connect the interrupt output
signal from the port to the NMI control logic of your emulation circuitry. When a
new character is received at the serial port, the NMI is asserted, and you’re into
the debug kernel.
If the Target Can’t Be Socketed Easily
Some processors have a dedicated input pin that, when asserted, turns the chip
completely off. You can plug the replacement chip (with the emulator signals) into
the target system as an overlay. You can do this several wayssome ways are easy,
some are not so easy, some are costly, and some are fragile. For example,
suppose the target processor is a surface-mounted part with 300 extremely deli
cate pins mounted around its periphery. This is typical of what you might expect to
find today. If the target system has room, the hardware designers might be able to
place some high-density sockets on the target PC board so that each pin of the
socket intercepts one of the I/O pins of the target processor. Two or three high-
density sockets easily can cover the 300 pins of the target processor. If you get
the mechanical design just right, you should be able to plug the connectors on the
emulator board into the matching sockets of the target system.
If the target processor has a “disable everything” pin, you can turn it off. If it
doesn’t, you must remove the processor from the target and depend on the emula
tion processor, mounted on the generic emulation board, to become the target
processor. You probably won’t have the luxury of sockets on the target system, so
go to plan B.
In this situation, you need to find a manufacturer of specialized connection devices
(such as Ironwood Electronics Corporation at www.ironwoodelectron ics.com or

Emulation Technology, Inc., at www.emulation.com
) so you can solder an interface
connector to the 300-pin footprint on your target printed circuit board and provide
a mating socket into which ou can plug your emulator. This is shown schematically
in Figure 8.3
, in which a mechanical adapter can be soldered to the target system
PC board to replace the embedded microprocessor that you are trying to
emulate/control.
With this socket adapter mounted to the PC board, you can plug in the target pro
cessor (by mounting it to a small PC board with an SMT footprint on the top side
and mating PGA pins on the bottom), or you can plug in your emulator. Adapters
such as this cost anywhere from $1 per pin to $5 per pin, so one very fragile
adapter might set you back $1,000. Also, because these sockets add some addi
tional length to the electrical interconnections of the target system, some distor
tion of the waveforms might occur at high bus rates. How this impacts your target
system is generally impossible to predict in advance.
Another advantage of this technique is that it’s generally usable with many minia
ture and crowded target systems. That’s not to say that it’s universal because
some perverse mechanical designs are out there that absolutely defy physical
access, but, at least in this situation, it’s not taking up any more space at the
board-level than the actual footprint of the microprocessor itself.