We devised the following new specification techniques for dynamically reconfigurable systems consisting of CPUs and DRPs:

・ We use linear hybrid automata [7] describing changes in the operating frequency.

・ We use linear hybrid automata that have creation/destruction events describing dynamic creations and destructions of configuration components.

・ We use FIFO queues describing asynchronous communication.

We developed a new specification language (DLHA) based on a linear hybrid automaton with both creation/destruction events and unbounded FIFO queues. DLHA is different from existing research in the following points:

・ V. Varshavsky and J. Esparza proposed the GALA (Globally Asynchronous - Locally Arbitrary) modeling approach including timed guards [8] . This approach cannot describe hybrid systems since it is the specification language based on discrete systems. Thus, GALA cannot represent changes in operating frequency.

・ S. Minami and others have specified a dynamically reconfigurable system using linear hybrid automata and have verified it by using a model checker, H YT ECH [9] . Since linear hybrid automata cannot describe changes to the configuration and asynchronous communications, the system has been specified as a static system. Therefore, the specification presented in their work is unsuitable for representing dynamically reconfigurable systems. Moreover, they verified only the schedulability property of the system, whereas we have verified several other properties in our work.

The originality of our work on the verification method is twofold:

・ Our method targets systems that dynamically change their configurations, which is something the existing work, such as H YT ECH, has studied. We extend the syntax and semantics of linear hybrid automata with special actions called creation actions and destruction actions. We define a state in which an automaton does not exist and transitions for creation and destruction.

・ Our method is a comprehensive symbolic verification for hybrid properties, FIFO queues and creation/destruction of tasks.

For the experiments, we specified a dynamically reconfigurable embedded system consisting of a CPU and DRP, and verified some of its important features. This is the first time that specification and verification of dynamic changes have been tried in a practical case.

Our method introduces convex polyhedra for the reachability analysis in accordance with [15] .

A polyhedron is convex if it can be defined by a formula which is a conjunction of linear formulae. For a set of variables, a convex polyhedron on V is a n-dimensional real space. In particular, we define true and false as and.

Example 2 (Convex Polyhedron). The formula is a convex polyhedron. From linear formula, the existential quantifier can be eliminated effectively. Therefore, we obtain

We define a state s in the reachability analysis as, where

・ is a finite set of locations.

・ is a convex polyhedron.

・ is a vector of the content of the queues.

Figure 2, Figure 3 and Figure 4 show the algorithm of the reachability analysis.

Figure 2 is an overview of the reachability analysis, and this algorithm is performed using the expanded method of [16] with a set of queues. The analysis is performed as follows:

1. Compute an initial state of the system (ll.1-3).

2. Initialize a traversed set and a untraversed set of states by and (line 4).

3. While is not empty, repeat the following process (ll.5-16).

(a) Take a state from and remove the state from (ll.6-7).

(b) If the set of locations contains the target location, return “yes” and terminate (ll.8-10).

(c) If the state has not been traversed yet () (line 11),

i. add the state into (line 12),

ii. compute the set of successors by using the subroutine (line 13), and

iii. add all components of to (line 14).

Subroutine Succ Figure 3 shows the subroutine to compute the successors of a state. In this algorithm, we make the following assumptions.

where

Let the initial state of be; is, where

Here, is a function that assigns a convex polyhedron to each state.

is a function that returns a convex polyhedron after performing a time transition on a given set L of locations and a convex polyhedron (line 4). We define this function in accordance with [15] as follows:

Let the set of all variables in the system and their derivatives be and.

where

For a convex polyhedron and a set of update expressions, denotes the convex polyhedron updated by for. Let the set of reset variables and set of shifted variables be and . can be computed as

where

Given a state and a system, the successors are computed using the procedure described below.

1. For each transition (or destruction-transition) outgoing from a location, the set of post states is computed as follows (ll.5-31):

(a) Compute the convex polyhedron for the time transition (line 4).

(b) If a is an internal action, is computed as follows:

i. Compute the set of locations (line 8)

ii. Compute the convex polyhedron for the discrete transition (line 9)

iii. If a is an enqueue action (ll.11-15),

where

iv. If a is a dequeue action (ll.16-20),

v. If a is another internal action (line 22),

(c) If a is an output action, is computed with the subroutine Syncs (line 26 and 29).

(d) If a is an input action,.

Subroutine Syncs Figure 4 shows the subroutine Syncs of Succ to compute successors by using the transition that has an output action. Given a state, a transition (or destruction-transition), and a system, a set of successors is computed as follows:

1. Initialize as (line 1).

2. Compute a convex polyhedron for the time transition (line 2).

3. For each in the system, compute the set of transitions that are outgoing from the state by using an input action (ll.3-5),

4. Compute the set of combinations of (line 6).

5. For each combination, the successor is computed as follows (ll.7-29):

(a) Compute the set of transitions (line 9).

(b) Compute the set of locations (ll.9-14, line 21).

where

(c) Compute the update expression (ll.9-14).

where

(d) Compute the conjunction of guard conditions (ll.9-14).

(e) Compute the convex polyhedron (ll.22-24).

where

(f) If, the successor is added to (ll.26-27).

The correctness of this algorithm is implied by Lemma 1 and Lemma 2.

Lemma 1. If the algorithm terminates and returns “is not reachable”, the system has the safety property.

Lemma 2. If this algorithm terminates and returns “is reachable”, the system does not hold the safety property.

By definition, all linear hybrid automata are DLHAs. Our system dynamically changes its structure by sending and receiving messages. However, the messages statically determine the structure, and the system is a linear hybrid automaton with a set of queues. It is basically equivalent to the reachability analysis of a linear hybrid automaton. Therefore, the reachability problem of DRSs is undecidable, and this algorithm might not terminate [16] .

Moreover, in some cases, a system will run into an abnormal state in which the length of a queue becomes infinitely long, and the verification procedure does not terminate.

We have specified a dynamically reconfigurable embedded system consisting of a CPU and DRP for the model described in our previous research [9] . A DRP is a processor that can execute exclusive processes at the same time by dynamically changing the circuit configuration, and it is used to accelerate CPU computations, for example, in image processing and cipher processing. A DRP has computation resources called tiles (or processing elements), and it dynamically sets the context of a process if there are enough free tiles. In addition, a DRP can change the operating frequency in accordance with running processes. In this paper, we assume that the number of tiles and the operating frequency for each process have been set in advance and that the operating frequency of the DRP is always the minimum frequency of the running co-tasks.

Figure 7 shows an overview of the system. This system processes jobs submitted from the external environment through the cooperative operation of the CPU and DRP. The CPU Dispatcher creates a task when it receives a call message of the task from the external environment. When a task on the CPU uses the DRP, The CPU Dispatcher sends a message to the DRP Dispatcher. The DRP Dispatcher receives the message asynchronously and creates a co-task (it means “cooperative task”) in a first-come, first-served manner if there are enough free tiles. Here, we will assume that this system has two tasks and two co-tasks that have the parameters shown in Table 1 & Table 2.

The system, whose components are illustrated in Figure 8, consists of 11 DLHAs and 1 queue. We show part of the state-transition diagram in Figure 9. The external environment consists of EnvA (Figure 10) and EnvB (Figure 11) that periodically create

TaskA (Figure 12) and TaskB (Figure 13). That is, EnvA uses Crt_taskA! to create TaskA every 70 milliseconds, and EnvB uses Crt_taskB! to create TaskB with every 200 milliseconds. The Scheduler (Figure 14) performs scheduling in accordance with the priority and actions for creation and destruction of DLHAs. For example, when TaskA is created by EnvA with Crt_taskA! and TaskB is already running, The Scheduler receives Crt_taskA? from EnvA and sends Act_Preempt! to TaskA and TaskB. Then, Act_Preempt! causes TaskA to move to RunA and TaskB to move to WaitB.

TaskA and TaskB send a message to The Sender if they need a co-task. The Sender (Figure 15) enqueues the message to create a co-task to q when it receives a message from tasks. When TaskA sends Act_Create_a0! and moves to RunA from WaitA, The Sender receives Act_Create_a0? and enqueues cotask_a0 in q with q! cotask_a0.

The DRP_Dispatcher (Figure 16) dequeues a message and creates cotask_a0 (Figure 17), cotask_a1 (Figure 18), and cotask_b0 (Figure 19) if there are enough free tiles. The Frequency_Manager (Figure 20) is a module that manages the operating frequency of the DRP. When a DLHA of a co-task is created, The Frequency_Manager moves to the location that sets the frequency to the minimum value.

We have the parameters of the model in subsection 5.2.1 and conducted experiments with it.

・ Modified Tasks: We modified the parameters of the tasks on the CPU as shown in Table 3. Here, the parameters of the co-tasks are the same as those in Table 2.

・ Modified co-tasks: We modified the parameters of the co-tasks on the DRP, as shown in Table 4. The parameters of the tasks are the same as those in Table 1.

Here, schedulability is a property in which each task of the system finishes before its deadline. Let be the total processing time and be the deadline in task A (Figure 13); the remaining processing time is represented as, and the remaining time till the deadline is represented as. Therefore, the monitor automaton moves the error location if the task A is created and it satisfies the condition (Figure 21). In the case of Table 1, since and. Similarly, the condition for task B is.

In the embedded system, each co-task must be created before the remaining time in the task calling it reaches its deadline. When the message is received from task A, the monitor automaton starts counting time for co-task a0. If the waiting time exceeds the deadline of task A before it receives the message, the monitor moves to error location. Figure 22 shows The monitor automaton for the case of Table 1 for co-task a0. Monitor automata for co-tasks a1 and b0 can be similarly described.

Each co-task must be destroyed before the waiting time reaches its deadline. For the co-task a0, when the message is received from the dispatcher DRP_ Dispatcher, the monitor automaton checks the message. Figure 23 shows the monitor automaton for the case of Table 2.

Creating or destroying a co-task, the DRP changes the operating frequency corresponding to the co-tasks being processed. Since this system requires that the frequency is always at the minimum value, the monitor checks whether the frequency manager (Frequency_Manager) moves to the correct location when it receives a message for creating a co-task. For example, when co-task a0 and co-task b0 are running on the DRP, Frequency_Manager must be at location. Figure 24 show the monitor automaton for the case of Table 2.

When the DRP receives a message for creating of a co-task and the number of free tiles is enough to process it, the dispatcher creates the co-task. The dispatcher then updates the number of used tiles. The monitor automaton checks whether the number tiles in DRP_Dispatcher is always between 0 and the maximum number, 8 in this case (Figure 25).