Server-grade FPGA deployments form a viable substrate for flexible accelerator deployment. The simplest deployment approach is to assigning an entire device to one application, which can leave compute and memory resources underutilized. Multi-tenancy offers a way to improve utilization, provided that resource sharing preserves isolation and the performance benefits of hardware acceleration. However, muiti-tenancy support requires more than a simple partitioning the reconfigurable fabric. Hardware tasks need controlled access to shared memory, while dependent tasks must communicate seamlessly when they are scheduled or reconfigured independently. This talk examines the architectural role of the FPGA shell in supporting these requirements, including address-space protection, resource sharing, and dataflow execution supporting both memory-mapped and streaming tasks on a shared device.
The talk will conclude with a brief presentation of our ongoing activities in efficient multiple page size support including the benefits of SVNAPOT-like page allocation and the challenges it imposes on TLB implementations.

Modern development cycles require rapid evaluation of cpu and system implementations, and the development of software, long before silicon is available. Codasip will show how it uses system simulators and CPU emulation (in software and on FPGA) to evaluate and co-develop the GPP hardware and software early in the development lifecycle.

This work introduces SystemCXL, a framework for exploration of CXL-based systems using functional and timing models of CXL switches, CXL Type 3 devices and hosts. We implement the timing models using SystemC with representative latency and bandwidth performance characteristics, and CXL features that affect timing including 256B flit packing and back-pressure. The multi-fidelity modeling infrastructure further enables integration of functional CXL component models, such as those based on gem5 or QEMU, by interfacing them through standardized CXL port interface.

Long-vector RISC-V can greatly reduce the number of instructions executed by scientific codes, but this does not always make them faster. We study this effect in two atmospheric-physics kernels: CloudSC cloud microphysics and ACRANEB2 radiation. We combine timing measurements from a 16,384-bit RISC-V Vector Extension 1.0 (RVV 1.0) FPGA prototype with instruction traces from RAVE. RAVE is a tracing plugin for the QEMU emulator; it records vector length, active lanes, memory operations, and instruction mix. These traces help explain the native FPGA results, but do not provide their timing. Although both kernels use 256-element double-precision vectors, their performance differs substantially. Some CloudSC regions slow down because most lanes are inactive, so selective scalar execution matters for the full kernel. In contrast, all measured ACRANEB2 hotspots benefit from RVV; its adapted fused version reaches 3.07×, with vector mathematics remaining the main limit. These results point to mask-aware vectorisation choices, separate handling of indexed memory, and low-overhead instrumentation for vector mathematics and vector-unit stalls.

Heterogeneous Parallel Error Detection (HPED) provides a promising alternative to conventional LockStep for protecting high performance out-of-order processors, exploiting the parallelism that exists in a secondary execution. However, moving HPED from architectural models to real systems exposes challenges that are largely hidden by high-level simulation. Here, we summarize our experience in progressively realizing HPED through MEEK and PEEK. MEEK establishes a full-RTL, Linux-capable implementation and reveals practical bottlenecks. Building on this substrate, PEEK further extends protection to privileged execution, addressing the substantially different requirements of privileged state synchronization, replay, and system-level resource dependencies. Together, these efforts provide lessons for designing practical fault-tolerant RISC-V systems and suggest a broader role for heterogeneous cores as dynamically managed reliability resources.

Lockstep RTL co-simulation against an instruction set simulator (ISS) is a standard way to verify RISC-V cores. However, ISS selection is commonly guided by team familiarity or standalone benchmarking. We argue that neither is sufficient once the target is a Linux-capable SoC rather than bare-metal code. We build a co-simulation environment based on open-source tools to evaluate three popular open-source RISC-V ISSs: (i) Spike, (ii) Whisper, and (iii) Dromajo, with the same RISC-V core RTL (CVA6 in this work), the same Linux boot stack (OpenSBI, device-tree, kernel, BusyBox), and the Verilator open-source SystemVerilog RTL simulator. In our evaluations, the RTL, the workload (Linux), and RTL simulator are fixed and only the ISS and the ISS integration mechanisms vary. We find that Dromajo standalone offers the highest instruction throughput and remains the fastest also during RTL co-simulation. When the ISSs are used for RTL co-simulation, the throughput is affected unevenly based on the specific integration mechanism. Spike and Dromajo, are integrated in-process as a library, show markedly less overhead than whisper, which runs as a separate process. We also find that reaching full-system fidelity requires non-trivial, per-ISS adaptations, including peripheral modeling, address/loader setups, and interrupt injection. Importantly, during these evaluations, divergent code paths between RTL and the ISS uncovered two bugs in the CVA6 RTL codebase. Finally, checkpointing emerges as the most valuable qualitative feature for co-simulation with a full Linux stack, materially affecting day-to-day usability independent of raw throughput. We conclude that ISS selection for co-simulation must evaluate the complete integration path: performance, feature support, and the engineering effort needed to reach full-system fidelity, rather than raw ISS performance alone, since the fastest ISS is not always the right one for a given verification or co-design task.

TURBO is a new tool developed by Openchip, which helps users to tune software for the RISC-V architecture. It uses QEMU as the backing emulator and improves the user experience of profiling code by showing performance metrics on-the-fly while a program is running. The metrics captured are focussed to the `V` vector ISA extension, providing the user with the required details to improve code to utilise the hardware abilities to their full potential. While the `V` extension is currently the main focus, other ISA extensions are planned for support in future too.

The DARE (Digital Autonomy with RISC-V in Europe) project aims to develop new RISC-V based hardware to meets Europe's high-performance computing and AI needs. However, hardware is only one half of the equation and software also needs to be co-designed and developed to perform efficiently on these new platforms. But how well does your code run on hardware that doesn't exist (yet)? This talk takes a look at current tools and techniques being used by ECMWF, in collaboration with BSC, as reported in DARE deliverable D26.2. Through the use of both the RAVE emulator and Paraver data browser, we can gain an understanding of how our code could perform on these platforms while they are still in development. From this we can optimise applications for upcoming platforms - with surprising accuracy.

Architectural exploration of AI and HPC systems increasingly relies on multi-simulator frameworks that combine workload replay, device modeling, and network simulation. This makes cross-layer performance diagnosis manual and prone to errors. We present an automated cross-layer analysis workflow for heterogeneous simulation outputs, instantiated in the DARE Dashboard. The workflow bridges heterogeneous workload and simulation outputs to performance insights, deriving metrics for compute/communication/idle decomposition, per-kernel roofline classification, and per-port congestion localization, without modifying or rerunning the underlying simulators. On a 256-NPU HPCG configuration, the dashboard identifies communication as 94.7% of device time, classifies compute kernels as memory-bound, and localizes congestion to individual switch ports. In contrast, an 8-NPU Llama3-8B training workload is compute-dominant, with 79.8% of device time attributed to compute. These cases demonstrate how the workflow turns heterogeneous simulator outputs into cross-layer architectural diagnoses.