Choosing an in-circuit emulator for your next 8051 project is a major decision. The chances are, you will be working with it continuously for several years, so any short shortcomings will become major irritations.

Emulator demonstrations can be very confusing and it is very easy for clever sales engineers to cover up serious deficiencies in their machines. To help spot this, read the following very carefully and raise the highlighted points with your sales engineer to reveal the true worth of the system....

ROMless variants may easily be emulated as full access to the bus is possible via ports 0 and 2. Previously though, only Intel emulators supported single-chip versions of the basic 8051 family devices like the 805C1FB, FC and FD. These have 8, 16 and 32KB ROMs on the same silicon and thus used to require a bondout chip, not surprisingly, only available from Intel. However, since the demise of Intel's own emulators, the emulation parts are now available to specialist emulator manufacturers who use "HOOKS" technology to permit the reconstruction of ports 0 and 2, making the CPU bus available for the emulator. This technology requires the emulator manufacturer to buy a special licence and consequently raises the price of HOOKS-based emulation adaptors. The Philips 83C528 also uses HOOKS to permit single chip emulation.

For simple ROMmed devices like the 80C51/52, independent manufacturers use the OKi 85C154 piggyback EPROM chip to get access to both the bus and ports 0 and 2. This is completely 8051/52/31/32 (and CMOS) compatible except that some of the reserved sfr bits are actually used for power down control etc.. When the Intel 8051/52 data book says do not use these bits, heed the advice.

Normal ROMless devices like the 8032, C501, C509 80C552, 80C537 etc. can be supported by simply using off-the-peg ROMless parts. Note that to support the ROMmed versions (83C552, 80C517) requires special and rather expensive devices supplied by Philips and Infineon respectively. Indeed, the latter actually list the bondout version in their data books!

The emergence of the Dallas 320 has rendered many existing 8051 family emulators obsolete. This device has the crystal frequency divided by 4 rather than 12 and so will run 3 times as fast for the same clock. The bus cycle timing is different and some emulators simply cannot cope with it. Make sure that the system you are assessing supports it!

Beware - emulation gear produced by a silicon manufacturer will support only their devices!

Overall, the ability to perform single chip emulation either via conventional bondout devices, or HOOKS are unfortunately rather expensive and only need to be used where you are certain that a masked version of you application will be produced.

Beware of this - some emulator manufacturers offer only a bond-out based version for the 83C552 where in most cases only the ROMless 80C552 version needs to be supported. This can cost an extra £1000 for something you'll never need.

Ideally to change from say an 8031 to 80C535, you'd only need to swap the processor. Some machines only need a cable to be changed or perhaps a processor-specific card in the emulator base unit.

Beware - changing dip switches for different variants or clock speeds may point to an old-fashioned hardware design.

In the old days, (1992!), 8051 devices were either 40DIL or 68PLCC and the emulator simply had to attach to have a male DIL or PLCC adaptor. These days, there are also 84PLCC, 80PQFP, TQFP and many more. In some cases there is no socket available as they are designed to be surface mounted, there is no real way of hooking up the emulator. However, some manufacturers offer a method of emulating via a simple EPROM socket, with no loss of emulator performance, ICEConnect51 is such a system.

Most systems have standardised on the Intel OMF format for code and symbols. Note that to allow automatic display of variable type (int, char etc.) the extended OMF format must be used. Some cheap "Universal" systems cannot cope with the UK's most popular C51 compiler, Keil C51, rendering them almost useless.

Any serious high level debuggers will cope with C, PLM51 and ASM without modification. Beware ones that do not as they will ultimately cost more.

This is a difficult one. Smaller companies, consultancies in particular, may have to work with several completely different CPU's at once or within a short space of time. The beauty of the 8051 family is that there is a version for almost every application. Having standardised on this basic CPU type, new versions can be employed depending on the particular application. If your customer insists that you use, for instance, a 68HC11 instead of an 80C552 and funds are tight, then you may well have to buy a general purpose system.

Larger companies though tend to be better financed and choose a CPU and stick with it, so this capability is not really an issue. For them, easy conversion to new variants is more important.

Beware - Whilst supporting both the 68HC11 and the 8051 will not compromise the `HC11 to any great extent, the 8051 is such a difficult CPU to emulate properly that you will find very serious drawbacks with any general purpose system (See later). Note that in the field of in-circuit emulation, the saying "jack of all trades and master of none" holds very true!

Strangely, the loading time for test programs is more influenced by the speed with which the PC can generate the necessary symbol tree file rather than the data transfer rate down the serial link. A fast 486/P5 PC with extended memory is far more effective than a fast link.

Beware (i) - some PC add-in card format emulators claim very fast code transfer rates. Whilst this is true, the time to generate the symbol file remains the real bottleneck. Common sense says that transferring 16KB of code at 19200 baud is never going to take many seconds. If the time to sort symbols is not taken during loading, then it will be done each time you single step - be prepared for a very long wait if you happen to single step into a new module! The sales engineer will probably be equipped with a very fast 486 portable...

Beware (ii) - Ask your sales engineer how big the demo program actually is - it is probably just a noddy affair of a few KB, designed to show fast loading.

8051/31 hardware is generally fairly straight forward when compared with C166's etc.. Ideally, you should simply plug the machine into your hardware and type "GO". However, many machines require various switches to be set first of all, which can be annoying.

Beware - most sales engineers will demonstrate emulators running standalone with well practiced and trivial demo programs. This is normally to prevent unexpected problems cropping up when using real 8051 hardware - if something can go wrong, it will happen during a demo! Really put your sales engineer in the hot seat by asking him to try the emulator in your own project hardware with your software. If any more than a few minutes setting up is required, be very wary...

The reality of most projects is that the hardware is always late and with software development times being so prone to overrun, it is very useful to be able to get the coding underway as soon as possible. The best emulators will allow unrestricted emulation, even with no target hardware present. A very useful feature is being able to access the 8051's serial port directly from the emulator chassis.

The ability to view the C source code as it was originally written is essential. In addition, you should be able to view C and the resulting assembler in an interleaved fashion. This is very useful for figuring out what the compiler is actually doing! You should be able to easily pop variables into a watch window from the instruction or source level windows with a single keystroke and the better systems will explode unions, arrays and structures into a C-like two-dimensional display.

Some systems have special databook-like windows for the CPU's peripherals such as the A/D convertor, serial port etc. which can make configuring them very much easier than thumbing through a 300 page databook.

Execution should be on a "point and shoot" basis, allowing the current program counter to be set to the current cursor position within the list file. The emulator should run until the line before the indicated line or statement. Cheap emulators will run to a CALL instruction, stopping after the CALL, i.e. in the subroutine. This can be infuriating. Although Windows user interfaces are now very common, many Windows front-ends are cobbled-together efforts, derived from old-fashioned command-line driven software from the 1980's and so do not use Windows' menu and mouse-driven approach. You can thus be sure of lots of typing.

Some debuggers can function as simulators, allowing the 8051 program to be tested without an emulator at all !

Beware (i) - some systems only allow forward jumps under cursor control. In practice, it is almost more important to be able to jump backwards to allow critical sections to be repeated several times.

Beware (ii) - the emulator should run until just before the pointed-at line so that you can single step the line at your leisure. Most simple machines cannot do this and it will be a source of constant irritation. To overcome this, a very expensive opcode decoder is required. Here, as an example is an extract from the Avocet AVC51 8051 C compiler release notes which highlights the problem:

" 6. AVC51
The -EMULATOR and -NOEMULATOR options have been added.
Specifying -EMULATOR causes the assembler to insert a NOP instruction before the first instruction of each C statement, when assembling the compiler's output, and before every instruction when assembling any other program. This facilitates use with certain hardware emulators (e.g.. Nohau) in which breakpoints break AFTER executing the breakpointed instruction (rather than before). With the -EMULATOR option in effect, setting a breakpoint on a C line will work as expected, since the break will occur after executing the inserted NOP instruction. "

Beware - each C line requires a redundant NOP! Thus in a large C program, many hundreds of useless NOPs will need to be inserted. Ask the sales engineer to explain why this is a good feature....

Variables also need to be readily accessible, either by pointing or by allocating part of the screen permanently to chosen items.

The ability to record program execution in a high level language via the trace buffer is really essential, after all, if you have written a program is C, it makes sense to debug it at C level as well.

It is here that the rather unfriendly nature of the 8051 becomes apparent....

Most 8051 applications make extensive use of the on-chip RAM, indeed, the single chip 8051 offers no alternative. It is therefore absolutely essential to be able to trigger on the internal data RAM. Unfortunately, many 8051 emulators simply cannot do this. Thus the contents of the internal RAM is a complete mystery, unless the processor is halted.

The problem is that Intel provided no means of accessing the internal RAM whilst the processor is executing code. More enlightened manufacturers like Motorola provide a special "Internal Visibility" mode and expansion chips that allow their microcontrollers' internal RAM to be accessed "on-the-fly". Intel do not.

So, if any sales engineer claims to be able to trigger on internal RAM, he may be on very dodgy ground - get him to fully explain any restrictions.

However on opcode-decoder equipped systems, it is possible, subject to some limitations, to allow triggering on reads and writes to internal RAM that do not use data originating from timers, and other sfr's. This achieved by scanning the code for areas in which such a read/write is possible. When running, should these areas be executed, the emulator can halt the processor and extract the RAM location's value. With Intel's lack of foresight, this is the best that can be achieved.

Note: even bond-out or HOOKS equipped emulators cannot do better than this

So, to summarise, ensure that the emulator can trigger on at least internal and external RAM, with a value stated and opcode fetches. The better systems can trigger on jumps, calls and interrupt acknowledge as well.

Beware - It is in the area of the triggers that dedicated 8051 systems will prove far more powerful than general purpose emulators. Really press the sales engineer to explain exactly what can be done.

If the emulator is any good at all, you should simply be able to use the same code in the emulator that you would blow into an EPROM. However, be aware that some machines need special compiler switches to insert NOP's between subroutines and C lines to stop mis-triggering on opcode fetches. Some 8051 C compilers, like the Avocet AvCase 8051 have special switches to do this (see above).

Why is this an issue? Well, the 8051 always loads opcodes as words, even though they are all bytes. Thus if you jump to a subroutine at an odd address, the preceding even address is loaded and then just discarded. Thus if you are trying to trace a subroutine by starting the trace on the entry address and stopping on the RET, it is very likely that the RET belonging to the preceding subroutine will be seen before the actual start address. A similar situation exists if you jump to the immediate data in a two-byte instruction. Why is this? Simple emulators will trigger on the RET lying immediately before the start address, not realising that the 8051 never actually executed it! This is the type of obscure problem that can drive you mad - until you come across the throwaway line in the Intel data book....

Again it requires a lot of clever hardware to overcome this kind of problem. Ask your sales engineer if they have thought of this. The chances are, they won't have!

Technical Note: To overcome this discarded opcode quirk, the emulator needs to predict what the CPU will do next and hence foresee the event. For this, an opcode decoder is required, in effect, a copy of the CPU's bus interface and execution unit that drives the trigger system. Other clues as to whether the emulator has such a "look-ahead" facility is check how it stops at break points. If it executes the target address before stopping or when running to the cursor, it actually executes the pointed at address, then it probably has no opcode decoder. Again, cheaper and general purpose machines will not have this kind of specific 8051 feature.

A final clue, is to check the sales engineer's demo program - are there any tell-tale NOP's inserted between subroutines or C lines? Ask the sales engineer to run until a CALL or JMP instruction and check very carefully where the emulation actually halts....

Some systems can combine externally sampled signals with bus events to allow processor events to be linked with related signals in the real world.

To some extent, this is a matter of personal preference. However, most PC add-in machines are very low cost and lack many refinements found on more expensive standalone systems. Drawbacks with PC add-ins are being tied to a single PC which makes use with a notebook impossible, loss of expansion slots and most significantly, the emulator will stop when the PC is off - a problem for trapping "once in a blue moon" bugs. Finally, if the sales engineer turns up with a complete desktop PC system unit slung over his shoulder, just think ahead a little - that could be you doing in-the-field work!

For single engineer projects and where desk space is very limited, a PC add-in may have some advantages.

Beware - putting a PC add-in emulator in a standalone chassis usually brings the cost up the price of a proper standalone unit.

Manufacturers usually claim a length in cycles and a width in bits. Typical dimensions are 2048 cycles by 64 bits. The latter is made up of various combinations of bus and external signals. Any trace buffer worth its salt records completely unobtrusively.

At a minimum, the trace should record:
- executed addresses (not loaded- then-discarded ones)
- code labels and variable names
- external signals, either ports or other signals
- bus status - read, write, fetch plus interrupt acknowledge

Better machines will also allow tracing of external program variable data and time stamp information.

The former facility is really essential as it allows the invisibility of the 8051's internal RAM to be compensated for to some extent.

Beware - some machines offer the more advanced facilities only as part of an expensive performance analysis add-on. The result is thus usually disjointed and awkward.

A complication occurs with high level language tracing. Each HLL line can consist of many assembler statements thus every HLL line will soak up several valuable trace buffer cycles. Unless special steps are taken, the normal trace buffer may only hold at most a few hundred lines of C. A better solution is to make the trace record only program branches, filling in the C source lines when the trace is examined. Assuming 4-5 assembler statements per HLL line, the trace buffer capacity can be magnified by a similar degree. Thus such a trace buffer might hold 6000-8000 HLL lines. In some cases, the lack of this line recording trick can make a source level trace almost useless; if there are many library function calls in your code, each library function execution will have every assembler instruction cluttering up the trace buffer when all that is really needed is a simple "strcpy(x,y)", for example!

Beware - a 2k cycle buffer might only hold 500 HLL lines. The problem is further compounded on low cost emulators by the presence of redundant NOP's between each HLL line (see above). It is thus significant that cheaper emulators often have very large trace buffers...

The purpose of the trace buffer is to allow program events to be recorded in real time for later examination. In an ideal world, the trace could be stopped and started by any processor event. Some machines can almost do this with the proviso that the trigger system is actually capable of detecting the event.

The simplest trace mode is a "backward" trace. Here, the trace runs until the processor is halted. When examined, the last event appears at the bottom of the screen. When the buffer is full, it simply overwrites the oldest events.

Beware - some systems only run the trace buffer if explicitly told to do so. However, life is usually such that unexpected events are guaranteed to occur when the trace is not running. It is always best to have a trace which defaults to the running state. Unless of course, you have clairvoyant capabilities!

A forward trace allows the first recorded event to be seen at the top of the screen. This is most usually used when the trace is started by a trigger.

The better traces allow overwriting, trace halt or processor halt when full. A further refinement is an "auto clear" facility so that the buffer is cleared before each new trace recording begins.

Trace control is normally via two or more triggers or by special region definition triggers. These allow specific addresses or address ranges to be either included or excluded from the trace whereas the trace triggers allow the trace to start/stop in response to data read/writes etc. If delay counters are attached to triggers, these can be used to provide a centred trace, with the trigger event actually in the middle of the buffer.

The ideal way of setting up what to trace is to simply select procedure, function or module names from a list. With assembler, just being able to type the start and end addresses for the target areas to be included/excluded can save much head-scratching.

The better systems can use ordinary triggers to control the trace, combinable according to AND, OR and IF-THEN.

This is really what sorts the wheat from the chaff in the emulation world. Whilst not having on-the-fly access to the trace is not a major problem early in a project, once the software is capable of performing real tasks, having to stop the CPU all the time is a major headache. If the software is controlling any sort of mechanical device or is part of any multi-processor network or communications system, having to keep stopping the CPU is guaranteed to be a serious limitation.

The beauty of proper on-the-fly trace access is that you can really see how your system behaves when running in real time and in the target environment. If real-world driven interrupts are crashing into each other, it can actually be seen!

Beware - if your sales engineer cannot demonstrate on-the-fly access to the trace, be very dubious about the system's real time capabilities in general. Most people tend to assume that all emulators have on-the-fly capabilities when in reality, only the very best do. Look for flashing LED'S on the sales engineer's target system or other evidence of uninterrupted operation. Demonstrations where no real inputs/outputs are used are likely to be covering up some basic deficiency.

Technical Note: Being able to access the trace on the fly requires either dual port memory or some clever switching of the trace memory by the emulator's supervisory processor. Simple machines unload the trace memory via the 8051 itself - there is no actual connection between the supervisory processor and the trace memory.

With several thousand assembler or HLL lines to sort through it is almost essential to be able to search for specific events. As the trace buffer is in effect a bus recording, an approach similar to setting a trigger on that event is sensible.

Beware - If you cannot easily search through the buffer, ensure that it can be dumped to a printer for a manual search!

On the majority of 8051 systems, not much! As has been said, Intel do not make it possible to get data out of on-chip RAM in real-time at all. The better systems do at least allow access to external program variables on-the-fly which is extremely useful.

Beware - it is relatively easy for sales engineer's to fool you into thinking that what you are seeing is real time variable retrieval, especially if no target hardware is used. Again, unless explicit evidence is given that real time operation is being maintained, be very suspicious.

A useful trick for C compiler users is to compile any modules which need real time examination in a the LARGE model so that external RAM will be used. A dual ported emulator can then display and trace then on-the-fly.

A good halfway-house towards full real-time access to the on-chip RAM is to trigger on the access to the location, dump the results to the screen and then continue. This does assume though, that the system can trigger on internal memory.

In reality, being able to see variables change in real time is useful but the 8051 is likely to be operating on a microsecond timescale which even the fastest Pentium PC will not be able to keep up with. To make this facility really useful, some means of logging data values into the trace is essential. A normal trigger should be used to simply filter the trace contents, thus giving a real time "data logger"..

A very useful facility is being able to keep your program's interrupts active when the CPU is halted. This allows the real-time elements of the system to carry on whilst you investigate what the background code is up to. Again, an emulator which cannot do this is likely to prove very tiresome once your system is capable of doing real things.

Beware - unless you can also change triggers on-the-fly as well, simple variable retrieval to a PC screen is really just a gimmick. Ask your sales engineer to show you this!

If you engaged in a large 8051 project then the answer is almost certainly "yes". At a simple level, it eliminates the need for counting cycles/microseconds down the side of listing paper when working out an interrupt routine's run time. It should allow rapid identification of where the program run-time bottlenecks are and show which program areas are actually being used. The better systems will also show which areas are never executed - an important measure of software quality. The loading of the stack can also be shown but the limitations of 8051 memory access precludes a proper picture. An indication of the nesting levels reached is also useful.

Beware - the most important performance analysis feature is being able to measure run times EXCLUDING subroutine calls. As an example, a C function may be being examined with a view to optimising it. Normally, many library functions will be called as it proceeds. However from your point of view, this code is of no importance. Therefore it is vital that the performance analyser can measure run times with and WITHOUT these subroutine calls. Ask your sales engineer whether this is possible. Any analyser which cannot EXCLUDE subroutines is little more than a toy.

Coverage monitoring is becoming increasingly important test method and if your projects are done under a quality regime such as TICKIT, is essential.

Yes there are! TICKIT is the most widely used within the UK and it recommends the extensive use of test harnesses, performance analysis and coverage monitoring. Whilst several machines offer performance analysis systems of varying merit, very few 8051 emulators offer a proper means of writing test harnesses. Only one we know of has a test language with PC file IO for documentation generation built into the command language,,,

Some emulators can be very difficult to use, especially if you are not an 8051 expert! Very glitzy, complex user interfaces may appear very friendly but on closer examination can turn out to be very awkward. The use of a mouse is often not a good idea due to the very slowness of the mode when mixed with conventional keyboard entry as well. If a mouse is offered, make sure that it really can access every part of the emulator and that symbols in particular can be chosen from mouse-controlled lists. Many manufacturers now only offer a Windows user interface which is OK if you are a Bill Gates fan. Having both a DOS and Windows version can be useful. Beware - many manufacturers claim their systems are fully mouse-driven. This is rarely the case. Symbols in particular are often entered from the keyboard. Mice and pull-down menus are frequently bodged onto existing software simply to look good during demonstrations. Ask your sales engineer to show you how to operate the emulator without any recourse to the keyboard.

Emulators often have inadequate user manuals and even if this is not the case, being able to make a simple `phone call to the supplier can save many hours of head scratching. Thankfully, the days when manufacturers charged for telephone support are over. However, expect very poor support for emulators supplied via chip distributors. These companies are really only interested in selling silicon so emulators are viewed as just a necessary evil.

Frequently, manufacturers will supplement their own manufacturer equipment to broaden their processor coverage. The USA is normally the source of such machines.

Beware - many small companies spring up selling imported equipment. Finding few customers, they quickly disappear, leaving what users they do have completely stranded.

Beware - A similar situation can exist where systems are bought in to supplement existing products. In one notable case in 1988/90, a range of very expensive 80386 emulators was imported from the USA by one UK manufacturer. That arrangement has now ended, leaving users high and dry. At the end of the day, supporting someone elses products is always very difficult, resulting in much wasted customer time.

Beware- An often overlooked point is that getting technical support directly from USA or Japan-based companies is tricky simply because of the time difference. With something as complex as in-circuit emulation, it is vital that you can get direct access to the manufacturer's own engineers. Ask your sales engineer how long they have been in business in this country and if they are a properly financed subsidiary of the foreign manufacturer. You need to be confident that they will still be there next year to answer your questions...

Some manufacturers price the emulator hardware and software separately so the initial £2999 may actually turn out to be £3999 to get the system running. To further confuse the issue, every sub-function like HLL debugging, performance analysis is priced separately so that trying to cost the system can be very tricky.

With PC add-in emulators, the cost of adding an external chassis often makes the cost comparable to a proper standalone unit.

Beware (i) - if you work for a small company, it is very likely that you will be offered a much lower price than a large organisation as the sales engineer will pitch the price at what he thinks you can afford. This is obviously totally unethical and no reputable manufacture would do this.

Beware (ii) - Some USA-sourced equipment is offered at around one and a half to twice the USA price as the original $ price is converted to £ one-for-one. Ask why UK customers have to pay so much more for the same thing, and still get no direct technical support!

If the system is genuinely reliable and really able to do what is claimed, the sales engineer should be only too happy to oblige. A week is normally long enough to tell whether it is any good or not.

If the emulator under consideration meets all the above criteria, it will probably prove an invaluable tool without which, you will feel lost!. If the answers to more than a few of the questions are unsatisfactory, then you might end with something which will try everybodies patience for a few months and end up just gathering dust under a desk.

[get more info]