EE249 Project Report
Yunjian Jiang, Yujia Jin
Mentor: Freddy Mang
Abstract
We study the problem of protocol conversion using controller synthesis. Given protocols P, Q and a constant integer K, we synthesize the most general converter (controller) C such that the composition of P,
Q and C will behave like a FIFO buffer with size K. We also study the problem of minimization of the converter. Experiments are carried out in the tool Mocha.
I.
Introduction
The protocol converter synthesis problem emerges from the need for system composition of reusable IP blocks, which function on different communication protocols. In this project, we study the protocol conversion problem in the context of synchronous hardware. In particular, we view the problem as an instance of the classical synchronous controller synthesis problem: Given a module S (product of the two protocols) and a specification module R (a FIFO buffer of size K), synthesize a controller C (converter) such that the composed system S||C refines R.
The general controller synthesis problem is known to be computationally intractable. We restrict our attention to a subclass of the problem: Neither P nor S have private states. The problem is then reduced to transition invariant control synthesis with complete information, and the complexity is linear in the size of the state space of P and the size of the description of S.
Furthermore, by imposing these restrictions, symbolic methods can be employed.
We also study the problem of minimizing the textual description of the generated controller. We distinguish three kinds of minimum controller: minimum most general controller, minimum deterministic controller, and the minimum controller containing a subset of behaviors. All three kinds of controllers can be obtained by applying two-level multi-valued logic synthesis algorithms. The notion of partial cares is introduced for obtaining controllers of the latter two kinds.
The report is organized as follows: in Section 2 we formally define our problem; in Section 3 we give a symbolic algorithm for transition invariant control; in Section 4 we define the notion of partial cares, and describe how multi-valued logic minimization can be used to minimize the generated converter. In Section 5 we describe some protocol conversion experiment between a four-phase protocol, a two-phase protocol and a simplified PCI protocol. All protocols are described in Reactive Modules and experiments are carried out in the tool Mocha[1].
II. Problem Statement
There has been related work in the literature that apply control synthesis to the protocol conversion problem. We adopt a similar flow in our experiment, but make the problem more tractable by inserting additional assumptions:
 At the functional level, the information being exchanged from protocols P and Q is a bit stream;
 P and Q are synchronous and share a common clock;

Bits are sent by an abstract message producer and received by an abstract consumer;

P||C||Q, where C is the converter, exhibits FIFO buffer behavior at top level;

Invariant R, the FIFO buffer, is modeled without private variable;
1


Protocols P and Q are modeled without private variable. datain dataout producer
K-Buffer validin validout consumer datain dataout producer P C Q consumer validout validin
Figure 1. Communication model
We view a protocol as a mechanism for transfer of bit streams between an abstract message producer and an abstract message consumer. As shown in Figure 1, we require the producer to produce one bit of data in datain whenever validin is asserted; the consumer absorbs one bit of data whenever validout is asserted. We currently require the communication behave like a FIFO buffer, which reads datain and controls validin, validout and dataout .
Definition [Producer] A message producer Prod is a reactive module with Boolean type external variable validin and Boolean type interface variable datain . In each cycle, Prod sets datain to a random Boolean value iff validin is true.
Definition [Consumer] A message consumer Cons is a reactive module with Boolean type interface variable dataout and validout . In each cycle, Cons reads dataout iff validout is true.
Definition [Protocol] A protocol P is a reactive module. The external variables of P includes
Boolean type variable datain . The interface variables of P includes Boolean type variable validin .
A protocol Q is a reactive module. The interface variables of Q includes Boolean type variables validout and dataout .
Definition [K-Buffer] A K-Buffer KB is a reactive module. The external variable of KB is
Boolean type variable datain . The interface variables of KB are Boolean type variables validin , validout and dataout .
Definition [Protocol conversion] Given K-Buffer KB , protocol P and Q , synthesis reactive module C , such that P || C || Q < KB
. “||” is parallel composition as defined in reactive modules[2].
“<” is refinement relation as defined in reactive modules.
Definition [Control synthesis] Given reactive modules S and R , synthesize reactive module C , such that S || C < R .
Protocol conversion problem can be reduced to control synthesis problem by setting S = P || Q , R =
KB . The resulting controller C from control synthesis is the converter C for P and Q in the protocol conversion problem.
We adopt the following flow in the process:
1.
Formalize the two protocols P and Q in reactive modules;
2.
Formalize a K-sized FIFO buffer in reactive module;
3.
Set S=P||Q; Set R=KB;
2

4.
Apply control synthesis algorithms to find C ;
5.
Apply multi-value logic synthesis to minimize the size of C.
Since R can be modified as desired, we can impose additional requirements as invariant such as liveness in the buffer module. We can also change the buffer to some other top level P1||C||Q2 behavior like lossy bus.
III. Control synthesis
Definition [controllable state] A state s of P is controllable for invariant R iff there exists an environment C such that P s
|| C < R.
Definition [controllable system] A system P is controllable iff the initial states are controllable.
We use formula (1) to determine the controller’s controlled variables. Ext means external variables, Ctl means controller variables, and All (C, P1, Q2) means all variables from C, P1, and
Q2.
Ctl (C) = All (FIFO, P1, Q2) – Ext (FIFO) – Ctl (P1, Q2) (1)
The algorithm we used for transition invariant control synthesis can be divided into 3 steps.
1.
Find the maximum controllable region and the corresponding controller C transition.
2.
Find the maximum controllable initial region.
3.
Find the reachable region of the maximum controllable region and the corresponding controller C transition.
3.1 maximum controllable region
In step 1, the cpre (x)=y operation is used. Here x and y are state regions. Intuitively, cpre(x) is the controllable previous state region, meaning y is a set s.t. if transition exists, then there exist an environment s.t. invariant R is always satisfied and transition from y to x is always made.
Depending on whether the resulting controller is a Mealy or Moore machine, or maybe even with some arbitrary execution order for updating the controller C’s outputs with respect to system S’s outputs, the necessary logic operations and so are the result will be different. Here we will only deal with Mealy and Moore machine controller. For Moore machine, controller C must control its outputs based on the current state s.t. no matter what system S does, only transition to x is taken and invariant R is satisfied. This translates to the following logic equation (2), where
Ctl(C) are controller C’s outputs, Ext(C) are controller C’s inputs, T(S) are the transition predicate for system S and prime means next state value. For Mealy machine the controller C can control its outputs based on the previous states and system S’s current state output.
Consequently, the Mealy controller C is more powerful in that when there exists a Moore controller C, a Mealy controller C will also exist. However, when a Moore controller C doesn’t exist, a Mealy controller C may still exist. The logic equation for Mealy cpre(x) is (3). cpre (x) =

Ctl(C).

Ext(C). (T(S)

(T(R)

x’) ) (Moore Machine) (2) cpre (x) =

Ext(C).

Ctl(C). (T(S)

(T(R)

x’) ) (Mealy Machine) (3)
C
C
1
= TRUE i+1
= cpre(
C =

C i
C i
)
( C is the maximum controllable region)
3

By iterating on cpre(x) with x starting from x = true and stop until a fix point is reached, a controllable region is obtained, which equals to the fix point. This is the maximum controllable region because the starting point is everything and every cpre(x) iteration shrinks the region. So if there is another a bigger fix point, it would have been found by the algorithm. The corresponding controller C transition predication is the following, where C is the maximum controllable region, T(C) is the transition predicate for controller C.
T(C) =

Ext(C). (T(S)

(T(R)
 C’
) ) (Moore Machine)
T(C) =T(S)

(T(R)
 C’
) (Mealy Machine)
3.2 maximum initial region
Finding the maximum controllable region and corresponding controller C transition is not enough because if the entrance into the controllable region can not be guaranteed then controller C still does not exist. So in step 2, the maximum initial region that controller can guarantee entrance into controllable region is determined. This is similar to step1 except there is no iteration. The following equation is used, where I(C), I(S) and I(R) are the initial state for the controller C, system S and invariant R, respectively.
I(C) =

Ext(C). (I(S)

(I(R)

C ) ) (Moore Machine)
I(C) = I(S)

(I(R)

C ) ) (Mealy Machine)
3.3 reachable analysis
After step 1 and 2, the controller C may contain unreachable states, which is useless in practice.
To eliminate unreachable states, step 3 performs a reachable analysis, which keeps only the reachable state in the controller C. The analysis start from the initial state of the controlled system, that is S||C, and then continuously explore the controlled system by following the transition, or post operation, until no more new state can be explored. In term of equation it is the following, where CR is the maximum reachable controllable region.
CR
1
= I(C)

I(S)
CR i+1
’ =

All(C, S). (T(C)

T(S)

CR
CR =

CR i i
)
I(CR) = I(C)
T(CR) = T(C)

CR
IV. Controller minimization
The control synthesis result is the assignment strategy for controlled variables at each controllable state. We minimize the size, namely the number of guarded commands, in the resulting reactive module. The reasons are: (1) the size of the reactive module is directly related to the implementation cost, either in hardware or software; (2) smaller controllers are easier to be understood by protocol designers who may want to add further restrictions or requirements to the specification. Notice that performance issues like delay or buffer size are not addressed in the minimization. They are expressed in the specification module and the controller satisfies those requirements automatically by construction.
We borrow multi-valued logic synthesis techniques in the minimization of reactive modules.
Propositional reactive modules naturally resemble multi-valued sequential logic networks, with state variables representing latched wires and atoms representing multi-valued intermediate nodes
4

in logic networks. The following sections describe the mapping between reactive modules and multi-valued logic and elaborate the concepts and algorithms that have been used in this approach.
4.1 Similarity between reactive modules and multi-valued logic
Reactive modules are a high level modeling language that has been used in formal verification. A system is modeled as a set of modules. A module P has a finite set of typed variables, denoted by
X
P
. A state of P is a valuation for the variables in X
P
. X
P
is partitioned into two sets: the set of controlled variables, containing the variables whose values are determined by the module P , and the set of external variables containing the variables whose values are determined by the environment of P . atom A3 controls data, s, data_out reads data awaits valid_in,valid_out,data_in init
[] true

data_out':=nondet; data':=nondet; s':=false; update
[] (valid_in')

s':=true; data':=data_in';
[] (valid_out')

s':=false; data_out':=data;
Valid_in’ 
Valid_out’

data_in’

data

s’
 data’  data_out’
1 - 0 - 1 0 -
1 - 1 - 1 1 -
- 1 - 0 0 - 0
- 1 - 1 0 - 1
Guarded Commands
Multi-Valued relation
Valid_in’  Valid_out’ 
data_in’

data

Q
1 - 0 - 1/5
1 - 1 - 3/7
- 1 - 0 0/2
- 1 - 1 4/6
Encoded MV relation
Valid_in’  Valid_out’ 
data_in’

data

Q
01 11 10 11 01000100
01 11 01 11 00010001
11 01 11 10 10100000
Characteristic function
11 01 11 01 00001010
Figure 2. Mapping from reactive modules to multi-valued relations
A module is composed of atoms, each of which controls a subset of the controlled variables.
Within each atom, the initial values and update values of the variables it controls are specified using initial and update guarded commands. A guarded command has the form

, where the guard

is a Boolean predicate over primed and unprimed variables, and

is an assignment specifying the values assigned to all the controlled variables in the atom when the guard is true.
The resulting controller is mapped to a two-level multi-valued relation represented in characteristic functions. The controllable states, i.e. an evaluation of observable variables of the controller, are treated as the input part of the multi-valued relation; the updating strategies, i.e. assignments to controlled variables, are treated as the output part of the multi-valued relation. For each minterm in the input space, there exists multiple minterms in the output space, representing multiple updating strategies. For the ease of minimization, the output variables are encoded into one variable that takes multiple values. The resulting relation is expressed in characteristic function form for minimization. The above process is shown graphically in Figure 2.
4.2 Multi-valued relations
5

Consider a multi-valued function with multiple multi-valued inputs and a single multi-valued output. A multi-valued relation is a one to many mapping. Let P
1
={0,1,...,|P
1
|-1}, P
2
={0,1,...,|P
2
|-
1}, … , P n
={0,1,...,|P n
|-1} be the input space, and Q={0,1,...,|Q|-1} be the output space. Then the multi-valued relation R: P
1 in Q, i.e. R(m,q) , m

P
1

P

2
P
2
 … 
P n

Q maps each minterm in the input space to a set of values
 … 
P n
, q

Q . Associated with this is a set of multi-valued functions f i
that are compatible with R , f i

R . We extend the notion of don’t cares used in binary logic into multi-valued logic and define partial cares, which contain both in-complete specification and nondeterminism.
Definition [Don't Care] A minterm m
P n

Q is a don't care, iff
 q

Q , (m,q)

P

1

P
2
R.
 … 
P n
for multi-valued relation R: P
1

P
2
 … 
Definition [Partial Care] A minterm m

P
1

P
2
P n

Q is a partial care, iff
 q

Q , (m,q)

R.
 … 
P n
for multi-valued relation R: P
1

P
2
 … 
Don't care is a special case of partial care for multi-valued relations. Partial care represents nondeterminism in multi-valued relations. In the case of controller minimization, the multiple update assignments for controlled variables are captured by partial cares.
4.3 Minimization approaches
The main objective in the minimization is the textual size of the reactive modules. Three types of minimization approaches are used, which result in three “smallest” controllers: smallest most general controller, smallest controller that contains subset behaviors and smallest determinized controller.
4.3.1 Smallest most general controller
This approach keeps all behavior of the most general controller. This is useful in design specification and verification, where an abstract view of the design is maintained and all possible implementation decisions are preserved. The minimization result is used as input to verification tools or under human inspection.
The controller is expressed using the multi-valued relation R:(P,Q) represented as a characteristic function F(m
R
) , i.e. F(m
R
) =1 iff m
R

R:(P,Q) . P part in R represents the controllable states, and Q part represents the update assignments for the controlled variables. Thus the onset of the characteristic function F(m
R
) contains all possible update transitions in the most general controller. The characteristic function of the multi-valued relation is minimized directly with
ESPRESSO-MV[3]. The resulting number of sum of product terms directly relates to the number of guarded assignments for the reactive module of the most general controller.
Uncontrollable states in P space do not need to be specified in terms of update assignments, thus can be treated as don’t cares in the minimization. We achieve this by adding don’t cares minterms with uncontrollable states encoded in P part and all ONE’s in Q part.
P
1

P
2
 … 
P n

Q

B
Controllable states assignments 1
Un-Controllable states 11……1 Don’t Care
4.3.2 Smallest controller that contains subset behaviors
In order to obtain the smallest controller in terms of size, or number of terms, some of the update assignments can be pruned as long as there exists at least one update assignment for each
6

controllable state. The resulting controller is potentially non-deterministic, but for the purpose of verification and human inspection this approach is still useful.
We use branch and bound technique combined with two-level logic minimizer ESPRESSO-MV to obtain the smallest controller that contains subset behaviors. The characteristic function is obtained from the control synthesis procedure. The minterms are then partitioned into three sets: care set, partial care set and don’t care set. Care set minterms are those controllable states with single update assignment; don’t care set minterms are those uncontrollable states; partial care minterms are those controllable states with multiple update assignments. The algorithm iterates through all partial care terms and branch on the output values in Q for each partial care term and bound on the number of product terms as a result from ESPRESSO. This process is shown in
Figure 3.
Algorithm: partial care minimization
Input: characteristic function P

Q

B
Output: characteristic function P

Q

B with minimal number of terms
For each product term u and v
If u[P]

v[P] then u:=u|v /* combine same controllable states */
For each product term u
If |u[Q]|

1 then push(Care, u) /* care set */
If |u[Q]|>1 then push(Partial Care, u) /* partial care set */
For each product term u
v = {complement(u[P])}

{all ONE’s} /* uncontrollable states as don’t care set */
While (next partial care u) {
Select an output value q in u[Q]
Push (Care, u[P]

{q}) /* branch on partial values */
Push (Don’t care, u[P]
Call ESPRESSO to minimize characteristic function P

Q

B

{u[Q]\q} /* rest partial values treated as don’t care */
If all partial care terms have been bounded, update lower bound
If (cost>lower bound) Bound next value in Q
else Branch on next partial care term
}
Figure 3. Partial care minimization algorithm
4.3.3 Determinized controller
In order to be implemented in hardware or software, the converter needs to determinized.
Determinizing a multi-valued relation and minimizing the number of product terms can be theoretically formulated as a binate covering problem. There has been some research on minimizing Boolean relations using binate covering by Brayton and Somenzi. The recent research work of AURA by L. Carloni and A. Sangiovanni-Vincentelli et al.
uses negative thinking to solve unate covering problem and state minimization. It can also be used to minimize binate covering problem and thus can be applied in this framework. In this project we use branch and bound technique in combination with ESPRESSO-MV to solve this problem. The algorithm is similar with the second approach except that after bounding one of the output values in the care set, the rest values are included in OFFSET instead of don’t care set. Therefore each controllable state is guaranteed to have only one update assignment.
V. Experiments
The control synthesis algorithm is implemented is Mocha[2] (Java version). Multi-valued logic synthesis algorithms are implemented in MVSIS. Some of the characteristics of the protocol examples we have used are shown in Table 1.
7

size_1 buffer size_4 buffer phase 2 phase 4
PCI
Number of variables
6
11
5 || 5
5 || 5
6 || 6
Table 1. Example protocols and FIFO buffer
5.1 Example protocols
Phase 2 and phase 4 protocols are simple bus transaction protocols. They are modeled with two control signals, namely request and acknowledge , and one data signal. As can be seen from the transition wave form, 2 phase protocol requires at least two cycles to complete a transaction, i.e.
( req = ack ) and ( req != ack ); 4 phase protocol requires at least four cycles to complete a transaction, i.e. ( req , ack ) = {(00),(10),(11),(01)}.
For PCI protocol, we modeled the bus write transactions. Since many of the possible operations such as bus arbitration are not required for our limited case, we only kept Frame , IRDY , TRDY , and Data signal. This led to our simplified PCI protocol.
5.2 Protocols Formalization
From the perfect knowledge assumption, the converter C generated in our process can observe all variables P1 and Q2 are in contact with. However in real world, converter C can not see validin , datain , validout , and dataout . To resolve datain , we require P1 to send out data in the same cycle that it receives one. Suppose dataP is the data signal that P1 uses to send data to the converter C, then dataP=datain must always be true. Then within the converter C we can replace any occurrence of datain with dataP . Similarly, we can resolve dataout by requiring dataout = dataQ , where dataQ is the data signal that Q2 receives data from the converter. Generally no similar technique exists for validin and validout because otherwise P1 and Q2 would just be space-less FIFOs with unnecessary signals. So to resolve this we have to relax the perfect knowledge assumption and use another controller algorithm that works without it. This may results additional computation complexity. Presently in our experiment, we leave validin and validout as they are.
5.3 FIFO Formalization
In Formalizing the FIFO, the main problem is separating the FIFO specification from the actual converter implementation. Recall the formula we use to determine converter C’s controlled variable.
Ctl(C) = All(FIFO, P1, Q2) – Ext(FIFO) – Ctl(P1, Q2)
The variables that converter controls are dependent on how FIFO is specified. Because of this, the dependency order for the variables in FIFO specification is crucial. If dependency is such at it is impossible to achieve by P1 and converter C then no converter will be generated. One example of this during the project is the following. In 2 phase to 4 phase case for Moore controller, we used a FIFO module specification in which signal s has to be updated in the same cycle as signal validin . These two signal are controlled by P1 and converter C separately. So it is impossible for the Moore converter C to update signal s in the same round that P1 updates its signal validin .
Currently, we break down the FIFO into 4 different atoms and specified each atom as Moore machine when ever possible.
8

Aside from safety constraints, we attempted to experiment liveness constraints. If we allow the buffer to stutter for arbitrary cycles, the resulting most general converter may do nothing, which does not satisfy liveness constraints. We introduce liveness by disallowing the buffer to stutter, the converter is guaranteed to promote data transfer by following exactly the cycle behaviors specified in the buffer. However, this additional liveness constraint will trim down both useless and some useful controller.
5.5 Results
The characteristics for the converters we have generated are shown in Table 2. The numbers in the table are numbers of sum of product terms, which relate to the number of guarded commands. phase 2 Master || phase 4 slave
PCI Master || phase 4 slave
PCI Master || phase 2 slave
Before
612
289
421
Moore Controller (size 1 FIFO buffer)
Espresso Partial Determinized
20 16 18
10
32
10
26
10
26
Table 2. number of product terms (guarded assignments)
VI. Future work
In the minimization process, it is promising to combine the minimization algorithms with reachability analysis. Whenever a decision is made and some of the transitions are pruned, some reachable states may become unreachable. This can results in more improvement in minimization performance.
Within our frame work, the perfect knowledge assumption is restrictive. Converter should not know protocol’s interaction with the producer and consumer. We need to hide certain variables to mirror the real world environment. To achieve this, we need to explore efficient control algorithm with incomplete information.
In specifying constraints, only safety aspects are concerned thus far. The resulting converter may in the extreme do nothing. We will explore liveness constraints to force the converter to do useful work.
Reference
[1] R. Alur and T. A. Henzinger and F. Y.C. Mang and S. Qadeer and S. K. Rajamani and S. Tasiran, “Mocha: Modularity in model checking” in Proceddings of the tennth International Conference on Computer-aided Verification, 1998.
[2]
R. Alur and T. A. Henzinger, "Reactive modules" in Proceedings of the 11th
Annual Symposium on Logic in Computer Science.
[3] R. L. Rudell and A. Sangiovanni-Vincentelli,”Multiple-valued minimization for
PLA optimization”, in IEEE Transaction on CAD, 1988.
9

Appendix A. Reactive module for size 1 buffer module K is interface valid_in,valid_out,s: bool; data_out,data: dataType; external data_in: dataType; atom A1 controls valid_in reads s,valid_in init
[] true -> valid_in':=false; update
[] (~s & ~valid_in) -> valid_in':=true;
[] (valid_in) -> valid_in':=false; atom A2 controls valid_out reads s,valid_out init
[] true -> valid_out':=false; update
[] (s & ~valid_out) -> valid_out':=true;
[] (valid_out) -> valid_out':=false; atom A3 controls s reads data,data_out,data_in,s,valid_in,valid_out init
[] true -> s':=false; update
[] (valid_in & ~s) -> s':=true;
[] (valid_out & s) -> s':=false; lazy atom A4 controls data,data_out reads data,data_out,data_in,s,valid_in,valid_out init
[] true -> data_out':=nondet; data':=nondet; update
[] (~valid_in & s) -> data':=data_in;
[] (~valid_out & ~s) -> data_out':=data;
Appendix B. Reactive module for 2 phase and 4 phase protocol module PHASE2 is interface valid_in,req2: bool; data2_out: dataType; external data_in: dataType; ackC: bool; atom AM1 controls valid_in,req2 reads ackC, req2,valid_in init
[] true -> req2':=false; valid_in':=false; update
[] (req2 = ackC) -> valid_in':=true; req2':=~req2;
[] ~(req2 = ackC) -> valid_in':=false; req2':=req2; atom AM2 controls data2_out reads data2_out,valid_in,req2,ackC awaits data_in init
[] true -> data2_out':=nondet; update
[] (valid_in & ~(req2=ackC)) -> data2_out':=data_in';
[] (~valid_in | req2=ackC) -> data2_out':=data2_out; module PHASE4 is interface valid_out,ack4: bool; data_out: dataType; external data4_in: dataType; reqC: bool; atom AS1 controls valid_out,ack4 reads reqC,ack4,valid_out init
[] true -> ack4':=false; valid_out':=false ; update
[] (reqC & ~ack4) -> valid_out':=true; ack4':=~ack4;
[] (~reqC & ack4) -> valid_out':=false; ack4':=~ack4; atom AS2 controls data_out reads data_out,valid_out,reqC,ack4 awaits data4_in init
[] true -> data_out':=nondet; update
[] (valid_out & reqC & ack4) -> data_out':=data4_in';
[] (~valid_out | ~reqC | ~ack4) -> data_out':=data_out;
10

Appendix C. Reactive module for synthesized 2 phase and 4 phase protocol converter module CTRL1 interface reqC, ackC, s:bool; data,data4_in: bool external data2_out,data_out,data_in: bool; req2,ack4,valid_in,valid_out: bool atom AM1 controls reqC,ackC,s,data,data4_in reads s,data,reqC,ackC,req2,ack4,data2_out,data_out,valid_in,valid_out,data4_in,data_in init
[] true -> reqC':=false; ackC':=false; s':=false; data':=nondet; data4_in':=nondet update
[] (~data)&(s)&(data_in)&(~reqC)&(~req2)&(ackC)&(ack4)&(valid_out)&(~valid_in) -> reqC':=false;ackC':=false;data4_in':=false;data':=false;s':=false
[] (~data)&(s)&(data_in)&(~reqC)&(req2)&(~ackC)&(ack4)&(valid_out)&(~valid_in) -> reqC':=false;ackC':=true;data4_in':=false;data':=false;s':=false
[] (~data)&(s)&(data_in)&(reqC)&(req2)&(~ackC)&(~ack4)&(~valid_out)&(~valid_in) -> reqC':=false;ackC':=false;data4_in':=false;data':=false;s':=true
[] (~data)&(s)&(data_in)&(reqC)&(~req2)&(ackC)&(~ack4)&(~valid_out)&(~valid_in) -> reqC':=false;ackC':=true;data4_in':=false;data':=false;s':=true
[] (s)&(~data_in)&(~reqC)&(~req2)&(ackC)&(ack4)&(valid_out)&(~valid_in) -> reqC':=false;ackC':=false;data4_in':=false;data':=false;s':=false
[] (s)&(~data_in)&(~reqC)&(req2)&(~ackC)&(ack4)&(valid_out)&(~valid_in) -> reqC':=false;ackC':=true;data4_in':=false;data':=false;s':=false
[] (data)&(s)&(~reqC)&(~req2)&(ackC)&(ack4)&(valid_out)&(~valid_in) -> reqC':=false;ackC':=false;data4_in':=false;data':=true;s':=false
[] (data)&(s)&(~reqC)&(req2)&(~ackC)&(ack4)&(valid_out)&(~valid_in) -> reqC':=false;ackC':=true;data4_in':=false;data':=true;s':=false
[] (s)&(~data_in)&(reqC)&(req2)&(~ackC)&(~ack4)&(~valid_out)&(~valid_in) -> reqC':=false;ackC':=false;data4_in':=false;data':=false;s':=true
[] (s)&(~data_in)&(reqC)&(~req2)&(ackC)&(~ack4)&(~valid_out)&(~valid_in) -> reqC':=false;ackC':=true;data4_in':=false;data':=false;s':=true
[] (data)&(s)&(reqC)&(req2)&(~ackC)&(~ack4)&(~valid_out)&(~valid_in) -> reqC':=false;ackC':=false;data4_in':=false;data':=true;s':=true
[] (data)&(s)&(reqC)&(~req2)&(ackC)&(~ack4)&(~valid_out)&(~valid_in) -> reqC':=false;ackC':=true;data4_in':=false;data':=true;s':=true
[] (~data)&(~s)&(~reqC)&(req2)&(~ackC)&(~ack4)&(~valid_out)&(valid_in) -> reqC':=true;ackC':=false;data4_in':=false;data':=false;s':=true
[] (~data)&(~s)&(~reqC)&(~req2)&(ackC)&(~ack4)&(~valid_out)&(valid_in) -> reqC':=true;ackC':=true;data4_in':=false;data':=false;s':=true
[] (data)&(~s)&(~reqC)&(req2)&(~ackC)&(~ack4)&(~valid_out)&(valid_in) -> reqC':=true;ackC':=false;data4_in':=false;data':=true;s':=true
[] (data)&(~s)&(~reqC)&(~req2)&(ackC)&(~ack4)&(~valid_out)&(valid_in) -> reqC':=true;ackC':=true;data4_in':=false;data':=true;s':=true
[] (~data)&(~s)&(~reqC)&(~req2)&(~ackC)&(~ack4)&(~valid_out)&(~valid_in) -> reqC':=false;ackC':=false;data4_in':=false;data':=false;s':=false
[] (~data)&(~s)&(~reqC)&(req2)&(ackC)&(~ack4)&(~valid_out)&(~valid_in) -> reqC':=false;ackC':=true;data4_in':=false;data':=false;s':=false
[] (data)&(~s)&(~reqC)&(~req2)&(~ackC)&(~ack4)&(~valid_out)&(~valid_in) -> reqC':=false;ackC':=false;data4_in':=false;data':=true;s':=false
[] (data)&(~s)&(~reqC)&(req2)&(ackC)&(~ack4)&(~valid_out)&(~valid_in) -> reqC':=false;ackC':=true;data4_in':=false;data':=true;s':=false endatom endmodule
11