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.
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!
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