例如，在调试UART驱动的问题时，可以为处理器所看不到的UART自身的特定条件设置断点。开发人员甚至能够改变这些设备的状态，从而在系统中加入虚拟硬件故障，以便测试软件如何发现硬件故障并从中恢复。

全系统仿真帮助软件开发人员进行系统级调试，而不是单板级调试。很多工程师可能都做过以下一些尝试：
调试在多板系统启动时间歇性出现，且看似与电路板之间细微的时间变化有关的问题。

在完全相同的时间同时停止系统的所有电路板，以便调试出现在电路板C但很可能起源于电路板A的问题。

调试看似发生在内部SoC I/O外设的设备驱动中的软件问题，却发现不能完全看到SoC内部实际发生的事件。

要求
全系统仿真支持处理所有上述情况。它可以成为非常难的软件和系统问题的一种强大的解决方案。但是，要使得全系统仿真成为现实，必须遵循一些重要的原则：
● 无论整套系统多么复杂，这种仿真需要快到足以运行完整的软件加载。
● 这种仿真必须可升级。如果不能仿真整套系统（无论是5块、10块还是100块电路板），那么它的作用就很有限。
● 仿真环境必须支持一套大型开箱即用的模型库，并同时向用户提供为自己的目标系统快速创建模型的方法。
● 仿真环境需要提供整个仿真系统的控制和可见性。
Virtutech公司的Simics就是仿真系统的一个例子，这是一款支持上述原则的全系统仿真器。设计人员可以运行完整系统的仿真，有时会包含具有异质目标架构的数百块不同的电路板。

目标应用程序代码、实时操作系统、驱动和固件都可以使用虚拟化的目标硬件进行调试、测试和执行。虚拟化的软件开发环境可以运行的二进制代码，与实际目标上所运行的二进制代码完全相同。这就是说，不再需要RTOS/OS API抽象层，stubbed-out驱动或固件，或者在生产环境和stubbed-out环境中使用不同软件编译方法的多编译脚本。

虚拟化的软件开发环境提供了：
● 适用于目标硬件中微处理器的指令集仿真器。
● 目标硬件中与目标软件进行交互的所有设备的行为仿真。
● 仿真目标和现实世界内部及二者之间的连接（例如，诸如以太网、MIL-STD-1553、ARINC 429、SpaceWire、Firewire、USB、ATM等网络以及磁盘镜像、内存镜像等其他机制。）。
● 使用与软件开发人员与实际硬件交互时相同的工具（如编译器、链接器、调试器、IDE和RTOS）和方法的能力。