Decoupling model descriptions from execution: a modular paradigm for extensible neurosimulation with EDEN

TYPE Original Research PUBLISHED 07 August 2025 DOI 10.3389/fninf.2025.1572782 OPEN ACCESS EDITED BY Revathi Appali, University of Rostock, Germany REVIEWED BY Stefan Fuertinger, Max Planck Society, Germany Charl Linssen, Helmholtz Association of German Research Centres (HZ), Germany *CORRESPONDENCE Sotirios Panagiotou [email protected] Christos Strydis [email protected] RECEIVED 07 February 2025 ACCEPTED 25 June 2025 PUBLISHED 07 August 2025 CITATION Panagiotou S, Miedema R, Soudris D and Strydis C (2025) Decoupling model descriptions from execution: a modular paradigm for extensible neurosimulation with EDEN. Front. Neuroinform. 19:1572782. doi: 10.3389/fninf.2025.1572782 COPYRIGHT ©2025 Panagiotou, Miedema, Soudris and Strydis. This is an open-access article distributed under the terms of the Creative Commons Attribution License (CC BY). The use, distribution or reproduction in other forums is permitted, provided the original author(s) and the copyright owner(s) are credited and that the original publication in this journal is cited, in accordance with accepted academic practice. No use, distribution or reproduction is permitted which does not comply with these terms. Decoupling model descriptions from execution: a modular paradigm for extensible neurosimulation with EDEN Sotirios Panagiotou1*, Rene Miedema1, Dimitrios Soudris2and Christos Strydis1,3* 1Neuroscience Department, Neurocomputing Lab, Erasmus MC, Rotterdam, Netherlands, 2Microlab, School of Electrical & Computer Engineering, National Technical University of Athens, Athens, Greece, 3Quantum and Computer Engineering Department, Electrical Engineering, Mathematics and Computer Science Faculty, TU Delft, Delft, Netherlands Computational-neuroscience simulators have traditionally been constrained by tightly coupled simulation engines and modeling languages, limiting their flexibility and scalability. Retrofitting these platforms to accommodate new backends is often costly, and sharing models across simulators remains cumbersome. This paper puts forward an alternative approach based on the EDEN neural simulator, which introduces a modular stack that decouples abstract model descriptions from execution. This architecture enhances flexibility and extensibility by enabling seamless integration of multiple backends, including hardware accelerators, without extensive reprogramming. Through the use of NeuroML, simulation developers can focus on high-performance execution, while model users benefit from improved portability without the need to implement custom simulation engines. Additionally, the proposed method for incorporating arbitrary simulation platforms—from model-optimized code kernels to custom hardware devices—as backends offers a more sustainable and adaptable framework for the computational-neuroscience community. The effectiveness of EDEN’s approach is demonstrated by integrating two distinct backends: flexHH, an FPGA-based accelerator for extended Hodgkin-Huxley networks, and SpiNNaker, the well-known, neuromorphic platform for largescale spiking neural networks. Experimental results show that EDEN integrates the different backends with minimal effort while maintaining competitive performance, reaffirming it as a robust, extensible platform that advances the design paradigm for neural simulators by achieving high generality, performance, and usability. KEYWORDS computational neuroscience, spiking neural network, simulation, accelerated computing, high performance computing, NeuroML, software architecture, plugins 1 Introduction A rapidly growing subfield of computational biology is computational neuroscience, which is about running numerical models of natural (or nature-inspired) neural structures, so as to investigate the network dynamics that produce the marvelous capabilities of the nervous system. What makes computational neuroscience interesting from a computerscience standpoint is that the formulations for neurons and synapses is exceptionally diverse among models in use, to the degree that different processing algorithms, data schemes and numerical methods are needed for different models. To make matters Frontiers in Neuroinformatics 01 frontiersin.org Panagiotou et al. 10.3389/fninf.2025.1572782 Parse model description Resolve cross-refs between model parts Analyse model for backend support/feasibility Convert model to backend-friendly data Run the simulation on the backend NeuroML model files EDEN NML loader & resolved model aEDEN model analysis tools b Generic CPU backend analyser OpenMP + MPI + generated kernels flexHH analyser c FlexHH accelerators FPGA GPU etc. flexHH-specific model description Synthesised code + data layout Any device or just different algorithm Example backend: flexHH accelerator Alternative backends Community-supplied model specification (NeuroML) EDEN API & generic backend EDEN processing pipeline Method steps Software components ... Device-specific model description a All references resolved, for direct processing b Facilitating backend-specific analysers c Additions for EDEN integration Backend-agnostic Backend-dependent Custom NeuroML analyser c flexHH analyser c flexHH-specific model description Device-specific model description Any device or just different algorithm FlexHH accelerators FPGA GPU etc. OpenMP + MPI + generated kernels Synthesised code + data layout Generic CPU backend analyser flexHH analyser c flexHH-specific model description Device-specific model description Any device or just different algorithm FlexHH accelerators FPGA GPU etc. OpenMP + MPI + generated kernels Synthesised code + data layout Generic CPU backend analyser API GRAPHICAL ABSTRACT EDEN’s multi-backend architecture. Software components included in the first EDEN release are shown with a colored background. The components marked with crepresent the necessary additions required to integrate arbitrary backends into EDEN. worse, state-of-the-art modeling involves increasingly highermodel complexity, as the understanding of single-neuron dynamics becomes clearer, while the co-simulation of hybrid-complexity models is at times also necessary. In this rapidly evolving and challenging landscape, neural-simulation design hinges predominantly on three, competing goals: •Generality in supported model dynamics; that is, supporting more neuron types in conjunction, more dynamics equations, more interactions between parts of the model; •Computational performance, so that more complex models can be explored at larger scales in space and time; •Usability, so that users can express and implement the proposed models with as little effort as possible. We put forward the simulator triangle shown in Figure 1 as the taxonomical space of neural simulators built by the neuroscience community. Despite their large diversity and coverage, we propose that all of them fall short of at least one of these goals: General-purpose (or simply, general) and performant simulators involve implementing the whole model and simulation as a custom program; performance-aware programming (whether linear-algebra or tensor-based, or platform-specific coding) adds to the required effort, thus losing on usability. In contrast, highly performant and user-friendly solutions [e.g., TVB (Sanz Leon et al., 2013), CARLsim (Niedermeier et al., 2022)] focus on a narrow model type, thus have limited generality. Finally, simulators focusing both on generality and usability end up sacrificing processing speed in performing specific tasks for the sake of a streamlined, uniform interface (Hines and Carnevale, 1997). Figure 1 suggests that there is a general lack of simulators able to deliver high simulation speeds without sacrificing their general applicability. After careful study of the field of domainspecific simulators, we identify two key design decisions that have prohibited notable solutions in that triangle niche. The problem Frontiers in Neuroinformatics 02 frontiersin.org Panagiotou et al. 10.3389/fninf.2025.1572782 FIGURE 1 Simulator triangle. The three vertices represent competing design goals: general purpose (GP), high performance (HP), usability (UX). Dots in black represent existing simulator designs, and dots in red represent cross-simulator model specification languages. The area enclosed by the dashed curve, along with the small dots within it, represents the multitude of high-performance, ad-hoc solutions tailored to specific SNN models. The three shaded regions indicate the reach of three different approaches to simulator design: ad hoc, loosely or tightly coupled (introduced in Section 2). lies in that each simulator (a) is built around a single high-level simulation algorithm and data format (henceforth collectively called engine) for processing the information; and (b) accepts models expressed in a modeling language that is tightly bound to the aforementioned internal algorithm. These two decisions constrain greatly the formalism of models that a simulator can support through its internal design as well as for which model types or use cases, and for which computer systems it is an efficient design. At the same time, porting a model across simulators, that is, porting between the designdictated formalisms takes considerable effort (Goddard et al., 2001; Davison et al., 2009;Gleeson et al., 2010). However, models do not have to—in principle—be expressed in a system-specific language. The ongoing dynamics can be described objectively in a simulator-agnostic format (as usually captured at the time of publication), such as natural language or mathematical language (e.g., ODEs); for instance, NeuroML v2 (Cannon et al., 2014) can capture many Spiking Neural Network (SNN) models. This observation is important since moving from a simulator-agnostic format to a simulator-dependent one is easy, yet it is much harder to “decompile” in the opposite direction. Hence, when there is a machine-readable, simulator-independent way to fully describe SNN models, we do not have to select a single simulator engine and, then, proceed to make its codebase cumbersome and less efficient by adding an ever-expanding list of features. We can instead express the intended model, and then deploy the engine that serves our needs best each time. In response to the limitations outlined above, the EDEN simulator was proposed in Panagiotou et al. (2022), introducing two key design principles. First, rather than developing a new model-specification language, EDEN adopts the existing NeuroML standard as input, which is agnostic to the underlying simulation mechanisms. This choice is depicted as a dashed red arrow connecting EDEN to NeuroML in Figure 1. Second, EDEN embraces a loosely coupled architecture that decouples the simulation engine from the rest of the system. This allows different simulation backends to be flexibly integrated for different parts of a model, with the goal of improving performance or leveraging existing tools. Engines are thus reconceptualized as backends to a common model input frontend, rather than being the central component of the simulation system, as illustrated in Figure 1. The aforementioned design decisions permit EDEN to provide model generality and usability while, at the same time, achieving performance competitive with other simulators by generating code that it tailored to the model to be run each time. In its original form, EDEN was validated using a generic CPU-based simulation backend. In the present work, we extend its architecture to fully support arbitrarily different SNN simulation backends, including both software simulators and specialized hardware platforms. Although this extensibility was anticipated in the original design, it is only in this manuscript that we (a) introduce the necessary API extensions and (b) demonstrate the extended framework in practice using two fundamentally different backends. Frontiers in Neuroinformatics 03 frontiersin.org Panagiotou et al. 10.3389/fninf.2025.1572782 In the following, we revisit EDEN’s multi-engine framework and supporting infrastructure, and lay out in detail a methodology for attaching engines with disparate capabilities and target hardware, without sacrificing processing performance or redesigning the engines. We, then, proceed to validate this methodology by incorporating flexHH (Miedema et al., 2020), a competitive, exascale-ready, Field-Programmable Gate Array (FPGA)-based engine that simulates biophysically-detailed neuron models as an alternative to EDEN’s universal engine, and evaluate EDEN’s performance under different neural-network compositions for both engines. The goal here is to show that the EDEN framework offers (1) a short time to solution for incorporating custom simulation engines, (2) performance benefits, when they can be had, and (3) a clear, user-friendly methodology for other neuromodellers to replicate. In so doing, we aim to reaffirm the novel paradigm that EDEN brings about and to fulfill the three foundational goals expressed in the beginning of this section. Concisely, the contributions of this work are: 1. A taxonomy categorizing existing approaches to SNN-simulator design. 2. Further development of a novel paradigm for designing general, efficient, and user-friendly SNN simulators, exemplified by EDEN. 3. A systematic methodology for extending EDEN-based accelerated simulation backends, validated through the integration of two distinct, heterogeneous simulation platforms. 4. An experimental evaluation of the performance gains enabled by these backends, demonstrating the benefits of EDEN’s multiengine support. The rest of the manuscript is organized as follows: In Section 2, we review related works and provide a taxonomy of current simulator designs, highlighting the different paradigm that EDEN brings about. In Section 3, we provide a quick overview of the EDEN architecture and its key properties essential to incorporating diverse, optimized backends. We, then, proceed to outline a methodology to do so which can be repeated for any alternative backend. In Section 4, we proceed to demonstrate how two disparate, preexisting simulator backends—flexHH, based on a FPGA platform, and SpiNNaker, based on an MPI CPU cluster—can be connected to EDEN. In Section 5, we evaluate the functionality and performance of EDEN’s universal backend against the two example backends, and discuss our findings. In Section 6, topics worth future investigation are discussed. Paper conclusions are drawn in Section 7. 2 Related work The simulator triangle of Figure 1 attempts to illustrate the underlying tradeoffs in neurosimulator design when trying to score high in all three aspects of generality of use, high simulation speed and user friendliness. The figure also shows another taxonomy of the various proposed simulators among so-called ad-hoc, tightly coupled and loosely coupled simulators. Due to various implementation or historical reasons, we estimate that ad-hoc simulators have mostly focused on high performance and, to some degree, user friendliness. Tightly coupled simulators have typically prioritized a broad coverage of supported neural models along with user friendliness, while attempting (but not always achieving) some measure of good simulation performance. Finally, our focus in this manuscript are loosely coupled simulators which attempt to cover the gap between high performance and generality of use, which is the toughest challenge to tackle. Figure 2 presents a conceptual overview of this SNN-simulator taxonomy along with the design philosophy behind each one. As we will explain next, modern-day neurosimulators belong under classes (A) or (B), relying on a single simulation algorithm and tightly coupled, proprietary modeling languages, which constrain the range of models and use cases they can efficiently support. This design limits interoperability, making it difficult to port models between simulators and necessitating a shift toward simulatoragnostic, machine-readable formats for describing models; this is class (C). 2.1 Ad-hoc model implementations The so-called ad-hoc way of implementing (simulations for) models (Figure 2A) forgoes support for multiple use cases and focuses on the needs of a particular experiment line. This exclusive focus on the immediate requirements allows for a perfect fit of the simulator design to the experiment, and thus is the only way to implement extreme-scale simulations, that exploit the available (e.g., neuromorphic) technology to the limit. Examples of this approach are FACETS (Schemmel et al., 2010), Nepteron (Beuler et al., 2017) or other custom simulators like (Yamaura et al., 2020). Unfortunately, this engine-design approach incurs high costs in time and effort, since everything needed for the simulation is built from scratch. If, while exploring the model, it is desirable to modify or extend it, the necessary changes may come in conflict with key assumptions of the design at the technical level. In that case, the necessary significant modifications may escalate to a redesign of the whole simulation system. And when an experiment is completed, there are few re-usable parts for follow-up projects; hence most of the setup cost is recurring for each experiment. 2.2 Tightly coupled simulators A different way to build a neural-simulation system (Figure 2B) is to start with a specific engine—which is effective for a certain sub-class of neural models—and expose specific “code hooks” via which the engine can be generalized (such as the post-synaptic current trace of a synapse type, or the dynamics of an ion channel population). This produces a generalized (but not truly general) simulator, that can be used to implement many new, neural models within the originally intended class. Each targeted model must then be expressed as an engine-specific “recipe” that modifies the simulator hooks, so that running the simulator will produce the intended behavior. Examples of this approach are NEURON (Hines and Carnevale, 1997), Brian2 (Stimberg et al., 2019), NEST (Gewaltig and Diesmann, 2007), and Arbor (Akar et al., 2019); further examples can be found in Blundell et al. (2018). The recipe constructs the neural network to be simulated and Frontiers in Neuroinformatics 04 frontiersin.org Panagiotou et al. 10.3389/fninf.2025.1572782 Model language type 1 Model language type 2 Declarative model language Smart backend translation and mapping Ad-hoc engine 1 Ad-hoc engine 2 Universal engine(s) Ad hoc Model+Method 1 Ad hoc Model+Engine 4 Ad hoc Model+Engine 2 Ad hoc Model+Engine 3 Engine type 1 Engine type 2 Ad hoc model and engine Loosely-coupled models and engines High friction to port; Port not always complete Porting involves a rewrite Interface-based recipes Engine backends access the model description A C Tightly-coupled models and engines B FIGURE 2 Different neurosimulator design approaches: (A) Ad-hoc solutions, made for specific experiments and offering scarce re-usability. (B) Tightly coupled simulators, designed around one simulation algorithm and recipes that express models as customisations of that algorithm. (C) Loosely-coupled simulators, which ingest platform-agnostic model descriptions and map them to best-suited (existing) simulation platforms. directly controls the simulation’s progress through an experiment. This approach significantly enhances productivity for modelers compared to ad-hoc model implementations. Modifying the model under investigation is straightforward by adjusting the recipe at the engine’s code hooks. However, this monolithic “recipe-in-engine” methodology introduces challenges for both simulator users and developers, in terms of modeling ease as well as simulation performance. Modeling-wise, the challenges are as follows: •Limited model portability: since different simulators rely on distinct engines with varying formulations and code hooks, converting a recipe created for one simulator for use in another can be a labor-intensive task. This is especially problematic because the boundaries between model classes are often fluid, and neuroscience practice frequently involves combining features from different classes (e.g., integrating biophysically detailed neurons into a point-neuron network, or vice versa). This “hybridisation” of models may lead to another complication: if a model spans multiple classes extensively, no single engine may fully support it. In such cases, modelers are compelled to adopt ad-hoc solutions, such as exchanging information between simulators that handle different parts of the model or constructing a complete, bespoke simulator tailored to the specific model. •High model-engine dependence: parts of how the engine works are implicitly included to the functional behavior of the model, which complicates understanding and unambiguously describing models that are written as recipes. Performance-wise, tightly coupled simulators incur additional penalties: •Limited performance portability: simulator engines are—by definition—obsolete the very minute they are designed. The reason is that each engine is optimized for a contemporary computing platform. As technology evolves, the assumptions that led to efficient execution on the original platform may not hold when migrating to a new one. •Limited performance optimisations: related to the previous problem, any code hooks that an engine provides are— by design—tailored to said engine. When the engine is modified to exploit new improvements in technology, those hooks—meant for generality—may prevent effecting necessary engine optimisations. 2.3 Loosely coupled simulators The aforementioned limitations of the so-called tightly coupled simulators gave rise to the so-called loosely coupled simulator designs; see Figure 2C. Although we are not the first to propose solutions in this direction (see the discussion on PyNN by Davison et al., 2009, below), we are the first to attempt this taxonomy and clear separation among design approaches, as shown in Figure 2. In this approach, models are described in a declarative, unambiguous,engine-agnostic way and can be simulated using different engines. One such modeling language is NeuroML (Goddard et al., 2001;Gleeson et al., 2010;Cannon et al., 2014;Sinha et al., 2024) which captures a model closer to its published textual form and the original intent, catalyzing model adoption and exchange. These same properties also permit a “pure” mathematical inspection of a model, without being polluted by engine-induced (and in a sense, unnecessary) model behavior. This approach trades some additional development effort due to decoupling,1for model-description reuse and the ability to switch engines at will. Reusable descriptions are beneficial to the research community and, at the same time, interchangeable engines allow employing best-in-class alternatives each time. Loosely coupled simulators, thus, bypass the modeling issues of 1 i.e. forgoing design shortcuts that could be taken with engine-specific model descriptions. Frontiers in Neuroinformatics 05 frontiersin.org Panagiotou et al. 10.3389/fninf.2025.1572782 model expressiveness and model-engine dependence by excluding any engine-related assumptions from the models. Dependence on a particular engine to fill in parts of the behavior is also avoided for the same reasons. Lacking any engine-incurred assumptions, model portability is ensured since any part of the model may be described in the most semantically appropriate formalism. In terms of performance portability and potential optimisations, this approach is only constrained by inherent model idiosyncrasies (if any) that may or may not map efficiently onto a given platform. 2.3.1 The EDEN simulator Recently, a new simulator for spiking neural networks, EDEN (Panagiotou et al., 2022) was developed. A core design choice in EDEN was to not develop a new model-design environment and specification language for the simulator, but to instead directly load and run model files expressed in NeuroMLv2 (Cannon et al., 2014). The aim of EDEN is to run aproduction-ready range of models2with high computational performance, without forcing users to program against the engine but, instead, by directly reading models in an unambiguous format such as NeuroML; see dashed, red line connecting EDEN to NeuroML in Figure 1. All in all, the major novelty of EDEN is that it decouples: •the abstract description of the mode at the top; and •the code and data representation used to simulate the model. Computational performance is achieved through, first, analyzing the various model parts (namely, neurons, synapses and experimental setup) and, then, translating them to suitable machine code. The type of generated code depends on the per-case available simulation platforms; for instance, just-in-time code generation takes place for standard CPUs, while custom (3rd-party) code can be leveraged for GPUs, FPGAs, AI chips, and so on. 2.3.2 Other multi-backend approaches Perhaps the most well-known, all-around alternative approach to EDEN is PyNN (Davison et al., 2009). PyNN is a Python interpreter-based language for constructing SNN models and simulating them, which delegates the simulation workload to different simulators through a uniform interface, provided that they support the described model features. PyNN originated in the FACETS project (Schemmel et al., 2010)—the predecessor of BrainScaleS (Pehle et al., 2022)—stemming from the pragmatic need to run portable experiments on various simulation platforms (both softwareand hardware-based); see dashed, red line from BrainScaleS to PyNN in Figure 1. As discussed above, Brian2 (Alevi et al., 2022) is a tightly coupled simulator since its event-handling order3is implicitly defined into the engine rather than explicitly defined in the model. While the later-added GeNN backend (Stimberg et al., 2019) offers some degree of decoupling, its differing event-handling order (in all 2 i.e., wide enough for typical computational-neuroscience projects. 3 Refer to https://brian2.readthedocs.io/en/stable/user/running.html# scheduling. but simple models) can result in inconsistent execution compared to Brian2. Thus, Brian2 falls short in that it does not provide consistency guarantees. It is because of this issue that it is not classified as a proper loosely coupled simulator. The distinction between these prior developments and the EDEN architecture lies in two key aspects: (a) we introduce a methodology that enables a repeatable approach for integrating different simulators with alternative simulation engines, and (b) by leveraging the open specification format of NeuroML, our architecture remains independent of any single simulation environment’s formalism and its associated assumptions. 3 Methods 3.1 The EDEN architecture so far SNN models and simulation engines are in constant flux over time, making it difficult for a single simulator to handle the plethora of targeted experiments. This observation led to the development of EDEN, which leverages best-in-class simulation backends at each point in time. SNN-model inspection takes place so as to maximize simulation performance given available computing resources. As already mentioned, EDEN adopts NeuroML for SNN modeling, making no assumptions about the simulation backend. The first release of EDEN (Panagiotou et al., 2022) had implemented a single, generic, simulation backend, targeting general-purpose CPUs. Under this design, parts of the code template are adapted independently for the different parts of the neural network to be simulated, but certain high-level design decisions remain fixed. This generic backend is, however, not the sole target of development. In line with the EDEN architecture which prescribes specialized engines and, thereby, backends, this existing backend is intended to complement more optimized future designs, as an always-applicable, last-resort option. Generic backends can, hence, guarantee a lower bound on the computational performance that EDEN can offer. In this section, we will present the EDEN methodology for replacing or adding arbitrary, alternative simulation backends. 3.2 The general engine-integration process The EDEN processing pipeline, originally discussed in (Panagiotou et al., 2022,figure 2), is shown in Graphical Abstract (left: method steps) and consists of a sequence of stages between the model files and the code and data to run the simulation: 1. Parse the NeuroML files that describe the model. 2. Resolve cross-references between the model’s entities, to aid analysis. 3. Analyse the model’s parts before deciding how to implement them. 4. Convert the model into a configuration (code and data) for simulating. 5. Execute the generated code on the model data. The last three stages are called the “backend” of the processing pipeline and, so far, they have been implemented in the context of the generic, CPU backend described above. This backend can Frontiers in Neuroinformatics 06 frontiersin.org Panagiotou et al. 10.3389/fninf.2025.1572782 handle all parts of a NeuroML model and it adapts the simulation code and data structures separately for each part, using the leaflevel “signatures” of what has to be simulated (Panagiotou et al., 2022, sec. 2.4.2). This same pipeline can also be employed with different simulation backends (either softwareor hardware-based). In such cases, the last three stages are adjusted as follows: 3. Analyse the model for optimal mapping onto the specific backend. 4. Convert the model into a backend-specific configuration for simulating. 5. Run backend simulation with the specified configuration. In Graphical Abstract, the original EDEN components are highlighted in orange color, indicating the extensions done for this work. As the figure reveals, the EDEN architecture entails a backend-agnostic component and necessary, backend-specific components (blocks with colored outline). These components need to be authored every time a new simulation backend is hooked up to EDEN. The interface between these backend-agnostic and backend-specific components is called the EDEN API, to be discussed next. 3.3 An overview of EDEN’s API Since NeuroML assumes no particular simulation engine, EDEN delegates to each backend how to inspect and implement the user-specified SNN model. The main point of contact between EDEN’s backend-independent part and the various backends is therefore exposing the model to the backends. In fact, this is the only strictly necessary part of the interface; the API also offers some auxiliary tools which do not provide additional information but may assist backends and their analysers to interpret the NeuroML model. 3.3.1 Model interface The main part of the EDEN API is the ReadNeuroML function which, given the file location of a NeuroML model file (and other NeuroML files that it probably includes), returns the Model data structure that represents the parsed and cross-referenced NeuroML model. The Model comprises the set of NeuroML entities described in the input file(s), including the references between entities. Details about and the reference relationships between different types of NeuroML entities are shown in Figure 3. An important purpose of resolving cross-references is that, at this point, the model information is not simply parsed but also semantically validated; if the provided model is successfully processed, it is guaranteed to be consistent and implementable by a compatible backend. One could, as well, load the NML with a custom new parser, but in that case they would also have to validate the semantic information implicit in NeuroML: that is, validate and resolve cross-references between NeuroML entities, and ensure that biophysical mechanisms are defined and are compatible with their uses in the model description. EDEN offers the aforementioned routine in the API that takes care of these considerations (for the cases that a more specialized parser implementation is not needed). 3.3.2 Optional API More than providing an actionable model description, EDEN’s API also offers additional, optional tools. These auxiliary parts of the API can assist common tasks with (1) model-related analysis, for example, in determining compatibility between neuron models and the synapse models attached to them, mapping the geometrybased, neuron-site designators to specific compartments, and unit conversion; (2) “signature”-composition facilities for analyzing and processing LEMS components, and generation of C-like simulation code (of interest to backends that can work with generated code); and (3) basic input/output functions that follow the NeuroML convention for simulation-data formatting, which can be replaced with higher-performance implementations as needed. Keep in mind that, as far as the EDEN architecture is concerned, the presented interface can be implemented in any formalism (for example, a text-based intermediate-representation language). We have implemented it as C++ headers and data structures in view of the existing needs for (a) a streamlined integration process (i.e., no need for learning and writing a parser for yet another data format vs. walking through structs), and (b) high-performance data processing (also at initialization time), which is necessary for large-scale models. 3.3.3 Backend design guidelines Although the specific methods depend intimately on the internal design of each backend, the analyser component for each backend must invariably perform the following tasks to run a user-provided simulation: 1. Explore the model’s structure by traversing the references between the NeuroML entities involved. 2. Given the interactions between model parts, determine whether and how each can be simulated by the backend. 3. Transform the given NeuroML model to a backend configuration that simulates the model. One path to developing a new simulation backend is to cover the full set of models expressible in NeuroML. Naturally, covering so wide a range comes with certain complexities in simulating all types of model parts and interactions thereof, and on top of that supporting custom-dynamics models (described through LEMS) for each of these entities. This complexity is inherent to simulating diverse SNN model types, whether using the EDEN framework or not. It follows that the model analyser for such a backend will also involve a certain level of complexity, just to handle the full set of NeuroML entities. Another approach is to assume a very narrow range of supported models, and take advantage of this narrow scope to develop a backend with a highly specialized engine. This case is, in fact, close to the “ad-hoc” design approach presented in Section 2.1. In this case, the analyser’s job is to directly map the model description provided by the API to the corresponding engine’s features and customisable parameters, and reject any other (e.g., neuron, synapse) model part that this specialized backend cannot simulate. Frontiers in Neuroinformatics 07 frontiersin.org Panagiotou et al. 10.3389/fninf.2025.1572782 FIGURE 3 EDEN’s minimal API laying out the structure of NeuroML simulations. Frontiers in Neuroinformatics 08 frontiersin.org Panagiotou et al. 10.3389/fninf.2025.1572782 FIGURE 4 The backend implementation and evaluation plan. 4 Implementation and experimental plan One of the central points of this paper is that developing a backend-specific analyser involves two tasks: work to process the NML hierarchy and work to configure the backend’s engine, both key to maintaining a loosely coupled simulator architecture. In this section and Appendix A, we will demonstrate how this same process is applied for completely different simulation backends, within the model limitations of each. These demonstrations are purposefully detailed so as to enable any interested researcher to replicate the process for any other potential backend; details nonessential for a first reading have been moved to the Appendix.4We thus validate our EDEN engine-integration methodology as follows (see also Figure 4): •Select two accelerated simulation platforms with disparate feature sets (flexHH and SpiNNaker); •Use the EDEN API to create backends targeting these platforms, mapping NeuroML features to platform-specific configurations as necessary; •Validate the integrated backends and evaluate simulation correctness, as well as simulation speed, compared to EDEN’s existing generic backend. 4.1 Backend case 1: the FPGA-based flexHH simulator flexHH (Miedema et al., 2020) is a FPGA-based design for simulating SNNs of the standard Hodgkin-Huxley (HH) model and other HH extensions including multicompartmental cells and gap junctions, while delivering very high simulation speeds. These speeds are achieved by following the dataflow processing paradigm, which forgoes random access of data for pre-determined sequential access and deep overlapping of calculations, so that the data “flows” from one calculation to the next. However, this dataflow design imposes certain 4 The code to reproduce this study can be found on: https://edensimulator.org/links/paper-backends-2025-material. limitations on the neuron models that can be simulated, as described in a next section. The interested reader may refer to the paper for the full details of the accelerator’s design and modeling scheme. Here, we will focus on the key design decisions that impact the feasible range of models and on the flexHH analyser. 4.1.1 flexHH architecture and model representation The flexHH design consists of a dataflow algorithm that advances the state of neurons for each time step of the simulation, and the model’s data arranged in a layout amenable to the dataflow algorithm. The algorithm has been designed ahead of time and does not change frequently; modifications for, e.g., different gapjunction dynamics have to be designed up-front as alternative FPGA configurations. Run-time decisions about the calculations to be done are encoded and included in the model data. The data layout is assembled as three sequences of “per-cell”, “percompartment,” and “per-gate” data for the whole network, and one dense matrix containing the synaptic-connectivity weights. It is important to keep in mind for the following that compartments, channels and gates are laid out in a nested sequential manner; all compartments of a cell, all channels of a compartment, and all gates of a channel are listed and considered in a certain order, to aid data-flow processing (see Figure 5). 4.1.2 Models as supported by the accelerator Each neuron in the model comprises one or more compartments, which are electrically coupled to each other by ohmic resistors. Compartments must be connected in a linearchain topology. The compartment’s physiological parameters are the electrical capacitance, passive leak conductance and membrane reversal potential, axial conductance to the preceding compartment in the neuron (when applicable), and a (direct) current-clamp stimulus with programmable start time, duration, and amplitude (set to zero when not present). Each compartment may contain a number of ion channels, and an ion pool that some of the ion channels contribute to. Ion channels follow the HH formalism (Hodgkin and Huxley, 1952) of independent gate populations with one open and one closed state, so that the “gate variable” is the fraction of each gate population that is in the “open” state. The momentary transition dynamics between states is described as α,βthat are the rates of transition from open to closed and closed to open respectively, or ss,τfor the steady-state value of the gate variable and the time constant to converge to by. Each of these expressions can be programmed as one of four different formulae of univariate functions, each with arbitrary coefficients. The argument to these rate functions can be either membrane voltage, or the state variable of the previous generalized “gate variable” in the sequence (this can be the ion concentration to model ion concentration-activated ion channels, as explained in Section A.1.1.1). As synaptic connectivity is the most computationally demanding part of the model for large network sizes, it also the most specialized function in this accelerator. Neurons are assumed to be coupled via gap junctions only, which connect the Frontiers in Neuroinformatics 09 frontiersin.org Panagiotou et al. 10.3389/fninf.2025.1572782 Generative AI statement The author(s) declare that Gen AI was used in the creation of this manuscript. AI was strictly used for improving the readability of the Abstract and Conclusion sections. Generative AI has not been used for any part of the Methods and Results sections of the manuscript. Publisher’s note All claims expressed in this article are solely those of the authors and do not necessarily represent those of their affiliated organizations, or those of the publisher, the editors and the reviewers. Any product that may be evaluated in this article, or claim that may be made by its manufacturer, is not guaranteed or endorsed by the publisher. Supplementary material The Supplementary Material for this article can be found online at: https://www.frontiersin.org/articles/10.3389/fninf.2025. 1572782/full#supplementary-material References Akar, N. A., Cumming, B., Karakasis, V., Küsters, A., Klijn, W., Peyser, A., et al. (2019). “Arbor: a morphologically-detailed neural network simulation library for contemporary high-performance computing architectures,” in 2019 27th Euromicro International Conference on Parallel, Distributed and Network-Based Processing (PDP) (Pavia: IEEE), 274–282. doi: 10.1109/EMPDP.2019.8671560 Alevi, D., Stimberg, M., Sprekeler, H., Obermayer, K., and Augustin, M. (2022). Brian2CUDA: Flexible and efficient simulation of spiking neural network models on gpus. Front. Neuroinform. 16: 883700. doi: 10.3389/fninf.2022.883700 Betting, J., De Zeeuw, C., and Strydis, C. (2023). “Oikonomos-II: a reinforcementlearning, resource-recommendation system for cloud HPC,” in 2023 IEEE 30th International Conference on High Performance Computing, Data, and Analytics (HiPC) (Goa: IEEE), 266–276. doi: 10.1109/HiPC58850.2023.00044 Betting, J.-H., Liakopoulos, D., Engelen, M., and Strydis, C. (2023). “Oikonomos: an opportunistic, deep-learning, resource-recommendation system for cloud HPC,” in 2023 IEEE 34th International Conference on Application-specific Systems, Architectures and Processors (ASAP) (Porto: IEEE), 188–196. doi: 10.1109/ASAP57973.2023.00039 Beuler, M., Krum, A., Bonath, W., and Hillmer, H. (2017). “Nepteron processor for real-time computation of conductance-based neuronal networks,” in 2017 Euromicro Conference on Digital System Design (DSD) (Vienna: IEEE), 78–85. doi: 10.1109/DSD.2017.52 Blundell, I., Brette, R., Cleland, T. A., Close, T. G., Coca, D., Davison, A. P., et al. (2018). Code generation in computational neuroscience: a review of tools and techniques. Front. Neuroinform. 12:68. doi: 10.3389/fninf.2018.00068 Brette, R., Rudolph, M., Carnevale, T., Hines, M., Beeman, D., Bower, J. M., et al. (2007). Simulation of networks of spiking neurons: a review of tools and strategies. J. Comput. Neurosci. 23, 349–398. doi: 10.1007/s10827-007-0038-6 Brunel, N. (2000). Dynamics of sparsely connected networks of excitatory and inhibitory spiking neurons. J. Comput. Neurosci. 8, 183–208. doi: 10.1023/A:1008925309027 Cannon, R. C., Gleeson, P., Crook, S., Ganapathy, G., Marin, B., Piasini, E., et al. (2014). LEMS: a language for expressing complex biological models in concise and hierarchical form and its use in underpinning NeuroML 2. Front. Neuroinform. 8:79. doi: 10.3389/fninf.2014.00079 Davison, A. P., Brüderle, D., Eppler, J. M., Kremkow, J., Muller, E., Pecevski, D., et al. (2009). PyNN: a common interface for neuronal network simulators. Front. Neuroinform. 2:11. doi: 10.3389/neuro.11.011.2008 De Gruijl, J. R., Bazzigaluppi, P., de Jeu, M. T. G., and De Zeeuw, C. I. (2012). Climbing fiber burst size and olivary sub-threshold oscillations in a network setting. PLoS Comput. Biol. 8, 1–10. doi: 10.1371/journal.pcbi.1002814 Furber, S., and Bogdan, P. (2020). SpiNNaker-A Spiking Neural Network Architecture. Delft: NOW Publishers. doi: 10.1561/9781680836523 Gamma, E., Helm, R., Johnson, R., and Vlissides, J. (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional Computing Series. London: Pearson Education. Gewaltig, M.-O., and Diesmann, M. (2007). NEST (NEural Simulation Tool). Scholarpedia 2:1430. doi: 10.4249/scholarpedia.1430 Gilbert, E. N. (1959). Random graphs. Ann. Math. Stat. 30, 1141–1144. doi: 10.1214/aoms/1177706098 Gleeson, P., Crook, S., Cannon, R. C., Hines, M. L., Billings, G. O., Farinella, M., et al. (2010). NeuroML: a language for describing data driven models of neurons and networks with a high degree of biological detail. PLoS Comput. Biol. 6, 1–19. doi: 10.1371/journal.pcbi.1000815 Goddard, N. H., Hucka, M., Howell, F., Cornelis, H., Shankar, K., Beeman, D., et al. (2001). Towards NeuroML: model description methods for collaborative modelling in neuroscience. Philos. Trans. R. Soc. Lond. Ser. B: Biol. Sci. 356, 1209–1228. doi: 10.1098/rstb.2001.0910 Hines, M. L., and Carnevale, N. T. (1997). The NEURON simulation environment. Neural Comput. 9, 1179–1209. doi: 10.1162/neco.1997.9.6.1179 Hodgkin, A. L., and Huxley, A. F. (1952). A quantitative description of membrane current and its application to conduction and excitation in nerve. J. Physiol. 117, 500–544. doi: 10.1113/jphysiol.1952.sp004764 Lytton, W. W. (1996). Optimizing synaptic conductance calculation for network simulations. Neural Comput. 8, 501–509. doi: 10.1162/neco.1996.8.3.501 Miedema, R., Smaragdos, G., Negrello, M., Al-Ars, Z., Möller, M., Strydis, C., et al. (2020). flexHH: a flexible hardware library for Hodgkin-Huxley-based neural simulations. IEEE Access 8, 121905–121919. doi: 10.1109/ACCESS.2020.3007019 Niedermeier, L., Chen, K., Xing, J., Das, A., Kopsick, J., Scott, E., et al. (2022). “CARLsim 6: an open source library for large-scale, biologically detailed spiking neural network simulation,” in 2022 International Joint Conference on Neural Networks (IJCNN) (Padua: IEEE), 1–10. doi: 10.1109/IJCNN55064.2022.9892644 Panagiotou, S., Sidiropoulos, H., Soudris, D., Negrello, M., and Strydis, C. (2022). EDEN: a high-performance, general-purpose, NeuroML-based neural simulator. Front. Neuroinform. 16:724336. doi: 10.3389/fninf.2022.724336 Pehle, C., Billaudelle, S., Cramer, B., Kaiser, J., Schreiber, K., Stradmann, Y., et al. (2022). The BrainScaleS-2 accelerated neuromorphic system with hybrid plasticity. Front. Neurosci. 16:795876. doi: 10.3389/fnins.2022.795876 Sanz Leon, P., Knock, S. A., Woodman, M. M., Domide, L., Mersmann, J., McIntosh, A. R., et al. (2013). The virtual brain: a simulator of primate brain network dynamics. Front. Neuroinform. 7:10. doi: 10.3389/fninf.2013.00010 Schemmel, J., Brüderle, D., Grübl, A., Hock, M., Meier, K., Millner, S., et al. (2010). “A wafer-scale neuromorphic hardware system for large-scale neural modeling,” in 2010 IEEE International Symposium on Circuits and Systems (ISCAS) (Paris: IEEE), 1947–1950. doi: 10.1109/ISCAS.2010.5536970 Sinha, A., Gleeson, P., Marin, B., Dura-Bernal, S., Panagiotou, S., Crook, S., et al. (2024). The NeuroML ecosystem for standardized multi-scale modeling in neuroscience. Elife 13:e95135. doi: 10.7554/eLife.95135.3 Stimberg, M., Brette, R., and Goodman, D. F. (2019). Brian 2, an intuitive and efficient neural simulator. Elife 8:e47314. doi: 10.7554/eLife.47314.028 Yamaura, H., Igarashi, J., and Yamazaki, T. (2020). Simulation of a humanscale cerebellar network model on the K computer. Front. Neuroinform. 14:16. doi: 10.3389/fninf.2020.00016 Frontiers in Neuroinformatics 16 frontiersin.org