Formal Synthesis and Code Generation of Embedded

Formal Synthesis and Code Generation of Embedded Software Using Extended Quasi-Static Scheduling Feng-Shi Su

A Thesis Submitted To Institute of Computer Science and Information Engineering College of Engineering National Chung Cheng University For The Degree of Master in Computer Science and Information Engineering 2002

Abstract

Software in an embedded system is often specified as a set of concurrent reactive tasks to be executed under certain architectural constraints such as maximum memory bound. To implement embedded software, concurrent tasks need to be scheduled on some shared resources such as a processor and memory. Data-dependent control structures such as ifthen-else or for constructs and the dynamic behaviors of a system cannot be completely predicted at compile time and some scheduling decisions are to be made at run-time. We consider the problem of formally synthesizing embedded software from a specification of concurrent tasks, modelled by our proposed models with memory constraints. In contrast to previous work, we allow the occurrence of branch and concurrency on the same transition in the system model, which we call Complex-Choice Petri Nets (CCPNs). A larger of class of more general applications can be covered by our model and approach. We present an Extended Quasi-Static Scheduling (EQSS) algorithm that generates a schedule in which run-time decisions are made only for more complex data-dependent control structures than in Quasi-Static Scheduling (QQS). We use the CCPNs as system models and define the schedulability for CCPNs. We have implemented our EQSS method into an embedded software synthesis tool, which allows a designer to specify software requirements in the CCPN model and the size of available memory space. The tool automatically synthesize embedded software and generate the corresponding code. Finally, we use some examples to illustrate how to synthesize quasi-static schedules and to generate embedded software in C/C++.

Keyword: embedded software, Complex-Choice Petri Nets, extended quasi-static scheduling, code generation

1

Contents

1 Introduction 1.1

1.2

1

Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.1.1

Embedded System . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.1.2

System Model Extension . . . . . . . . . . . . . . . . . . . . . . .

3

1.1.3

Scheduling Method Extension . . . . . . . . . . . . . . . . . . . .

3

Embedded System Design . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2 Previous Work

8

3 Embedded Software Synthesis 3.1

3.2

11

System Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1.1

Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.2

Complex-Choice Petri Nets . . . . . . . . . . . . . . . . . . . . . 12

Cyclic Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2.1

Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.2

Implementation of Cyclic Schedules . . . . . . . . . . . . . . . . . 17 i

3.3

Problem Formulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.4

Synthesis Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.4.1

Extended Quasi-Static Scheduling . . . . . . . . . . . . . . . . . . 21

3.4.2

Code Generation with Multiple Threads . . . . . . . . . . . . . . . 27

4 Application Examples

31

4.1

Master/Slave Role Switch in the Bluetooth Protocol . . . . . . . . . . . . . 31

4.2

Motor Speed Control System . . . . . . . . . . . . . . . . . . . . . . . . . 41

5 Conclusions & Future Work

46

Bibliography

47

ii

List of Figures 1.1

Complex-Choice Petri Net (CCPN) Model for Part of an Automatic Cruise Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

3.1

(a) CFPN, (b) CCPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2

(a) Concurrency, (b) Synchronization, (c) Choice . . . . . . . . . . . . . . 14

3.3

Cyclic schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.4

(a) Schedulable net, (b) Unschedulable net . . . . . . . . . . . . . . . . . . 19

4.1

CCPN model of Host A in Bluetooth M/S Role switch . . . . . . . . . . . 35

4.2

CCPN model of Host Control/Link Manager of Device A in Bluetooth M/S Role switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.3

CCPN model of Host B in Bluetooth M/S Role switch . . . . . . . . . . . 37

4.4

CCPN model of Host Control/Link Manager of Device B in Bluetooth M/S Role switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.5

Main Module of Motor Speed Control System . . . . . . . . . . . . . . . . 42

4.6

Interrupt 0 of Motor Speed Control System . . . . . . . . . . . . . . . . . 43

4.7

Interrupt 1 of Motor Speed Control System . . . . . . . . . . . . . . . . . 44 iii

List of Tables 3.1

Extended Quasi Static Algorithm . . . . . . . . . . . . . . . . . . . . . . . 23

3.2

Extended Quasi Static Scheduling Algorithm (continued) . . . . . . . . . . 24

3.3

Code Generation Algorithm for EQSS . . . . . . . . . . . . . . . . . . . . 29

3.4

Code Generation Algorithm for EQSS (continued) . . . . . . . . . . . . . . 30

4.1

Scheduling Results for Bluetooth M/S Role Switch . . . . . . . . . . . . . 39

4.2

Variables used in Bluetooth M/S Role Switch Model . . . . . . . . . . . . 40

4.3

Scheduling Results for Main Module of Motor Speed Control System (MSCS) 43

4.4

Scheduling Results for Interrupt T0 of Motor Speed Control System (MSCS) 44

4.5

Scheduling Results for Interrupt T1 of Motor Speed Control System (MSCS) 45

iv

Chapter 1 Introduction In the recent few years, there has been a proliferation of embedded systems into our daily lives in the form of home appliances, internet appliances, personal assistants, wearable computers, telecommunication gadgets, and transportation facilities among numerous others. Flexibility and complexity in such embedded systems are growing rapidly with increasing needs of the human.

1.1 Motivation The previously mainly hardware ASIC-based embedded system has now evolved into a hardware-software system, with a microprocessor that executes software accounting for more than 70% of system functions. Software has enhanced the accessibility, testability, and flexibility of embedded systems, but along with these advantages the inherent complexity of software often introduces design errors that increase maintenance costs. To ensure the correctness of software designs in an embedded system, formal methods are being adopted successfully for embedded software design. Nevertheless, the type of systems that can be modelled and synthesized was fairly restricted in several previous works, thus the aim of

1

this work is to remove model restrictions such that a larger domain of applications can be modelled and synthesized. In this work, after extending the model coverage, we propose and implement a method for synthesizing the modelled software applications. Finally, a code generator automatically produces embedded software code in the C programming language.

1.1.1 Embedded System For a precise comprehension of our target of synthesis, that is, embedded software, we first briefly give an overview of the embedded system in which it is installed.

Definition 1.1 : Embedded System An embedded system is a computation unit, installed in a larger environment system, such that it helps the environment accomplish some dedicated set of tasks.

k

Some examples include avionics flight control, vehicle cruise control, washing machine fuzzy control, and network-enabling devices in home appliances such as embedded web servers. In general, an embedded system architecture has both hardware and software parts. Hardware is fabricated as one or more ASICs, ASIPs, or PLDs. Software is executed on one or more microprocessors, with or without an operating system. Embedded software is a piece of program code that must satisfy memory-size constraints and concurrent task requirements with precedence constraints. Embedded software communicates with the embedded hardware either through an interface or through direct connections between a microprocessor and a hardware logic.

2

1.1.2 System Model Extension The functions that an embedded software is required to perform are generally specified as a set of communicating concurrent tasks, where each task is a sequential process. Since Petri nets (introduced later in Section 3.1) are a semantically precise model for several desirable common system properties such as concurrency, branching, synchronization, and mutual exclusion, previous works on software synthesis were mainly based on a subclass of the Petri net model. We also adopt the Petri net model for software requirements specification, but we remove restrictions from previously used models. As a motivating example, consider the Petri net model for part of an Autonomous Cruise Controller (ACC) [9] depicted in Figure 1.1. There are two sensors in ACC, one of which periodically senses the distance between a preceding vehicle and the vehicle in which ACC is installed, and another periodically senses the speed limit of the road on which the vehicle is currently moving. Based on these sense data, there is a choice of decision on whether to decelerate or accelerate the vehicle with ACC. This choice is not a free one (as in Free-Choice Petri Nets), thus the software for such a system cannot be modelled and synthesized by previous works which have the Free-Choice restriction imposed on the system model.

1.1.3 Scheduling Method Extension Non-free choices appear often in many embedded systems, thus removing the restriction significantly expands the domain of applications that can be modelled and synthesized. However, with the enhancement in model expressiveness, synthesis becomes more complicated. We propose an Extended Quasi-Static Scheduling (EQSS) method for the synthesis of embedded software that are modelled using Complex-Choice Petri Nets (CCPN). Fur-

3

Figure 1.1: Complex-Choice Petri Net (CCPN) Model for Part of an Automatic Cruise Controller ther elaborations on the CCPN system model, our target problem, and the proposed EQSS method will be described in Sections 3.1, 3.3, and 3.4, respectively.

1.2 Embedded System Design Embedded system design requires the efficient use of limited resources to execute algorithms that consist of a set of concurrent tasks with complex mutual dependencies. An embedded system always has a limited amount of memory, thus we must ensure that all software and data fit into whatever memory exists. The tasks in an embedded system are often concurrent and are required to be scheduled. An implementation on a shared resource, the processor, requires a method to schedule the operation of the concurrent modules, while simultaneously (1) making use of the processor and memory resources as efficiently as

4

possible, and (2) satisfying real-time constraints. Thus, there is a need for practical formal software synthesis techniques for implementing embedded systems. There are two classes of scheduling: static and dynamic. Static means a schedule is pre-computed at compile time and dynamic means the schedule is determined at run-time by an operating system, that detects which tasks are to be executed and determines when they are fired. Static scheduling could be predictable, so we could estimate the maximum code size and memory requirement at compile time, but it cannot be used to implement an embedded system that requires run-time decisions with control structures. In general, control structures consist of either data-dependent controls, such as if-then-else and for constructs, or real-time controls, such as suspension and preemption. On the other hand, it is inefficient to use fully dynamic approach because the run-time overhead becomes significant especially when task invocations are frequent and the execution time of a single task is small. Sgroi et al [22] has proposed a Quasi-Static Scheduling algorithm to mix static and dynamic scheduling, but it can not allow the occurrence of branch and concurrency on the same transition in the system model. In order to solve the problem, we extend the system model and propose an Extended Quasi-Static Scheduling algorithm. Our algorithm consists of dataflow and data-dependent control structures, but does not contain time constraints. The EQSS algorithm takes a graph including dataflow and data-dependent control structures as an input, and generates a C/C++ program that satisfies system requirements and memory constraints. A resolution of a control is still made at run-time, because the value of data is set at run-time and tasks could be sequentially scheduled at compile-time. EQSS computes most schedules at compile-time, leaving at run-time only the solution of data-

5

dependent decisions. EQSS also partitions the functionality of the specification into tasks. General real-time techniques need to decide schedules at run-time. This type of schedules is called dynamic. An ideal scheduling technique should use: (1) static scheduling to exploit fixed dependencies between blocks of operations, (2) extended quasi-static scheduling to identify and schedule data-dependent operations with independent firing rates, and (3) dynamic scheduling to determine which tasks are to be executed. EQSS extends previously proposed quasi-static scheduling (QSS) [22] by handling non-free choices (or complex choices) that appear in CCPN models. Further, EQSS also ensures that limited embedded memory constraints are satisfied. For feasible schedules, embedded software code is generated as a set of communicating POSIX threads, which may then be deployed for execution by a Real-Time Operating System (RTOS). An application example on a master/slave switch software driver for Bluetooth wireless communication devices will illustrate the feasibility and benefits of our proposed method. In this Thesis, we use Complex-Choice Petri Nets (CCPNs) as our models, which allow us to express concurrent, non-deterministic choices and synchronization conditions and allow the occurrence of branch and synchronization on the same transition in the system model. Data-computing is represented by a type of nodes called transitions. Channels which do not have the FIFO property between computing units, are represented by another type of nodes called places. Data are represented as tokens, which are passed by transitions through places. CCPNs are appropriate to model computations in which the outcome of a choice depends on the value rather than on the arrival time of a token. The rest of this Thesis is organized as follows. Chapter 2 describes previous work related to embedded software synthesis. Chapter 3 presents our embedded software syn-

6

thesis method which includes CCPN model and EQSS algorithm. Chapter 4 gives two examples: Bluetooth Master/Slave Role switch and Motor Speed Control System to illustrate our method. Chapter 5 concludes the Thesis with future work.

7

Chapter 2 Previous Work In the past, a large number of efforts was directed towards hardware synthesis and comparatively little research were directed towards software synthesis. Partial software synthesis was mainly carried out for communication protocols [19], plant controllers [18], and real-time schedulers [1] because they generally exhibited regular behaviors. Only recently has there been some work on automatically generating software code for embedded systems [17, 22, 25, 2], including commercial tools such as MetaH from Honeywell. In the following, we will survey the existing works on the synthesis of embedded software, on which our work is based. Bhartacharyya [3] have reviewed the state-of-the-art in programming language and compiler technology for DSP (digital signal processing) software implementation. In particular, they review techniques for high-level block-diagram-based modelling of DSP applications. Raithel [21] have addressed the problem of trading off between the minimization of program and data memory requirements of single-processor implementations of dataflow programs. Based on the formal model of synchronous dataflow (SDF) graphs [16], so-called single appearance schedules are known to be program-memory optimal. van

8

Bokhoven [24] have discussed software synthesis for a realistic system level design language, to generate an executable model for implementation, simulation and verification purposes and have shown a completely automatic mapping of both the architectural aspects and data objects including real-time garbage collection. Thoen [23] have proposed the internal system-level model which capture the embedded software and which is the backbone of our software synthesis methodology. The model captures the fine-grain behavior of a system, and supports multiple threads of control (concurrency) , synchronization, data communication, hierarchy and timing constraints. Hsiung [14] proposed a formal method based on Time Free-Choice Petri Nets (TFCPN) for Embedded Real-Time System (ERTS) synthesis. He uses quasi-static data scheduling for satisfying limited embedded memory requirements and uses dynamic real-time scheduling for satisfying hard real-time constraints. Hsiung [15] proposed a controller synthesis algorithm for design a controller of an embedded system and a periodic synthesis algorithm for obtaining optimal execution periods of real-time software tasks. Lin [17] proposed an algorithm that generates a software program from a concurrent process specification through intermediate Petri-Net representation. This approach is based on the assumption that the Petri-Nets are safe, i.e., buffers can store at most one data unit. The work of [6] is to propose the approach that maximizes the amount of static scheduling to reduce the need of context switch and operation system intervention. The work of [22] is related to ours but they cannot handle the condition, when conflict and synchronization occur on the same transition. A quasi-static algorithm was proposed for Free-Choice Petri Nets (FCPN) [22]. A necessary condition was given for FPCN to be schedulable. Schedulability was first tested for a FCPN and then a valid schedule generated by decomposing a FCPN into a

9

set of Conflict-Free (CF) components which were then individually scheduled. FCPN and CF will be defined in Section 3.1.2. Besides synthesis of software, there are also some recent work on the verification of software in an embedded system such as the Schedule-Verify-Map method [11], the linear hybrid automata techniques [10, 12], and the mapping strategy [8]. Recently, system parameters have also been taken into consideration for real-time software synthesis [13]. As introduced in Chapter 1, the current work mainly extends the work of Sgroi et al [22] by removing the free-choice restriction on the Petri model, by proposing an extended scheduling method for the unrestricted model, and by implementing a code generator that produces multithreaded embedded software code in the C programming language.

10

Chapter 3 Embedded Software Synthesis In our proposed software synthesis method, we use a system model as described in the following Section, which models user’s requirement.

3.1 System Model In order to synthesize embedded software and generate corresponding code, we need to first model user’s requirements. A system model must concisely represent a user’s requirements.

3.1.1 Preliminaries Transition is a type of nodes for representing data-computations. Place is a type of nodes for representing buffer or conditions. Given a node x, either a place or a transition, its preset is defined as • x = y|(y, x) ∈ F and its poset is defined as x• = y|(x, y) ∈ F . A transition (place) whose preset is empty is called source transition (place), a transition (place) whose poset is empty is called sink transition (place). A place p such that | p• |> 1 is called choice. If |• p |> 1 is called merge. A marking µ is an vector µ = (µ1 , µ2 , · · · , µn ) where n =| P | and µi is the non-negative number of tokens in place pi . A transition t such

11

that input place pi is marked with at least F (pi , t) tokens is enabled and may fire. When transition t fires, F (pi , t) tokens are removed from each input place pi and F (t, pj ) tokens are created into each output place pj . The following properties [20] are decidable for any Petri Net (PN). Deadlock-freedom: a PN is deadlock-free if, no matter what marking has been reached, it is possible to fire at least one transition of the net. Boundedness: a PN is said to be k-bounded if the number of the tokens in every place of a reachable marking does not exceed a finite number k. A safe PN is 1-bounded. Reachability: a marking µ0 is reachable from a marking µ if there is a firing sequence σ starting at µ and finishing at µ0 . Liveness: a PN is live if for every reachable marking and every transition t it is possible to reach a marking that enables t.

3.1.2 Complex-Choice Petri Nets Definition 3.1 : Complex-Choice Petri Nets (CCPN) A Complex-Choice Petri Net is a 4-tuple (P, T, F, M0 ), where: • P is a finite set of places, • T is a finite set of transitions, P ∪ T 6= ∅, and P ∩ T = ∅, • F : (P × T ) ∪ (T × P ) → N is a weighted flow relation between places and transitions, represented by arcs, where N is a set of nonnegative integers. The flow relation has the following characteristics. – Synchronization at a transition is allowed between a branch arc of a choice place and another independent concurrent arc. – Synchronization at a transition is not allowed between two or more branch arcs of the same choice place. 12

(a) Free-Choice Petri Net (FCPN)

(b) Complex-Choice Petri Net (CCPN)

Figure 3.1: (a) CFPN, (b) CCPN – A self-loop from a place back to itself is allowed only if there is an initial token in one of the places in the loop. • M0 : P → N is the initial marking (assignment of tokens to places).

k

Free-Choice Petri Nets (FCPNs) clearly distinct the notation between concurrency and choice. Complex-Choice Petri Nets (CCPNs) is different from FCPN because CCPNs allow the occurrence of branch and synchronization on the same transition. The difference between FCPNs and CCPNs can be seen in Figure 3.1. Graphically, a CCPN can be depicted as shown in Figure 1.1, where circles represent places, vertical bars represent transitions, arrows represent arcs, black dots represent tokens, and integers labelled over arcs represent the weights as defined by F . Here, F (x, y) > 0 implies there is an arc from x to y with a weight of F (x, y), where x and y can be a place or a transition. Conflicts 13

(a)

(b)

(c)

Figure 3.2: (a) Concurrency, (b) Synchronization, (c) Choice are allowed in a CCPN, where a conflict occurs when there is a token in a place with more than one outgoing arc such that only one enabled transition can fire, thus consuming the token and disabling all other transitions. The transitions are called conflicting and the place with the token is also called a choice place. For example, decelerate and accelerate are conflicting transitions in Figure 1.1. Our CCPN model can represent the following constructs: concurrency , synchronization and choice as shown in Figure 3.2. Concurrency means that several transitions may be concurrently enabled. It may be caused by one transition that products several tokens into several places to enable several transitions. Synchronization means that a transition t can be enabled if all the places in its preset, • t, have at least F (p, t) tokens. Free-Choice means that every transition that is successor of a choice place has exactly one predecessor place. This implies that whenever an output transition of a place is enabled, all the output transitions of that place are enabled.

14

Definition 3.2 : Loop When the same marking occurs more than once in a firing sequence, it is called a loop.

k

Intuitions for the characteristics of the flow relation in a CCPN, as given in Definition 3.1, are as follows. First, unlike FCPN, confusions are also allowed in CCPN, where a confusion is a result of synchronization between an arc of a choice place and another independently concurrent arc. For example, the accelerate transition in Figure 1.1 is such a synchronization. Second, synchronization is not allowed between two or more arcs of the same choice place because arcs from a choice place represent (un)conditional branching, thus synchronizing them would amount to executing both branches, which conflicts with the original definition of a choice place (only one succeeding enabled transition is executed). Third, at least one place occurring in a loop of a CCPN should have an initial token because our EQSS scheduling method requires a CCPN to return to its initial marking after a finite complete cycle of markings. This is basically not a restriction as can be seen from most real-world system models because a loop without an initial token would result in two unrealistic situations: • External trigger: The loop is triggered by a token produced by some external transition. Since it is a loop the token is never exhausted. For the case of most reactive embedded systems, a single triggering implies possibly infinite triggering, thus the number of tokens in the loop will increase unboundedly, resulting in an infeasible infinite amount of memory space requirements by the CCPN system model. • No trigger: The loop is never triggered because no external transition introduces any tokens into the loop and no transition within the loop is enabled for execution. There is thus unreachable or redundant computations in the system model. 15

Semantically, the behavior of a CCPN is given by a sequence of markings, where a marking is an assignment of tokens to places. Formally, a marking is a vector µ = (µ1 , µ2 , · · · , µn ) where n =| P | and µi , where mi is the non-negative number of tokens in place pi ∈ P . Starting from an initial marking µ0 , a CCPN may transit to another marking through the firing of an enabled transition and re-assignment of tokens. A transition is said to be enabled when all its input places have the required number of tokens, where the required number of tokens is the weight as defined by the flow relation F . An enabled transition need not necessarily fire. But upon firing, the required number of tokens are removed from all the input places and the specified number of tokens are placed in the output places, where the specified number of tokens is that specified by the flow relation F on the connecting arcs.

16

3.2 Cyclic Schedules Feasibility in embedded systems is often guaranteed through the well-known scheduling technique. If an embedded system is wrongly scheduled, it may break down or terminate without any warning or symptoms. A typical example of a wrong schedule is one which leaves some unutilized data in the system occupying memory space. Since embedded software generally has an infinite loop, a collection of unnecessary data in each iteration, finally amounts to exhausting all memory space available.

3.2.1 Motivation A correct schedule for a reactive system is a sequence of task executions, which may be infinite. Infinite sequences of task executions may cause some problems such as unboundedness. It means a large amount of data may get collected in internal buffers. In our method, we use finite schedules to compose infinite schedules and check the feasibility of the finite schedules. Given a Petri Net and an initial marking, since both the transition firings in a finite complete cycle and the tokens produced by each firing are finite, the number of tokens that can accumulate in any place of the net during the execution is bounded. Therefore, if such a finite cyclic schedule exists (for every resolution of non-deterministic choices), the net can be executed forever with bounded memory by repeating infinitely many times this sequence of transition firings [5].

3.2.2 Implementation of Cyclic Schedules As shown in Figure 3.3, in order to find a cyclic schedule σ, we start from a marking µ and return to the same marking µ, thus we must solve the equation, f (σ) D = 0, where D is a 17

1

t1

p1

2

t2

p2

t3

f(V) D = 0 f(V) = ( 2 , 1 , 1 ) V = t1t1t2t2t3

(0,0)

V = t1t1t2t2t3

(0,0)

( 0 , 0 ) …….

Figure 3.3: Cyclic schedules matrix with the i-th row corresponding to a transition ti , the j-th column corresponding to a place pj , and D[i, j] = F (ti , pj ) − F (pj , ti ). F (ti , pj ) is a integer weight from transition ti to place pj . A solution f (σ), when it exists, is called a T-invariant [7]. A T-invariant f (σ) is a vector whose i-th component fi (σ) is the number of times that transition ti appears in sequence σ.

Definition 3.3 : Petri Net Consistency A Petri Net is consistent iff ∃f (σ) > 0 such that f (σ) D = 0.

k

The existence of a T-invariant is a necessary, but not a sufficient condition for a finite complete cycle to exist. In fact, even if there exists a solution of the state equations, the net may deadlock during execution because there are not enough tokens to fire any transition. It is necessary to detect deadlock existence by simulation. If a deadlock exists in a sequence firing, then it is not a valid schedule. Figure 3.4 shows the schedulable condition and the unschedulable condition. Fig18

t2

p2

t4

p1

p1

t1

t2 t4

t1

p3 t3

p3

t5

p2

t3

f(V) = a( 1 , 1 , 0 , 1 , 0 ) + b( 1 , 0 , 1 , 0 , 1 )

f(V) = ( 1 , 1 , 1 , 2)

valid

a , b=0 , 1 , 2 ….

f(V) = ( 1 , 1 , 1 , 1)

unbounded

f(V) = ( 1 , 0 , 1 , 1)

unbounded

(a)

(b)

Figure 3.4: (a) Schedulable net, (b) Unschedulable net ure 3.4 (a) shows several schedulable sequences that could start from the marking µ and end on the same marking µ. Figure 3.4 (b) shows unschedulable sequences that may break the system. In Figure 3.4, unbounded means the amount of data in the internal buffers is unbounded.

19

3.3 Problem Formulation A user specifies the requirements for an embedded software by a set of CCPNs. The problem we are trying to solve here is to find a construction method by which a set of CCPNs can be made feasible to execute as a software code, running under given limited memory space. The following is a formal definition of the embedded software synthesis problem.

Definition 3.4 : Embedded Software Synthesis Given a set of CCPNs and an upper-bound on memory use, a piece of embedded software code is to be generated such that (1) it satisfies all the CCPN requirements, (2) it can be executed on a single processor, and (3) it uses memory no more than the upper-bound.

k

There are mainly two issues in solving the above defined embedded software synthesis problem as described in the following. • CCPN Scheduling: The first issue is how to schedule all the CCPN requirements onto a single processor. In the original QSS method [22], due to the free-choice characteristic of FCPN, net decomposition was straightforward resulting in a simpler scheduling strategy. But, now due to complex-choice characteristic of CCPN, net decomposition and scheduling are more intricate. • Code Generation: The second issue is how to generate uniprocessor code so that the multi-tasking behavior of an embedded software is still visible, thus increasing the ease of future maintenance. Further, how can interrupt handling code be generated?

20

3.4 Synthesis Algorithm As formulated in Definition 3.4 and described in Section 3.3, there are two objectives for solving the embedded software synthesis problem, namely scheduling of CCPN requirements on a single processor and embedded software code generation. For CCPN scheduling, we propose an Extended Quasi-Static Scheduling (EQSS) algorithm, which can handle complex-choices in a CCPN. For code generation, we propose a Code Generation with Multiple Threads (CGMT) method, which can generate code such that the multi-tasking behavior of an embedded software is still visible, thus increasing the ease of future maintenance.

3.4.1 Extended Quasi-Static Scheduling To handle complex choices that may occur in a CCPN, we propose the Extended QuasiStatic Scheduling (EQSS) method. EQSS is based on the previously proposed QSS method, which makes most scheduling decisions statically, leaving only the data-dependent decisions to run-time. Before describing EQSS, we first explain QSS which works as follows [22]. Whenever a choice place is encountered, a T-allocation selects one of the enabled conflicting transition for execution, thus disabling all other conflicting transitions. The T-allocation is performed for each conflicting transition. Then, a T-reduction actually eliminates all the disabled conflicting transition from a T-allocation, including all successor places and transitions that are no longer triggerable. Intuitively, each T-reduction is a possible computation behavior of the net, which is then scheduled independently from the other T-reductions. If all T-reductions can be scheduled, then the system is declared schedulable and valid schedules generated, which is used for code generation. The generated code 21

ensures that the number of tasks is minimal, that is, it is the same as the number of source transitions with independent firing rates, where a source transition is one without any incoming place thus represents a system input event. Two source transitions are said to have independent firing rates if the rates at which they fire are not related in any way.

22

Table 3.1: Extended Quasi Static Algorithm EQSS Schedule(S, µ) S = {Ai | Ai = (Pi , Ti , Fi , Mi0 ), i = 1, 2, . . . , n}; µ: integer;

// Maximum memory

{ 6 N U LL) { while (C = Get CCS(S) =

(1)

// Construct Exclusion Table ExT able for CCS C Initialize Table(ExT able); // Initialize table to False

(2)

for each transition t ∈ C

(3)

for each transition t0 ∈ C

(4)

if (M Exclusive(t, t0 )) ExT able[t, t0 ] = True;

(5)

// Decompose CCS C into conflict-free subsets D = {C};

// D is a power-set of C

for each subset H ∈ D

(6) (7)

for each transition t ∈ H

(8)

for each transition t0 ∈ H

(9)

if (ExT able[t, t0 ] = True) {

(10)

H 0 = Copy Set(H);

(11)

Delete Trans(H, t0 );

(12)

Delete Trans(H 0 , t);

(13)

D = D ∪ H 0; }

(14)

} //while

23

Table 3.2: Extended Quasi Static Scheduling Algorithm (continued)

// Decompose a CCPN into subnets according to D for each subset H ∈ D

(15)

Decompose CCPN(S, H);

(16)

// Schedule all CF components for each CCPN Ai ∈ S

(17)

for each conflict-free subnet X of Ai {

(18)

Xs = Schedule(X, µ);

(19)

if (Xs = N U LL) return ERROR;

(20)

else EQSSi = EQSSi ∪ Xs ; }

(21)

Generate Code(S, µ, EQSS1 , . . . , EQSSn ); }

As described above, QSS cannot handle non-free choices, which we call complex choices, thus EQSS is proposed. The details of our proposed EQSS algorithm are as shown in Table 3.1. Given a set of CCPNs S = {Ai | Ai = (Pi , Ti , Fi , Mi0 ), i = 1, 2, . . . , n} and a maximum bound on memory µ, the algorithm finds and processes each set of complex choice transitions (Step (1)), which is simply called Complex Choice Set (CCS) and is defined as follows.

24

(22)

Definition 3.5 : Complex Choice Set (CCS) Given a CCPN Ai = (Pi , Ti , Fi , Mi0 ), a subset of transitions C ⊆ Ti is called a complex choice set if they satisfy the following conditions. • There exists a sequence of the transitions in C such that any two adjacent transitions are always conflicting transitions from the same choice place. • There is no other transition in Ti \C that conflicts with any transition in C, which means C is maximal.

k

From Definition 3.5, we can see that free-choice is a special case of CCS, which implies QSS is also a special case of EQSS. For each CCS, EQSS analyzes the mutual exclusiveness of the transitions in that CCS and then records their relations into an Exclusion Table (Steps (2)–(5)). Two complex-choice transitions are said to be mutually exclusive if the firing of any one of the two transitions disables the other transition. An exclusion table is a square matrix of size |T | × |T |. The (i, j) element of an exclusion table can take values True or False, where True means that the ith and the jth transitions are mutually exclusive, and False means not mutually exclusive. Based on the exclusion table, a CCS is decomposed into two or more conflict-free (CF) subsets, which are sets of transitions that do not have any conflicts, neither free-choice nor complex-choice. The decomposition is done as follows (Steps 6–14). • For each pair of mutually exclusive transitions t, t0 , do the following. • Make a copy H 0 of the CCS H (Step (11)), • Delete t0 from H (Step (12)), and 25

• Delete t from H 0 (Step (13)).

Based on the CF subsets, a CCPN is decomposed into conflict-free components (subnets) (Steps (15)–(16)). The CF components are not distinct decompositions as a transition may occur in more than one component. Starting from an initial marking for each component, a finite complete cycle is constructed, where a finite complete cycle is a sequence of transition firings that returns the net to its initial marking. A CF component is said to be schedulable (Step (19)) if a finite complete cycle can be found for it and it is deadlockfree. Once all CF components of a CCPN are scheduled, a valid schedule for the CCPN can be generated as a set of the finite complete cycles. The reason why this set is a valid schedule is that since each component always returns to its initial marking, no tokens can get collected at any place. Satisfaction of memory bound is checked by observing if the memory space represented by the maximum number of tokens in any marking does not exceed the bound. Here, each token represents some amount of buffer space (i.e., memory) required after a computation (transition firing). Hence, the total amount of actual memory required is the memory space represented by the maximum number of tokens that can get collected at all the places in a marking during its transition from the initial marking back to its initial marking. Finally, embedded software code is generated (Step (22)), which will be discussed in Section 3.4.2.

26

3.4.2 Code Generation with Multiple Threads In contrast to the conventional single-threaded embedded software, we propose to generate embedded software with multiple threads, which can be processed for dispatch by a realtime operating system. Our rationalizations are as follows: • With advances in technology, the computing power of microprocessors in an embedded system has increased to a stage where fairly complex software can be executed. • Due to the great variety of user needs such as interactive interfacing, networking, and others, embedded software needs some level of concurrency and low contextswitching overhead. • A multi-threaded software architecture preserves the user-perceivable concurrencies among tasks, such that future maintenance becomes easier. The procedure for code generation with multiple threads (CGMT) is given in Table 3.3. Each source transition in a CCPN represents an input event. Corresponding to each source transition, a Pthreads is generated (Steps (1), (2)). Pthreads is a standard model and its purpose is to divide a program into multilevel tasks for parallel execution. P represents POSIX (Portable Operation System Interface). Thus, the thread is activated whenever there is an incoming event represented by that source transition. There are two sub-procedures in the code generator, namely Visit Trans() and Visit Place(), which call each other in a recursive manner, thus visiting all transitions and places and generating the corresponding code segments. A CCPN transition represents a piece of user-given code, and is simply generated as call t k; as in Step (3). Code generation begins by visiting the source transition, once for each of its successor places (Steps (4), (5)). 27

In both the sub-procedures Visit Trans() (Steps (1)–(3)) and Visit Place() (Steps (6– 8)), a semaphore mutex is used for exclusive access to the token num variable associated with a place. This semaphore is required because two or more concurrent threads may try to update the variable at the same time by producing or consuming tokens, which might result in inconsistencies. Based on the firing semantics of a CCPN, tokens are either consumed from an input place or produced into an output place, upon the firing of a transition. When visiting a choice place, a switch() construct is generated as in Step (3). After all the codes in threads are generated, a main procedure is generated, which creates all the threads and passes control to the executing threads upon input events or interrupt.

28

Table 3.3: Code Generation Algorithm for EQSS Generate Code(S, µ, EQSS1 , EQSS2 , . . . , EQSSn ) S = {Ai | Ai = (Pi , Ti , Fi , Mi0 ), i = 1, 2, . . . , n}; µ: integer;

// Maximum memory

EQSS1 , . . . , EQSSn : sets of schedules of conflict-free CCPNs { for each source transition tk ∈

S i

Ti do {

(1)

Tk = Create Thread(tk );

(2)

output(Tk , "call t k;");

(3)

for each successor place p of tk

(4)

Visit Trans(EQSSk , Tk , tk , p);

(5)

} Create Main();

(6)

} Visit Trans(EQSSk , Tk , tk , p){ output(Tk , "mutexs lock(&mutex);");

(1)

output(Tk , "p.token num += weight[t k, p];");

(2)

output(Tk , "mutexs unlock(&mutex);");

(3)

Visit Place(EQSSk , Tk , p);

(4)

}

29

Table 3.4: Code Generation Algorithm for EQSS (continued) Visit Place(EQSSk , Tk , p){ if(Visited(p) = True) return;

(1)

if(Is Choice Place(p)=True)

(2)

output(Tk , "switch (p) {");

(3)

for each successor transition t0 of p

(4)

if(Enabled(EQSSk , t0 )) {

(5)

output(Tk , "mutexs lock(&mutex);");

(6)

output(Tk , "p.token num-=weight[p,t’];");

(7)

output(Tk , "mutexs unlock(&mutex);");

(8)

output(Tk , "call t’;");

(9)

for each successor place p0 of t0 {

(10)

Visit Trans(EQSSk , Tk , t0 , p0 ); } output(Tk , "break;"); }

(11) (12)

output(Tk , "}");

(13)

}

30

Chapter 4 Application Examples We give two examples to illustrate our proposed EQSS algorithm and code generation procedures, namely Master/Slave Role Switch in the Bluetooth Protocol and a Motor Speed Control System .

4.1 Master/Slave Role Switch in the Bluetooth Protocol This example is on an embedded software for the master-slave role switch between two wireless Bluetooth devices. In the Bluetooth wireless communication protocol [4], a piconet is formed of one master device and seven active slave devices. By definition, the master is represented by the Bluetooth unit that initiates the connection. The names ‘master‘ and ‘slave‘ only refer to the protocol on the channel, the Bluetooth units themselves are identical that is, any unit can become a master of a piconet. Once a piconet has been established, master-slave roles can be exchanged. As described in the following, there are three situations in which a master device and a slave device would attempt to perform a Master/Slave (M/S) role switch. First, a device may want to join an existing piconet thus it will have to assume the master role, requiring a role switch with the original master. Second,

31

a slave device sets up a new piconet with the original master as its slave. Third, a slave device takes the role of master of the original piconet. Due to wireless device mobility, M/S role switches are quite frequent and are accomplished by exchanging some commands between the two devices at the host control and link manager layers and a time-division duplex switch at the baseband layer. The MS switch procedure will now be described in more detail by giving an example. Assume unit A wants to become master, unit B was the former master. Then there are basically two alternative scenarios, either the slave takes the MS switch initiative or the master takes the MS switch initiative. If the former case is true, it finalizes the transmission of the current ACL (Asynchronous Connection-Less link) packet with L2CAP information, stops L2CAP transmission and sends LMP slot offset immediately followed by LMP switch req. If the master accepts the master-slave switch it finalizes the transmission of the current ACL packet with L2CAP information, stops L2CAP transmission and responds with LMP accepted. If the master rejects the master-slave switch it responds with LMP not accepted and the slave re-enables L2CAP transmission. If the latter case is true, it finalizes the transmission of the current ACL packet with L2CAP information, stops L2CAP information and sends LMP switch req. If the slave accepts the master-slave switch it finalizes the transmission of the current ACL packet with L2CAP information, stops L2CAP transmission and responds with LMP slot offsets immediately followed by LMP accepted. If the slave reject the master-slave it responds with LMP not accepted and the master re-enables L2CAP transmission. At the moment of the TDD (Time-Division Duplex) switch, both units A and B will start a timer with a time out of newconnection Timeout (TO). The timer is stopped in slave

32

B as soon as it receives an FHS (Frequency Hop Synchronization) packet from master A on the TDD-switch channel, the timer is stopped in master A as soon as it receives an ID packet from slave B. If the newconnection Timeout (TO) expires, the master and slave will return to the old piconet timing and take their old role of master and slave. The FHS packet is sent by master A using the ”old” piconet parameter. The AM ADDR (Active Member Address) in the FHS packet header is the former AM ADDR used by unit A. The AM ADDR carried in the FHS payload is the new AM ADDR intended for unit B when operating on the new piconet. After the FHS acknowledgement, which consists of the ID packet and is sent by the slave on the old hopping sequence, both master A and slave B turn to the new channel parameters of the new piconet. Summarized, the MS-switch takes place in two steps: first a TDD switch of the considered master and slave, followed by a piconet switch of the both participants. Then, if so desire, other slaves of the old piconet can be transferred to the new piconet. When a unit have acknowledged the reception of the FHS packet, this unit uses the new piconet parameters defined by the new master and the piconet switch is completed. In our CCPN model of an M/S switch between two devices A and B, there are totally four Petri nets as follows. Host of device A as shown in Figure 4.1, Host Control / Link Manager (HC/LM) of device A as shown in Figure 4.2, host of device B as shown in Figure 4.3, and HC/LM of device B as shown in Figure 4.4. The proposed EQSS algorithm (Tables 3.1 and 3.2), was applied to the given system of four CCPNs. The results of scheduling are given in Tables 4.1 and 4.2. We observe that each of the two HC/LM models has a CCS {t8 , t9 , t10 }, which is decomposed by EQSS into three subsets: {t8 , t10 }, {t9 }, and {t10 }, because {t8 , t9 } and {t9 , t10 } are mutually

33

exclusive pairs of transitions. There are totally six source transitions in the four CCPN models of the M/S role switch. Thus, six threads were generated to handle each of the six input events represented by the source transitions. The partial generated code structure is given in the Appendix.

34

Host_A Initialize

ACL_Connection

Send HA2LA_HCI_Switch_R ole

Receive LA2HA_HCI_Command_ status_event

Send LA2HA_HCI_Role_ change_event

End

Figure 4.1: CCPN model of Host A in Bluetooth M/S Role switch

35

HC/LM_A Initialize

ACL_Connec tion

Receive HA2LA_HCI_Switch_ Role

Receive N2LA_LMP_Switch_reg

Receive N2LA_LMP_ Slot_offset_ sub1

Checking NetWork End Checking NetWork

Send LA2N_ LMP_n ot_acc epted

Receive BA2LA_Role_ SwitchA_Succ ess

Receive BA2LA_ TimeOut 1

Send LA2N _LMP _acce pted Receive N2LA_LM P_accept ed

Send LA2HA_HCI_ Role_Change _event

End

Send LA2HA_HCI_Command_ States_event

Send LA2N_LMP_slot_offset_ sub2

Send LA2N_LMP_Switch_req

Receive N2LA_LMP_not_ accepted

End Send TDD_ Switch A

End

Figure 4.2: CCPN model of Host Control/Link Manager of Device A in Bluetooth M/S Role switch 36

Host_B Initialize

ACL_Connection

Send HB2LB_HCI_Switch_ Role

Receive LB2HB_HCI_Command_status_ event

Send LB2HB_HCI_Role_ change_event

End

Figure 4.3: CCPN model of Host B in Bluetooth M/S Role switch

37

HC/LM_B Initialize

ACL_Connection

Receive HB2LB_HCI_Switch_ Role

Receive N2LB_LMP_Switch_reg

Receive N2LB_LMP_ Slot_offset_ sub1

Checking NetWork End Checking NetWork

Send LB2N_ LMP_n ot_acc epted

Receive BB2LB_Role_ SwitchB_Succ ess

Receive BB2LB_ TimeOut 1

Send LB2HB_HCI_ Role_Change _event

Send LB2N_ LMP_ accept ed

Receive N2LB_L MP_acc epted

End

Send LB2HB_HCI_Command_ States_event

Send LB2N_LMP_slot_offset_ sub2

Send LB2N_LMP_Switch_req

Receive N2LB_LMP_not_ accepted

End Send TDD_ Switch B

End

Figure 4.4: CCPN model of Host Control/Link Manager of Device B in Bluetooth M/S Role switch 38

Table 4.1: Scheduling Results for Bluetooth M/S Role Switch CCPN

#T

#P

#S

Host A

7

5

2

ht0 , t1 , t2 , t4 , t5 , t6 i, ht0 , t1 , t3 , t5 , t6 i

21

15

6

ht0 , t1 , t2 , t4 , t6 , t7 , t10 , t11 , t12 , t14 i

HC/LM A

Schedules

ht0 , t1 , t3 , t5 , t6 , t8 , t10 , t14 i ht0 , t1 , t2 , t4 , t6 , t7 , t10 , t11 , t13 , t15 ,16 , t18 i ht0 , t1 , t2 , t4 , t7 , t11 , t13 , t15 , t16 , t18 i ht0 , t1 , t2 , t4 , t6 , t7 , t10 , t11 , t13 , t15 , t17 , t19 , t20 i ht0 , t1 , t3 , t5 , t6 , t9 , t15 , t17 , t19 , t20 i Host B HC/LM B

7

5

2

Same as for Host A

21

15

6

Same as for HC/LM A

where # T: number of transitions, # P: number of places, # S: number of schedules.

39

Table 4.2: Variables used in Bluetooth M/S Role Switch Model

CCPN

Transitions Description

Host A

t0 : Initialize, t1 : ACL Connection, t2 : Send HA2LA HCI Switch Role t3 : t4, t4 : Receive LA2HA HCI Command status event t5 : Receive LA2HA HCI Role change event, t6 : End.

HC/LM A

t0 : Initialize, t1 : ACL Connection, t2 : Receive HA2LA HCI Switch Role t3 : Receive N2LA LMP Switch reg, t4 : Send LA2HA HCI Command States event t5 : Receive N2LA LMP Slot offset sub1, t6 : Checking NetWork t7 : Send LA2N LMP slot offset sub2, t8 : Send LA2N LMP not accepted t9 : Send LA2N LMP accepted, t10 : End Checking Network, t11 : Send LA2N LMP Switch req, t12 : Receive N2LA LMP not accepted, t13 : Receive N2LA LMP accepted, t14 : End, t15 : Send TDD SwitchA t16 : Receive BA2LA TimeOut1, t17 : Receive BA2LA Role SwitchA Success t18 : End, t19 : Send LA2HA HCI Role Change event, t20 : End.

Host B

Same as for Host A

HC/LM B

Same as for HC/LM A 40

4.2 Motor Speed Control System The other example is Motor Speed Control System (MSCS). The purpose of the MSCS is to change the speed of the motor depending on the current motor speed. Figure 4.5 describes the system main module. Two timer interrupts, T0 and T1, are first initialized. For an example, if you want to produce a timer interrupt every 100 ms you must set timer counter T0 or T1 to be 100 ms. In 8051 chip, there are two timer interrupts and you can set T0 and T1 to control them. INT1 and INT3 are used to enable two timer interrupts. In Figure 4.5 after initializing, the system checks the variable value, newrdgf lag, if its value is true the system could check current speed. If current speed is too slow it could increase drive to increase speed. Otherwise, it could decrease drive to slow down speed. Finally, the newrdgf lag is cleared and the system goes to initial marking. Two timers are used in this system. The timer1 interrupt in Figure 4.6 is driven by an opto-interruptor triggered by a mark on the motor shaft. It determines the time for a revolution of the shaft by comparing the reading of timer1 with the previous reading. It signals the control algorithm by setting newrdgf lag zero. The other timer interrupt timer0 in Figure 4.7 is to set or clear the output to a port bit to produce a PWM (Pulse-Width Modulated) signal to a DC motor. PWM outputs will run stable duty cycle and repetition rates. Timer1 first resets timer1 and increases count that counters that derive their on and off times. A variable nowtime is incremented before the test. If nowtime reaches the number in width the high part of the pulse is ended, while, if the time count reaches freq, a new pulse is started. Although this system has not the Complex Choice Set, there has the Free-Choice structure. In this case, we could know that EQSS also could handle the Free-Choice struc41

Figure 4.5: Main Module of Motor Speed Control System

ture. The results of scheduling are given in Tables 4.3, 4.4 and 4.5. We show the result of code generation for Motor Speed Control System in the Appendix.

42

Figure 4.6: Interrupt 0 of Motor Speed Control System

Table 4.3: Scheduling Results for Main Module of Motor Speed Control System (MSCS) CCPN

#T

#P

#S

MSCS

7

4

2

Schedules ht0 , ht1 i∗ , t2 , t3 , t6 , t7 , t8 i, ht0 , ht1 i∗ , t2 , t4 , t5 , t7 , t8 i

where # T: number of transitions, # P: number of places, # S: number of schedules, ht1 i∗ : t1 must fire at least one time. t0 : initialize, t1 : t1, t2 : t2, t3 : t3, t4 : decrease drive, t5 : increase drive, t6 : clear newrdgflg and end.

43

Figure 4.7: Interrupt 1 of Motor Speed Control System

Table 4.4: Scheduling Results for Interrupt T0 of Motor Speed Control System (MSCS)

CCPN

#T

#P

#S

MSCS

7

4

4

Schedules ht0 , t1 , t4 , t6 i, ht0 , t1 , t3 , t5 , t6 i, ht0 , t2 , t3 , t5 , t5 , t6 i, ht0 , t2 , t4 , t5 , t6 , t6 i

where # T: number of transitions, # P: number of places, # S: number of schedules. t0 : initialize, t1 : t1, t2 : shut off pulse, t3 : t3, t4 : turn on pulse and reset count, t5 : t5 , t6 : End.

44

Table 4.5: Scheduling Results for Interrupt T1 of Motor Speed Control System (MSCS) CCPN

#T

#P

#S

MSCS

4

3

1

Schedules ht0 , t1 , t2 , t3 i.

where # T: number of transitions, # P: number of places, # S: number of schedules. t0 : capture count, t1 : subtract last count, t2 : set newrdgflg, t3 : return.

45

Chapter 5 Conclusions & Future Work We have extended the expressiveness of previous system models such as Free-Choice Petri Net (FCPN) by allowing complex choices in the Petri net specifications and by introducing a new model called Complex-Choice Petri Net (CCPN). We have also extended the quasi-static scheduling algorithm to handle such complex choices during embedded software synthesis. Further, we proposed a multi-threaded code generation procedure for a scheduled system of embedded software specifications. The newly proposed Extended Quasi-Static Scheduling (EQSS) algorithm can synthesize a larger domain of application and the multi-threaded code structure can express that many source transitions could fire concurrently. A thread structure is more efficient than a process structure, because threads need fewer resource than processes. Through a real-world example on the master/slave role switch between two wireless Bluetooth devices and a Motor Speed Control System, we have shown the feasibility of our approach and the benefits obtained from broadening the possible class of systems that could be modelled and scheduled for code generation. The current work on EQSS can be further enhanced or improved along the following future research directions.

46

• Time-constraints are not considered in our EQSS algorithm. In recent years, realtime system is a hot topic of research. Many embedded systems need to satisfy time-constraints. Many tasks in an embedded system must finish in real-time. If a task cannot finished in real-time, the system may be break down. Thus, we may add a time structure into our CCPN model and time-constraints into our EQSS algorithm • EQSS can handle simple loop situations as defined in Definition 3.2, but cannot handle recursive loops or deeply-nested loops. Thus, we need some algorithm to detect where loops occur, record loops, and handle them. • EQSS algorithm seems like a brute force approach, which is not efficient enough. We may discard some situations that can be predicted as infeasible, so that we can make EQSS more efficient.

47

Bibliography [1] K. Altisen, G. G¨obler, A. Pneuli, J. Sifakis, Tripakis S., and Yovine S. A framework for scheduler synthesis. In Real-Time System Symposium (RTSS’99). IEEE Computer Society Press, 1999. [2] F. Balarin and M. Chiodo. Software synthesis for complex reactive embedded systems. In Proc. of International Conference on Computer Design (ICCD’99), pages 634 – 639. IEEE CS Press, October 1999. [3] S.S. Bhartacharyya, R. Leupers, and P. Marwedel. Software synthesis and code generation for signal processing systems. 49(9):849 – 875, September 2000. [4] J. Bray and C.F. Sturman. Bluetooth: Connect Without Cables. Prentice Hall, 2001. [5] J. Buck. Scheduling dynamic dataflow graphs with bounded memory using the token flow model. Ph.D dissertion. UC Berkeley, 1993. [6] J. Cortadella, A. Kondratyev, L. Lavagno, M. Massot, S. Moral, C. Fasserone, Y. Watanabe, and A Sangiovanni-Vincentelli. Task generation and compile-time scheduling for mixed data-control embedded software. Proc. of the 37th Design Automation Conference, pages 489 – 494, 2000. [7] J. Desel and J. Esparza. Free choice petri nets. Cambridge University Press, 1995. 48

[8] J.-M. Fu, T.-Y. Lee, P.-A. Hsiung, and S.-J. Chen. Hardware-software timing coverification of distributed embedded systems. IEICE Trans. on Information and Systems, E83-D(9):1731–1740, September 2000. [9] H.A. Hansson, H.W. Lawson, M. Stromberg, and S. Larsson.

BASEMENT:

A distributed real-time architecture for vehicle applications. Real-Time Systems, 11(3):223–244, 1996. [10] P.-A. Hsiung. Timing coverification of concurrent embedded real-time systems. In Proc. of the 7th IEEE/ACM International Workshop on Hardware Software Codesign (CODES’99), pages 110 – 114. ACM Press, May 1999. [11] P.-A. Hsiung. Embedded software verification in hardware-software codesign. Journal of Systems Architecture — the Euromicro Journal, 46(15):1435–1450, December 2000. [12] P.-A. Hsiung. Hardware-software timing coverification of concurrent embedded realtime systems. IEE Proceedings — Computers and Digital Techniques, 147(2):81–90, March 2000. [13] P.-A. Hsiung. Synthesis of parametric embedded real-time systems. In Proc. of the International Computer Symposium (ICS’00), Workshop on Computer Architecture (ISBN 957-02-7308-9), pages 144–151, December 2000. [14] P.-A. Hsiung. Formal synthesis and code generation of embedded real-time software. In Proc. of the 9th ACM/IEEE International Symposium on Hardware Software Codesign (CODES’01, Copenhagen, Denmark), pages 208 – 213. ACM Press, April 2001.

49

[15] P.-A. Hsiung. Formal synthesis and control of soft embedded real-time systems. In Proc. 21st IFIP WG 6.1 International Conference on Formal Techniques for Networked and Distributed Systems (FORTE’01, Cheju Island, Korea), pages 35–50, August 2001. [16] E. Lee and D. Messerschmitt. Synchronous dataflow. pages 1235 – 1245, September 1987. [17] B. Lin. Software synthesis of process-based concurrent programs. In Proc. of the Design Automation Conference (DAC’98), pages 502 – 505. ACM Press, June 1998. [18] O. Maler, A. Pnueli, and J. Sifakis. On the synthesis of discrete controllers for timed systems. In 12th Annual Symposium on Theoretical Aspects of Computer Science (STACS’95), volume 900, pages 229 – 242. Lecture Notes in Computer Science, Springer Verlag, March 1995. [19] P. Merlin and G.V. Bochman. On the construction of submodule specifications and communication protocols. ACM Trans. on Programming Languages and Systems, 5(1):1 – 25, January 1983. [20] T. Murata. Petri nets: properties, analysis and applications. In Proc. of the IEEE. IEEE Press, April 1989. [21] T. Raithel. Software synthesis with evolutionary algorithms. In Proc. of the IEEE International Symposium on Industrial Electronics, (ISIE ’99), pages 1490 – 1495, 1999.

50

[22] M. Sgroi, L. Lavagno, Y. Watanabe, and A. Sangiovanni-Vincentelli. Synthesis of Embedded Software Using Free-Choice Petri Nets. In Proc. Design Automation Conference (DAC’99). ACM Press, June 1999. [23] F. Thoen, J. Van Der Steen, G. de Jong, G. Goossens, and H. De Man. Multi-thread graph: A system model for real-time embedded software synthesis. In Proc. of the European Design and Test Conference, pages 476 – 487, 1997. [24] L.J. van Bokhoven, J.P.M. Voeten, and M.C.W. Geilen. Software synthesis for system level design using process execution trees. In Proc. of the 25th EUROMICRO Conference, pages 463 – 467, 1999. [25] X. Zhu and B. Lin. Compositional software synthesis of communicating processes. In Proc. of the International Conference on Computer Design (ICCD’99), pages 646 – 651. IEEE CS Press, October 1999.

51

Appendix Partial Code Structure for Host A #include #include #define tot_tra_num 7 #define tot_pla_num 5 struct place { int token_num=0; }; pthread_mutex_t mutex; place _places[tot_pla_num]; bool check_enable(int tra) { int i; bool value=true; for(i=0;i 0) if(_places[i].token_num