Languages, Compilers, Tools and Theory of Embedded SystemsLCTES 2025

LCTES 2025

Welcome to the 26th ACM SIGPLAN/SIGBED International Conference on Languages, Compilers, and Tools for Embedded Systems (LCTES 2025)!

LCTES provides a link between the programming languages and embedded systems engineering communities. Researchers and developers in these areas are addressing many similar problems but with different backgrounds and approaches. LCTES is intended to expose researchers and developers from either area to relevant work and interesting problems in the other area and provide a forum where they can interact.

LCTES 2025 is co-located with and shares the venue and activities with PLDI 2025.

The important dates are as follows:

• Paper Submission Deadline: March 14, 2025 March 21, 2025 (extended firm deadline)
• Paper Notification: April 21, 2025
• Artifact Evaluation Submission Deadline: April 28, 2025
• Artifact Evaluation Notification: May 9, 2025
• Camera-Ready Deadline: May 12, 2025
• Conference Dates: June 16–17, 2025

Call for Artifacts

Submission Site

Submit your artifacts through https://lctes2025ae.hotcrp.com.

• Artifact Submission Deadline: 11:59 pm Apr 28, 2025 (AoE)
• Artifact Decision Notification: May 12, 2025

General Info

The authors of all accepted LCTES papers (including WIP papers) are invited to submit supporting materials to the Artifact Evaluation process. Artifact Evaluation is run by a separate Artifact Evaluation Committee (AEC) whose task is to assess how well the artifacts support the work described in the papers. This submission is voluntary but strongly encouraged and will not influence the final decision regarding the papers.

At LCTES, we follow ACM’s artifact review and badging policy, version 1.1. ACM describes a research artifact as follows:

By “artifact” we mean a digital object created by the authors to be used as part of the study or generated by the experiment itself. For example, artifacts can be software systems, scripts used to run experiments, input datasets, raw data collected in the experiment, or scripts used to analyze results.

Submission of an artifact does not imply automatic permission to make its content public. AEC members will be instructed that they may not publicize any part of the submitted artifacts during or after completing the evaluation, and they will not retain any part of any artifact after evaluation. Thus, you can include models, data files, proprietary binaries, and similar items in your artifact.

We expect each artifact to receive three reviews. Papers that pass the Artifact Evaluation process will receive up to three ACM artifact evaluation badge(s) directly printed on the paper and available as meta information in the ACM Digital Library.

Artifact evaluation is single-blind. Please take precautions (e.g., turning off analytics and logging) to help prevent accidentally learning the reviewers’ identities.

Badging

The papers with accepted artifacts will be assigned official ACM artifact evaluation badges based on the criteria defined by ACM. The AEC awards up to three types of badges that reflect the evaluation (red), availability (green), and validation (blue) of the artifact and the results of the paper. Refer to the ACM website for detailed badge information. Note that artifacts will be evaluated with respect to the claims and presentation in the submitted version of the paper, not the camera-ready version.

The awarded badges will appear on the first page of the camera-ready version of the paper. Artifact authors will be allowed to revise their camera-ready paper after being notified of their artifact’s publication to include a link to the artifact’s DOI.

Note that we only award the “Reproducibility” (dark blue) badge but not the “Replication” (light blue) one.

Guidelines

1. Carefully think which badge(s) you seek to receive.
   • If your only goal is to publish your code, seek the “Availability” (green) badge. The reviewers will not exercise the artifact for its functionality or validate the paper’s claims.
   • If you wish you have your results reproduced without making your artifact documented, consistent, complete, and exercisable, seek the “Reproducibility” (blue) badge rather than the “Functionality/Reusability” (red) badge.
   • If you do not want to make the artifact available publicly, do not seek the “Availability” (green) badge.
2. Minimize the artifact setup overhead.
   • A well-packaged artifact is easily usable by the reviewers and conveys the value of your work. A great way to package an artifact is as a VM image or Docker container that runs “out of the box.” We encourage authors to include pre-built binaries along with the source and build scripts that allow the AEC to regenerate the binaries to guarantee maximum transparency. Pre-built VM or docker images are preferred over scripts that build the image since this alleviates reliance on external dependencies. Make sure to test your artifact on at least one machine different than the one you used to prepare the artifact to identify missing dependencies.
   • Giving AE reviewers remote access to your machines with preinstalled (proprietary) software is possible.

Preparing the Artifact

You should make your artifact available as a single archive file and use the naming convention <paper #>.<suffix>, where the appropriate suffix is used for the given archive format. Use a commonly-available compressed archive format such as .tgz, .tbz2, or .zip and open document formats. The link to download your artifact must protect the anonymity of the reviewers (e.g., a Google Drive URL).

The compressed archive should consist of three pieces:

1. The submitted version of your accepted paper.
2. A README file (PDF or plaintext format) that explains your artifact (details below).
3. A folder containing the artifact.

The README.txt should consist of two parts:

1. A Getting Started Guide and
2. Step-by-Step Instructions that detail how your artifact can be evaluated. Include appropriate references to the relevant sections of your paper.

The Getting Started Guide should contain instructions on how to set up (including, for example, a pointer to the VM player software, its version, and passwords if needed) and test your artifact. Anyone following this guide should be able to handle the rest of your artifact easily.

The Step-by-Step Instructions explain how to reproduce experiments or other activities supporting your paper’s conclusions. Write this for readers who are deeply interested in your work and are studying to improve or compare against it. If your artifact runs for more than a few minutes, point this out and explain how to run it on smaller inputs.

Where appropriate, include descriptions of and links to files (included in the archive) that represent the expected outputs such as log files generated by your tool for a given set of inputs. If there are warnings that can be ignored, explain what they are.

Further, include the following:

• A list of claims from the paper supported by the artifact. Explain how and why the artifact supports those claims.
• A list of claims from the paper not supported by the artifact. Explain why the artifact does not support those claims. Examples: performance claims cannot be reproduced in a VM, authors cannot redistribute specific benchmarks, etc.

When preparing your artifact, please keep in mind:

• How accessible you are making your artifact to other researchers.
• The AEC members will have a limited time to assess your artifact.

Artifact Evaluation Committee

Other than the chair, the AEC members are senior graduate students, postdocs, or recent Ph.D. graduates, identified with the help of the LCTES PC and recent artifact evaluation committees. Please check SIGPLAN’s Empirical Evaluation Guidelines for some methodologies to consider during evaluation.

Throughout the review period, reviews will be submitted to HotCRP and continuously visible to authors. AEC reviewers will be able to continuously interact (anonymously) with authors for clarifications, system-specific patches, and other logistics to help ensure that the artifact can be evaluated. Continuous interaction prevents rejecting artifacts for “wrong library version” types of problems.

Our goal is that all submitted artifacts successfully pass the artifact evaluation.

Call for Papers

Programming languages, compilers, and tools are important interfaces between embedded systems and emerging applications in the real world. Embedded systems are aggressively adapted for deep neural network applications, large language models, autonomous vehicles, robots, healthcare applications, etc. However, these emerging applications impose challenges that conflict with conventional design requirements and increase the complexity of embedded system designs. Furthermore, they exploit new hardware paradigms to scale up multicores (including GPUs and FPGAs) and distributed systems built from many cores. Therefore, programming languages, compilers, and tools are becoming more important to address these issues, such as productivity, validation, verification, maintainability, safety, and reliability for meeting both performance goals and resource constraints.

The 26th ACM SIGPLAN/SIGBED International Conference on Languages, Compilers, Tools and Theory of Embedded Systems (LCTES 2025) solicits papers presenting original work on programming languages, compilers, tools, theory, and architectures that help in overcoming these challenges. Research papers on innovative techniques are welcome, as well as experience papers on insights obtained by experimenting with real-world systems and applications. Papers can be submitted to https://lctes2025.hotcrp.com/.

Important Dates

• Abstract Submission: March 7, 2025 March 14, 2025 (soft, new submission is open until March 14, 2025 March 21, 2025)
• Paper Submission: March 14, 2025 March 21, 2025 (extended firm deadline)
• Paper Notification: April 21, 2025
• Artifact Evaluation Submission: April 28, 2025
• Artifact Evaluation Notification: May 9, 2025
• Camera-Ready Submission: May 12, 2025
• Conference Dates: June 16–17, 2025

Paper Categories

• Full paper: 10 pages presenting original work (at most 2 additional pages for references and appendix).
• Poster, work-in-progress and invited paper: 4 pages papers presenting original ideas that are likely to trigger interesting discussions.
• Accepted papers in both categories will appear in the proceedings published by ACM. In addition, this year’s LCTES will have Distinguished Paper awards selected from this year’s accepted paper to recognize the outstanding work among all papers.

Special Issue Invitation

Accepted full papers will be invited to submit to a special issue of the ACM Transactions on Embedded Computing Systems (TECS). A TECS publication will require substantial additional material over the conference publication and will undergo a separate review process. Papers submitted to LCTES (including the WIP papers) will be welcome to submit manuscripts to a special issue of the IEEE Embedded Systems Letters (IEEE ESL). A 4-page IEEE ESL manuscript will require clearly distinct intellectual contribution as compared to the conference paper and will undergo a separate review process.

Topics

Original contributions are solicited on the topics of interest including, but not limited to:

Programming language challenges

• Domain-specific languages
• Features to exploit multicore, reconfigurable, and other emerging architectures
• Features for distributed, adaptive, and real-time control embedded systems
• Capabilities for specification, composition, and construction of embedded systems
• Language features and techniques to enhance reliability, verifiability, and security
• Virtual machines, concurrency, inter-processor synchronization, and memory management
• Compiler challenges

Interaction between embedded architectures, operating systems, and compilers

• Interpreters, binary translation, just-in-time compilation, and split compilation
• Support for enhanced programmer productivity
• Support for enhanced debugging, profiling, and exception/interrupt handling
• Optimization for low power/energy, code/data size, and real-time performance
• Parameterized and structural compiler design space exploration and auto-tuning
• Tools for analysis, specification, design, and implementation, including:
• Hardware, system software, application software, and their interfaces
• Distributed real-time control, media players, and reconfigurable architectures
• System integration and testing
• Performance estimation, monitoring, and tuning
• Run-time system support for embedded systems
• Design space exploration tools
• Support for system security and system-level reliability
• Approaches for cross-layer system optimization
• Theory and foundations of embedded systems

Predictability of resource behavior: energy, space, time

• Validation and verification, in particular of concurrent and distributed systems
• Formal foundations of model-based design as the basis for code generation, analysis, and verification
• Mathematical foundations for embedded systems
• Models of computations for embedded applications
• Novel embedded architectures

Design and implementation of novel architectures

• Workload analysis and performance evaluation
• Architecture support for new language features, virtualization, compiler techniques, debugging tools
• Architectural features to improve power/energy, code/data size, and predictability
• Mobile systems and IoT

Operating systems for mobile and IoT devices

• Compiler and software tools for mobile and IoT systems
• Energy management for mobile and IoT devices
• Memory and IO techniques for mobile and IoT devices

Large language models (LLMs) and programming languages/compilers

• Impact of LLMs on embedded system design and architectures
• LLM-based debugging tools for embedded software
• Adapting LLMs for resource-constraint environment
• LLM for embedded systems and compilers
• LLM for program analysis, testing and verification.
• Program analysis, testing and verification for LLM

Submission

Submissions must be in ACM SIGPLAN subformat of the acmart format (available at and explained in more detail at https://www.sigplan.org/Resources/Author/). Each paper should be in 10pt font and have no more than 10 pages for full papers or 4 pages for work-in-progress papers, excluding the bibliography. There is a 2-page limit on the page count for references. Each reference must list all authors of the paper (do not use et al.). The citations should be in numeric style, e.g., [52]. Submissions must be in PDF format and printable on US Letter and A4-sized paper. For papers in the work-in-progress category, add the suffix “(WIP)” to your title, such as “Title (WIP)”.

To enable double-blind reviewing, submissions must adhere to two rules:

• author names and their affiliations must be omitted; and,
• references to related work by the authors should be in the third person (e.g., not “We build on our previous work …” but rather “We build on the work of …”).

However, nothing should be done in the name of anonymity that weakens the submission or makes the job of reviewing the paper more difficult (e.g., important background references should not be omitted or anonymized). Papers must describe unpublished work that is not currently submitted for publication elsewhere as discussed here. Authors of accepted papers will be required to sign an ACM copyright release.

ACM Publications Policies

1. By submitting your article to an ACM Publication, you are hereby acknowledging that you and your co-authors are subject to all ACM Publications Policies, including ACM’s new Publications Policy on Research Involving Human Participants and Subjects. Alleged violations of this policy or any ACM Publications Policy will be investigated by ACM and may result in a full retraction of your paper, in addition to other potential penalties, as per ACM Publications Policy.

2. Please ensure that you and your co-authors obtain an ORCID ID, so you can complete the publishing process for your accepted paper. ACM has been involved in ORCID from the start, and we have recently made a commitment to collect ORCID IDs from all of our published authors. The collection process has started and will roll out as a requirement throughout 2022. We are committed to improve author discoverability, ensure proper attribution and contribute to ongoing community efforts around name normalization; your ORCID ID will help in these efforts.

AUTHORS TAKE NOTE

The official publication date is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of your conference. The official publication date affects the deadline for any patent filings related to published work.

By submitting the paper, the authors agree that if the paper is accepted, one author will have to register at the conference rate and present the paper in person at the LCTES 2025 conference.

Submission site

https://lctes2025.hotcrp.com