arXiv:2606.08515v1 [cs.DC] 7 Jun 2026
Unifying von-Neumann HPC and Neuromorphic Acceleration via the EBRAINS Research Infrastructure: A Framework for High-Performance Workflows Krishna Kant Singh1[0000−0002−7472−6299] , Charl Linssen1[0000−0002−8140−2866] , Eric Müller2[0000−0001−5880−2012] , Eleni Mathioulaki3[0009−0008−2019−7724] , Wouter Klijn1[0000−0002−8996−488X] , and Lena Oden4[0000−0002−9670−5296] Simulation & Data Lab Neuroscience, Jülich Supercomputing Centre, Forschungszentrum Jülich, Germany {k.singh, c.linssen, w.klijn}@fz-juelich.de 2 Kirchhoff Institute for Physics, Ruprecht-Karls-Universität Heidelberg, Germany [email protected] 3 ATHENA Research & Innovation Center, Marousi, Greece [email protected] 4 Computer Engineering, FernUniversität in Hagen, Germany [email protected] 1
Abstract. Modern scientific workflows increasingly span diverse computing architectures, yet executing a single computational model across disparate systems often forces researchers to maintain fragmented, sitespecific pipelines. In this paper, we address this challenge within the domain of computational neuroscience by presenting a unified, cloudbased workflow orchestrated via EBRAINS JupyterLab. This workflow enables users to transparently execute spiking neural networks on both von-Neumann supercomputers and neuromorphic hardware. Using a single federated identity, the system dispatches jobs to HPC sites (JUSUF, Galileo100) via PyUNICORE and to the SpiNNaker-1 neuromorphic system via the Neuromorphic Computing Platform Interface. To guarantee cross-site reproducibility and mitigate software version drift, we utilize a zero-installation execution mode that dynamically pulls PMIxaware Apptainer containers to HPC compute nodes. Furthermore, we demonstrate genuine model-level portability using the NESTML domainspecific language, allowing custom neuron models to be written once and automatically compiled for either the NEST (C++) or sPyNNaker backends. Validated with a balanced random network case study, this work illustrates a practical, end-to-end path for hardware-agnostic workflows while highlighting the critical role of containerization and domain-specific languages in achieving true cross-platform reproducibility. Keywords: EBRAINS Research Infrastructure · Neuromorphic Computing · HPC · Scientific Workflows · Spiking Neural Networks · NEST · SpiNNaker · PyNN · NESTML · UNICORE · Software Containers
2
Singh et al.
1
Introduction
Modern scientific workflows increasingly span computing architectures with fundamentally different execution models, and computational neuroscience is a particularly clear example of this trend [2]. The same spiking neural network (SNN) that a researcher wants to explore at high numerical precision on a classical von-Neumann supercomputer may, in a follow-up experiment, need to run in biological real-time on a digital neuromorphic substrate such as SpiNNaker [7], or in an accelerated regime on a mixed-signal system such as BrainScaleS [14,11]. Each platform has its own submission interface, its own authentication mechanism, its own software stack with its own version constraints, and, in the worst case, its own dialect of the network description itself. The EBRAINS Research Infrastructure (RI) was created, in part, to flatten this cost [2]. It combines a federated identity layer based on OIDC, a curated and versioned software environment called the EBRAINS Software Distribution (ESD), and a set of client libraries that expose HPC sites (through PyUNICORE [3]) and the neuromorphic platform (through the Neuromorphic Computing Platform Interface, NMPI) as programmable accessible compute resources. In principle, this should let a researcher write a single Jupyter notebook (or Python script) that dispatches the same model to a supercomputer and to a neuromorphic system with no more than a target-backend parameter change, and do so under the FAIR principles for scientific data and software [17]. In practice, two obstacles get in the way. First, ESD deployments are updated independently across sites, so the NEST [8], PyNN [6], or sPyNNaker [13] versions a user finds on a target HPC site often differ, and might even lag behind those in the EBRAINS JupyterLab environment—a version drift that undermines reproducibility in ways that are easy to miss. Second, simulator-independent APIs such as PyNN provide portability only for the standard library of neuron models; the moment a user introduces a custom neuron or plasticity rule, model portability breaks down and the model must be re-implemented for each backend. Beyond execution frameworks, standardizing the network representation itself remains an active area of research. The Neuromorphic Intermediate Representation (NIR) has recently emerged as a unified format for mapping SNN topologies across disparate platforms [10]. However, NIR currently focuses strictly on the static signal-flow graph (or the computational graph for numerical descriptions of dynamics), standing in contrast to PyNN, which defines a complete “experiment flow” including stimulation, recording, and simulation control. Furthermore, NIR and NESTML serve complementary, rather than competing, roles in a fully hardware-agnostic stack. While initiatives like NIRData standardize data conversion for network topologies, executing these graphs on numerical backends still requires generating efficient simulator code for individual neuron dynamics—the exact gap NESTML fills. In the future, a highly unified workflow could naturally combine NIR for structural representation with NESTML for compiling the underlying node dynamics, all orchestrated across federated computing sites using the containerization strategies presented here.
Unifying von-Neumann HPC and Neuromorphic Acceleration via EBRAINS
3
Previous efforts within EBRAINS-RI and its HBP predecessor have tackled parts of this problem. Van Albada et al. [1] benchmarked the Potjans–Diesmann microcircuit on NEST and SpiNNaker carefully, but the two runs were independent and the harness was hand-built on each side. Brüderle et al. [4] introduced an end-to-end PyNN workflow for FACETS/BrainScaleS in 2011, neuromorphic-only. Senk et al. [15]—the closest precedent to ours—showed in 2017 that one HBP Collaboratory notebook could dispatch to NEST on HPC and to SpiNNaker, but did not address version drift, which becomes the main obstacle the moment the workflow moves to another HPC site. In this paper, we use EBRAINS Software Distribution (ESD) on the cloud (via JupyterLab)5 to build and execute workflows that answer one question: can a user dispatch the same spiking network from one notebook across multiple federated HPC sites and a neuromorphic substrate, with the run reproducible regardless of which ESD version each site happens to have installed, and with custom neuron models? Our contributions are: 1. A reference workflow, hosted entirely in EBRAINS JupyterLab, that targets two HPC sites through PyUNICORE, assuming the ESD is pre-installed on each site (§3.1). 2. A pre-built container execution mode for HPC, in which a single PyUNICORE submission chains two steps on the target site: a login-node precommand pulls a PMIx-based, ESD-derived Apptainer container from the EBRAINS OCI registry via ORAS, and an sbatch step then runs the simulation inside that container on the compute nodes (§3.2). 3. A demonstration of the same workflow targeting both a von-Neumann substrate (JUSUF) and the SpiNNaker-1 neuromorphic system, via the Neuromorphic Computing Platform Interface (NMPI) (§3.3). 4. An end-to-end path through the NESTML domain-specific language, in which neuron and synapse models written once in the Collaboratory are codegenerated for the appropriate target: NEST C++ on HPC, or the SpiNNaker toolchain on NMC (§3.4). For contributions (1)–(3) we use the balanced random network [5], a model commonly used in the neuroscience community. By changing the number of neurons, it scales from a single SpiNNaker board to several, in the same way it scales across HPC nodes. Finally, we discuss what works and what does not yet work, including the potential of Apptainer-based containers to mitigate the version drift between sites and the cloud that we observed repeatedly while building the workflow. Although this work is done in the EBRAINS JupyterLab, it is not tied to that frontend: any client that can obtain an OIDC token from EBRAINS-RI can drive it (§5). 5
https://lab.ebrains.eu
4
Singh et al.
Table 1. Simulation backends for Spiking Neural Networks (BSS-2 included for context; not exercised in this work) Dimension
HPC / NEST
SpiNNaker-1
BSS-2
Arithmetic float64 fixed-point S16.15 analog (continuous) Timestep 0.1 ms (tunable) 1 ms (real-time) none (physical model) Neuron model exact LIF ODE LIF, truncated LIF (up to MC-AdEx) Time scale faster than real-time biological real-time 1000× accelerated “Imprecision” — fixed-point rounding device mismatch Parallelism MPI + OpenMP 18 cores/chip, 864/board 512 neurons/chip Connectivity no constraint per-core memory and placement/routing and routing calibration constraints
2
Background: EBRAINS as a Research Infrastructure
2.1
The EBRAINS Software Distribution (ESD)
The EBRAINS Software Distribution (ESD) is the central software component of EBRAINS Research Infrastructure: a spack-managed ecosystem of approximately eighty top-level packages (“EBRAINS tools”). It acts as the reproducible execution layer of EBRAINS, providing a curated and versioned software environment that enables workflows, services, and computational experiments to run consistently across heterogeneous infrastructures. It also facilitates service deployments such as the EBRAINS JupyterLab environment used in this work. At the same time, it provides a validation framework for EBRAINS tools, as its components are continuously tested together to ensure compatibility and functional interoperability across the ecosystem. The ESD encompass HPC-enabled simulation and data processing tools, AI applications and workflows, access libraries to EBRAINS services (such as the neuromorphic platform or the neuro-robotics platform). Beyond these standalone tools, it supports the definition of workflow packages, which capture complete, validated sets of interoperable tools required to execute specific computational workflows. The ESD’s components fall, roughly, into four classes (with key SNN simulation backends summarized in Table 1): – HPC-oriented simulators. NEST, NEURON, and Arbor, together with the Python interfaces (PyNN, NEST’s Python module, NESTML’s codegeneration backends) that brain modellers actually program against. – Hardware-specific toolchains. BrainScaleS APIs, middleware and access libraries, SpiNNaker support packages (sPyNNaker), and robotics middleware used by the Neurorobotics Platform. – Visualisation and analysis. Tools such as the siibra brain atlas client, NEST Desktop, and Elephant for spike-train analysis. – Services and clients. PyUNICORE for cross-site job submission, the NMPI client for neuromorphic submission, and various Knowledge Graph and dataaccess libraries.
Unifying von-Neumann HPC and Neuromorphic Acceleration via EBRAINS
2.2
5
Heterogeneous compute resources
For multi-site workflows, we use JUSUF at Jülich Supercomputing Centre and Galileo100 (G-100) at CINECA, both of which are classical von-Neumann HPC systems with the ESD pre-installed . This mismatch is one of the practical reasons we adopt the container-based execution mode of §3.2. G-100 is used only for the first workflow; JUSUF carries the rest of the HPC runs. SpiNNaker-1 [7] represents the neuromorphic (non-von-Neumann) side. Unlike standard HPC interconnects, this digital many-core substrate features a bespoke routing fabric optimized for sparse, asynchronous communication, delivering large-scale SNN simulations with exceptional energy efficiency.
3
Workflow Design
The workflow is orchestrated in the JupyterLab instance hosted by the EBRAINS Collaboratory. As a first step, the user retrieves an EBRAINS OIDC access token from the running Collaboratory session (via clb_oauth.get_token()); the same token is then used to authenticate against PyUNICORE and NMPI when submitting jobs to the HPC sites and to the neuromorphic substrate. The notebook runs under the ESD kernel, which already provides PyUNICORE, the NMPI client, PyNN, NEST, and NESTML. From this notebook the user assembles a workflow by specifying three things: the network (a script written in PyNN or NESTML), the target (an HPC site or SpiNNaker), and the execution recipe (a short Python helper that wraps the model in either a UNICORE job or an NMPI ticket). 3.1
Cross-site HPC submission via PyUNICORE
UNICORE [3] is a federation software suite that exposes HPC compute and data resources through a RESTful API. It is deployed across the Fenix Research Infrastructure supercomputing sites, including JSC and CINECA, and provides a uniform job-submission, data-movement, and workflow interface on top of each site’s native resource manager. We use UNICORE through its Python client, PyUNICORE, which is shipped as part of ESD and lets the submission code live in the same notebook that defines the network. A single notebook can target multiple sites by varying the registry URL and the site name in the submission step (Listing 1.2); the job description itself (Listing 1.1) is independent of the site and can be reused or version-controlled. Listing 1.1. Workflow 1 job description. Declarative, OIDC-free, and safe to versioncontrol or archive as a FAIR artefact. The same description shape supports either of UNICORE’s submission modes – a batch submission to the site’s scheduler, or direct execution on the login node – by varying a few fields. 1 2 3
# Batch - mode job : UNICORE forwards the sbatch request to # the site scheduler job_desc_batch = {
6 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Singh et al. " Executable " : " sbatch " , " Arguments " : [ " run_batch . slurm " ] , " Resources " : { " Project " : " < project > " , " Queue " : " batch " , " Nodes " : "1", " Runtime " : " 3600 " , # seconds },
} # Login - node job : UNICORE runs executable on the login node job_desc_login = { " Executable " : " / bin / bash " , " Arguments " : [ " run_login . sh " ] , " Job type " : " ON_LOGIN_NODE " , } Listing 1.2. Workflow 1 submission. The OIDC token is obtained from the Collaboratory session and used to authenticate against the UNICORE registry. Either job description from Listing 1.1 can be passed unchanged.
1 2 3 4 5 6 7 8 9 10 11 12 13
import pyunicore . client as uc from pyunicore . credentials import create_credential from clb_nb_utils import oauth as clb_oauth credential = create_credential ( token = clb_oauth . get_token () ) registry = uc . Registry ( credential , " < registry - url > " ) site = registry . site ( " < site - name > " ) job = site . new_job ( job_description = job_desc_batch , # or job_desc_login inputs =[ " run_batch . slurm " , " brunel_alpha_nest . py " ] , ) job . poll () # block until DONE / FAILED
3.2
Zero-installation execution with containers
The common way to run a PyNN or NEST script on an HPC site is to rely on the site’s pre-installed software modules. While the ESD provides a curated and versioned software environment, native deployments are site-specific and, in practice, version availability can vary between sites: at the time of writing, EBRAINS JupyterLab provides ebrains/25.04, JUSUF provides ebrains/24.10, and Galileo100 provides ebrains/23.02. A script developed against one of these versions is not guaranteed to produce reproducible results on another HPC site or in the JupyterLab environment, which directly undermines the cross-site reproducibility that EBRAINS RI is designed to provide. Container-based execution mitigates site-specific deployments by encapsulating complete runtime environments with fixed software versions. In this work, it does so by shipping a pre-built, PMIx-aware Apptainer image with all userspace dependencies – NEST,
Unifying von-Neumann HPC and Neuromorphic Acceleration via EBRAINS
7
its Python bindings, MPI, and their transitive dependencies – pinned to fixed versions. The container environment is aligned with the ESD software environment, reproducing equivalent version constraints to ensure compatibility across execution sites. In this way, containerization complements the ESD by enabling a consistent instantiation of its curated software ecosystem across heterogeneous infrastructures, allowing workflows to be executed under controlled and reproducible conditions, independent of the specific deployment available at each site. This allows workflows to be executed reproducibly even on systems where the ESD is not pre-deployed, provided that a compatible container runtime and access mechanism (e.g. UNICORE) are available. Previous work has shown that such containers are portable across EuroHPC sites with negligible performance overhead compared to bare-metal installations on CPU clusters [16]. The remaining sources of variability are the ABI surfaces the container cannot encapsulate: the host kernel, the resource manager (SLURM), and the MPI launcher, and—for GPU-accelerated workloads—hardware drivers such as CUDA. Of these, the MPI launcher is the only one that materially affects our workflow. NEST relies on MPI for inter-rank communication, which requires that the container’s MPI build and the host’s launcher agree on a bootstrap protocol. We rely on PMIx for this purpose: the container ships an MPI implementation compiled against PMIx, and the host (JUSUF) provides ParaStationMPI with PMIx support. The invocation srun –mpi=pspmix apptainer exec –sharens therefore allows the host launcher to bootstrap NEST’s MPI ranks across container instances without requiring binary compatibility between the container and host MPI builds. Our PyUNICORE workflow exploits this in two stages within a single submission. The login node, which has internet access, pulls the pre-built container from the EBRAINS Harbor container registry. Listing 1.3. Workflow 2 job description. Stage 1 (User precommand, executed on the login node) pulls the pre-built, PMIx-aware Apptainer image from EBRAINS Harbor. Stage 2 (the sbatch Executable) runs the simulation on the compute nodes. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
job_desc_container = { # Stage 2: dispatched to the compute nodes after the # precommand " Executable " : " sbatch " , " Arguments " : [ " run_container . slurm " ] , # Stage 1: runs on the login node " Job type " : " ON_LOGIN_NODE " , " R u n U s e r P r e c o m m a n d O n L o g i n N o d e " : " true " , " User precommand " : ( " apptainer pull -F " " oras :// docker - registry . ebrains . eu / hpc - containers / " " < image >: < tag > " ), " Resources " : { " Project " : " < project > " } , }
8
Singh et al.
The same UNICORE job then dispatches an sbatch step to the compute nodes, which read the image from the shared filesystem (compute nodes have no internet access) and run the simulation under srun –mpi=pspmix apptainer exec –sharens. Post-processing returns to the login node. From the user’s perspective this is one submit call; under the hood it is a two-stage flow whose stages are stitched together by UNICORE. Listing 1.4. Compute-node SLURM script (run_container.slurm) dispatched by Stage 2 of the job description in Listing 1.3. The container provides NEST and its dependencies; the host contributes only the ParaStationMPI/PMIx bootstrap. 1 2 3 4 5 6
# !/ bin / bash # SBATCH -- nodes =1 # SBATCH -- time =01:00:00 srun -- mpi = pspmix apptainer exec -- sharens < image >. sif \ python3 brunel_alpha_nest . py
3.3
Neuromorphic submission via NMPI
The neuromorphic side uses a different submission interface. NMPI, the Neuromorphic Computing Platform Interface, exposes the SpiNNaker and BrainScaleS systems as remote services: the user uploads a Python script and a small JSON descriptor, and the platform schedules execution on the chosen hardware. The notebook helper for SpiNNaker is symmetrical to the UNICORE helper: Listing 1.5. Submitting the same network to SpiNNaker-1 through NMPI. import nmpi client = nmpi . Client ( token = ebrains_oidc_token ) job_id = client . submit_job ( source = " balanced_random . py " , platform = " SpiNNaker " , collab_id = " my - collab " , config ={ " spynnaker_version " : " 6.0.0 " } ,) client . wait ( job_id ) result_dir = client . download_data ( job_id )
From the user’s point of view, swapping platform="SpiNNaker" for a UNICORE call against JUSUF is the only line that changes between a neuromorphic and an HPC run. The network description itself is unchanged. 3.4
NESTML: one model, two backends
While PyNN [6] abstracts the network topology and overall experiment flow, it still requires the underlying simulator to provide the implementation for the desired neuron model. When a user wants a non-stock neuron – a modified adaptive exponential model, say, or a custom plasticity rule – the model must be implemented for each backend separately.
Unifying von-Neumann HPC and Neuromorphic Acceleration via EBRAINS
9
NESTML [12,9] was created precisely to close this last gap. It is a domainspecific language (DSL) for neuron and synapse models, paired with a codegeneration toolchain that emits high-performance simulation code for a chosen target platform. The language is agnostic of numerical methods and simulation platform; the toolchain is what knows about backends. This separation supports the FAIR principles for computational models [17], and ESD ships the NESTML toolchain together with both its NEST and SpiNNaker backends, which lets us place code generation inside the cloud notebook. However, bridging the gap between generated source code and a running neuromorphic simulation requires a highly specialized software stack capable of both compiling custom dynamics and mapping the user-defined network onto the physical hardware substrate. Targeting SpiNNaker, for instance, necessitates not only an ARM cross-compiler to generate binaries for the physical cores, but also the complete SpiNNaker developer software stack to handle linking and subsequent hardware mapping and routing. By bundling the NESTML toolchain alongside these complex, backend-specific dependencies, the ESD allows us to execute the entire code generation, cross-compilation, and mapping pipeline transparently within the cloud notebook. Listing 1.6. Driving NESTML from the notebook to generate code for either the NEST or SpiNNaker target. from pynestml . frontend . pynestml_frontend import generate_target generate_target ( input_path = " iaf_adapt . nestml " , target_platform = " NEST " , target_path = " build / nest " ) generate_target ( input_path = " iaf_adapt . nestml " , target_platform = " SpiNNaker " , target_path = " build / spinn " )
The generated artefacts – a NEST C++ module in one case, a PyNNcompatible Python module backed by the SpiNNaker toolchain in the other – are then shipped with the corresponding UNICORE or NMPI job. The model itself, the .nestml file, is never edited between targets. This is the closest thing in the workflow to a genuine “write once, run on heterogeneous neural hardware” experience, and in our view it is the contribution that matters most in the long run.
4
Case Study: A Balanced Random Network
To validate contributions (1)–(3) we use the balanced random network from the sPyNNaker example collection [13]. The network is a small Brunel-style configuration [5]: an excitatory population E and an inhibitory population I with a 4:1 size ratio, sparse random connectivity with probability 0.1, Gaussiandistributed weights and delays, and external Poisson stimulation that drives the
10
Singh et al.
network into an asynchronous irregular firing regime at a few tens of Hz. The example predates our work; we treat it as a fixed reference network and only adapt the harness around it. 4.1
Execution on JUSUF and Galileo100
The PyNN script is submitted unmodified to both JUSUF and Galileo100 through the helper of Listing 1.2. The simulator backend is NEST 3.x, invoked from PyNN through pyNN.nest. The container image referenced by $EBRAINS_ESD_IMAGE was pre-built. The resulting spike trains, after the usual transient, show the expected asynchronous irregular regime; the per-neuron firing rates match between sites to within Monte Carlo noise of the random seed, as one would hope. 4.2
Execution on SpiNNaker-1
For the SpiNNaker run, only the import line at the top of the PyNN script changes (import pyNN.spiNNaker as sim instead of import pyNN.nest as sim). The script is submitted via NMPI (Listing 1.5). sPyNNaker is responsible for mapping the network onto SpiNNaker chips; for a Brunel network of the size shipped in the example, this fits comfortably on a single SpiNN-5 board and executes in real time. The recorded spikes are returned to the notebook through the NMPI data-download endpoint and analysed with the same code path that processes the HPC results. We do not claim a quantitative match between the SpiNNaker run and the NEST run; the two backends use different random-number generators, different internal timestep semantics, and (deliberately) different floating-point precision. What we do claim is that the workflow is uniform: the same notebook drove the same network, with one-line edits, against three target machines spanning two computing paradigms, and brought all results back to the same analysis cells.
5
Discussion and Lessons Learned
Building the workflow we have just described turned out to be less an exercise in writing code and more an exercise in pinning versions. We close with three observations that we believe are useful to anyone considering a similar effort. Version drift is the dominant practical problem. The ESD has the explicit goal of providing identical packages everywhere, but in practice the deployments at federated sites are refreshed on different schedules. During the work reported here we encountered combinations in which the NEST version installed natively on a site was older than the version available in EBRAINS JupyterLab. As a result, the same script produced different numerical outputs depending on where it ran. . To systematically address this drift, two distinct deployment strategies emerge. The first is the portable, HPC-enabled container execution path detailed in §3.2; by isolating the execution and forbidding the script to see any host Python, we
Unifying von-Neumann HPC and Neuromorphic Acceleration via EBRAINS
11
trade native flexibility for strict cross-site reproducibility. A second solution lies in shared software deployment frameworks like the European Environment for Scientific Software Installations (EESSI). Distributing the ESD via EESSI would allow all federated EuroHPC sites to utilize the exact same optimized software stack, eliminating version drift without container-based encapsulation. Similar standardization efforts are ultimately needed on the neuromorphic side, where aligning the sPyNNaker, PyNN, and NESTML backend versions still requires manual iteration. Authentication is, surprisingly, the easy part. A single EBRAINS OIDC token grants access to every federated UNICORE site and to the NMPI gateway. This is a strong improvement over the SSH-key-per-site situation that preceded EBRAINS RI, and it is the main reason a workflow like ours can fit in a single notebook at all. Genuine portability is at the model layer, not the script layer. PyNN gives us source compatibility for stock neuron models, which is enough for the demonstration network. The moment a user wants a non-stock neuron, PyNN portability evaporates and one is back to writing the model twice. The NESTML path of §3.4 is, in our experience, the only escape: expressing the model in a DSL whose compiler is the thing that knows about backends. We expect that future EBRAINS work will lean further in this direction.
6
Conclusion
We have presented a JupyterLab-hosted workflow within the EBRAINS Research Infrastructure that lets a user target multiple HPC sites and a neuromorphic platform with the same network description and the same OIDC identity. By leveraging the EBRAINS Software Distribution via pre-built containers and orchestrating jobs through PyUNICORE, HPC execution requires zero installation on the user’s side. The neuromorphic path uses NMPI symmetrically. Furthermore, to achieve true model-level portability, custom neuron models are defined once in NESTML and compiled directly within the notebook for the chosen backend. We successfully validated this end-to-end framework across all execution paths using a standard balanced random network. Despite these advances, practical deployment challenges remain. Software version drift between site-specific ESD deployments is the dominant source of friction. Future work must address this gap, either by tightening the releaseengineering loop or by making the container-based path the default across all EBRAINS sites. A longer-term solution would be the integration of the ESD software environment into shared frameworks like EESSI. We would also like to push more of the model layer into NESTML, including plasticity rules, so that the “write once” property of §3.4 extends to a wider class of experiments. Acknowledgments. This work has received funding from the EC Horizon 2020 Framework Programme under grant agreement 945539 (HBP SGA3), the EC Horizon Europe Framework Programme under grant agreement 101147319 (EBRAINS 2.0).
12
Singh et al.
Disclosure of Interests. The authors have no competing interests to declare that are relevant to the content of this article.
References 1. van Albada, S.J., et al.: Performance comparison of the digital neuromorphic hardware SpiNNaker and the neural network simulation software NEST for a full-scale cortical microcircuit model. Frontiers in Neuroscience 12, 291 (2018). https://doi.org/10.3389/fnins.2018.00291 2. Amunts, K., et al.: The coming decade of digital brain research: A vision for neuroscience at the intersection of technology and computing. Imaging Neuroscience 2, 1–35 (2024). https://doi.org/10.1162/imag_a_00137 3. Benedyczak, K., et al.: Unicore 7—middleware services for distributed and federated computing. In: International Conference on High Performance Computing & Simulation (HPCS). pp. 613–620. IEEE (2016) 4. Brüderle, D., et al.: A comprehensive workflow for general-purpose neural modeling with highly configurable neuromorphic hardware systems. Biological Cybernetics 104(4–5), 263–296 (2011). https://doi.org/10.1007/s00422-011-0435-9 5. Brunel, N.: Dynamics of sparsely connected networks of excitatory and inhibitory spiking neurons. Journal of Computational Neuroscience 8(3), 183–208 (2000) 6. Davison, A.P., et al.: PyNN: a common interface for neuronal network simulators. Frontiers in Neuroinformatics 2, 388 (2009) 7. Furber, S.B., et al.: The SpiNNaker project. Proceedings of the IEEE 102(5), 652–665 (2014) 8. Gewaltig, M.O., Diesmann, M.: NEST (NEural Simulation Tool). Scholarpedia 2(4), 1430 (2007). https://doi.org/10.4249/scholarpedia.1430 9. Linssen, C., et al.: NESTML: a generic modeling language and code generation tool for the simulation of spiking neural networks with advanced plasticity rules. Frontiers in Neuroinformatics 19, 1544143 (2025). https://doi.org/10.3389/fninf.2025. 1544143 10. Pedersen, J.E., et al.: Neuromorphic intermediate representation: A unified instruction set for interoperable brain-inspired computing. Nature Communications 15(1), 8122 (2024). https://doi.org/10.1038/s41467-024-52259-9 11. Pehle, C., et al.: The BrainScaleS-2 accelerated neuromorphic system with hybrid plasticity. Frontiers in Neuroscience 16, 795876 (2022). https://doi.org/10.3389/ fnins.2022.795876 12. Plotnikov, D., et al.: NESTML: a modeling language for spiking neurons. arXiv preprint (2016). https://doi.org/10.48550/arXiv.1606.02882 13. Rhodes, O., et al.: sPyNNaker: a software package for running PyNN simulations on SpiNNaker. Frontiers in Neuroscience 12, 816 (2018) 14. Schmidt, H., et al.: From clean room to machine room: commissioning of the firstgeneration BrainScaleS wafer-scale neuromorphic system. Neuromorph. Comput. Eng. 3(3), 034013 (Sep 2023). https://doi.org/10.1088/2634-4386/acf7e4 15. Senk, J., et al.: A collaborative simulation-analysis workflow for computational neuroscience using HPC. In: High-Performance Scientific Computing (JHPCS 2016). Lecture Notes in Computer Science, vol. 10164, pp. 243–256. Cham (2017). https://doi.org/10.1007/978-3-319-53862-4_21 16. Singh, K.K., et al.: HPC containers for EBRAINS: Towards portable cross-domain software environment (2026). https://doi.org/10.48550/arXiv.2603.12044, accepted at HPCW’26
Unifying von-Neumann HPC and Neuromorphic Acceleration via EBRAINS
13
17. Wilkinson, M.D., et al.: The FAIR guiding principles for scientific data management and stewardship. Scientific Data 3(1), 160018 (2016). https://doi.org/10.1038/ sdata.2016.18