Emulation and Simulation
As The Machine hardware does not actually exist in complete form, software creators are in a bind. This includes SoC firmware, Linux device driver writers, application developers, system software integrators, and more. We have not waited to start developing all this software and here's how we're doing it.
Great arguments have been written about the meaning of those two words; here are the working definitions for this project:
| Simulation | Emulation |
|---|---|
| Strives to recreate internal workings to fine, mostly exact detail, with an eye to reach a desired overall effect. Here "The means ARE the ends" and results are accurate at a micro scale. Simulation provides a functional model of the bridge, SoC, and NVM, and exercises their hardware interactions. Firmware and OS driver writers care because their code touches that touches "real hardware". | Focuses primarily with the end results or net effects, perhaps with little or no concern for internal workings. In other words, "The ends justify the means" as long as results are accurate at a macro scale. Some kernel layers, OS libraries and user applications don't actually need to "see" that hardware to use it. Emulation can let the hardware be invisible. |
This simplified version of the multi-node diagram may offer some clarity:
Simulation is a more accurate virtual platform but has tremendous performance requirement on the host system; faithful reproduction of all those ICs doesn't come cheap. Emulation chooses to ignore the minutiae of the hardware (which seems "invisible" after proper configuration) and yields the functional end results. Large classes of software can be written in the simpler emulation environment running on hosts no more powerful than a laptop.