Skip to content
Free planNo credit card requiredStart writing
AI for Research home
AI for Research home
Dashboard
Sign inGet started

Search 250 million research papers

Read the abstract, see who wrote it and who cites it, and get the citation in APA, MLA, Chicago or Harvard.

About 7,123 papers for “simulation code generation”

On Simulation-Guided LLM-based Code Generation for Safe Autonomous Driving Software

Ali Nouri, J. Andersson, Kailash De Jesus Hornig et al. · 2025

Automated Driving System (ADS) is a safety-critical software system responsible for the interpretation of the vehicle’s environment and making decisions accordingly. The unbounded complexity of the driving context, including unforeseeable events, necessitate continuous improvement, often achieved through iterative DevOps processes. However, DevOps processes are themselves complex, making these improvements both time- and resource-intensive. Automation in code generation for ADS using Large Language Models (LLM) is one potential approach to address this challenge. Nevertheless, the development of ADS requires rigorous processes to verify, validate, assess, and qualify the code before it can be deployed in the vehicle and used. In this study, we developed and evaluated a prototype for automatic code generation and assessment using a designed pipeline of a LLM-based agent, simulation model, and rule-based feedback generator in an industrial setup. The LLM-generated code is evaluated automatically in a simulation model against multiple critical traffic scenarios, and an assessment report is provided as feedback to the LLM for modification or bug fixing. We report about the experimental results of the prototype employing Codellama:34b, DeepSeek (r1:32b and Coder:33b), CodeGemma:7b, Mistral:7b, and GPT4 for Adaptive Cruise Control (ACC) and Unsupervised Collision Avoidance by Evasive Manoeuvre (CAEM). We finally assessed the tool with 11 experts at two Original Equipment Manufacturers (OEMs) by conducting an interview study.

Cited by 1Open access

A Scalable Code Generation Flow for Heterogeneous Parallel RTL Simulation using MLIR

Jie Tong, Zhengxiong Li, Ümit Y. Ogras et al. · 2025

As hardware design complexity increases, efficient Register Transfer Level (RTL) simulation becomes critical for reducing the long runtime of design and verification. Although several parallel RTL simulators have been developed, they often suffer from long compilation times and slow simulation performance, especially for large-scale heterogeneous architectures and deep learning SoC designs that exhibit repetitive and hierarchical structures. These limitations arise because existing simulators fail to effectively map heterogeneous architectures onto CPU-GPU platforms, resulting in underutilized compute resources. In addition, they repeatedly regenerate and recompile redundant code, missing the opportunity to exploit the structural parallelism inherent in deep learning accelerators. To address these challenges, we propose HeteroRTL, a scalable code generation flow that produces hybrid CPU-GPU parallel RTL simulators for heterogeneous deep learning accelerator SoCs. Built on the MLIR infrastructure, HeteroRTL analyzes RTL designs, partitions the simulation between CPU and GPU targets, identifies structural repetition to reduce compilation overhead, and generates efficient simulation executables. Compared to state-of-the-art simulators, HeteroRTL achieves compilation speedups of three to five orders of magnitude and delivers up to 9× and 122× simulation speedups across various designs.

Cited by 0

Source code generation for aggregate simulation models and their integration with database.

Munčys, Darius, · KTUePubl (Repository of Kaunas University of Technology) · 2007

This paper analyses MDE approach to software engineering as well as OMG’s MDA and Microsoft DSL Tools. MS DSL Tools are a powerful addition to MS Visual Studio 2005 for creating your own Domain Specific Language metamodels and generating IDEs for working with it. Then you can make a text template to transform your model directly into code. The work describes developed aggregate modeling language metamodel. It also explains text template language for model transformations. The research also includes analysis of the possibility to use model transformations to generate code for data acquisition form database.

Cited by 0Open access

Preparing the Next Generation of Code Blue Leaders Through Simulation: What's Missing?

Ayaaz K. Sachedina, Sarah Blissett, Alliya Remtulla et al. · Simulation in Healthcare The Journal of the Society for Simulation in Healthcare · 2018

The CBSP enhanced resident preparedness to serve as code blue leaders. Learners highlighted that they valued the CBSP; however, differences remain between simulated and real codes that could be addressed to enhance the fidelity of future simulations.

Cited by 14

Fast Verilog Simulation using Tel-based Verification Code Generation for Dynamically Reloading from Pre-Simulation Snapshot

Yonghun Lee, Daejin Park · 2023

As design complexity increases, turn-around time (TAT) of design development increases. Designers may not have enough time to cover all test, because Verilog simulation time increases. The aim of this paper is to present an existing Verilog simulation method and to propose a new method to reduce simulation run time for the design of large system implemented in Verilog in the iterative flows. Small changes in testbench caused the need to repeat all design flows, including basic and common test sequences such as booting and power on stabilization sequences. The proposed verification flows use the Tcl based verification code for dynamically reloading from previous simulation snapshot without repeated compiling of source code. The basic and commonly used long test sequences are saved by simulator using Tcl command and reload the saved snapshot after driving the test sequence using Tcl code without recompiling. The total simulation time was reduced by 53% with the proposed verification flow.

Cited by 1

A Framework for Modeling, Simulation and Automatic Code Generation of Sensor Network Application

Mohammad Mozumdar, Francesco Gregoretti, Luciano Lavagno et al. · 2008

Showing functional correctness by simulation before implementation, and preserving it by automated code generation, is extremely useful to reduce the development time for an embedded application. This is even more true for wireless sensor networks, since their nodes often provide very rudimentary debugging facilities, and sufficiently large networks for realistic analysis may be expensive to deploy. While this approach, also known as model-based design, is becoming quite standard for several domains that have similar constraints as wireless sensor networks, such as automotive electronics, there is a lack of tools for this purpose in the WSN world. In order to fill this gap, in this paper we present a framework (based on Simulink, Stateflow and Embedded Coder) in which an engineer can create sensor network components (both at the application and at the protocol level) that can be used as building blocks to model, simulate and automatically generate code for different underlying platforms and operating systems.

Cited by 76

MOD2IR: High-Performance Code Generation for a Biophysically Detailed Neuronal Simulation DSL : Artifact

Mitenkov, George, Magkanaris, Ioannis, Awile, Omar et al. · Zenodo (CERN European Organization for Nuclear Research) · 2023

<strong>Introduction</strong> This ZENODO folder was created to archive all the needed files for the artifact submission of the <em>MOD2IR: High-Performance Code Generation for a Biophysically Detailed Neuronal Simulation DSL</em> paper to the ACM SIGPLAN 2023 International Conference on Compiler Construction containing all necessary source code, data and scripts to reproduce the results published in the paper. <strong>Artifact Description</strong> MOD2IR is implemented as a code generation backend inside the NMODL Framework and it makes heavy use of the LLVM IR and compilation passes. Most of the relevant code of the described work can be found here and here. <strong>Hardware Requirements</strong> The provided artifact can in theory be run on any x86 hardware platform. For the purpose of closely reproducing our benchmark results it is required a workstation (or cloud instance) with Intel Xeon Skylake (or newer) CPU that supports AVX-512 instructions and an NVIDIA Volta V100 (or newer) GPU.<br> All benchmark runs are single-core and have relatively low memory-requirement. For building or running the Docker image (and more specifically the NMODL Framework) we, however, recommend a system with plenty of cores, at least 32GB of RAM available and 20 GB of disk space. <strong>Software Requirements</strong> Any reasonably up-to-date Linux system with Docker should be sufficient (we recommend Ubuntu 22.04). If GPU results are to be reproduced, an up-to-date CUDA (11.0 or newer) should be present. <strong>Benchmarking Instructions</strong> To reproduce as closely as possible our environment and to lower the burden of the installation of the different compilers and libraries we have created Docker images which take care of installing all the necessary packages and compilers to install MOD2IR and execute the benchmarks.<br> Due to technical restrictions imposed by Docker to execute a Docker image and be able to execute applications on NVIDIA GPUs there are some extra steps needed. For this reason we have created two different <em>Dockerfile</em>s, one that takes care of both the CPU and GPU benchmarks and one for CPU only execution if there is no NVIDIA GPU available in the test system. The original instructions (markdown file) with the executable script snippets can be found here. <strong>CPU and GPU docker image</strong> The <em>Dockerfile</em> that targets both CPU and GPU can be found in <em>Dockerfile_cpu_gpu</em>.<br> To launch the Docker image you can execute the following: <pre><code class="language-bash"># Install docker and NVIDIA docker runtime (needs sudo # permission and is based on Ubuntu 22.04 but with small # changes it should be supported by any Ubuntu version # or other linux distributions) bash install_gpu_docker_env.sh # Build docker image with CPU and GPU enabled execution # (~16GB) docker build -t bluebrain/nmodl:mod2ir-gpu-benchmark - &lt; Dockerfile_cpu_gpu # Run docker image docker run -it -v $PWD:/opt/mount --gpus \ all bluebrain/nmodl:mod2ir-gpu-benchmark</code></pre> After building and launching the docker file we can now execute the benchmarks and generate the same plots as the ones we included in the paper with the new results along the reference plots from the paper.<br> To do this we need to execute the following two scripts inside the docker image environment: <pre><code class="language-bash"># Enter the directory where the scripts are inside the docker # image cd nmodl/test/benchmark # Runs all the benchmarks on CPU and GPU bash run_benchmark_script_cpu_gpu.sh # Generate the plots based on the outputs of the previous script python3 plot_benchmarks_cpu_gpu.py # Copy the graphs from the docker image to your environment cp -r graphs_output_pandas /opt/mount</code></pre> Executing <em>run_benchmark_script_dockerfile.sh</em> will generate two pickle files that include the results in <em>hh_expsyn_cpu/benchmark_results.pickle</em> for the CPU benchmarks and <em>hh_expsyn_gpu/benchmark_results.pickle</em> for the GPU benchmarks. Those will then be loaded by <em>plot_benchmarks.py</em> to generate the plots.<br> Now you can exit the docker image terminal and open the above files which exist in your local directory. <br> <strong>CPU only docker image</strong> In case there is no GPU available instead of running the above Docker container you can also run a CPU only container.<br> To do this you need to build the image using <em>Dockerfile_cpu</em>: <pre><code class="language-bash"># Build CPU only Docker image (~16GB) docker build -t bluebrain/nmodl:mod2ir-cpu-benchmark - &lt; Dockerfile_cpu # Execute docker image docker run -it -v $PWD:/opt/mount \ bluebrain/nmodl:mod2ir-cpu-benchmark</code></pre> Then inside the docker shell: <pre><code class="language-bash"># Enter the directory where the scripts are inside the docker # image cd nmodl/test/benchmark # Runs all the benchmarks on CPU bash run_benchmark_script_cpu_only.sh # Generate the plots based on the outputs of the previous script python3 plot_benchmarks_cpu_only.py # Copy the graphs from the docker image to your environment cp -r graphs_output_pandas /opt/mount</code></pre> By executing <em>run_benchmark_script_cpu_only.sh</em> there will be only <em>hh_expsyn_cpu/benchmark_results.pickle</em> generated containing the CPU results. <br> <strong>Notes</strong> The benchmark results with <em>GCC</em> and <em>NVHPC</em> compilers might be better in the docker container than the presented manuscript due to the newer OS we’re using in the <em>Dockerfile</em>. The current Ubuntu versions come with GLIBC 2.3x, which includes <em>libmvec</em> providing vectorized implementations for some mathematical functions and which is used by the <em>GCC</em> and <em>NVHPC</em> compilers. This results in much more vectorization use in the benchmark kernels even without providing the SVML library to <em>GCC</em> (or <em>NVHPC</em>).

Cited by 1Open access

Simulation code for modeling of coherent effects of radiation generation in oriented crystals

Alexei Sytov, В. В. Тихомиров, L. Bandiera · Physical Review Accelerators and Beams · 2019

We present the crystalrad simulation code, combining all the features of the crystal simulation code for simulations of charged particles trajectories in a bent crystal and the radcharm++ code for calculation of the radiation spectrum. The crystalrad code is based on Monte Carlo simulations of trajectories in the planar and axial electric field either in a straight, bent, or periodically bent crystal taking into account multiple and single Coulomb scattering on nuclei and electrons, nuclear scattering and ionization energy losses. The trajectories simulated are used for calculation of radiation spectra by the Baier-Katkov method. We compare our simulations with experimental data taken at MAMI (MAinzer MIkrotron) as well as give an example for a possible future study with sub-GeV electrons interacting with Si bent crystals.

Cited by 32Open access

MOD2IR: High-Performance Code Generation for a Biophysically Detailed Neuronal Simulation DSL : Artifact

Mitenkov, George, Magkanaris, Ioannis, Awile, Omar et al. · Zenodo (CERN European Organization for Nuclear Research) · 2023

<strong>Introduction</strong> This ZENODO folder was created to archive all the needed files for the artifact submission of the <em>MOD2IR: High-Performance Code Generation for a Biophysically Detailed Neuronal Simulation DSL</em> paper to the ACM SIGPLAN 2023 International Conference on Compiler Construction containing all necessary source code, data and scripts to reproduce the results published in the paper. <strong>Artifact Description</strong> MOD2IR is implemented as a code generation backend inside the NMODL Framework and it makes heavy use of the LLVM IR and compilation passes. Most of the relevant code of the described work can be found here and here. <strong>Hardware Requirements</strong> The provided artifact can in theory be run on any x86 hardware platform. For the purpose of closely reproducing our benchmark results it is required a workstation (or cloud instance) with Intel Xeon Skylake (or newer) CPU that supports AVX-512 instructions and an NVIDIA Volta V100 (or newer) GPU.<br> All benchmark runs are single-core and have relatively low memory-requirement. For building or running the Docker image (and more specifically the NMODL Framework) we, however, recommend a system with plenty of cores, at least 32GB of RAM available and 20 GB of disk space. <strong>Software Requirements</strong> Any reasonably up-to-date Linux system with Docker should be sufficient (we recommend Ubuntu 22.04). If GPU results are to be reproduced, an up-to-date CUDA (11.0 or newer) should be present. <strong>Benchmarking Instructions</strong> To reproduce as closely as possible our environment and to lower the burden of the installation of the different compilers and libraries we have created Docker images which take care of installing all the necessary packages and compilers to install MOD2IR and execute the benchmarks.<br> Due to technical restrictions imposed by Docker to execute a Docker image and be able to execute applications on NVIDIA GPUs there are some extra steps needed. For this reason we have created two different <em>Dockerfile</em>s, one that takes care of both the CPU and GPU benchmarks and one for CPU only execution if there is no NVIDIA GPU available in the test system. The original instructions (markdown file) with the executable script snippets can be found here. <strong>CPU and GPU docker image</strong> The <em>Dockerfile</em> that targets both CPU and GPU can be found in <em>Dockerfile_cpu_gpu</em>.<br> To launch the Docker image you can execute the following: <pre><code class="language-bash"># Install docker and NVIDIA docker runtime (needs sudo # permission and is based on Ubuntu 22.04 but with small # changes it should be supported by any Ubuntu version # or other linux distributions) bash install_gpu_docker_env.sh # Build docker image with CPU and GPU enabled execution # (~16GB) docker build -t bluebrain/nmodl:mod2ir-gpu-benchmark - &lt; Dockerfile_cpu_gpu # Run docker image docker run -it -v $PWD:/opt/mount --gpus \ all bluebrain/nmodl:mod2ir-gpu-benchmark</code></pre> After building and launching the docker file we can now execute the benchmarks and generate the same plots as the ones we included in the paper with the new results along the reference plots from the paper.<br> To do this we need to execute the following two scripts inside the docker image environment: <pre><code class="language-bash"># Enter the directory where the scripts are inside the docker # image cd nmodl/test/benchmark # Runs all the benchmarks on CPU and GPU bash run_benchmark_script_cpu_gpu.sh # Generate the plots based on the outputs of the previous script python3 plot_benchmarks_cpu_gpu.py # Copy the graphs from the docker image to your environment cp -r graphs_output_pandas /opt/mount</code></pre> Executing <em>run_benchmark_script_dockerfile.sh</em> will generate two pickle files that include the results in <em>hh_expsyn_cpu/benchmark_results.pickle</em> for the CPU benchmarks and <em>hh_expsyn_gpu/benchmark_results.pickle</em> for the GPU benchmarks. Those will then be loaded by <em>plot_benchmarks.py</em> to generate the plots.<br> Now you can exit the docker image terminal and open the above files which exist in your local directory. <br> <strong>CPU only docker image</strong> In case there is no GPU available instead of running the above Docker container you can also run a CPU only container.<br> To do this you need to build the image using <em>Dockerfile_cpu</em>: <pre><code class="language-bash"># Build CPU only Docker image (~16GB) docker build -t bluebrain/nmodl:mod2ir-cpu-benchmark - &lt; Dockerfile_cpu # Execute docker image docker run -it -v $PWD:/opt/mount \ bluebrain/nmodl:mod2ir-cpu-benchmark</code></pre> Then inside the docker shell: <pre><code class="language-bash"># Enter the directory where the scripts are inside the docker # image cd nmodl/test/benchmark # Runs all the benchmarks on CPU bash run_benchmark_script_cpu_only.sh # Generate the plots based on the outputs of the previous script python3 plot_benchmarks_cpu_only.py # Copy the graphs from the docker image to your environment cp -r graphs_output_pandas /opt/mount</code></pre> By executing <em>run_benchmark_script_cpu_only.sh</em> there will be only <em>hh_expsyn_cpu/benchmark_results.pickle</em> generated containing the CPU results. <br> <strong>Notes</strong> The benchmark results with <em>GCC</em> and <em>NVHPC</em> compilers might be better in the docker container than the presented manuscript due to the newer OS we’re using in the <em>Dockerfile</em>. The current Ubuntu versions come with GLIBC 2.3x, which includes <em>libmvec</em> providing vectorized implementations for some mathematical functions and which is used by the <em>GCC</em> and <em>NVHPC</em> compilers. This results in much more vectorization use in the benchmark kernels even without providing the SVML library to <em>GCC</em> (or <em>NVHPC</em>).

Cited by 0Open access

Design, Code Generation and Simulation of a BLDC Motor Controller usuuing PIC Microcontroller

Md. Fahim Bhuiyan, Mohammad Rejwan Uddin, Zaima Tasneem et al. · 2018

Brushless Direct Current (BLDC) motor are one of the electrical drives that are continually gaining popularity in motion control applications due to their high efficiency, good dynamic response and low maintenance. Unlike DC motors and Induction motors, BLDC motors needs a controller as the motor runs in 3 phases but takes DC input. The controller converts DC power to 3 phase AC power suitable for the motor. This paper propose a design, code generation method and digital logic control of a BLDC motor controller for turning the rotor clockwise or counter clockwise. A Pulse Width Modulation (PWM) speed control strategy is performed to adjust the rotor speed. The framework is modelled and simulated by using Proteus software.

Cited by 10

Symbolic Processing and Code Generation of Equation Based HVAC&amp;amp;R Simulation Models

Per Sahlin, Pavel Grozman, Ph. D · 2007

this paper is to discuss necessary standards and software infrastructure to remedy this problem. In particular, results from a recent ASHRAE research project (RP839) that deals with automatic translation of equation based simulation models into executable code will be presented. An Example to Indicate the Magnitude of the Problem Quantifying the cost of a missing standard is obviously close to impossible. We will nevertheless attempt to provide some indicators by means of an example. A very successful ASHRAE research project was RP629 A Toolkit for Secondary HVAC Systems, the first of a series of three similar projects that have been initiated by Technical Committee 4.7. The purpose of this project was to collect, evaluate, package and document component models for secondary HVAC equipment such as cooling coils, fans and various heat exchangers. Since the whole idea of the project was to provide easily accessible model material for simulation, considerable effort was spent on finding a suitable presentation format. A subroutine-based format in FORTRAN 77 was selected and guidelines for the written account of the models were settled. The total cost of the project was $ 65 000, and the main result is a well appreciated ASHRAE publication with accompanying software (Brandemuehl 1992). Utilizing these results in practical simulations is however still quite laborious. The simplest thing to do is to run a single component, with given input parameters and boundary variables. A small subroutine driver is provided in the package for this case. However, in order to make the toolkit truly useful, arbitrary combinations of toolkit components must be connected in the structure of the air-handling unit to be studied. This is considerably more involved, since some numerical procedure...

Cited by 0