Welcome to the 2021 edition of the International Conference on Languages Compilers, Tools and Theory of Embedded Systems. LCTES provides a link between the programming languages and the embedded systems 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.

Paper Categories

• Full paper: 10 pages presenting original work.
• Work-In-Progress (WIP) paper: 2-4 page papers presenting original ideas that are likely to trigger interesting discussions.
• Invited (INV) papers: 2-3 page papers, presenting an overview of the field, and shining light on important research problems. After acceptance, the authors will submit a full (up to) 10-page paper for publication.

Accepted papers in all the categories will appear in the proceedings published by ACM. Selected papers will be invited for a special issue in ACM TECS.

Artifact Evaluation

Authors of accepted papers will be invited to formally submit their supporting materials to the Artifact Evaluation process. The Artifact Evaluation process is run by a separate committee whose task is to reproduce (at least some) experiments and how the artifacts support the work described in the papers. This submission is voluntary and will not influence the final decision regarding the papers.

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

• Programming languages
• Compilers
• Tools for analysis, specification, design, and implementation
• Theory and foundations of embedded systems
• Novel embedded architectures
• Mobile systems and IoT
• Industrial case studies

Accepted Papers

Call for Papers

Embedded system design faces many challenges both with respect to functional requirements and nonfunctional requirements, many of which are conflicting. They are found in areas such as design and developer productivity, verification, validation, maintainability, and meeting performance goals and resource constraints. Novel design-time and run-time approaches are needed to meet the demand of emerging applications and to exploit new hardware paradigms, and in particular to scale up to multicores (including GPUs and FPGAs) and distributed systems built from multicores.

LCTES 2021 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.

Paper Categories:

• Full paper: 10 pages presenting original work.
• Work-in-progress 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.

This year LCTES is introducing a journal mode in addition to the usual conference mode. All accepted full papers will be invited to be published in a special issue of ACM Transactions on Embedded Computing Systems (TECS).

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

• Programming language challenges, including:
• Domain-specific languages
• Features to exploit multicore, reconfigurable, and other emerging architectures
• Features for distributed, adaptive, and real-time control embedded systems
• Language 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, including:
• 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 and data size, and best-effort 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, including:
• 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, including:
• 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, including:
• 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
• Empirical studies and their reproduction, and confirmation

Submission Site

Submit your artifact via EasyChair

Submission Due: 11:59pm 04/17/2021 (AOE)

AE Notification: 11:59pm 05/03/2021 (AOE)

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 that was either 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 evaluation, and they will not retain any part of any artifact after evaluation. Thus, you are free to include models, data files, proprietary binaries, and similar items in your artifact.

We expect each artifact to receive three reviews. Papers that go through the Artifact Evaluation process successfully will receive ACM reproducibility badge(s) printed on the papers themselves and available as meta information in the ACM Digital Library.

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

Badging

The papers with accepted artifacts will be assigned official ACM artifact evaluation badges, based on the criteria defined by ACM. ACM recommends awarding three different types of badges, generally saying, Availability (green) badge, Reproducibility (blue) badge [^1], and Functionality/Reusability (red) badge, to communicate how the artifact has been evaluated. A single paper can receive up to three badges. (Please refer to 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 badges will appear on the first page of the camera-ready version of the paper, indicating that the artifact was submitted, evaluated, and found to be functional. Artifact authors will be allowed to revise their camera ready paper after they are notified of their artifact’s publication in order to include a link to the artifact’s DOI.

[^1]: We do not provide the “Replication” (light blue) badge, just the “Reproducibility” (dark blue) one.

Guidelines

1. Carefully think which badge(s) you want.
   • If making your code public is all you want to do, seek only the “Availability” (green) badge. The reviewers will not exercise the artifact for its functionality or validate the claims.
   • If you only plan to reproduce the claims without making your artifact Documented, Consistent, Complete, and exercisable, seek for the “Reproducibility” (blue) badge rather than the “Functionality/Reusability” (red) badge.
   • If you do not plan on making the artifact available to the public, do not seek the “Availability” (green) badge but the other one or two.
2. Minimize the artifact setup overhead.

A well-packaged artifact is easily usable by the reviewers, saving them time and frustration, and more clearly conveying the value of your work during evaluation. A great way to package an artifact is as a Docker image or in a virtual machine that runs #“out of the box” with very little system-specific configuration. We encourage authors to include pre-built binaries for all their code, so that reviewers can start with little effort; together with the source and build scripts that allow to regenerate those binaries, to guarantee maximum transparency. Providing pre-built VMs or docker containers is preferable to providing scripts (e.g. Docker or Vagrant configurations) that build the VM, since this alleviates reliance on external dependencies. Your artifact should have a container or a bootable virtual machine image with all of the necessary libraries installed. After preparing your artifact, download and test it on at least one fresh machine where you did not prepare the artifact; this will help you fix missing dependencies, if any.

Giving AE reviewers remote access to your machines with preinstalled (proprietary) software is also possible.

Preparing the Artifact

Your submission should be in ONE pdf file, consisting only a URL link pointing to a widely available compressed archive format, such as ZIP (.zip), tar and gzip (.tgz), or tar and bzip2 (.tbz2). Ensure the file has the suffix indicating its format. The URL must protect the anonymity of the reviewers (e.g., a Google Drive URL).

The compressed archive should consist of three pieces:

1. The submission version of your accepted paper.
2. A README.txt 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 for how you propose to evaluate your artifact (with appropriate connections to the relevant sections of your paper);

The Getting Started Guide should contain setup instructions (including, for example, a pointer to the VM player software, its version, passwords if needed, etc.) and basic testing of your artifact that you expect a reviewer to be able to complete in 30 minutes. Reviewers will follow all the steps in the guide during an initial kick-the-tires phase. The Getting Started Guide should be as simple as possible, and yet it should stress the key elements of your artifact. Anyone who has followed this guide should have no technical difficulties with the rest of your artifact.

The Step by Step Instructions explain how to reproduce any experiments or other activities that support the conclusions in your paper. Write this for readers who have a deep interest in your work and are studying it to improve it 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 expected outputs (e.g., the log files expected to be generated by your tool on the given inputs); if there are warnings that are safe to be ignored, explain which ones they are.

Please include the following if possible:

• A list of claims from the paper supported by the artifact, and how/why.
• A list of claims from the paper not supported by the artifact, and how/why. Example: Performance claims cannot be reproduced in VM, authors are not allowed to redistribute specific benchmarks, etc. Artifact reviewers can then center their reviews / evaluation around these specific claims.

When packaging your artifact, please keep in mind:

• how accessible you are making your artifact to other researchers, and
• the fact that the AEC members will have a limited time in which to make an assessment of each artifact.

We strongly encourage to use a container (e.g., https://www.docker.com/) which provides a way to make an easily reproducible environment. It also helps the AEC have confidence that errors or other problems cannot cause harm to their machines.

You should make your artifact available as a single archive file and use the naming convention <paper #>., where the appropriate suffix is used for the given archive format. Please use a widely available compressed archive format such as ZIP (.zip), tar and gzip (.tgz), or tar and bzip2 (.tbz2). Please use open formats for documents.

Artifact Evaluation Committee

Other than the chair, the AEC members are senior graduate students, postdocs, or recent PhD 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 EasyChair and will be (approximately) 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. The goal of continuous interaction is to prevent rejecting artifacts for a “wrong library version” types of problems.

During the evaluation process, authors and AEC are allowed to anonymously communicate through EasyChair system to overcome technical difficulties. Ideally, we hope to see all submitted artifacts to successfully pass the artifact evaluation.

Contact

If you have any questions, please don’t hesitate to contact Jiajia Li (jiajia.li@pnnl.gov or fruitfly1026@gmail.com).

Please click this link for registration.

Formatting Guidelines: Submissions must be in ACM SIGPLAN subformat of the acmart format by downloading acmart-sigplanproc.zip, double-column, 10-point type, and may not exceed 10 pages for full papers and 4 pages for work-in-progress papers (not including references; there is no page limit for references for both categories of papers.). A more detailed explanation about formatting can be found at http://www.sigplan.org/Resources/Author/. For papers in the work-in-progress categories, please prepend “WIP: **” in front of the title. 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.

The ACM template can be found at https://www.acm.org/publications/proceedings-template.

The submission site: is https://lctes-2021.hotcrp.com/.