Preservation of LTL Properties in Desynchronized Systems

Transcription

1 Preservation of LTL Properties in Desynchronized Systems Yu Bai, Jens Brandt and Klaus Schneider Embedded Systems Group Department of Computer Science University of Kaiserslautern, Germany es.cs.uni-kl.de Abstract The synchronous programming model is perfect for modeling, simulation, verification and implementation of reactive systems. While this paradigm can be directly implemented as hardware circuits, multithreaded software implementations are typically based on asynchronous threads. For this reason, an efficient multithreaded software implementation of a synchronous program requires a so-called desynchronization that could however potentially violate the already verified properties of the synchronous program. In this paper, we therefore present a theory to check whether properties verified for a synchronous system are preserved by a desynchronization. In particular, we prove a theorem based on directed-flow equivalence that specifies the requirements of delay relations among system variables that a desynchronization has to meet. I. INTRODUCTION The synchronous model of computation [2] has shown to be well-suited for the design of reactive systems. Its core is the paradigm of perfect synchrony which assumes that the overall system behavior is divided into a sequence of reactions, and all computations within a reaction are completed in zero time. This temporal abstraction simplifies reactive programming in that developers do not have to bother about many low-level details related to timing, synchronization and scheduling. The synchronous abstraction of time together with a concise formal semantics of most synchronous languages have many important advantages, e. g. they simplify to a great extent (1) the reasoning about compiler correctness as well as (2) the verification of programs with respect to given formal specifications [16 19]. In particular, since all computations within a macro step are done in parallel in zero time, the product of processes is the synchronous automaton product that has a much smaller size than asynchronous ones. On the other hand, the synchronous paradigm has certain drawbacks that make its implementation quite difficult. In the domain of embedded systems, synthesis often has to map a synchronous model to a target architecture that does not directly support this model of computation. For example, many embedded applications in the automotive or avionic industry are implemented on a heterogeneous set of distributed processing elements. Using these architectures, it is in general not reasonable to maintain a single global clock, since the resulting performance would be unacceptably low. Instead, the use of several clocks is often considered: the higher the abstraction level, the slower is the corresponding clock. A somehow extreme case of multi-clock systems are GALS (globally asynchronous, locally synchronous) systems which perfectly match real-world systems. In a GALS system, a number of synchronous components are asynchronously connected, e. g. by sending messages over asynchronous FIFO channels. Since there is no global clock in an asynchronous system, each component runs independently of the other components. Their composition is done by only unifying their input and output channels. Thus, their behavior can no longer be split into a sequence of steps or reactions. Related Work. In this context, the desynchronization of synchronous systems has gained attention [1, 3, 6, 12, 14]. Its basic idea is to use existing methods and tools for synchronous systems throughout the whole development process, in particular, for modeling and verification. A subsequent desynchronization step decomposes the system into several components to implement a GALS system. Thereby, some synchronization logic is added so that the behavior of the synthesized system corresponds to the original model. Previous publications have considered the desynchronization of synchronous programs, as in particular, the pioneering work in [1, 11 13]. Their definitions of (weak) endochrony and isochrony are intended to answer the question of which systems can be safely desynchronized without additional effort while preserving the original behavior with respect to flow-equivalence of each signal, i. e. each asynchronous channel will still transport the same sequence of tokens. Their main result is that systems composed of endochronous components which are isochronous to each other can be safely desynchronized without additional effort. Thereby, a component is said to be endochronous if it can infer its own clock from the currently available input values (even if not all are present). Several components are isochronous to each other if they agree on the clocks of exchanged signals depending on the signal values they both know. However, the guarantee that all signal flows are preserved may not be sufficient in particular, if the original synchronous systems has been proved correct with respect to specifications given in temporal logics. As these properties rely on an alignment of the signal flows, previously verifi /12/$ IEEE 53

2 properties. Section IV contains the core of our contribution, which considers desynchronization and preservation of global properties. Finally, we conclude with a short summary in Section V. Figure 1. Simple desynchronization example cation results are generally no longer valid. To illustrate the problem, consider a very simple example (see Figure 1). Assume that we have a system which consists of three parts: the first one only forwards its inputs to its outputs, whereas the other two parts implement the same function f. Obviously, in this synchronous system the LTL property G(z 1 = z 2 ) holds. However, after a desynchronization of the three parts, this is no longer the case since z 1 and z 2 may be delayed differently. However, there are other global properties, which can be still guaranteed after the desynchronization. Assume that all signals in our example are Boolean, and the function f is a simple negation. Then, the LTL property [z 1 U x] will still hold in the desynchronized system. Hence, in contrast to previous work [1, 11 13], where desynchronization under flow-preservation was explored, we consider a different problem in this paper: We aim at identifying which LTL properties formally verified for a synchronous system are still preserved by desynchronized implementations. Obviously, this is a very important question for model-based design which clarifies the compatibility of verification and desynchronization. Note that our approach is different to previous ones [7, 15], where the verification is carried out on the GALS model (desynchronized model in our context). Our approach avoids the analysis on the desynchronized model, which is generally more complex. In contrast, we want to benefit from the synchronous abstraction of time by using the verification results from the synchronous level, and our theory will guarantee that the gained results also hold in the desynchronized implementation. Contribution. The main contribution of this paper is a method to check the preservation of LTL properties in desynchronized implementations of a synchronous system. The core consists of a theorem which gives us sufficient conditions to guarantee the preservation of already verified LTL properties. In particular, this enables us to answer two questions: (1) Given a synchronous system S, an already verified LTL property ϕ and a desynchronization of S, will ϕ hold in the desynchronization? (2) Given a synchronous system S and an already verified LTL property ϕ, will ϕ be preserved in any desynchronized implementation of S? The rest of the paper is structured as follows: Section II first gives fundamental definitions. Section III briefly summarizes previous results on the preservation of local II. FOUNDATIONS In this section, we first explain some basic notions related to systems and traces. After defining the desynchronization, we review the classic theorem on stutter-free LTL, which is the starting point of our contribution shown Section IV. A. Systems and Traces In our approach, the synchronous system is given as a Kripke structure. Definition 1 (Kripke Structure). A Kripke structure K(I, S, R, L) for a finite set of variables V Σ is given by a finite set of states S, a set of initial states I S, a transition relation R S S, and a label function L : S 2 VΣ which maps each state to a set of variables. A path π of a Kripke structure K(I, S, R, L) is a function π : N S such that π(0) I and i N.(π(i), π(i + 1)) R. Kripke structures are synchronous, since all variables are updated simultaneously along each transition. As we want to consider asynchronous executions, where each variable follows its own clock and updates may not be synchronized anymore, we introduce traces to study the behavior of a system on the level of changes of variables. Definition 2 (Trace). Let V Σ be the set of variables of system K, let π be a path of K. A trace t of the system K is a function t : V Σ N B, where i N. v V Σ.t(v, i) = true if and only if v L(π(i)). The set of traces of K is given by T (K). For a given trace t of system K, we may derive for any variable v V Σ a trace: t(v) : N B. Similarly, we can also derive a trace mapped to a set of variables V V Σ only, denoted as t V : V N B. Before we proceed with our definition, we have to look closer to the semantic foundation of our approach. In the original synchronous model, we have a notion of steps, i. e. we have a linear model of discrete time. LTL perfectly matches this model and is therefore the best choice for specification of temporal properties of synchronous systems. However, in the final GALS implementation, the synchronization of components is lost. Instead, a notion of time is used that is based on a partial order on instants. Nevertheless, we want to check whether an LTL property is still valid for the GALS implementation. We deal with this problem by modeling the partial order of time with the help of inserting arbitrary (but finite) delays between the streams of single variables in a synchronous computation. Thus, a trace of the GALS system is represented by a corresponding equivalence class of computations 54

3 of the synchronous system. This is a common approach, and has been used for instance in previous work on latency insensitive systems [3] or synchronous elastic systems [4, 5]. There, the delay is modeled by the insertion of bubbles (or absence values) between two signal events. Unfortunately, inserting such values raises the question of defining the evaluation of LTL formulas containing them, which is completely unclear. Instead, we replace the bubbles by stuttering steps, i. e. the previous value of a variable is repeated finitely many times. i := t u := a a a a b b b b a a a... t u := a a a a b b b b a a... t u := a a a a a a b b b b b b a a a... Consider the three traces above, where the values assigned to u at each point of time i are listed: t u is a trace of variable u and t u is its desynchronized counterpart (with inserted to represent the delay). a, b are values from the domain of u. In our approach, we use t u instead of t u where is replaced by the previous known value. Using stuttering steps avoids problems with LTL semantics for desynchronized traces but raises the following question: if the same value is repeated forever in a desynchronized trace, then the desynchronized trace cannot be distinguished from a finite synchronous trace ending in that value or a synchronous trace that repeats this value forever after some time. Therefore, we assume in the following that we always have infinite synchronous paths, and only finitely many stuttering steps are allowed between two synchronous steps. The fact that we lose the exact timing of a repetition does not harm since an LTL property still holds as long as its variable assignments remain the same. B. Stretching The following definitions formalize the ideas presented in the previous section. They define the stretching of traces, which model the delays in the asynchronous channels. Definition 3 (Stretch Function). A function f : N N + where N + = N {ℵ 0 } and i N.i < ℵ 0 is called a stretch function if the following holds: f(0) = 0 i N.i f(i) i 1, i 2 N.i 1 i 2 f(i 1 ) f(i 2 ) We write Stretch(f ) if f satisfies the above requirements. Definition 4 (Stretch Functions of Traces). Let K be a system with the set of system variables V Σ, p V Σ and t a trace of K. Then, there is a function f : N N + such that Stretch(f) and i N.t(p, f(i)) = t(p, f(i) + 1) =... = t(p, f(i+1) 1) and one of the following cases holds: if k 0. i > k.t(p, f(i)) = t(p, f(i + 1)), then i < k.f(i) f(i + 1), i N.f(i) f(i + 1) We call such a function f a stretch function of trace t(p). The set of stretch functions of p w.r.t. t is denoted by Str(t, p). For example, for the trace t u a possible stretch function f tu would be: f tu (0) = 0, f tu (1) = 4, f tu (2) = 5, f tu (3) = 8,.... The stretch function of a trace for a single variable can be naturally extended to a trace for a set of variables V such that i N.t V (i) = t V (i + 1). We denote the set of stretch functions of t V as Str(t, V ) and Str(t) the set of stretch functions of t. We further define some auxiliary operations over traces as follows: Definition 5 (Trace Operations). Let t be a trace of system K and p V Σ a system variable of the system. We define the duplication and deletion operations of x as follows: for a given i N, let dup : T (K) V Σ N T (K) be a function such that t = dup(t, p, i) be a trace of system K, j N.: t(j, v) v V Σ.t (j, v) = t(j, p) t(j 1, p) if p v if p = v and j i if p = v and j > i for a given i N, let del : T (K) V Σ N T (K) be a function such that x = del(x, p, i) be a trace of system K, j N.: t(j, v) if p v v V Σ.t (j, v) = t(j, p) if p = v and j < i t(j + 1, p) if p = v and j i We write dup k (t, p, i) as an abbreviation of dup(dup(...(dup(t, p, i),...),...), p, i) where dup is applied k times over the variable p in trace t at position i. Similarly, we write del k (t, p, i) as a short form for applying del k times. As defined, dup duplicates for a particular position the value of the one before it, while del deletes it. A stretch function can be used to characterize the occurrence of events in a trace. This is important in our context since we aim at checking the validity of a property in the desynchronized environment. Given that it is valid in the original synchronous system, the time shift of events changes the validity of the property. The following lemma gives us a unique stretch function that characterizes the variant of variable assignments in a trace: Lemma 6. For any trace t of system K, there exists a unique stretch function f such that either i N.t(p, f(i)) = t(p, f(i) + 1) =... = t(p, f(i + 1) 1) t(p, f(i)) t(p, f(i+1)) or k 0. i < k.t(p, f(i)) = t(p, f(i)+1) =... = t(p, f(i + 1) 1) t(p, f(i + 1)) i > k.f(i) = ℵ 0 i f(k).t(p, i) = t(p, i + 1). We denote this function as χ(t, p). 55

4 As an example, f tu = χ(t u, u) is then: f tu (0) = 0, f tu (1) = 4, f tu (2) = 8,.... Definition 7 (Order of Stretch Functions). For two stretch functions f 1, f 2 Stretch, define the relation f 1 f 2 if and only if i N.f 1 (i) f 2 (i). Then the relation of is a partial order (with the infimum and the supremum ), and (F, ) forms a complete lattice. For characterizing traces of variables, we define the combination of stretch functions as follows: Definition 8 (Combination of Stretch Functions). Let f 1, f 2 be two stretch functions. Let F = {m m N i N.f 1 (i) = m f 2 (i) = m}. Let m 0, m 1,..., m n,... be the sorted sequence of elements of F in increasing order (or m 0, m 1,..., m n if F is finite). Then the combination of f 1 f 2 is defined as follows: if F is infinite, then i N.(f 1 f 2)(i) := m i, else i n.(f 1 f 2)(i) := m i i > n.(f 1 f 2)(i) := ℵ 0. The following lemma is simple to prove. Lemma 9. For f 1, f 2 Stretch, the following hold: f 1 f 2 Stretch, m F, there exist unique i, j, k such that for (f 1 f 2 )(i) = m one of the following cases holds: f 2 (k) = (f 1 f 2 )(i) f 1 (j) < f 2 (k) < f 1 (j + 1), f 1 (k) = (f 1 f 2 )(i) f 2 (j) < f 1 (k) < f 2 (j + 1), f 1 (j) = f 2 (k) = (f 1 f 2 )(i) For example, consider the following two stretch functions f 1, f 2 : the combination f 1 f 2 is: i f 1 (i) f 2 (i) i f 1 f 2 (i) III. PRESERVATION OF LOCAL LTL PROPERTIES In this section, we briefly discuss the preservation of local LTL properties, i. e. properties which are limited to a single synchronous component of a GALS system. As the following definitions and theorems will show, this corresponds to the classic result of stutter-free LTL. As all the variables in a component are synchronous, they are delayed in the same way. Thus, local properties see only a stuttering of the system. In the following, we formalize this fact by defining the notion of stretch equivalence, and based on this, we recall the result on the preservation of stutter-free LTL formulas. Definition 10 (Stretch Trace). Let V Σ be the set of variables of system K and t a trace of K. Then, a stretch trace is defined as: t : N V Σ B, so that i N. v V Σ.t(v, i) = t (i, v). Definition 11 (Stretch Equivalence). For two traces t x and t y of a given system and the set of system variables V Σ, the traces t x and t y are stretch equivalent if only if there exist two strictly monotonic functions f 1 and f 2 such that the following hold: Stretch(f 1) Stretch(f 2) i N.t x (f 1(i)) = t x (f 1(i) + 1) =... = t x (f 1(i + 1) 1) i N.t y (f 2(i)) = t y (f 2(i) + 1) =... = t y (f 2(i + 1) 1) i N.t x (f 1(i)) = t y (f 2(i)) t x and t y are stretch-equivalent is denoted as t x st t y. For example, the following two traces t 1, t 2 over variables {x, y} are stretch-equivalent: t 1 (x) : a a a a b b... t 1 (y) : b b a a b b t 2 (x) : a a a b b b... t 2 (y) : b a a b b b... Definition 12 (Stretch Equivalent Systems). A stretch equivalent system of K is a system S K such that t T (K). t T (S K ).t st t and t T (S K ). t T (K).t st t. Theorem 13 (Stutter-Invariant LTL Properties [9, 10]). For arbitrary traces x and y with x st y and every LTL property ϕ without X operators, we have x = ϕ if and only if y = ϕ. An LTL property without X operator defines exactly a set of stretch-equivalent traces. This defines stutter-equivalence in [9, 10]. Stutter-equivalent properties already cover a large set of useful properties. In particular, we can deduce from Theorem 13 that for a given system K and a stretch equivalent counterpart S K, for any stutter-invariant property ϕ, K = ϕ S K = ϕ. We denote the set of stutter-invariant properties by F st. In the context of a GALS system, stutter-invariant properties of synchronous components are preserved locally, i. e. in the synchronous components of the GALS system. Hence, local stutter-free properties can be verified for the original synchronous system, and they are still valid in the desynchronized implementation (as already stated in [1]). However, nothing is said about properties that relate outputs of several components which run asynchronously to each other. This question will be addressed in the following. IV. PRESERVATION OF GLOBAL LTL PROPERTIES In this section, we study the preservation of global LTL properties, i. e. properties which contain variables of different components of the GALS system. Thus, variables are now delayed differently. In Section IV-A, we only use the flow equivalence of traces which models that the delays in our desynchronized system may change the timing of events, but never change the sequence of actual values. As we will see, 56

5 this notion of equivalence does not give us much power for preservation of properties. In consequence, we exploit the temperal ordering of flows of our desynchronization (Section IV-B). There are many events which are still partially ordered in the final implementation in particular, the sending of a value always occurs before its reception. This will finally lead to our main theorem (Theorem 27), which yields syntactic preservation constraints for global properties in desynchronized implementations. A. Flow Equivalence Let us first consider the preservation of properties under general flow equivalence in this subsection. Definition 14 (Flow Equivalent Variable Traces). For a system K with the set of variables V Σ, we say that two traces t p and t q are flow equivalent if there exist two functions f 1 and f 2 of N N + such that the following holds: Stretch(f 1) Stretch(f 2) i N.t p(f 1(i)) = t p(f 1(i) + 1) =... = t p(f 1(i + 1) 1) i N.t q(f 2(i)) = t q(f 2(i) + 1) =... = t q(f 2(i + 1) 1) i N.t p(f 1(i)) = t q(f 2(i)) The fact that t p and t q are flow equivalent is denoted as t p fl t q. Definition 15 (Flow Equivalent Traces). Two traces t x, t y of a given system K over the set of system variables V Σ are flow equivalent if and only if v V Σ.t x (v) fl t y (v). If the context is clear, we denote the fact that t x and t y are flow-equivalent as t x fl t y. For example, consider the following traces t 1, t 2 over variables {x, y}: t 1 (x) : a a a b b b... t 1 (y) : b b b a b b... t 2 (x) : a a a b b b... t 2 (y) : b a a b b b... It is clear that t 1 (x) fl t 2 (x) and t 1 (y) fl t 2 (y). As a result, t 1 fl t 2. It is easy to check that t 1 and t 2 are not stretch-equivalent. By Lemma 6 and Definition 3, it is easy to deduce the following corollary: Corollary 16. For traces t and t : t fl t i N.t(v, χ(t, v)(i)) = t (v, χ(t, v)(i)) Lemma 17. The flow-equivalence relation is an equivalence relation, i.e. for traces t x, t y, t z : t x fl t x, (t x fl t y ) (t y fl t x ), (t x fl t y ) (t y fl t z ) (t x fl t z ) For any trace t x of a system K, it yields a congruent set T tx (K), such that t x T tx (K).t x fl t x. We further define the set of flow-equivalent traces of T (K) as Flw(T (K)). Lemma 18. For a congruent set T t of traces t of a system K with V Σ as the set of system variables, there exists a unique trace u T t such that either i N. v V Σ.u(v, i) u(v, i + 1) or i 0. v V Σ.u(v, 0) u(v, 1)... u(v, i) j i.u(v, j) = u(v, j + 1). Based on the definition of flow equivalence, we define the properties that can be preserved in flow-equivalent traces as follows: Definition 19 (Elastic Property). An LTL property ϕ is elastic if for any traces t x and t y of a system, (t x fl t y ) (t x = ϕ t y = ϕ). We denote the set of elastic properties by F fl. Then, we conclude this section by the following theorem that characterizes the expressiveness of the X-free LTL for elastic properties: Theorem 20 (Elastic Properties). Let F prop be the set of formulas using only propositional logic, then we have: F prop F fl F st. In particular, elastic properties can be preserved under flowequivalent traces. Unfortunately, it is almost useless since the set of X- free LTL is not closed under U for elastic properties. For example, the formula (1Ua) is elastic: for any trace that satisfies (1Ua), it must be the case that somewhere in the time line a state at a particular time point satisfies a. No matter how the trace is stretched, it would not change this fact. However, the formula (aub) is not elastic but stutterinvariant. For example, consider the following two traces t 1, t 2 over variables {a, b}: t 1 (a) := a a a ā ā... t 1 (b) := b b b b b... t 2 (a) := a a a ā ā... t 2 (b) := b b b b b... It is clear that t 1 fl t 2, but while t 1 = aub, t 2 aub Hence, we lose the operator U to specify temporal properties in the context of flow equivalence. B. Temporal Ordering of Traces In the previous section, we saw that flow equivalence alone does not help much to guarantee the preservation of LTL properties. Therefore, we refine our approach by taking orders of data-flows into consideration. The idea behind this is to exploit the fact that the streams are not arbitrarily desynchronized but that a delay of some event E 1 leads to at least the same delay of another one E 2 if E 2 depends on E 1 in some way. In the following, we show how to determine for a given LTL property a somehow minimal set of constraints a desynchronization must respect for its preservation. Thus, we aim at finding the most general desynchronization that still preserves the validity of the property. We illustrate the idea with the help of the following example: t a := a a a ā ā ā ā... t b := b b b b b b b b b... 57

6 t a := a a ā ā ā ā... t b := b b b b b b b b b... t t a := a a a a ā ā ā ā... b := b b b b b b b b b... For a given system trace t, t a = t(a) and t b = t(b) are the traces of the variables a and b. It is simple to check that t = aub holds. As we already saw in the previous section, arbitrary delays break the validity of this property, e. g. for t = del(t, a, 1), the property is not preserved. In contrast, for t = dup(t, a, 1) the formula still holds, and in fact, it is clear that for any k > 0, t = dup k (t, a, 1), the formula always holds. Thus, as long as we can ensure that events of signal a are always delayed more than those of b, the property can be preserved. Thus, once we know the relative delay of variables, we could ensure property preservation while loosening the synchronization. Let us now define how we can determine the set of desynchronization constraints, such that the LTL formula is preserved under these constraints. To this end, we define an order on variable traces. As already stated in the introduction, variables in a synchronous system are synchronized in each macro step, and all computations of a macro step are done in zero time. In the implementation, this paradigm means that all computations are executed according to the data dependencies which has the same effect. Thus, there is a natural order of variables in a synchronous system which must be also respected in any GALS implementation. Assume that we have a synchronous system with variables a and b, and assume that there is a data dependency from a to b (e. g. due to the assignment b = a). In a desynchronized system, the events on a and b do not have to occur at the same time. However, all events of b can be only delayed more than the ones of a, the opposite case is not possible. Definition 21 (Order of Variables Traces). Let t be a trace of system K, and t a trace in its desynchronized counterpart such that t fl t. Let v 1, v 2 V Σ be two variables. The variable v 2 is said to be delayed with respect to v 1, denoted by v 1 v 2, if the following holds: i, j N.χ(t, v 1 )(i) χ(t, v 2 )(j) χ(t, v 1 )(i) χ(t, v 2 )(j). For v 1 v 2 v 2 v 1 we denote that v 1 v 2. Lemma 22. Let t be a trace of a given system K and t fl t, the delay relation of variables for a trace t with respect to t is a partial order. For two variables x y if only if t {x,y} st t {x,y}. The order of traces of variables can be extended naturally for all traces of a system, i. e. for system K and its variables V Σ, and two variables a, b V Σ with t T (K).a b, we say that b is delayed with respect to a in system K. If the context is clear, we still denote it by a b. We can even extend the order to LTL formulas: Let V (ϕ) be the set of free variables appearing in LTL formula ϕ. For two LTL formulas ϕ and ψ, ϕ ψ x V (ϕ), y V (ψ).x y and ϕ ψ x V (ϕ), y V (ψ).x y. C. Directions of LTL Properties Before considering property preservation, we first introduce some attributes of LTL properties under the context of flow equivalence. In synchronous traces, all the variables are synchronously aligned. Now as we know the order of the variables, we know their relative delays. One variable is delayed w. r. t. another one means that we defer events relative to the other one by repetition (dup operation), i. e. it is moved forward on the timeline. Performing such moves obviously has an influence the validity of a property: either it is violated or the moves are within a range of tolerance. In the following, we develop an analysis that determines this range, given as variable ordering constraints. If the given desynchronized system complies with these orders, we are sure that the property is preserved otherwise, we do not promise anything. Definition 23 (Directions of LTL Formulas). Let F LTL be the set of X-free LTL-formulas and ϕ F LTL. Let Σ be the domain of variables and s Σ be a finite sequence of words over Σ:s 0, s 1,..., s m. Let t : t 0, t 1,... Σ ω be an infinite sequence of words. Then st Σ ω is an infinite sequence of words derived from the concatenation of s and t: s 0,..., s m, t 0,.... We define the domain of directions of LTL-formulas as DIRECT := {Invalid, Valid, Fix, Period, FwdDir, BckDir, BiDir}, where each element of DIRECT is a subset of F LTL defined as follows: Let L ϕ be the language satisfying ϕ, Valid := {true} Invalid := {false} Fix := F prop Period := F st FwdDir := {ϕ s L ϕ.s = s s.s Σ.s L ϕ } BckDir := {ϕ s L ϕ. s Σ.ss L ϕ } BiDir := FwdDir BckDir The set Fix refers to the propositional formulas. For a propositional formula ϕ, we know that it holds for a particular point of time, but it is not clear if it holds for any other points of time. Period refers to those formulas that usually hold in consecutive time points. For example, for a, b V Σ, [aub] Period. Once valid, we know that from the starting time of a until the starting time of b the formula remains valid. BckDir (backward-directed) is the set of formulas that once we know it holds for a particular time point, we can deduce for all the time points before the time it holds, the formula still holds, so the validity of the formula is backward-directed closed on the time line. For example, Fa BckDir. Similarly for the set FwdDir, the formulas are forward-directed closed on the time line. For example Gb FwdDir. BiDir is the set of formulas that once valid, we know the validity holds both forward the time line and 58

7 Figure 2. Lattice L backward the time line, so it is bidirectional-directed closed on the time line. An example for BiDir is (Fb U Ga). It is obvious that F LTL = P DIRECT P and that the following relations hold for the elements of Directs: BiDir FwdDir Period, BiDir BckDir Period, Fix Period. In [8] definitions (left-append closed, suffix closed etc.) similar to the directions we defined here were introduced, but were used to optimize automata. Here we use this abstract domain to explore more freedom in system synchronization. Before we give the details about the computation of directions for a given LTL formula, we make some auxiliary definitions. First, we extend our LTL syntax by adding the B (before) operator as syntactic sugar: [ϕ B ψ] [ ϕ U ψ]. Using the B operator, we can demand that operators are only applied to propositional variables which implies a negation normal form of LTL formulas. Second, we define L : (DIRECT,, Invalid, Valid), a lattice over the directions as shown by its Hasse diagram in Figure 2. Valid and Invalid are the minimum and maximum of the lattice, and are the meet and join operations. Now, we are in the position to compute the direction of a given formula. Let τ F LTL be an arbitrary LTL formula without X in negation normal form, then the following function D : F LTL DIRECT computes its direction. case(v Σ ) D(p) := Fix if p V Σ case(true) D(true) := Valid case(false) D(false) := Invalid case(ϕ ψ) D(ϕ ψ) := D(ϕ) D(ψ) case(ϕ ψ) D(ϕ ψ) := D(ϕ) D(ψ) case(τ = ϕuψ) D(ϕUψ) := (p(d(ϕ))) BckDir) p(d(ψ)) where p : DIRECT DIRECT, { Period x = Fix p(x) := x otherwise case(ϕbψ) D(ϕBψ) := (p(d(ϕ)) FwdDir) p(d(d(ψ))) where d : DIRECT DIRECT, BckDir x = FwdDir d(x) = FwdDir x = BckDir and p as above. x otherwise The following lemma justifies the soundness of our definition D, i. e. the computed direction is correct. Lemma 24. P DIRECT.D(ϕ) = P ϕ P for all formulas ϕ of F LTL. The function D computes a conservative approximation of the direction of a formula. Suppose the precise direction of ϕ is defined by function: D prec : F LTL DIRECT where D prec (ϕ) = P ( P DIRECT.ϕ P P P). Then we have D(ϕ) = P D prec (ϕ) P. The imprecision is due to the computation based on the syntax of LTL. For example, for ϕ = G(a) F(a) the direction is obviously D prec (ϕ) = BiDir but our computation returns D(ϕ) = Period which is a conservative approximation. A more precise computation demands a careful examination of the semantics of formulas, which we found impractical for an implementation. D. Move Constraints The directions of LTL properties gave us the possible directions to move an LTL property on the time line. We denote K, i = ϕ meaning for all traces of K, ϕ holds at position i. For example, if we know K, i = ϕ and D(ϕ) = BckDir, we may delay ϕ by an arbitrary number of steps. Due to i i, K, i = ϕ, the validity of ϕ is preserved, although ϕ may be delayed. Thus, provided that ϕ holds in the synchronous model, it also holds in the desynchronized implementation. For implementing the delay of ϕ, we can delay all variables v V (ϕ). However, such a synchronized delay of variables in the desynchronized system creates further constraints for the orders of variables in V (ϕ). For example, consider ϕ = au(f(b c)) where a, b, c are propositional variables, we compute the direction of F(b c) as D(F(b c)) = D(trueU(b c)) = (p(d(true)) BckDir) (p(d(b c))) = (p(valid) BckDir) (p(d(b) D(c))) = (Valid BckDir) (p(fix Fix)) = BckDir (p(fix)) = BckDir Period = BckDir so that we may delay F(b c) from a and expect that ϕ still holds. We do this by implementing a desynchronization w. r. t. the order a b and a c. However, if b c, it is clear that F(b c) does not hold any more which invalidates ϕ. A simple solution would be to restrict the delayed 59

8 variables to be stretch equivalent, so that the validity of the delayed formula remains. But this is unnecessarily strict. Consider another example ϕ = au(fb Fc), where it is easy to check that D((Fb Fc)) = BckDir, D(Fb) = BckDir and D(Fc) = BckDir. Then for delaying the formula Fb Fc from a, it is enough that only a b a c holds and b c is not necessary. In the following, we call the constraints that the set of variables of a formula must satisfy during its movement move constraints. The examples discussed above give rise to a more sophisticated analysis of the orders of variables for the delay of a formula. In particular, we need to ensure the validity of the formula during the variable movement on the timeline which is closely related to the direction of the formula. In the following, we first define an abstract concept of desynchronization of a system in terms of orders of variables. We then discuss the constraints of variable orders for preserving an LTL property while moving the variable events on the time line. Definition 25 (Desynchronization of a System). Let K be a system with the set of variables V Σ. Let C be a set of variable delay relations. Then D K is a desynchronized system of K with regard to C if it satisfies the following conditions: t T (K). t T (D K ). t fl t, t T (D K ). t T (K). t fl t, for a, b V Σ, a b C, t T (D K ). a b. We denote the desynchronized system obeying constraints C as the tuple (D K, C). The direction of a formula generates constraints for other formulas when they are composed. We can then decide how to move the formula based on the constraints they have. In general, if we are given a formula τ: τ := ϕ ψ (or τ := ϕ ψ): The propositional operator indicates that there is a single point of time where τ holds, so either when it is moving forward or backward, we need to keep the existence of this single time point. When both ϕ and ψ are Fix or Period, they should be synchronized. However, if one of them has a more relaxed direction, then we can move the other one freely along the allowed direction. τ := ϕuψ: τ is at least in Period. For τ it is easy to keep its validity as long as ψ holds at some point of time. This means that we can move ϕ freely regardless of ψ. However, if τ can only be moved backwards (which means moving a step forward might break the validity of the outer formula), then we should keep the formula hold for the very beginning time point. For example: t c := c c c c... t a := ā ā ā a a a a... t b := b b b b b b b b... t t t t c := c c c c... t a := ā ā a a a... t b := b b b b b... c := c c c c... a := ā ā a a a... b := b b b b b b b b... t and t are two desynchronized versions of trace t, where in t a c b c b a and in t a c b c a b. For the formula cu(aub), we can only move (aub) backwards. However, t does not preserve τ while t preserves it. In this case, besides a c b c, b a, it is also needed to ensure the validity of the whole formula. In general, we take a stronger constraint so that ϕ is always delayed as given by ψ. τ := ϕbψ: If ψ is valid at some point i, then there must be a time j that ϕ ψ holds, This excludes the possibility that D(ψ) is BckDir or BiDir. Or if it is one of the cases, we are sure that ψ never occurs. We then need to consider ϕ only. Otherwise, ψ should be synchronous with ϕ. As if we delay ϕ, it might be the case that ϕ happens after ψ. If we delay ψ, as we are not sure what happens before the time τ := ϕbψ holds, it might also violate the truth of the whole formula. Based on these informal considerations, we define the function C M for the computation of the move constraints as given in Figure 3. Lemma 26 (Move Constraints). For a system K with the set of variables V Σ, and an LTL formula ϕ, the move constraints of ϕ as computed by C M (ϕ) is the set of delay relations of V Σ, and i N.K, i = ϕ i N.(D K, C M (ϕ)), i = ϕ holds. This lemma simply states that the desynchronized system under the constraints keeps the validity of the formula in the time line. E. Initial Point of Time Now we have the function C M for computing the constraints of a formula for its movement, and it can be used to compute the preservation of an LTL formula. However, it overestimates the constraints, since it always assumes that a formula can be moved backwards on the timeline. This is not the case for a formula that holds at the initial point of time. For example, for any elastic property ϕ, for any constraint of orders of variable C, it is always the case that K = ϕ (D K, C) = ϕ. It means that there is no constraint for the variables of V (ϕ). As D(ϕ) = Fix, all the variables of V (ϕ) should be stretched equivalently to each other according to C M (ϕ). This is an unnecessarily strict constraint for preserving ϕ. Since we already know that ϕ holds initially, as the variable assignments can only be copied forward on the timeline, a delay of any variable 60

9 C M (p V Σ ) := C M (ϕ ψ) := case(d(ϕ)) : Fix, Period : case(d(ψ)) : Fix, Period : {V (ϕ) V (ψ)} BckDir : {V (ϕ) V (ψ)} C M (ϕ) C M (ψ) FwdDir : {V (ψ) V (ϕ)} C M (ϕ) C M (ψ) BiDir : C M (ϕ) C M (ψ) BckDir : case(d(ψ)) : FwdDir : {V (ϕ) V (ψ)} Fix, Period : C M (ψ ϕ) BckDir, BiDir : C M (ϕ) C M (ψ) FwdDir : case(d(ψ)) : BckDir : {V (ϕ) V (ψ)} Fix, Period : C M (ψ ϕ) FwdDir, BiDir : C M (ϕ) C M (ψ) C M (ϕ ψ) : dual to C M (ϕ ψ) C M (ϕuψ) := case(d(ϕ)) : BckDir, Period, Fix : case(d(ψ)) : FwdDir, Period, Fix : {V (ψ) V (ϕ)} C M (ϕ) C M (ψ) BckDir, BiDir : C M (ϕ) C M (ψ) FwdDir, BiDir : C M (ϕ) C M (ψ) C M (ϕbψ) := case(d(ψ)) : FwdDir, Fix, Period : {V (ϕ) V (ψ)} BckDir, BiDir : C M (ψ) C M (G(ϕ)) := case(d(ϕ)) : Period : {V (ϕ) V (ϕ)} default : C M (ϕ) C M (F(ϕ)) := C M (ϕ) Figure 3. Computing move constraints of V (ϕ) will not influence the validity of the variable at the initial point of time, thus the property remains valid. Nevertheless, if ϕ holds somewhere in the middle of the timeline, then it is possible that by delay of some variable the variable assignments will not remain the same at any point of time, thus the validity of ϕ might be lost. In the following, we refine our approach by defining a function C H that calculates the constraint for a formula by taking the initial time point into consideration: C H (p V Σ ) := C H (ϕ ψ) = C H (ϕ ψ) := C H (ϕ) C H (ψ) C H (ϕuψ) := case(d(ϕ)) : Fix, Period, FwdDir : (V (ψ) V (ϕ)) C H (ϕ) C M (ψ) BckDir, BiDir :C H (ϕ) C M (ψ) C H (ϕbψ) := case(d(ϕ)) : Fix, Period, FwdDir : (V (ϕ) V (ψ)) C M (ϕ) (V (ψ) V (ψ)) BckDir, BiDir : C M (ϕ) C H (G(ϕ)) := C M (G(ϕ)) C H (F(ϕ)) := C M (F(ϕ)) For any formula ϕ that is valid in a synchronous system, once a corresponding desynchronization satisfies the constraints computed by C H (ϕ), ϕ can be preserved. The correctness of our approach is guaranteed by the following theorem, which concludes the computation of desynchronization contraints for a given LTL property. Theorem 27 (LTL Property Preservation). Let K be a system with variables V Σ, and let ϕ F LTL be an LTL property. If K = ϕ, then (D K, C H (ϕ)) = ϕ With the help of Theorem 27, we can answer the two questions that we raised in the introduction. Given a synchronous system S, an already verified LTL property ϕ and a desynchronization of S, will ϕ hold in the desynchronization? Since we have a concrete desynchronization, we know which variables are in the same local (synchronous) part. To check the preservation for ϕ, we first compute the directions and move constraints of ϕ which only contain variables of local part. If the resulting constraints are fulfilled by the desynchronization, the property is preserved. Given a synchronous system S and an already verified LTL property, will ϕ be preserved in any desynchronized implementation of S? In principle, the approach is exactly the same as in the previous case, in particular the computation of the desynchronization constraints. The only thing that is different is the last step. Instead of a concrete desynchronization, we check the computed constraints against a maximally desynchronized implementation, i. e. a system where any pair of variables does not belong to the same local (synchronous) part. F. Example Consider the synchronous system given in Figure 4. The lefthand side of the figure depicts the structure, and the righthand side shows a list of LTL properties, which have already been verified for the system. As our approach does not use 61

10 ϕ 1 = G(x 1 x 2 ) F(y 1 y 2 ) ϕ 2 = GF(y 1 ) GF(y 3 ) ϕ 3 = G(y 2 F(z 1 )) ϕ 4 = ((y 1 B z 1 ) (y 2 B z 1 )) ((y 1 B z 1 ) (y 3 B z 1 )) Figure 4. A synchronous system and the corresponding validated properties the internals of the components, we do not give more details about the example system. Now we compute the constraints of the properties as described above. For example, for the first property: C H (G(x 1 x 2 ) F(y 1 y 2 )) = C H (F( x 1 x 2 ) F(y 1 y 2 )) = C H (F( x 1 x 2 )) C H (F(y 1 y 2 )) = C M (F( x 1 x 2 )) C M (F(y 1 y 2 )) = C M ( x 1 x 2 ) C M (y 1 y 2 ) We proceed with the directions D( x 1 ) = D( x 2 ) = Fix. Thus, we have: C M ( x 1 x 2 ) = {x 1 x 2 }. Furthermore, we also obtain C M (y 1 y 2 ) = {y 1 y 2 }. Hence, we have the following result for the first property: C H (ϕ 1 ) = {x 1 x 2, y 1 y 2 } For the three other properties, similar computations result to the following constraints: C H (ϕ 2 ) = {y 1 y 1, y 3 y 3 } C H (ϕ 3 ) = {y 2 y 2, z 1 z 1, y 2 z 1 } C H (ϕ 4 ) = {y 1 y 1, y 3 y 3, z 1 z 1, y 1 z 1, y 3 z 1 } With the help of these desynchronization constraints, we can check the preservation of the given LTL properties. For example, consider ϕ 1 : the given desynchronization (lefthand side of Figure 4) gives rise to the following ordering of streams {x 1 x 2, y 1 y 2,...} (we omit the remaining ones since they are irrelevant for the given properties). Comparing them to the computed set of constraints, we see that the first property demands that x 1 x 2 as well as y 1 y 2, which is not given in this desynchronization. Thus, this property may be violated. If we want to preserve it, the two components in the dashed block (see Figure 4) should work synchronously as the computed constraints suggest. V. SUMMARY This paper addressed the question whether a given LTL property ϕ, which has been proved for a given synchronous system K, is still correct in a given desynchronized implementation of K. We showed that classic stutter-invariant LTL properties are not a solution in this context, and that simply considering the flow-equivalence of traces in desynchronized systems does not give a useful result. Instead, our approach is built on two pillars: First, we consider the LTL property ϕ and compute how variables can be moved on satisfying paths without violating the property. The result is a set of constraints which define a temporal ordering of the variables occurring in ϕ. Second, we consider the partial order of the variables in the desynchronized system, which is a refinement of the data-flow dependencies of the synchronous system. If they comply with the computed set of constraints, the given LTL property can be preserved. Moreover, if we only consider the data dependencies, we can even prove that a given LTL property is preserved by any desynchronization. This paper focuses on checking the preservation of properties for a given desynchronization (or alternatively, for all desynchronizations). In our future work, we plan to use the results of this paper to implement a correct-by-construction desynchronization procedure which only desynchronizes a synchronous system such that the already verified LTL properties are preserved. REFERENCES [1] A. Benveniste, B. Caillaud, and P. Le Guernic. Compositionality in dataflow synchronous languages: Specification and distributed code generation. Information and Computation, 163: , [2] A. Benveniste, P. Caspi, S. Edwards, N. Halbwachs, P. Le Guernic, and R. de Simone. The synchronous languages twelve years later. Proceedings of the IEEE, 91(1):64 83, [3] L.P. Carloni, K.L. McMillan, and A.L. Sangiovanni- Vincentelli. Theory of latency-insensitive design. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems (T-CAD), 20(9): , [4] J. Carmona, J. Cortadella, M. Kishinevsky, and A. Taubin. Elastic circuits. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems (T-CAD), 28(10): , October [5] J. Cortadella, M. Galceran-Oms, and M. Kishinevsky. Elastic systems. In L. Carloni and B. Jobstmann, editors, Formal Methods and Models for Codesign (MEMOCODE), pages , Grenoble, France, IEEE Computer Society. 62

11 [6] J. Cortadella, A. Kondratyev, L. Lavagno, K. Lwin, and C.P. Sotiriou. From synchronous to asynchronous: An automatic approach. In Design, Automation and Test in Europe (DATE), pages , Paris, France, IEEE Computer Society. [7] F. Doucet, M. Menarini, I.H. Krüger, R. Gupta, and J.- P. Talpin. A verification approach for GALS integration of synchronous components. Electronic Notes in Theoretical Computer Science (ENTCS), 146(2): , [8] K. Etessami and G.J. Holzmann. Optimizing Büchi automata. In C. Palamidessi, editor, Concurrency Theory (CONCUR), volume 1877 of LNCS, pages , University Park, Pennsylvania, USA, Springer. [9] D. Peled and T. Wilke. Stutter-invariant temporal properties are expressible without the next-time operator. Information Processing Letters, 63(15): , September [10] D.A. Peled. Combining partial order reductions with on-the-fly model-checking. Formal Methods in System Design (FMSD), 8(1):39 64, [11] D. Potop-Butucaru and B. Caillaud. Correct-byconstruction asynchronous implementation of modular synchronous specifications. In Application of Concurrency to System Design (ACSD), pages 48 57, Saint- Malo, France, IEEE Computer Society. [12] D. Potop-Butucaru, B. Caillaud, and A. Benveniste. Concurrency in synchronous systems. In Application of Concurrency to System Design (ACSD), pages 67 76, Hamilton, Ontario, Canada, IEEE Computer Society. [13] D. Potop-Butucaru, B. Caillaud, and A. Benveniste. Concurrency in synchronous systems. Formal Methods in System Design (FMSD), 28(2): , [14] D. Potop-Butucaru, R. de Simone, and Y. Sorel. Necessary and sufficient conditions for deterministic desynchronization. In C.M. Kirsch and R. Wilhelm, editors, Embedded Software (EMSOFT), pages , Salzburg, Austria, ACM. [15] S. Ramesh, S. Sonalkar, V. D Silva, N. Chandra, and B. Vijayalakshmi. A toolset for modelling and verification of GALS systems. In R. Alur and D.A. Peled, editors, Computer Aided Verification (CAV), volume 3114 of LNCS, pages , Boston, Massachusetts, USA, Springer. [16] K. Schneider. A verified hardware synthesis for Esterel. In F.J. Rammig, editor, Distributed and Parallel Embedded Systems (DIPES), pages , Schloß Ehringerfeld, Germany, Kluwer. [17] K. Schneider. Embedding imperative synchronous languages in interactive theorem provers. In Application of Concurrency to System Design (ACSD), pages , Newcastle Upon Tyne, England, UK, IEEE Computer Society. [18] K. Schneider. Proving the equivalence of microstep and macrostep semantics. In V. Carreño, C. Muñoz, and S. Tahar, editors, Theorem Proving in Higher Order Logics (TPHOL), volume 2410 of LNCS, pages , Hampton, Virginia, USA, Springer. [19] K. Schneider, J. Brandt, and T. Schuele. A verified compiler for synchronous programs with local declarations. Electronic Notes in Theoretical Computer Science (ENTCS), 153(4):71 97,