So lets start with a question.
Which comic book hero … or villain, best represents ‘Unreal Simulation’?
Normally in simulation you find a virtual platform that is a representation of specific hardware components or systems, with sufficient accuracy to run unmodified software. An Unreal Simulation is possibly best visualised as Frankenstein. A combination of multiple virtual components to represent new hardware. Why would you possibly want such an abomination? Let me present you with a scenario to explain.
You have developed, validated, and maybe even deployed software for an embedded device. Now the villains in management want to switch and use a different chip. In their eyes it’s a relatively simple task, but the devil is always in the details. This new chip has a timer that has the equivalent functionality, but different interfaces, etc, etc. For some this would trigger a transformation from mild Bruce Banner to the Hulk at the injustice of such a request. Instead consider the path that Unreal Simulation offers.
Traditionally, best practice when changing SoC vendor has been to switch to the new system and hope that the failures due to change are easy to diagnose. With unreal hardware models you can follow a more incremental approach of only changing one variable at a time. Instead of starting with switching the instruction set and swapping out every single device driver in one go, add the new, or replace the current timer in your existing virtual platform and leave everything else as it was.
Now you can be sure that any failures come from only the single unit under test. No longer do you require the deductive brilliance of Sherlock Holmes, simply apply the scientific approach of Batman to debugging and nab the errant semicolon.
Still not convinced? Take a look at how Unreal Simulation can be used to quickly build a test bench in the video below.