An emulator is a piece of software that emulates a system (that is, imitates it in such a way as to be functionally indistinguishable from the original : e.g. entering input/data/software for the original should have the same result as with the real system) on a computer sufficiently more powerful than the original system to make this feasible in realtime. Usually the subject for emulation is a popular but superceded computer. However, it is possible to create emulations of all kinds of systems, electronic or otherwise.

A few years ago, emulators of microcomputers, coin-ops and games consoles became feasible on modern PC hardware. Initially, coders attempted to emulate these systems to the metal (e.g., a Sega Megadrive emulator would typically load a software emulation of a 68000, a Z80 and all the rest of the gubbins into memory - not as overkill as it sounds, in fact, you can emulate a full speed Z80 in Java). This method does not scale very well however, as an increase in the number and power of dedicated chips in later machines would be very computationally expensive.

So, for formats such as the N64, Neo Geo and Amiga (and of course, the Windows "platform" - in Wine) less "pure", but more efficient methods of emulation were devised. One downside of this shift from exact hardware recreation is that some software would now require specific alteration of the emulator to run as intended. In some cases, this results in the developer concentrating on getting specific programs to run and ignoring others.

It is problems like these, which become enormous obstacles with each increase in the subject system's complexity, that are causing WINE to take so long to be completed!

Another mission accomplished by The Old Node Revival Squad

Since machine code, ultimately, is nothing but ones and zeroes, any digital computer can, in theory, emulate any other digital computer. Whether the emulation is practical depends on, of course, the machine doing the emulating and the machine being emulated.

Reportedly, to offer a striking example of confirmation of this theory, a group of grad students some years ago wrote an 80386 emulator for the Z80. It took half an hour to get a DOS prompt, but it worked. (This may be a mere computing myth, but it illustrates the point.)

Chalk up another for The Old Node Revival Squad.

An emulator is software that translates or interprets machine code from another hardware platform (or the same hardware platform if you're an inefficient idiot (there's native execution and virtualization for that purpose)) See emulation.

Many people insist on calling things like VMWare or WINE an emulator. Speaking strictly technically (with great pedantry), you cannot "emulate" an operating system. Thus, "WINE is not an emulator".

Emulators can be invaluble. Admittedly their main value is in allowing you to play old games again, but some of the better emus allow you to use serious applications designed for a different OS, vastly increasing the usefulness of your lump of hardware. Emulators that I personaly use on a reguar basis include:

Warajevo (DOS->Spectrum): A 100% perfect emulation of every Speccy operating system. Can use just about every file format circulating on the web and even has provision for connecting a tape player to your PC!

Redsquirrel (Windows->Risc OS 3.1): A very good emulation of a early ROS computer. Alows full use of just about any application and most simple games (more advanced games eg. Starfighter work, but slowly) as well as full access to the hard drive. A godsend for a ROS lover wanting to use Impressions/Schema on a PC or laptop. A buggy Risc OS 3.7 work-in-progress version is now available. Very impressive.

Archie (DOS->Risc OS 3.1): A ROS emulator for DOS. In my experience a bit harder to use than Redsquirrel and crashes more often (that may just be me). Unlike Redsquirrel (at the time of writing) can access the floppy drive and can print.

"Emulator", meaning simply something which imitates something else, is generally taken to mean software to imitate a computer hardware platform, as covered elsewhere in this e2node. However, in the electronics industry, "emulator" (as an unqualified term) has a slightly different, and far more exciting specific meaning.

When designing a digital system which includes custom chips, there are a myriad of technical problems. Not least of these is the fact that, before being able to test your complete system (including system boards and software), you have to first finalise the design of your chip, then wait a few months (and pay about $1,000,000) for the chips to come back from the fab plant before plugging them into your system board and giving your software a go.

That's one hell of a debug cycle if you're still developing your chip. So, naturally, nobody does that. Instead, developers rely as heavily as possible on logic simulation of the current state of their work-in-progress chip. This generally works quite well for testing the design of the chip, and for testing the software. But because a software simulation is inherently, well, software, its interactions with the real world are limited.

Furthermore, software logic simulation is incredibly slow in comparison with real hardware, so if we were to allow our simulated hardware to interact with the real world (say via some I/O ports on the host computer running the simulation), it would do so incredibly slowly. If our device is supposed to generate sound, it would be so low that only whales could hear it. If it were intended to control a real-time process such as a chemical reaction, we'd probably have to evacuate the lab.

So, how do we let our chip design interact with the real world, in an almost-real-time nature? It depends on the scale of our chip, and what's on it. But the general answer is: we use an emulator.

What's that, then?

Simply put, an emulator is a large box, typically very expensive and power-hungry, which can be configured to behave like almost any synchronous digital circuit, up to a certain level of complexity and (typically very slow, but far faster than the equivalent software simulation) clock speed.

This allows developers to connect up their system boards and external peripherals to a device that will behave like the final chip (albeit more slowly) to test and debug the system, the chip design and the software. All in almost-real-time.

In the early days of VLSI, QuickTurn were the leaders in emulation technology, to the extent that "QuickTurn box" and "emulator" were almost synonymous. QuickTurn are now owned by Cadence Design Systems, and still making emulators, in competition with Aptix (who were recently bought by Mentor Graphics) and Ikos and a few others. Modern emulators range in size from the size of a deskside PC to a full 19" rack enclosure.


If you're familiar with the concept of a Field-programmable Gate Array (FPGA), you're probably thinking "Hey, that sounds a lot like an FPGA," and you'd be right. For many small designs, a single FPGA can be used to emulate the entire design, making the task of emulation very easy and cheap.

But for larger designs, which will not fit in a single FPGA, we need an emulator; and modern emulators are invariably implemented as, in the main, an array or matrix of FPGAs with a configurable interconnection fabric, allowing a design to be mapped across multiple FPGAs. In addition, they typically contain RAM and other types of specific function hardware which are commonly found in designs but which are more expensive to implement in FPGAs than to simply include in the emulator, as well as a host microprocessor for high-level control, network functions and configuration of the FPGAs.

The other main component found on emulators is, of course, a vast array of wires, to be connected up to system boards, or any other external hardware necessary for testing of the system design.

The process of mapping a design into an emulator is extremely computationally expensive, and is typically handled by a dedicated cluster.

Value added features

One of the primary uses of emulators, as mentioned above, is in debugging: debugging the software, and debugging the hardware design. To facilitate this, most emulation systems have extensive debugging facilities. For example, cosimulation: the ability to communicate with a logic simulator loaded with the same design, such that a developer can examine the current machine state of a paused emulator, using the debug facilities of conventional logic simulation software. Debug breakpoints and signal value traces are also common.

Since these facilities add quite a lot to the complexity of the emulator, and will not necessarily be used in all emulator use cases, so vendors are starting to offer "replicant" emulators, to be used additionally to a full emulator. A replicant emulator lacks many of the debug facilities, and will of course use the same cluster to map the design to its FPGAs, so effectively doubling the availability of emulation for less than half the price more.

Em"u*la`tor (?), n. [L. aemulator.]

One who emulates, or strives to equal or surpass.

As Virgil rivaled Homer, Milton was the emulator of both. Bp. Warburton.


© Webster 1913.

Log in or registerto write something here or to contact authors.