"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.
Architecture
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.