An in-circuit emulator (ICE) is an invaluable tool for software and hardware developers alike: and for anyone about to develop a microcontroller-based embedded system the ability to run and debug code, line by line if need be, is a great bonus.
An ICE will normally replace the system's (target's)
microcontroller, or processor with a 'pod' connected -- via a box
emulating the micro - to a host PC or workstation. Within the ICE, or
more commonly within the pod, is a processor similar to the one the
emulator replaces.
Sometimes the emulator's processor is a special bond-out version of the
chip. Bond-out chips give developers access to critical signals, buses
and 'deep' registers that they would otherwise not have access to. In
general, emulators that use bond-out chips have more features than
those that do not.
All the threes
There are essentially three methods available for debugging code
on the target hardware. The top-end offering is the full ICE.
Unfortunately, this fact has led the marketing people to commonly refer
to any piece of debug hardware as an 'ICE' or 'Emulator', so the
distinctions have become a little blurred. The full ICE comprises a pod
and an emulation box as described above. At the opposite end of the
spectrum is the ROM monitor (sometimes called a ROMulator), which
relies on running dedicated software on a working target and
communicates through a serial port to enable debug. In the middle we
have background mode emulators (BMEs), which have control over the chip
(via a dedicated port) and are connected through a secondary channel on
the target board.
In addition to the three types of debug methodology we have three types of user, as embedded systems development typically comprises three distinct concurrent activities: hardware development, software development and systems (application) development. In large companies teams of engineers might perform the various activities; in smaller organisations, all three may be the remit of just one designer/developer.
Hardware engineers need to be able to verify that the micro will interact correctly with the system's other components and I/O. Software engineers need to be able to step through code to verify its functionally. Systems and applications developers need to verify the system against the requirement and implementation specs, and ask:
Does the system do all that it should?
Does it do things it should not?
These two important questions can be answered by using either
background mode or ROM monitor emulators: although the latter (whilst
extremely cost effective) cannot offer real time control.
Memory half-life
The benefits of the full ICE emulator are: complete control of the micro and good visibility of its bus. The latter benefit facilitates 'bus-level trace', which enables the hardware engineer to verify that the data the micro places onto the bus is:
a) getting to its destination, and
b) is arriving intact.
This can be very useful if the hardware engineer has no previous experience of the particularly micro or family.Another key feature of an ICE is its ability to overlay memory on the target. For example, an ICE might have 8Mb of memory that can be used in place of the micro's own memory. This is particularly important during the development phase of a project as most embedded systems now employ flash memory, and some types of flash can only be reprogrammed around 200 times. Overlaying the system's flash memory also allows software breakpoints to be set in the ICE's ROM area.
Also available on a full ICE is the ability to stop the micro
based on what is happening on its bus. Such 'bus content' triggering is
not possible with other forms of emulator: they can only stop the micro
when they encounter a particular instruction.
As mentioned, the middle of the road (and therefore mid price
range) option is the BME. Rather than replace the target's micro, BMEs
connect to the micro in situ through a proprietary port on the chip.
This option relies on the device's on-chip debug functionality. Such
functionality is nearly always present on today's high-performance
microcontrollers and DSPs, but may not be available on many 16 or 8-bit
devices.
Working in the background
The majority of ports on today's micros conform to the JTAG
standard and most people think of BMEs as JTAG emulators. They are
wrong to do so: as, whilst a BME is a 'real-time' emulator in the sense
that it is possible to start and stop the micro, it is not possible to
analyse the micro while it is running at full speed, as there is no
'trace' function.
The level of interaction with the micro is typically governed by
the complexity of the interface the chip manufacturer has provided, and
this varies widely from manufacturer to manufacturer and from chip to
chip. For example, the ability to insert breakpoints through BME can be
limited depending on the micro.
In addition, the BME's inability to overlay memory means the debugging cycle relies on frequent reprogramming of the target. This means that the speed of download offered by the BME is an important consideration, and if the target memory is flash the reprogramming limitations (as discussed above) must be allowed for.
As a BME relies on the presence of a functioning target, if the
system under development does not yet have a functioning clock,
background mode emulation will be of no use and the engineer will have
recourse to use a full ICE. However, if the system is being debugged, a
BME may suffice if it can used in conjunction with a logic analyser
and/or oscilloscope -- but do not hold out too much hope, the
popularity of ball grid array (BGA) packaged devices is drastically
reducing probe access to critical nets/signals.
Whether it's a full ICE or a BME, gone are the days when such tools
occupied as much space as an upright freezer.
Today, the performance of the host PC means that there is more than
enough power to play host to an emulator. Most communicate via the PC's
parallel or serial port, but optimum performance is achieved over
either USB or Ethernet.
With this type, in addition to the obvious speed advantage when
downloading code, the target system can be some distance away from the
PC. Moreover, with an emulator pod connected, any of a number of PCs -
connected by Ethernet - can view and control the system. This is of
particularly benefit to software engineer, who prefer to sit at their
desks away from the hardware.
What to look for
The BME is by far the most popular type of emulator, down
chiefly to the price difference between it and a full ICE. An ICE will
typically cost between three and ten times more than a BME. It is,
however, development and debug functionality (as desired by the
hardware engineer mainly) that governs which type of emulator is
purchased: and the full ICE wins every time.
An ICE, as mentioned, is usually capable of running at full speed, which for the majority of embedded designs is usually in the 10 to several 100MHz range. Some ICE manufacturers struggle to get their emulator's hardware to run fast enough and it is typically only those manufacturers with partnership deals with the silicon vendors that manage to keep pace with the latest processor developments. So, when selecting an ICE, do check thoroughly the list of devices that can be emulated.
In addition, it is always good practice to make sure that what
you are about to buy can be upgraded. Look for flexibility in terms of
processor connections, as ICEs have always tended to be chip-variant
specific, and you may get caught out. For example, if your company is
planning to use a different processor for its next project, you may
have to invest in a whole new ICE.
Wherever possible choose a modular ICE -- one that that allows
the addition of personality cards and/or pods to be changed to suit
processor variants. Such modular additions/changes allow the ICE
chassis to remain unaltered -- therefore saving costs. For example, an
ICE for a high-end processor such as a PowerPC costs between £10k and
£15k. To change the pod to suit a different processor could cost up to
£3k. Whilst expensive, this is far cheaper than buying a new ICE.
So, modularity is very important but beware: do not expect to be
able to switch between different silicon manufacturers by changing
pods. It is very rare to find an ICE that would, for example, support
both an Infineon and a Motorola processor with the same chassis.
Remember, all ICEs rely on an external PC for the user interface and application software, so check the compatibility of the debugging software running on the host PC. It needs to:
Accept a wide range of file format inputs;
Be compatible with all compilers; and
Be capable of running on all current Windows OS versions.
It is surprising how many ICEs don't meet all three criteria, so watch out!
Making connections
When using an ICE, one of the greatest challenges is physically
connecting the pod to the target. The days of processors residing in
sockets have long gone and BGA packages micros soldered to the board
are fast becoming the norm.
The most reliable way to connect to the target is to leave the
processor off the PCB and fit an adaptor board, with a socket, in its
place. A simple fix but tricky to do, so make sure your ICE vendor has
local engineering support, and that they can source or recommend
solutions.
So far we have discussed the hardware engineers' emulator of
choice and what they should look out for - but there are a growing
number of companies who prefer to put their investment in software
engineers.
These companies tend to buy in ready-made boards, and develop their own
software applications. In such cases a BME is the most sensible choice.
Furthermore, if the target system consists of 'soft cores'
residing in PLDs, a BME will be sufficient. Here, the core vendor will
invariably allocate a number of the PLD's pins as a debug port. This
interface will allow the developer to have run control over the soft
core.
One of the problems a developer, using a BME, will face is
reduced accessibility (compared to full ICE): they will not be able to
trace what is happening. Starting and stopping the micro is all very
well - but stopping and going back to see what actually happened is
difficult.
Fortunately, some processor manufacturers are striving to deliver ICE-like accessibility through BME techniques. ARM for instance has an internal engine it calls the ETM (Embedded Trace Macrocell) -- a way of making multiplexed bus signals accessible for debugging purposes. So, just as with full ICE, when a break point is hit the BME can access a trace of bus activity and the events leading up to the break can be viewed. In such cases, a BME which supports this capability, such as iSYSTEM's iTrace, is well suited to high-end 32 bit processor development, as bus activity can be traced.
In addition, a number of emulator manufacturers are bringing full ICE like functionality into BMEs. These hybrid emulators avoid the high cost of full ICE, but employ innovative techniques to get around the limitations of BME debugging. iSYSTEM for example, has introduced SmartPOD, which provides the overlay memory function and complex breakpoint ability of an ICE within the BME. Call for backup
The level of technical support on offer should always be one of
your considerations when choosing between emulators - and such support
requires detailed knowledge of not only the tool but also the target
silicon.
It is worth noting that the silicon vendors typically farm out
their technical support to tool manufacturers and distributors, so, if
the tool people do not have the answers to your questions you may
become very frustrated. Most silicon manufactures only offer
'sit-and-wait' email support these days.
Tip: choose a distributor that has FAEs who, nine times out of ten, have direct design experience with the processor and/or of the problem. This means you will not have to wait around for fax-backs or an email to be returned.
Jonathan Hector is the engineering manager for embedded tools at Direct Insight. Jonathan has many years' experience of embedded tools - having worked both for silicon vendors and embedded tools manufacturers. For a complete list of ICE and embedded products supplied by Direct Insight visit www.directinsight.co.uk.
Published in Embedded Systems (Europe) April 2002
