Communicate with software experts on product changes and improvements
16 Discussions

Introducing RISC-V* in the Simics® Simulator

1 3 4,720

The latest release of the Public Release of the Intel® Simics® Simulator adds a new target processor type, RISC-V*.  This complements the Intel® Architecture-based Quick-Start Platform that was available previously, providing a way to experiment with both Intel and RISC-V target systems.

Target System

A processor on its own is not very useful, you need a platform to run software. For RISC-V, the platform provided is a simple virtual platform that does not correspond to any particular physical RISC-V system. It provides the basics that you expect from a platform: networking, serial, and disks. The platform in its current state looks like the below:


The hardware can be configured by varying the number of processor cores, active instruction set extensions, size of memory, size and contents of the virtual disks, Ethernet network address, and more. To simplify software support, the platform uses virtio devices for disks, networking, and entropy (instead of devices from some specific real-world RISC-V-based system-on-chip (SoC)). For all practical purposes, it looks and feels like a small embedded system, even though it can be configured with many gigabytes of both memory and disk.

The platform can run both Linux* and bare-metal software. For Linux, the standard software stack is built by using Buildroot. Buildroot makes it very easy to generate a bootloader, Linux kernel, and bootable file-system image that can boot on the RISC-V virtual platform.

Networking the RISC-V Virtual Platform

While developing the platform, one rather interesting use case was enabling networking. Getting networking to work to the level of “pinging” between machines was not hard. Enabling remote login from one machine to another took some work.

In the old days, this would have been accomplished using telnet. The protocol, client, and server are all simple, and little configuration is needed. However, the networking world is not the nice friendly place it used to be, and basically all Linux distributions require the use of secure shell (SSH) for any kind of remote login. Adding SSH to Buildroot is easy – add a few lines of configuration and rebuild.

But SSH is a more complicated beast. The first time the target system was booted after adding SSH to the root filesystem, it stopped and hung just before reaching the login prompt. The problem was a lack of randomness. When starting SSH on a fresh installation, it needs to generate a host key, and this requires a supply of randomness. The very simple virtual platform has very few sources of randomness for the Linux kernel to use, and as a result the random pool was filling up very slowly. Blocking progress of the boot. Nice case of “oh, I had no idea that could be a problem”.

The solution can be seen in the block diagram above – we added a “Virtio entropy” device to the target system. This provides a high-bandwidth source of randomness for the target system. It looks like a hardware random-number generator (RNG) to the target system, but is implemented using a deterministic pseudorandom system in the simulator to ensure simulation repeatability. The target software cannot tell the difference.

Here is a simple simulated network setup that uses multiple RISC-V virtual platforms, each with a different hardware configuration. Note that the simulated network also includes a “service node” that provides basic services like DHCP to configure the target systems and a reliable target for ping to test network connectivity within the virtual network.


Below you can see a screenshot of this setup in action, running on a Linux host. The “small” machine is using SSH to connect to the “medium” machine. The “medium” and “large” machines are both running top to show the memory size. They are also running a single-threaded coremark* benchmark in a few copies to demonstrate the simulation of a multicore target system. The Simics simulator command line is showing a list of the simulated machines and all the processor cores in the current simulation.


The Simics command-line interaction in the terminal shows that the target machines have different core counts, clock frequencies, and memory sizes.

Each RISC-V target is in its own Simics simulator cell and thus the simulation can run the three machines in parallel for faster simulation. It is also possible to turn on parallel simulation inside each machine, potentially creating two plus four plus eight, or 14-way parallelism for this case. Such acceleration is particularly useful for compute-heavy workloads.

Networking with the Quick Start Platform

Since the Public Release of the Intel Simics Simulator also contains the Intel Architecture-based Quick-Start Platform (QSP), it is possible to run heterogeneous mixed-architecture simulations. A simple example is combining the two targets in a single network inside a single Simics simulation process. Like this:


Any simulated network can be connected to the outside world using the Network Address Translation (NAT) functionality of the service node. In the screenshot below, we see the host system (running Microsoft* Windows* this time, just for variety) using an SSH client to log into the RISC-V target system via inbound port forwarding. There is also an SSH login from the QSP target system to the RISC-V target system, leading to there being two SSH sessions open (as can be seen from netstat on the RISC-V serial console).



To set this up, all that is needed is a small bit of top-level scripting on top of the existing virtual platform scripts. First, a YAML file is used to set up default parameter values where they differ from the standard values in the targets. Note that this is based on early drops of the targets, and the precise name of the parameters and the parameter hierarchy might change.



%YAML 1.2
description: > 
  Network containing a mix of RISC-V-Simple and QSP-X86 machines, 
  demonstrating heterogeneous simulation in Simics. 
  ## Network setup
      import: "%simics%/targets/common/ethernet-setup.yml"
      import: "%simics%/targets/common/sn-setup.yml"
        ethernet_switch: ^network:switch:ethernet_switch:name

  ## RISC-V machine 
    import: "%simics%/targets/risc-v-simple/"
        board_name: rvs
        num_cores: 4
        freq_mhz: 2000
        ## Don't create a local network for this machine
        create: false

  ## QSP-x86 machine
    import: "%simics%/targets/qsp-x86/clear-linux-setup.yml"
        machine_name: qsp
        memory_megs: 32768
          num_cores: 4
          freq_mhz: 3500
            image: "targets/qsp-x86/images/ubuntu-linux.craff"
            ## Automatically size disk after the image file
            size: 0

code-type: simics
script: "%script%/"



Second, a Simics simulator command-line script is called from the YAML file and builds the network and target systems by using existing setup scripts that create the discrete components of the setup.



## Example Simics simulator setup script, Copyright Intel 2023

## Create the network
run-script "%simics%/targets/common/ethernet-setup.yml" namespace = network:switch
local $ethernet_switch = (params.get network:switch:ethernet_switch:name)

## Create the RISC-V Simple target
run-script "%simics%/targets/risc-v-simple/" namespace = rvs
connect ($ethernet_switch.get-free-connector) (params.get "rvs:system:components:eth")

## Create the QSP-x86 target
run-script "%simics%/targets/qsp-x86/clear-linux-setup.yml" namespace = qsp
connect ($ethernet_switch.get-free-connector) (params.get "qsp:hardware:outputs:eth_slot")
# Adjust a presentation parameter 
$qsp = (params.get name = qsp:hardware:outputs:system)
$qsp->system_info = "QSP with Ubuntu Linux"

## Create a service node to provide DHCP, real network, etc.
run-script "%simics%/targets/common/sn-setup.yml" namespace = network:service_node

## Connect real network, with ports mapping to RISC-V simple by default



Counting Instructions

When I shared the above demos with my colleagues, their reaction was that it “looks like the old Virtutech demos”. That is true on the surface – heterogeneous network simulation is a classic part of the Simics simulation, being part of early demos as early as 2002.

Under the hood, however, the simulation technology and implementation are very different. The Simics simulator is much faster and more scalable, including the use of multiple host cores to run multiple target boards and multiple cores sharing memory. Setting up a heterogeneous target is much easier (as seen from the code above). Most importantly, the ability to inspect and control the target is much greater today.

A simple example of this framework power is counting the number and type of instructions being executed on the two target machines in the mixed network. This is easy to do using the Simics simulator instrumentation API. First, boot the network and set up an interesting scenario (such as setting up SSH sessions from the host and between the target machines). Second, create an instruction histogram tool for each target. Finally, run the simulation while collecting statistics.



The overhead is small enough that the target systems remain interactive. The screenshot above shows what this looks like in action. The instruction histograms are read out and presented every virtual second. In this case, the QSP virtual platform is mostly idle, while the RISC-V virtual platform was just finishing up a dhrystone run. The most frequent instructions are the basics: things like loads, stores, moves, compares, jumps, and some additions.

Final Words

This blog post looked at the system-level simulation aspects made possible by the new RISC-V simple virtual platform. Future blog posts will dig deeper into the aspects of running software on the platform, including changing the instruction set and debugging software.

Technical Note

The above setups were created using the Public Release of the Intel Simics Simulator, version 2023-19. Precise names of scripts and parameters can change in future releases.

Could this RISC-V virtual platfrom in public release add a PCI device, which designed by DML 1.4 ?

PCIe is not in the currently released platform.  It might be possible to add it in the future.


According to the last question,is it possible to add  PCIe in RISC-V virtual platfrom,just using existent classes like pcie-bus or 

pcie-downstream-port-legacy in public release?thank you!