Hardware emulation: running the chip before it exists
Simulating a modern chip in software is thousands of times too slow to run an operating system on it. Emulation maps the design onto a large array of reconfigurable hardware instead, fast enough to run real software against the real design — which is how a chip and its firmware arrive at the same time.
In one sentence
Hardware emulation maps a chip design onto purpose-built reconfigurable hardware so it can be executed at speeds many orders of magnitude above software simulation, allowing software to be developed and the design verified before manufacture.
Verification is the largest activity in a chip programme, and simulation alone cannot finish it. A software simulator runs a large design at a handful of cycles per second; booting an operating system needs billions of cycles. Emulators close that gap by executing the design in hardware, at speeds where booting takes minutes rather than centuries.
The machines are substantial: multi-rack systems costing millions, shared across teams and time-sliced like any scarce compute resource. They are sold by the same three companies that sell the design software, which is one of the reasons that market is as concentrated as it is.
How it works
Emulation versus prototyping
Emulators use custom processors or purpose-built arrays and give deep visibility into the running design — you can stop it and look at any signal. Prototyping systems use commercial programmable logic, run faster and cost less, and give far less visibility. Teams commonly use emulation for debug and prototyping for software development, on the same design.
Why it changed the schedule
Before emulation, firmware and drivers began when silicon arrived, adding months after tape-out before a product could ship. Running the real design in an emulator moves that work earlier, so hardware and software are ready together. That schedule compression is what justifies the cost of the machines.
Capacity is planned like fab capacity
A large design consumes a large fraction of an emulator, and the number of gates a company owns emulation capacity for is a real planning constraint. Buying more is a capital decision made a year ahead, which is why emulation appears in verification plans as a resource to be scheduled rather than a tool to be opened.
What this depends on
Technology dependencies are solved by engineering; supply dependencies are solved by building something, which takes years.
Technology
Synthesis and compile flow
A design has to be compiled onto the machine before it can run on it, and compile time on a large design is a real part of how usable an emulator is.
Emulators are built from custom processors and large programmable logic devices, which are themselves advanced parts competing for the same capacity as everything else.
What each company supplies at this step, and — where a public figure exists — its share of this specific market — with what that share measures, the period it covers and who published it. Some rows also show the company’s own reported revenue for the segment covering this step, which is a different thing: it says how much this business matters to that company, not how much of the market it holds. Not a ranking and not a recommendation.
Supplies the protocol validation and analysis gear a design is checked against once it leaves the emulator.
Questions people ask about this
Why not just simulate faster?
Because the gap is too large to close with more servers. Software simulation of a large design runs at a few cycles per second and booting software needs billions of cycles — a difference of many orders of magnitude. Executing the design in hardware is the only approach that closes it.
Is an emulator the same as an FPGA board?
Related but not the same. Prototyping systems do use commercial programmable logic and are faster and cheaper. Emulators use purpose-built hardware that compiles designs far more quickly and lets engineers observe any signal while it runs, which is what makes them usable for debugging rather than only for running software.
Each page explains one technology in plain language, states what it depends on, and names companies by what they supply at that step. Company roles are described qualitatively and deliberately carry no market shares, revenue figures or rankings — those change faster than an explainer can, and a stale number is worse than none. Ticker links point at company pages on this site and are provided for reference only.
Nothing here is investment advice, a recommendation, or a forecast. A company named on a page about a technology is not thereby a good investment, and the chokepoints described are structural facts about supply chains rather than predictions about prices. Technology moves; where a page describes something as unresolved or in development, that was true when it was written.
Plutux no es un asesor de inversiones. Los datos de mercado y el análisis generado por IA son solo informativos y educativos, no asesoramiento de inversión. Aviso legal