Software engineering teams building for RISC-V architectures often wait months for hardware prototypes before they can start development and evaluations.

This post shows how MachineWare’s SIM-V — an ultra-fast RISC-V Virtual Platform — runs on Amazon Web Services, Inc. (AWS), so software teams can develop, debug, and validate RISC-V software long before silicon is available.

For embedded software engineering teams aiming to run and optimize RISC-V simulation workloads, we will cover the integration architecture (open GNU Debugger (GDB) protocols, Arm and x86 Amazon EC2 support) and share benchmark results across the c8a, c8i, c8g, m8azn, and x8aedz instance families.

Key takeaways:

1. Clock frequency dominates single-thread simulation performance — 5 GHz m8azn.xlarge and x8aedz.xlarge instances outperform c8g.xlarge by up to 230%
2. Parallel workloads scale near-linearly with vCPUs — delivering ~8x speedup at 8 cores in our Matrix Multiplication benchmark
3. Right-size to actual workload parallelism — oversized instances deliver no benefit on single-threaded benchmarks like CoreMark, Dhrystone, or Whetstone

The Growing Complexity of Software-Defined Systems

Software is becoming increasingly complex, deeply interconnected, and embedded in nearly every aspect of our daily lives. To put this evolution into perspective: the Apollo 11 Command Module that carried the first humans to the moon required approximately 100,000 lines of code. In contrast, a modern vehicle now relies on more than 100 million lines of code—just to get us to the supermarket and back.

This exponential growth in software complexity challenges the traditional “hardware first, software second” development model. When software development begins only after the first hardware prototypes are available, organizations face:

• Increased time-to-market
• Higher development costs
• Elevated risk of hardware design flaws discovered too late
• Friction between hardware and software teams

To stay competitive, engineering organizations must rethink how systems are designed, validated, and deployed.

Shifting Left with Virtual Platforms

Virtual Platforms, which are digital twins of real hardware, help to tackle these problems by simulating an entire System on a Chip (SoC) including full software stack on general purpose hardware.

This approach delivers several key benefits:

• Earlier detection of hardware/software mismatches
• Reduced integration risks
• Shorter time-to-market
• Improved collaboration between hardware and software teams
• Scalable CI/CD pipelines independent of physical hardware availability

RISC-V– The Next Big Thing

The rise of RISC‑V amplifies this need even further. RISC‑V is an open‑standard ISA—the basic set of instructions a processor understands—offering a free, modular, and extensible alternative to proprietary architectures like Arm and x86. Its openness has helped it grow from a 2010 academic project into a global ecosystem powering billions of devices and supported by thousands of members worldwide, with analyst SHD Group estimating rapid progress toward 25% as adoption spreads across IoT, automotive, and edge AI applications. As companies look to escape licensing costs and vendor lock‑in, RISC‑V’s flexibility and accelerating industry support make it inevitable for the future of computing.

Despite its hardware progress, the RISC‑V software ecosystem is still catching up. Compiler optimizations lag behind established architectures, major vendors have been slow to port their applications, and the market still lacks a broad range of mature RISC‑V hardware platforms.

This is precisely where Virtual Platforms shine: by giving software teams the ability to build, test, and optimize RISC‑V software today, even when the underlying hardware is not yet available or fully mature. Virtual Platforms effectively bridge the gap, helping organizations adopt RISC‑V with confidence and without waiting for the ecosystem to catch up.

Ultra-Fast RISC-V Virtual Platforms from MachineWare

As a provider of RISC-V Virtual Platforms, MachineWare offers their RISC-V processor simulation model SIM-V, attaining native-speed performance while maintaining high flexibility, accuracy and customizability. However, the processor model alone is not enough to execute complex target software such as Real-Time Operating Systems (RTOS) or rich OSs such as Ubuntu, which require additional hardware components such as interface controllers for UART, Ethernet or CAN, accelerators like GPUs and more. To fill this gap, MachineWare provides VCML (Virtual Component Modeling Library), an open-source modeling library designed to facilitate swift assembly of complete Virtual Platforms. Built on the IEEE SystemC TLM-2.0 standard, it offers advanced modeling primitives as well as free models of industry-relevant hardware components. In the following sections, we describe how a RISC-V Virtual Platform based on SIM-V has been integrated into AWS to enable scalable, cloud-based virtual prototyping workflows.

Integrating SIM-V into AWS

Unlike many traditional Electronic Design Automation (EDA) tools, SIM-V was architected from the ground up for flexibility and portability. It is not tied to specialized infrastructure or rigid deployment models. Instead, it is designed to run on anything from anywhere.

On AWS, SIM-V is available across multiple instance types and supports both ARM- and x86-based instance architectures, as well as different operating systems. This flexibility enables customers to select the optimal infrastructure for their workloads, whether for interactive development, regression testing, or large-scale CI/CD pipelines.

The key challenges of running Virtual Platforms in the cloud are maintaining control and visibility over the simulation environment. SIM-V addresses these through two open protocols:

• GDB Remote Serial Protocol (GDB RSP) for debugging target software
• MachineWare’s VCML Session Protocol (VSP) for controlling the overall simulation environment

Because both protocols are open-source, customers can integrate SIM-V with their preferred development tools and frontends. For example, developers can use Visual Studio Code with GDB RSP support to remotely debug software running inside the Virtual Platform—leveraging a familiar interface while executing simulations in AWS.

Another important aspect of cloud-based Virtual Platforms is the injection of external test stimuli. In physical systems, these stimuli typically originate from peripherals outside the MCU or SoC, such as GPIO signals, CAN frames, or Ethernet packets. Within the Virtual Platform, such stimuli can be transmitted either through VSP or, in the case of virtual buses such as CAN or Ethernet, through dedicated TCP/IP connections. This architecture enables realistic system-level testing and integration scenarios while maintaining the flexibility of distributed cloud execution.

Figure 1: MachineWare’s SIM-V AMI on Amazon EC2, integrated with AWS License Manager

Benchmarks and Performance Characteristics of SIM-V on Amazon EC2

To answer the fundamental questions – How fast is SIM-V, and on what hardware should you run it? – we built a fully automated benchmarking harness that systematically measures and compares SIM-V’s simulation performance across different workloads, RISC-V architectures, core configurations, and AWS EC2 instance types.

The Benchmark Suite

Our benchmark suite comprises seven distinct workloads that stress different aspects of the Virtual Platform:

CPU Performance Benchmarks:

• CoreMark — Industry-standard CPU performance benchmark measuring how efficiently SIM-V executes typical embedded workloads
• Dhrystone — Integer computation throughput, testing the simulation’s ability to handle integer-heavy operations
• Whetstone — Floating-point performance measurement, critical for scientific and signal processing applications
• Matrix Multiplication — Multi-core benchmark that reveals how effectively SIM-V distributes computational load across virtual CPUs for example targeting AI applications

Peripheral and System Benchmarks:

• CAN Loopback — CAN bus throughput in a single-process loop, measuring raw peripheral simulation performance
• CAN Ping Pong — Bidirectional CAN communication between SIM-V and an external Python process over TCP, demonstrating real-time interaction with host-side tooling
• Buildroot Boot — Full OS boot time on RISC-V 64-bit with 1, 2, and 4 core configurations, providing a system-level benchmark for a light-weight OS
• Ubuntu Boot — Full OS boot time on RISC-V 64-bit with 1, 2, and 4 core configurations, providing a system-level benchmark that exercises the entire Virtual Platform stack

Performance Across AWS Instance Types

Our benchmarking revealed two critical insights for optimizing SIM-V deployment on AWS:

Instance Size Matters Only for Parallel Workloads

Testing across the c8a instance family (large, xlarge, 2xlarge, 4xlarge, 8xlarge) demonstrated that single-threaded benchmarks—CoreMark, Dhrystone, and Whetstone—showed virtually identical performance regardless of instance size and RISC-V architecture target, as figures 2 and 3 illustrate.

Figure 2: RV32 benchmark performance within c8a EC2 instance family

Figure 3: RV64 benchmark performance within c8a EC2 instance family

However, the Matrix Multiplication benchmark, configured to utilize up to 8 host cores, revealed dramatic scaling benefits, evident in figures 2 and 3. The c8a.2xlarge instance, which has 8 vCPUs, achieved a 3.7x performance improvement over the c8a.large instance, which has 2 vCPUs. The speed-up directly correlates with available host vCPUs, taking into consideration that at least one vCPU is required for other system applications. As expected, the performance improvement flattens out for c8a.4xlarge (16 vCPUs) and c8a.8xlarge (32 vCPUs) with the additional cores not contributing to the performance improvement.

Architecture Selection: Clock Frequency Drives Single-Thread Performance

When comparing xlarge instances across different EC2 architectures with fixed core counts (8 vCPUs), the m8azn.xlarge and x8aedz.xlarge instances emerged as the clear winners due to their superior 5 GHz clock frequency. They outperformed c8a.xlarge (4.5 GHz) by 15%, c8i.xlarge (3.9 GHz) by 60%, and c8g.xlarge (2.8 GHz, ARM-based AWS Graviton processor) by 230%, as seen in figures 4 and 5.

Figure 4: RV32 performance across EC2 instance families with fixed core counts

Figure 5: RV64 performance across EC2 instance families with fixed core counts

The performance hierarchy directly mirrors CPU clock speeds: m8azn/x8aedz (5 GHz) > c8a (4.5 GHz) > c8i (3.9 GHz) > c8g (2.8 GHz). This pattern held consistently across all single-threaded benchmarks, confirming that for Virtual Platform simulation, raw clock frequency is the dominant performance factor.

Multi-Core Scaling Analysis

The Matrix Multiplication benchmark demonstrates how effectively SIM-V leverages host parallelism. On the c8a.4xlarge instance (16 vCPUs) for RISC-V 64-bit, performance scaled by ~8x when moving from a single-core to an octa-core configuration. This near-linear scaling validates SIM-V’s multi-threaded architecture and confirms that users running parallel workloads should prioritize higher core-count instances.

CAN Bus Simulation Fidelity

The CAN benchmarks deserve special attention because they test SIM-V’s peripheral simulation, not just CPU performance. The CAN Loopback benchmark measures raw throughput within the Virtual Platform, while CAN Ping Pong coordinates with a CAN restbus simulation implemented in an external Python script communicating with the simulated CAN controller over TCP—demonstrating that SIM-V can interact with host-side tooling in real time with minimal latency overhead (figures 6 and 7).

Figure 6: RV32 CAN loopback and CAN pingpong benchmark results across EC2 instance families

Figure 7: RV64 CAN loopback and CAN pingpong benchmark results across EC2 instance families

Ubuntu Boot: A System-Level Validation

Booting a full Ubuntu 24.04 image on a simulated RISC-V 64-bit system serves as the ultimate integration test. The harness monitors stdout for login prompt detection, measures wall-clock boot time, and aggregates MIPS across all CPUs, as seen in figure 8. This benchmark proves that SIM-V handles real operating systems with complex initialization sequences, not just bare-metal microbenchmarks.

Figure 8: RV64 Buildroot and Ubuntu boot performance benchmarks

Performance improvements can be observed in multi-core scenarios, as SIM-V can exploit the parallel execution of Ubuntu’s systemd-based init system.

Conclusion and key takeaways for RISC-V developers on AWS

For single-threaded workloads like interactive development and debugging, prioritize high clock-frequency instances—the m8azn.xlarge and x8aedz.xlarge (5GHz) deliver up to 230% better performance than lower-frequency alternatives, while instance size has virtually no impact. However, for parallel workloads which might be carried out in regression testing or CI/CD pipelines, scale to higher core-count instances like c8a.2xlarge or larger to achieve near-linear performance gains—our Matrix Multiplication benchmark demonstrated ~8x speedup with 8 cores. The performance hierarchy is clear: m8azn/x8aedz (5 GHz) for maximum speed, c8a (4.5 GHz) for balanced cost-performance, and c8i/c8g for budget-conscious workloads. Importantly, right-size your instances based on actual parallelism—performance plateaus once you exceed your workload’s threading capabilities, making oversized instances cost-ineffective.

To get started with SIM-V, try out MachineWare’s SIM-V demo here: https://www.machineware.de/demo