Arm has its own simulator. Here is what it actually models.

I wrote a three-way comparison of embedded simulators — Wokwi vs Renode vs QEMU — and left out the one made by the company that designs the instruction set.

That was not an oversight so much as a reflex. Most conversations I have about running firmware without a board land on those three. Arm's Fast Models and the Fixed Virtual Platforms built from them rarely enter the comparison, even though Arm has shipped them for years, gives several of them away, and updates them regularly.

So here is the plain version.

What Arm's Fast Models and FVPs actually ship

Fast Models is the modeling technology. An FVP is a ready-made platform assembled from it: a processor model, some memory, some peripherals, packaged as a binary you run from a shell.

For Cortex-M, the ones that matter are the Corstone platforms — FVP_Corstone_SSE-300 (Cortex-M55), FVP_Corstone_SSE-310 (Cortex-M85), FVP_Corstone_SSE-315 and FVP_Corstone_SSE-320 (Cortex-M85 with Ethos-U65 or Ethos-U85, plus Mali-C55), and Ethos-U variants of the first two.¹ An older family of bare per-core models is named after the MPS2 board: FVP_MPS2_Cortex-M0 through -M85, one per core.¹ Arm steers you off those for anything recent — "It is recommended to use Corstone-320/315/310 FVP models for Cortex-M85".¹

The framing that explains everything else is Arm's phrase "programmer's view":

"FVPs provide Programmer's View (PV) models of processors and devices. The functional behavior of a model is equivalent to real hardware. PV models sacrifice absolute timing accuracy to achieve fast simulated execution speed. This means that you can use PV models for confirming software functionality, but you must not rely on the accuracy of cycle counts, low-level component interactions, or other hardware-specific behavior."²

Fast Models also produces a second kind of model, and the contrast between them is the clearest thing in Arm's documentation. An Architecture Envelope Model is "a fully-configurable, generic model of an Arm architecture. It aims to expose software bugs by modeling the range of behavior that the architecture allows."³ A Programmers' View model is "a high performance, functionally accurate model of a hardware platform. It can be used for booting an operating system and executing software, but not to provide hardware-accurate timing information."³

The timing story, told by Arm against its own interest

I have written about what "cycle-accurate" actually means, and Arm's documentation is one of the few vendor sources that does not blur the line to make itself look better.

A 2022 Arm reference-design guide says it in six words: "The FVP also cannot be used to measure software performance."⁴

And then there is the detail I find genuinely persuasive, because it is a product decision rather than a disclaimer. Arm removed a parameter that exposed the performance monitoring unit on the Cortex-M55 model. Arm staff, on Arm's own forum, explained that has_pmu "has been removed from the ARMCortexM55CT component... since version 11.22 because keeping this parameter is misleading... FVPs are not cycle accurate... so the values are inaccurate."⁵

A vendor deleting a feature because users kept reading real numbers into it says more than any paragraph of caveats. The honest fix was to remove the knob, and Arm removed it.

The crux: it models Arm's designs, not anyone's chip

Arm's technical overview for the Corstone SSE-300 FVP lists what is inside:

"The Corstone SSE-300 FVP models a r0p0 version of Corstone SSE-300 Subsystem. The FVP models the following IP components: Single Arm Cortex-M55 processor with MVE extension, Single Arm Ethos-U55 NPU, Memory Protection Controller (MPC), Peripheral Protection Controller (PPC), Implementation Defined Attribution Unit (IDAU). The FVP does not model every component that Corstone SSE-300 describes. For example, it does not model the CoreSight technology components."⁶

Every item on that list is Arm IP. The same is true one level up, at the board:

"Board — The board peripherals represent peripherals that may be present on the board onto which the SoC is mounted. The Corstone SSE-300 board model is based on the ARM MPS3 Board."⁶

So an FVP models an Arm reference subsystem, mounted on an Arm reference board, built from Arm IP, with real rigor — and models no specific vendor's silicon at all. Not an STM32. Not an nRF52. No vendor clock tree, no vendor flash controller, no vendor errata.

That is the exact inverse of Renode's proposition, which exists to model named parts from named vendors, and a different point again from QEMU's generic machines. I laid out that axis in Renode vs QEMU: what each actually models.

The stubs are labeled, and that is a good sign

Arm's peripheral tables mark UART3 and UART4 on the SSE-300 as "Dummy Stub" while UART0, 1, 2 and 5 are real CMSDK UARTs, and mark the CLCD configuration register as "Partial modelled". The legend is Arm's own: "Dummy Stub – These stubs have minimal implementation... Partial Modelled – Certain features are implemented."⁶⁷

I do not read that as a gotcha. A reference subsystem has no reason to model a UART nobody boots through. The same question runs through what QEMU models on Cortex-M: which parts of a machine exist.

The complication: two products, one brand

Arm's Virtual Hardware product page describes two different families. The first is "Arm Virtual Hardware FVPs", which is "Based on Arm Fast Model technology" and covers "Corstone platforms... All Cortex-M processor cores."⁸ That is everything above.

The second is "Arm Virtual Hardware Third-Party Hardware", "Underpinned by the Arm Neoverse CPU natively executing Arm code", offering "Accurate models of complete SoCs and development kits, including peripherals, sensors, and other board components. These models are not performance accurate."⁸ The product list is short and specific: "Raspberry Pi Model 4, NXP i.MX 93, NXP i.MX 8M Arm Cortex Complex, STM32U5 IoT Discovery Kit", and it is "Available via Corellium."⁸

So yes — Arm sells something that models a real STM32 development board. It is not an FVP. It runs on Corellium's virtualization technology, which Arm licensed in October 2022: "Arm is licensing Corellium's virtualization technology as part of its Arm Virtual Hardware (AVH) offering."⁹ And it is not finished: Arm's own learning material states that "Arm Virtual Hardware Third-Party Hardware is currently in public beta."¹⁰

That distinction is easy to lose, and I have watched people lose it mid-conversation, so here it is the long way: Fast Models and FVP technology do not model specific vendor silicon, and a separate, beta, partner-limited product under the same brand does, using different technology underneath.

How faithful that second family is, nobody outside has audited in public. A DVCon paper raises the obvious caution: "Emulation may be partial. For instance, the RPI4 model does not offer GPU emulation... it is not possible to assess whether Virtual Hardware allows development of end-to-end stacks... and the accuracy of the modeling."¹¹

Practical friction, in the order you will hit it

There are no macOS binaries. Arm is blunt: "Arm FVPs are not available for macOS. Refer to FVPs-on-Mac for a workaround using a Docker container."¹² Arm maintains that workaround repository itself.¹³ Darwin is the only absence, and on my team that is the conversation.

The Corstone models are free, and documented as free. Arm: "The Corstone-300 and Corstone-700 FVPs are now available at no cost... No license key, no fees, just one click. Your access to Corstone FVPs is free and not limited in time."¹⁴ Arm staff confirm the CI case separately: they "can be used freely in a CI system" and need no license key.¹⁵

The packaging changed, and that matters more than the price. Arm: "Arm Fixed Virtual Platforms (FVPs) were available as a library of ready to use platforms (and as a component of Arm Development Studio) up until version 11.28. From 11.29 onwards the FVPs are provided solely as part of Arm Development Studio."¹⁶ Development Studio Gold lists at "$5,170.00/year per license".¹⁷ The free Corstone downloads and the general library are now two different stories.

Speed: Arm publishes numbers, nobody publishes a comparison. Arm says code-translation models run "between 20-200 MIPS on a typical workstation, enabling an OS to boot in tens of seconds".³ No published head-to-head against QEMU exists, so I will not quote you a ratio.

Who should use one, and who should not

This is the practical distinction the documentation makes hard to find.

If you are...	FVP is...	because
Writing a CMSIS, TF-M or RTOS port against a core, not a chip	the right tool	the model is the architecture, from the people who define it
Hunting undefined-but-architecturally-legal behavior	the right tool	that is literally the AEM's stated job3
Validating a driver against a vendor's peripheral	the wrong tool	your peripheral is not in there6
Chasing a timing or performance question	the wrong tool	Arm says so itself4

Teams moving between simulators find the real cost is the test harness rather than the simulator, which I went through in Renode alternatives. An FVP is cheap to add alongside something else because its scope is narrow.

Four tiers, not three

So the map I have been carrying around has one more row in it than I thought.

Tier	Example	Models	Best at
Hobby / educational	Wokwi	popular boards, in a browser	learning, sharing, quick demos
Specific silicon	Renode	named vendor parts and peripherals	driver and board-level firmware
Generic core	QEMU	machines built around a CPU	booting, portability, breadth
Architecture authority	Arm FVP	Arm reference subsystems and boards	conformance to the architecture itself

The gap the fourth tier does not fill is the one I spend my working life on: a specific vendor's chip, hosted, no board and no local install, that a coding agent can drive without a human in the loop. An FVP gives me the architecture but not the chip. That is why Chiplab models named vendor microcontrollers rather than reference subsystems — different tier, different question.

Agents make that choice sharper. Point an agent at an FVP and it can expose architecture-level problems while leaving vendor peripherals untested. A vendor-specific model can exercise those peripherals, but only to the fidelity its implementation provides. A simulator answers the question it was built to answer, and an agent that does not know which question it asked reports success either way.

I do not think Arm's simulator is underrated. It is useful for a narrow job and easy to miss outside that job, partly because its documentation is written as if you already work at a silicon vendor. The first useful distinction takes hours of reading to reach.

It took me longer than that. Now it is one paragraph.

Sources

Footnotes

1. Arm, "Arm Virtual Hardware — Simulation," Arm Software documentation. https://arm-software.github.io/AVH/main/simulation/html/index.html ↩ ↩² ↩³

2. Arm, "Fast Models Fixed Virtual Platforms (FVP) Reference Guide," Arm. https://documentation-service.arm.com/static/5f4d1264ca7b6a3399375cb4 ↩

3. Arm, "What is Fast Models?," Fast Models User Guide, Arm. https://developer.arm.com/documentation/100965/1131/Introduction-to-Fast-Models/What-is-Fast-Models- ↩ ↩² ↩³ ↩⁴

4. Arm, "RD-TC22 Fixed Virtual Platform," Arm developer documentation, 2022. https://developer.arm.com/documentation/108028/0000/RD-TC22-Fixed-Virtual-Platform ↩ ↩²

5. Arm, "Measuring performance of programs on the FVP Corstone SSE-300," Arm Community support forums. https://community.arm.com/support-forums/f/soc-design-and-simulation-forum/55657/measuring-performance-of-programs-on-the-fvp-corstone-sse-300 ↩

6. Arm, "Corstone SSE-300 with Ethos-U55 FVP (MPS3) Technical Overview," Arm Software documentation. https://arm-software.github.io/AVH/main/simulation/html/Corstone_SSE-300_Ethos-U55_FVP_MPS3_Technical_Overview.pdf ↩ ↩² ↩³ ↩⁴

7. Arm, "Corstone SSE-310 FVP Technical Overview," Arm Software documentation. https://arm-software.github.io/AVH/main/simulation/html/Corstone_SSE-310_FVP_Technical_Overview.pdf ↩

8. Arm, "Arm Virtual Hardware," Arm products. https://www.arm.com/products/development-tools/simulation/virtual-hardware ↩ ↩² ↩³

9. Corellium, "Announcing the Corellium and Arm partnership," Corellium blog, October 2022. https://www.corellium.com/blog/announcing-corellium-and-arm-partnership-2022 ↩

10. Arm, "Platforms," Arm Learning Paths. https://web.archive.org/web/20251010211456/https://learn.arm.com/learning-paths/embedded-and-microcontrollers/nav-mlek/platforms/ ↩

11. DVCon proceedings paper on Arm Virtual Hardware. https://dvcon-proceedings.org/wp-content/uploads/91483.pdf ↩

12. Arm, "AVH FVP Artifactory," Arm Software documentation. https://arm-software.github.io/AVH/main/infrastructure/html/avh_fvp_artifactory.html ↩

13. Arm, "FVPs-on-Mac," Arm-Examples GitHub repository. https://github.com/Arm-Examples/FVPs-on-Mac ↩

14. Arm, "Arm Corstone virtual platforms now available at no cost," Arm Community IoT blog. https://community.arm.com/arm-community-blogs/b/internet-of-things-blog/posts/arm-corstone-virtual-platforms-now-available-at-no-cost ↩

15. Arm, "Arm FVP and continuous integration," Arm Community support forums. https://community.arm.com/support-forums/f/soc-design-and-simulation-forum/47151/arm-fvp-and-continuous-integration ↩

16. Arm, "Fast Models and Fixed Virtual Platforms install guide," Arm Learning Paths. https://learn.arm.com/install-guides/fm_fvp/fvp/ ↩

17. Arm, "Arm Development Studio," Arm store. https://store.arm.com/arm-ds/ ↩