How to choose an in-circuit emulator

How to choose an in-circuit emulator

By Jonathan Hector

http://www.embedded.com/23901694?_requestid=49956

An in-circuit emulator (ICE) is an invaluable tool for software andhardware developers alike: and for anyone about to develop amicrocontroller-based embedded system the ability to run and debugcode, 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 boxemulating the micro - to a host PC or workstation. Within the ICE, ormore commonly within the pod, is a processor similar to the one theemulator replaces.

Sometimes the emulator's processor is a special bond-out version of thechip. Bond-out chips give developers access to critical signals, busesand 'deep' registers that they would otherwise not have access to. Ingeneral, emulators that use bond-out chips have more features thanthose that do not.

All the threes

There are essentially three methods available for debugging codeon the target hardware. The top-end offering is the full ICE.Unfortunately, this fact has led the marketing people to commonly referto any piece of debug hardware as an 'ICE' or 'Emulator', so thedistinctions have become a little blurred. The full ICE comprises a podand an emulation box as described above. At the opposite end of thespectrum is the ROM monitor (sometimes called a ROMulator), whichrelies on running dedicated software on a working target andcommunicates through a serial port to enable debug. In the middle wehave background mode emulators (BMEs), which have control over the chip(via a dedicated port) and are connected through a secondary channel onthe target board.

In addition to the three types of debug methodology we havethree types of user, as embedded systems development typicallycomprises three distinct concurrent activities: hardware development,software development and systems (application) development. In largecompanies teams of engineers might perform the various activities; insmaller organisations, all three may be the remit of just onedesigner/developer.

Hardware engineers need to be able to verify that the micro willinteract correctly with the system's other components and I/O. Softwareengineers need to be able to step through code to verify itsfunctionally. Systems and applications developers need to verify thesystem 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 eitherbackground mode or ROM monitor emulators: although the latter (whilstextremely cost effective) cannot offer real time control.

Memory half-life

The benefits of the full ICE emulator are: complete control ofthe micro and good visibility of its bus. The latter benefitfacilitates 'bus-level trace', which enables the hardware engineer toverify 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 previousexperience of the particularly micro or family.Another key feature ofan ICE is its ability to overlay memory on the target. For example, anICE might have 8Mb of memory that can be used in place of the micro'sown memory. This is particularly important during the development phaseof a project as most embedded systems now employ flash memory, and sometypes of flash can only be reprogrammed around 200 times. Overlayingthe system's flash memory also allows software breakpoints to be set inthe ICE's ROM area.

Also available on a full ICE is the ability to stop the microbased on what is happening on its bus. Such 'bus content' triggering isnot possible with other forms of emulator: they can only stop the microwhen they encounter a particular instruction.

As mentioned, the middle of the road (and therefore mid pricerange) option is the BME. Rather than replace the target's micro, BMEsconnect to the micro in situ through a proprietary port on the chip.This option relies on the device's on-chip debug functionality. Suchfunctionality is nearly always present on today's high-performancemicrocontrollers and DSPs, but may not be available on many 16 or 8-bitdevices.

Working in the background

The majority of ports on today's micros conform to the JTAGstandard and most people think of BMEs as JTAG emulators. They arewrong to do so: as, whilst a BME is a 'real-time' emulator in the sensethat it is possible to start and stop the micro, it is not possible toanalyse 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 bythe complexity of the interface the chip manufacturer has provided, andthis varies widely from manufacturer to manufacturer and from chip tochip. For example, the ability to insert breakpoints through BME can belimited depending on the micro.

In addition, the BME's inability to overlay memory means thedebugging cycle relies on frequent reprogramming of the target. Thismeans that the speed of download offered by the BME is an importantconsideration, and if the target memory is flash the reprogramminglimitations (as discussed above) must be allowed for.

As a BME relies on the presence of a functioning target, if thesystem under development does not yet have a functioning clock,background mode emulation will be of no use and the engineer will haverecourse to use a full ICE. However, if the system is being debugged, aBME may suffice if it can used in conjunction with a logic analyserand/or oscilloscope -- but do not hold out too much hope, thepopularity of ball grid array (BGA) packaged devices is drasticallyreducing probe access to critical nets/signals.Whether it's a full ICE or a BME, gone are the days when such toolsoccupied as much space as an upright freezer.

Today, the performance of the host PC means that there is more thanenough power to play host to an emulator. Most communicate via the PC'sparallel or serial port, but optimum performance is achieved overeither USB or Ethernet.

With this type, in addition to the obvious speed advantage whendownloading code, the target system can be some distance away from thePC. Moreover, with an emulator pod connected, any of a number of PCs -connected by Ethernet - can view and control the system. This is ofparticularly benefit to software engineer, who prefer to sit at theirdesks away from the hardware.

What to look for

The BME is by far the most popular type of emulator, downchiefly to the price difference between it and a full ICE. An ICE willtypically cost between three and ten times more than a BME. It is,however, development and debug functionality (as desired by thehardware engineer mainly) that governs which type of emulator ispurchased: and the full ICE wins every time.

An ICE, as mentioned, is usually capable of running at fullspeed, which for the majority of embedded designs is usually in the 10to several 100MHz range. Some ICE manufacturers struggle to get theiremulator's hardware to run fast enough and it is typically only thosemanufacturers with partnership deals with the silicon vendors thatmanage to keep pace with the latest processor developments. So, whenselecting an ICE, do check thoroughly the list of devices that can beemulated.

In addition, it is always good practice to make sure that whatyou are about to buy can be upgraded. Look for flexibility in terms ofprocessor connections, as ICEs have always tended to be chip-variantspecific, and you may get caught out. For example, if your company isplanning to use a different processor for its next project, you mayhave to invest in a whole new ICE.

Wherever possible choose a modular ICE -- one that that allowsthe addition of personality cards and/or pods to be changed to suitprocessor variants. Such modular additions/changes allow the ICEchassis to remain unaltered -- therefore saving costs. For example, anICE 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 beable to switch between different silicon manufacturers by changingpods. It is very rare to find an ICE that would, for example, supportboth an Infineon and a Motorola processor with the same chassis.

Remember, all ICEs rely on an external PC for the user interfaceand application software, so check the compatibility of the debuggingsoftware 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 physicallyconnecting the pod to the target. The days of processors residing insockets have long gone and BGA packages micros soldered to the boardare fast becoming the norm.

The most reliable way to connect to the target is to leave theprocessor off the PCB and fit an adaptor board, with a socket, in itsplace. A simple fix but tricky to do, so make sure your ICE vendor haslocal engineering support, and that they can source or recommendsolutions.

So far we have discussed the hardware engineers' emulator ofchoice and what they should look out for - but there are a growingnumber of companies who prefer to put their investment in softwareengineers.

These companies tend to buy in ready-made boards, and develop their ownsoftware 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 willinvariably allocate a number of the PLD's pins as a debug port. Thisinterface will allow the developer to have run control over the softcore.

One of the problems a developer, using a BME, will face isreduced accessibility (compared to full ICE): they will not be able totrace what is happening. Starting and stopping the micro is all verywell - but stopping and going back to see what actually happened isdifficult.

Fortunately, some processor manufacturers are striving to deliverICE-like accessibility through BME techniques. ARM for instance has aninternal engine it calls the ETM (Embedded Trace Macrocell) -- a way ofmaking multiplexed bus signals accessible for debugging purposes. So,just as with full ICE, when a break point is hit the BME can access atrace of bus activity and the events leading up to the break can beviewed. In such cases, a BME which supports this capability, such asiSYSTEM's iTrace, is well suited to high-end 32 bit processordevelopment, as bus activity can be traced.

In addition, a number of emulator manufacturers are bringingfull ICE like functionality into BMEs. These hybrid emulators avoid thehigh cost of full ICE, but employ innovative techniques to get aroundthe limitations of BME debugging. iSYSTEM for example, has introducedSmartPOD, which provides the overlay memory function and complexbreakpoint ability of an ICE within the BME. Call for backup

The level of technical support on offer should always be one ofyour considerations when choosing between emulators - and such supportrequires detailed knowledge of not only the tool but also the targetsilicon.

It is worth noting that the silicon vendors typically farm outtheir technical support to tool manufacturers and distributors, so, ifthe tool people do not have the answers to your questions you maybecome 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 often, have direct design experience with the processor and/or of theproblem. This means you will not have to wait around for fax-backs oran email to be returned.

Jonathan Hector is the engineering manager for embedded tools at DirectInsight. Jonathan has many years' experience of embedded tools - havingworked both for silicon vendors and embedded tools manufacturers. For acomplete list of ICE and embedded products supplied by Direct Insightvisit www.directinsight.co.uk.

Published in Embedded Systems (Europe) April 2002