Evolutionary System Design with Answer Set Programming

Abstract

We address the problem of evolutionary system design (ESD) by means of answer set programming modulo difference constraints (AMT). The goal of this design approach is to synthesize new product variants or generations from existing products. We start by formalizing the underlying system synthesis problem and design space exploration process, which consists of finding the Pareto front with respect to latency, cost, energy, and similarity measures between the two designs. We then present AMT-based encodings to capture all of these aspects. The idea is to use plain ASP for conflict detection and resolution and for routing and to use difference constraints for scheduling. Moreover, we propose a new approach for expressing the similarity that we use at three alternative levels of AMT-based design space exploration, namely, at the strategic, heuristic, and objective levels, which is performed to guide the exploration towards designs of high interest. Last but not least, we systematically evaluate the emerging techniques empirically and identify the most promising AMT techniques.

Generative Design of the Architecture Platform in Multiprocessor System Design

“…Many previous state-of-the-art DSE publications [3,[5][6][7][8][9][10][11] are based on or are similar in nature to the system model originally presented by Blickle et al in [24], which uses fixed architecture graphs. They all have in common that they map tasks directly to processing elements in a fixed architecture graph.…”

“…The definition of the resource library L is closely related to our previous work in this field [3,10], where we specified a fixed architecture template containing processors, routers, and links at certain positions, which can be allocated. In contrast, we define the resource library as a set of resource types that are partitioned into processing, communication and interconnection types Types = Types Proc ∪ Types Comm ∪ Types Link , with Types Proc ∩Types Comm ∩Types Link = ∅ .…”

“…A set of mapping options M ⊆ T × Types Proc assigns each task t ∈ T with at least one processing type type Proc ∈ Types Proc , representing that the task t can be potentially executed on an instance of the processing type type Proc . In contrast to that, in previous work, the authors assigned each task to a specific processor instance [3,10,30]. For each mapping option m ∈ M = (t, type Proc ) the function w : M → N defines the worst-case execution time of the task t on an instance of the processing type type Proc .…”

“…The state-of-the-art work [3,[5][6][7][8][9][10][11] allows the exploration of the architecture up to a certain degree. Given a fixed architecture template, these approaches derive different architectures by allocating only those resources from the specification that are actually used for the task execution and message transmission in the final implementation.…”

“…However, most traditional approaches are limited because they only consider a fixed architecture template with a fixed set of available hardware components [3,[5][6][7][8][9][10][11]. Alterations in the architecture between design points are only achieved by not allocating idle hardware components.…”