Emulation and Simulation

This tutorial walks through building and running a SLASH application in emulation and simulation modes. Neither mode requires FPGA hardware — your application runs against a software model of the kernels instead.

For a conceptual overview of the three platforms see Platform Modes.

Prerequisites

  • The SLASH stack is installed (at minimum VRT and the CMake modules). See Build and Install SLASH.

  • AMD Vivado 2025.1 and Vitis HLS 2025.1 are installed and sourced in your shell:

    source <path-to-vivado>/settings64.sh
source <path-to-vitis-hls>/settings64.sh

    For csh/tcsh shells, use settings64.csh instead. Using versions other than 2025.1 may cause breakage.

  • For simulation: a Vivado-supported Verilog simulator licence.

  • No V80 board is required.

When to Use Each Mode

Mode

Speed

Accuracy

Best for

Emulation

Fast

Functional only

Rapid iteration on kernel logic

Simulation

Slow

Cycle-accurate RTL

Catching timing and protocol bugs

Use emulation first to verify functional correctness, then simulation when you need cycle-accurate behaviour.

Build an Emulation Vrtbin

Ensure you have sourced Vivado and Vitis HLS before building (see Prerequisites).

Using the 00_axilite example:

cd examples/00_axilite
cmake -B build -S . -G Ninja
cmake --build build                              # build the host application
cmake --build build --target hls                 # compile HLS kernels (requires Vitis HLS)
cmake --build build --target axilite_emu         # link into an emulation vrtbin

The axilite_emu target invokes the SLASH linker (slashkit) with PLATFORM "emu". The resulting .vbin file contains:

  • system_map.xml with <Platform>Emulation</Platform>

  • vpp_emu — a compiled C-model executable of the HLS kernels

  • emu_manifest.json — argument routing metadata

Run in Emulation

Run the same application binary, passing the emulation vrtbin:

./00_axilite 03:00 axilite_emu.vbin

The BDF argument (03:00) is still required for API compatibility but no hardware is accessed. Under the hood VRT:

  1. Extracts the vrtbin and reads system_map.xml.

  2. Detects Platform::EMULATION.

  3. Launches the vpp_emu process in a background thread.

  4. Connects to the C-model via ZeroMQ on a per-device endpoint, ipc://<vrtbin-extraction-dir>/zmq.socket, which VRT supplies to the model executable as its sole command-line argument. The per-device endpoint permits multiple emulated devices to run concurrently.

  5. Translates setArg(), start(), wait(), and sync() calls into JSON commands sent over ZeroMQ.

The application output should match hardware results exactly.

Build and Run in Simulation

cmake --build build --target axilite_sim  # link into a simulation vrtbin
./00_axilite 03:00 axilite_sim.vbin

The simulation vrtbin contains a vpp_sim executable (a Verilog simulator wrapper) and a system_map.xml with <Platform>Simulation</Platform>.

VRT launches the simulator and communicates via ZeroMQ in the same way as emulation. Simulation is significantly slower — expect minutes rather than seconds for even simple designs.

Querying the Platform at Runtime

Your application can check the active platform and adjust behaviour:

vrt::Device device(bdf, vrtbinPath);

if (device.getPlatform() == vrt::Platform::EMULATION) {
    std::cout << "Running in emulation mode" << std::endl;
}

if (device.getPlatform() == vrt::Platform::SIMULATION) {
    std::cout << "Running in simulation mode" << std::endl;
}

See VRT Enumerations for all vrt::Platform values.

How Buffers Work in Emulation and Simulation

In emulation and simulation, vrt::Buffer<T> allocates host memory instead of device memory. Fake physical addresses are assigned automatically so that kernel argument routing works transparently:

  • Emulation — sync(HOST_TO_DEVICE) sends the buffer contents over ZeroMQ to the C-model. sync(DEVICE_TO_HOST) fetches the results back.

  • Simulation — the same pattern applies, using the simulator’s memory model.

No changes to your buffer code are needed. The same sync() calls work on all three platforms.

Known Limitations

Emulation:

  • Timing is not modelled — performance measurements are not meaningful.

  • HLS kernels must include at least one AXI4-Lite interface.

Simulation:

  • Significantly slower than emulation.

  • Requires AMD Vivado and a simulator licence.

  • Floating-point representation in the simulator can introduce NaN artefacts. Your application should handle these with relaxed comparison tolerances.

Next Steps