Formal Model of a Protocol Converter

Jing Cao Albert Nymeyer

School of Computer Science and EngineeringThe University of New South Wales

Sydney 2052, AustraliaEmail:{jcao, anymeyer}@cse.unsw.edu.au

Abstract

Reuse of components is a burgeoning field in chipdesign. Shorter time to market and assured qual-ity are just two good reasons to reuse previously en-gineered components. Problems arise however whenchip designers need to interface these components asthey typically conform to different standards, or nostandards at all. The popular model of interfacingcomponents such as protocols is via a ‘converter’ thattranslates data between the components. We developa theoretical model of a converter that will enabletwo given arbitrary protocols to communicate. Thismodel includes buffers. We formally define correct-ness conditions, and guarantee that the resulting con-verter satisfies these conditions. We also allow thedesigner to define his own (CTL) conditions. As well,we allow protocols to be nondeterministic, and weensure only valid data is sent to the converter. Theverification of the conditions is carried out by a modelchecker (not reported in this work). We have imple-mented our theoretical model and we present experi-mental results.

Keywords: component reuse, formal verification, pro-tocol converter, converter synthesis

1 Introduction

In the semiconductor industry, a key challenge is theability to reuse components such as Intellectual Prop-erty (IP) that has been developed elsewhere (Mullane& MacNamee 2008). The drive to reuse existing tech-nology has become central to design particularly inthe development of Systems-on-Chip. The aims ofreuse are to reduce the design development time andto increase quality. It is reported for example (Keat-ing & Bricaud 1999) that 70% of time and money inchip design is spent on verification, including bothverification for each single component and communi-cation between multiple components. It would be aboon to the industry to have technology that enabledpre-verified IPs to be reused at will.

Reuse in design is fraught with difficulties howeveras most IPs have different interfaces based on differ-ent control and data protocols, different formats, or

We would like to thank the referees for their helpful comments.As well, we are grateful to Karin Avnit from the Universityof New South Wales for her insightful suggests that led to abetter paper and to Thang Hoai Bui for his assistance with theimplementation.

Copyright c©2009, Australian Computer Society, Inc. This pa-per appeared at the Fifteenth Computing: The AustralasianTheory Symposium (CATS2009), Wellington, New Zealand.Conferences in Research and Practice in Information Technol-ogy (CRPIT), Vol. 94, Rod Downey and Prabhu Manyem, Ed.Reproduction for academic, not-for profit purposes permittedprovided this text is included.

Figure 1: A model of a converter that interacts withtwo protocols P1 and P2

even different timing. We refer to these differencesas mismatches. To reuse IPs, we can deal with thesemismatches by building a converter that translatesthe signals from each IP to match the other. Thisbuilding process is called converter synthesis. Thereare important fundamental issues that need to beaddressed when considering synthesising a converter.For example, what kind of mismatches can we cor-rect? What kind of mismatches can’t we correct?When does a converter not exist? Is there more thanone kind of converter possible? How do we know thata converter is correct?

In Figure 1 we depict our model of a system com-prising two protocols and a converter. The labels dsand cs in this figure denote data and control (resp.)that are sent by the protocols, and dr and cr dataand control (resp.) that are received by the two pro-tocols. For the sake of simplicity we limit this work toIPs that share a clock and work synchronously. Notein this depiction we have separate data and controlchannels connecting the IPs with the converter, anda separate buffer in the converter attached to eachdata channel. The buffers are used to collect data,which is required to correct certain types of mismatch.While our work is based on a converter with preciselytwo buffers, more or less buffers could also be con-templated, and this would not change the underlyingtheory.

There are many potential sources of mismatch insuch a system. For example, data or even controlsent by one protocol may not be handled by the otherprotocol, or vice versa, one protocol may need datathat the other is not able to provide. Different datawidths is also a reason for data mismatch. For exam-ple, one protocol may use 8-bit data, the other 16-bitdata. There are mismatches that can be corrected,and mismatches that cannot be corrected. The aimof this work is to synthesise a converter that providesthe “glue-logic” that corrects the former, and avoidsthe latter.

In the next section we describe background re-search. In Section 3 we formally define the compo-

nent protocols in terms of finite-state automata, andwe address the issue of nondeterminism, which we willsee plays an important role in finding mismatches.The synthesis of a converter is based on the notionof the parallel composition of the components’ be-haviour, expressed as states of an automaton. Weformally define the parallel composition of two pro-tocols, and extend this definition to include the keynotions of stored data (i.e. buffers) and properties.To determine whether a converter exists or not, weneed to define the notion of correct behaviour. Intheory many definitions of correctness are possible,and naturally, the stricter we define correctness, themore difficult it is to synthesise a converter, and thegreater the likelihood that no converter exists. Ex-amples of conditions that we use are that the buffersmust never overflow or underflow, and the converternever receives invalid control signal or data from aprotocol. We also allow the designer to define tem-poral properties that the converter must satisfy. Thetemporal formalism that we use is CTL (Clarke et al.2000). During formal verification, any state and tran-sition in the extended parallel composition that vio-lates a correctness condition is pruned. If no stateremains then a converter does not exist. Otherwise,the resulting pruned converter must be correct w.r.t.the correctness conditions. We further define a con-verter to minimise the converter size, which behavesexactly the same as an original converter.

We have implemented our converter and ex-perimented with various protocols, including pro-ducer/consumer, pipeline, handshake and AMBAprotocols. A brief description of our implementationcan be found in Section 4. In Section 5, we presentthe results of synthesising converters between theseprotocols. In Section 6 we compare our work withrelated work, and we discuss the contribution of ourwork. Finally in Section 7 we present our conclusionsand discuss future work.

2 Background

We can classify previous work on defining a method-ology to build a converter into constructive ap-proaches (Androutsopoulos et al. 2003, Ihmor et al.2005, Roychoudhury et al. 2004, Shin & Gajski2002, Watanabe et al. 2007) and reductive ap-proaches (Akella & McMillan 1991, Androutsopouloset al. 2004, Avnit et al. 2008, D’Silva et al. 2004b,Passerone et al. 2002, Sinha et al. 2007, 2008b,a).These two approaches are complimentary. In the con-structive approach, the given protocols are analysed(often some kind of decomposition is used) revealingthe underlying ‘transactions’ that occur. These arethen used to build a state machine ‘from the groundup’, and along the way, buffers and timing considera-tions may be included, for example. In the reductiveapproach, all possible behaviours of the converter aremodelled, and those behaviours that are invalid areremoved, leaving a converter consisting of only validstates and transitions.

The reductive approach in particular lends itselfto formal methods. Research in this area dates backto the work by Green (1986). The work by Akella& McMillan (1991) first suggested using a productfinite-state machine and removing invalid states tosynthesise a protocol converter. Works by Passeroneet al. (1998) and then by Androutsopoulos et al.(2004) extended this research by ‘unrolling’ the prod-uct machine, analysing the data paths, and removingthose that represent undesirable behaviour. Whengiven a choice, they also removed data paths that pro-duced lower performance in terms of the data trans-fer rate. This involved graph theoretic algorithms.

The resulting converter has data paths with maxi-mum bandwidth.

D’Silva et al. (2004b) extended that work by for-mally modelling control and data separately, usingbuffers, and dealing with the problem of data mis-match explicitly. Very recently, that work was de-veloped further by Avnit et al. (2007, 2008) who im-proved the underlying formal model, added formaldefinitions of compatibility and of correctness, anddeveloped algorithms to implement the formal model.They use their formal correctness definition to drivethe pruning algorithm that iteratively removes ‘in-valid’ states and transitions from the product au-tomaton until a ‘fixed point’ is reached. The resultingconverter is called the most general converter, and isprovably correct w.r.t. their correctness conditions.Work not yet carried out by the authors includes re-moving all unreachable states from their most generalconverter, optimising the converter in terms of size(for example).

The starting point of our work was the researchfrom Sinha et al. (2007, 2008b,a). That work takes adifferent approach, integrating model-checking tech-nology, normally used in verification, to synthesisea converter. Using this approach, correctness is not(only) ‘hard-wired’ into the synthesis algorithms butis also specified in CTL instead. A comparison of theirwork and ours requires some basic technical under-standing of the approach. Accordingly, we postponeany further discussion until after the presentation ofour work.

3 Formal definitions

The general communication system in Figure 1 con-sists of two protocols and a converter with two buffers.To build this system, we first formally define a proto-col, and then develop a formal model of a converter.Definition 3.1 ProtocolA protocol P can be represented by a finite-state

machine 〈S, Σ, δ, i, f〉 where:

• S is a finite, non-empty set of states.

• Σ = Σs ∪ Σr is a finite set of send and receiveactions. Σs and Σr may not be disjoint.

• δ is a state-transition function: δ ⊆ S× 2Σ → S,which defines transitions that are labelled by zeroor more send and receive actions. For each tran-sition tl ∈ δ, tl = (si, A(tl), sj), where si, sj ∈ Sand A(tl) ⊆ Σ labels the transition by actions.

• i ∈ S and f ∈ S are the initial and final statesrespectively.

¤Notation In general text we write a! to indicate asend action a ∈ Σs, and a? to indicate a receive ac-tion a ∈ Σr. Furthermore, we write a# to indicatesome receive action b, where b ∈ Σr−{a} and a ∈ Σr.Transitions that are not labelled by any actions arelabelled by τ instead, i.e. the protocol has receivednothing in the transition. In practice, they may cor-

respond to timeouts for example. We write siA(ti)−→ sj

if δ(si, A(ti)) = sj for states si, sj ∈ S, and transitionlabel A(ti) ⊆ Σ. We also assume a protocol satisfiesthe following conditions:

a1. One transition occurs in each clock cycle.

a2. If there are both send and receive actions in atransition, then all receive actions must precedesend actions.

Figure 2: Two protocols: P1 can produce and con-sume data and P2 consumes data

a3. Each state can eventually reach the final state.

Example 3.2 The protocol P1 in Figure 2can be represented as a finite-state machine〈S, Σ, δ, i, f〉, where S = {s1, s2, s3, s4, s5}, Σ ={rin, rout, dout, etc}, δ = {s1

τ−→ s1, s1rout!−→

s2, s1rin!−→ s3, etc} and i = f = s1. Similarly for

protocol P2: S = {s1, s2}, Σ = {a, r, d}, δ = {s1r#−→

s1, s1r?a!−→ s2, s2

d?−→ s1} and i = f = s1.¤

Note in P1 in Figure 2 that the state s1 has onlytransitions with no input. This state is therefore non-deterministic as no external component can controlwhich outgoing transition will be taken. This canbe a problem because one of the transitions of such anondeterministic state may lead to correct behaviour,but another may be ‘invalid’, in the sense it may gen-erate control or data that the other protocol cannothandle. For example, in P1 in Figure 2, hypotheti-cally rout! may be correct, but rin! may not be. Ingeneral, any data that is sent to the converter as aresult of such an invalid transition is referred to asinvalid input to the converter. Recognising the exis-tence of nondeterministic states that may generate in-valid data is important in defining correct behaviour,as we shall see later. In the following definition, wedefine nondeterminism in a protocol.Definition 3.3 Non-deterministic (ND) protocolWe are given a protocol P = 〈S, Σ, δ, i, f〉 where Σ =Σs∪Σr as shown in Definition 3.1, and a state s ∈ S,via n > 1 outgoing transitions t1, . . . , tn ⊆ δ, canreach its children δ(s,A(t1)), . . . , δ(s,A(tn)) that aredenoted by s1, . . . , sn. For each outgoing transitionlabel A(ti), 1 ≤ i ≤ n, we denote its receive actionsby Σr,ti ⊆ Σr.For ∃l, m ∈ 1..n and l 6= m, if s has children sl =δ(s,A(tl)) and sm = δ(s, A(tm)) such that

• sl 6= sm and

• Σr,tl= Σr,tm

then s is a nondeterministic state and P is a non-deterministic protocol. Moreover, the children sl andsm are referred to as twins. We can of course simplyextend the notion of twins to triplets, quadruplets andso on.

¤In essence, a ND state has different transitions

that have identical receive actions in the labels. Note,however, that transitions from a state must be uniqueso the send actions must differ in that case. The con-sequence of this is that δ in Definition 3.1 is a func-tion.

Figure 3: The parallel composition P1||P2

3.1 Parallel composition of protocols

Having defined the protocols, the first step in thederivation of a converter is to define the parallel com-position of two protocols.Definition 3.4 Parallel composition of two protocols

Given two protocols P1 = 〈Sa,Σa, δa, ia, fa〉 andP2 = 〈Sb, Σb, δb, ib, f b〉, where each transition tl ∈ δa

denotes (si, A(tl), sj) in P1 and similarly t′l ∈ δb de-notes (s′i, A

′(t′l), s′j) in P2 as shown in Definition 3.1,

the parallel composition P1||P2 is defined as a finite-state machine 〈S′, Σ′, δ′, i′, f ′〉, where

• S′ = Sa × Sb

• Σ′ = Σas ∪Σa

r ∪Σbs∪Σb

r, where Σa = Σas ∪Σa

r andΣb = Σb

s ∪ Σbr.

• δ′ ⊆ S′×2Σa×2Σb → S′, where each transition islabelled by zero or more send and receive actionsfrom Σa and Σb. For all tl ∈ δa and t′l ∈ δb,∃tlt′l ∈ δ′, where tlt

′l = (sis

′i, A(tl), A′(t′l), sjs

′j).

• i′ = iaib ∈ S′ is the initial state and f ′ = faf b ∈S′ the final state.

¤Notation Graphically, we separate the transition la-bels from Σa and Σb by “|”. For example, x?|y! meansthat process P1 receives signal x, at the same time asprocess P2 sends signal y, where x ∈ Σa

r and y ∈ Σbs.

We write si,jA(tl)|A(t′l)−→ sg,h if δ′(si,j , A(tl), A(t′l)) =

sg,h for states si,j , sg,h ∈ S′, where transition labelA(tl) ⊆ Σa and A(t′l) ⊆ Σb. Note that for conveniencewe write si,j to denote sisj .Example 3.5 The parallel composition of proto-cols P1 and P2, shown in Figure 3, can be writtenas 〈S′, Σ′, δ′, i′, f ′〉, where S′ = {s1,1, s1,2, etc}, Σ′ =

{din, ack, r, etc}, δ′= {s1,1τ |r#−→ s1,1, s1,1

rout!|r#−→ s2,1,

s1,1rout!|r?a!−→ s2,2, s1,1

τ |r?a!−→ s1,2, etc}, i′ = f ′ = s1,1.¤

We now define a so-called extended parallel com-position of the given protocols, and in so doing, intro-duce data storage and the set of properties that theparallel composition is expected to satisfy. A counteris used to record the number k of data items that needto be stored in a given state. The counter is denotedby variable k, which is incremented and decrementedas data is received by and sent from the converter.The properties are expressed as CTL formulae. Each

Figure 4: A fragment of the extended parallel com-position P1||eP2.

formula that is true in a given state is included in thestate.Definition 3.6 Extended parallel composition (EPC)of two protocols

We are given a parallel composition P1||P2 =〈S′, Σ′, δ′, i′, f ′〉 where Σ′ = Σa ∪ Σb, and each tran-sition tlt

′l ∈ δ′ expresses (sis

′i, A(tl), A′(t′l), sjs

′j), as

shown in Definition 3.4. As well, we are given twosets of integers K1 and K2. An EPC P1||eP2 isdefined by an Extended Labelled Transition SystemP1||eP2 = 〈Se,Ψ, L, Σe, δe, ie〉, where

• Se ⊆ S′ ×K, where K = K1 ×K2. The integersk1 ∈ K1 and k2 ∈ K2 are the values of counters(which count the number of data elements in thecurrent state).

• Ψ is a set of temporal boolean formulae.

• L is a state labelling function: Se → 2Ψ.

• Σe = Σ′

• δe ⊆ Se × (2Σa × 2Σb

) → Se, where each tran-sition is labelled by zero or more actions fromΣa and Σb. For all tlt

′l ∈ δ′, we generate a set

of transitions in δe, with each member tmt′m =(sis

′ik, A(tl), A′(t′l), sjs

′jk′).

• ie = (i′, k) ∈ Se, where k = (0, 0).

¤Notation We denote (si,j , k) as si,j,k and(si,j , (k1, k2)) as si,j,k1k2 .Example 3.7 Given the PC P1||P2 shownin Figure 3, we can derive an EPC P1||eP2 =〈Se, Ψ, L, Σe, δe, ie〉 shown in Figure 4, where Se ={s1,1,00, s1,1,10, s1,2,10, etc}, Ψ = {φ1 : AG(s1,1,00 →AXAFs1,1,00), φ2 : ∀si,j,k ∈ Se, (0 ≤ k1 ≤ 1) ∧(0 ≤ k2 ≤ 1), φ3 : AG(s1,1,00 → AXAF((dout! ∨din?) ∧ d?))}, L = {s1,1,00 → {φ1, φ2, φ3}, etc},Σe = {din, ack, r, etc}, δe = {s1,1,00

rout!|r#−→s2,1,00, s2,1,00

ack#|r#−→ s2,1,00, etc}, ie = s1,1,00. Weassume the I/O data in this EPC has width of 1 unit.

¤

Note we have not yet placed any limit on the coun-ters, hence the EPC may contain an infinite numberof states.

Just like a protocol, an EPC may be nondetermin-istic. Similarly to Definition 3.3, we define a nonde-terministic EPC as follows.Definition 3.8 Nondeterministic (ND) EPCWe are given an EPC P1||eP2 = 〈Se, Ψ, L, Σe, δe, ie〉,and a state si,j,k ∈ Se with n > 1 outgoing transi-tions t1t

′1, . . . , tnt′n ⊆ δe.

If ∃l, m ∈ 1..n with l 6= m, assume we havetwo transitions δe(si,j,k, A(tl), A(t′l)) = sl,l′,k′ andδe(si,j,k, A(tm), A(t′m)) = sm,m′,k′′ . If one of the fol-lowing 3 cases occurs:

• t′l = t′m and si ∈ SP1 is ND (because of tl andtm as shown in Definition 3.3)

• tl = tm and sj ∈ SP2 is ND (because of t′l andt′m)

• si ∈ SP1 is ND (because of tl and tm); and sj ∈SP2 is ND (because of t′l and t′m)

then the children sl,l′,k′ and sm,m′,k′′ are twins. Hencestate si,j,k is ND and the EPC is ND.

¤Example 3.9 The EPC in Figure 4 is ND be-cause the state s1,1,00 is ND; caused by the transitionsrin!|r# and rout!|r#. The states s3,1,00 and s2,1,00are twins.

¤

3.2 Raw converter

There are many EPCs corresponding to any given twoprotocols, each exhibiting possibly quite different be-haviour. For example, the counters in the EPC mayviolate bounds that we would wish to impose on animplementation (where we use buffers to store datafor example). By applying correctness conditions toan EPC, we define a model of a raw converter for theprotocols.Definition 3.10 Raw converterWe are given an EPC P1||eP2 = 〈Se,Ψ, L, Σe, δe, ie〉

and two buffers with size q1 and q2, where Se ⊆S′ × K, K = K1 × K2 and Σe = Σa

s ∪ Σar ∪ Σb

s ∪Σb

r as shown in Definition 3.6. As well, we aregiven a final state f ′ from P1||P2 = 〈S′, Σ′, δ′, i′, f ′〉as shown in Definition 3.4. A raw converterP1||RP2 is defined by an extended finite-state machine〈SR, ΨR, LR,ΣR, δR, iR, fR〉 where:

• SR ⊆ Se is a finite set of states, and writtenas SR ⊆ S′′ × K ′, where S′′ ⊆ S′ and K ′ =(K ′

1 ×K ′2), where K ′

1 ⊆ K1, K ′2 ⊆ K2. In each

state si,j,k ∈ SR where k = (k1, k2), we have0 ≤ k1 ≤ q1 and 0 ≤ k2 ≤ q2.

• ΨR ⊆ Ψ is a set of boolean formulae.

• LR is a state labelling function: SR → 2ΨR

, andthe label in each state si,j,k is LR(si,j,k) = Φz,such that ∀si,j,k ∈ SR, we have si,j,k |= Φz.

• ΣR ⊆ Σ′, and ΣR can be written as ΣRa ∪ ΣRb ,where ΣRa = ΣRa

s ∪ ΣRar , ΣRb = ΣRb

s ∪ ΣRbr ,

where ΣRas ⊆ Σa

r , and ΣRar ⊆ Σa

s ; ΣRbs ⊆ Σb

r andΣRb

r ⊆ Σbs.

• δR ⊆ SR × (2ΣRa × 2ΣRb ) → SR, where eachtransition is labelled by zero or more actions fromΣRa and ΣRb .

Figure 5: Two protocols and their corresponding rawconverter Q1||RQ2.

• iR = ie, and fR = (f ′, 00). Each si,j,k ∈ SR willeventually reach fR.

¤If SR 6= ∅ then a raw converter exists, and the

given protocols are said to be compatible. Otherwise,a raw converter does not exist, and the given protocolsare said to be incompatible.

We need to remember here that a converter is aninterface between two protocols. In the definition ofΣR, we see actions are reversed at the interfaces be-tween the protocols and the raw converter: the sendactions in each protocol become receive actions in theraw converter, and the receive actions in each proto-col become send actions in the raw converter. Noteas well that action a# becomes the empty action τ ,and τ remains the same.

In P1, in each transition t|t′ ⊆ δR, the label con-sists of A(t) = Σts ∪ Σtr and A(t′) = Σ′ts

∪ Σ′tr,

where Σts ⊆ ΣRas and Σtr ⊆ ΣRa

r . Similarly in P2,Σ′ts

⊆ ΣRbs and Σ′tr

⊆ ΣRbr . In the raw converter, all

send actions Σts and Σ′tsprecede receive actions Σtr

and Σ′tr. This is of course the opposite of what hap-

pens in each given protocol where all receive actionsprecede send actions. This action reversal preservesthe order of the signals in the raw converter, and in-tuitively is what we expect.Example 3.11 Consider the two protocols and theresulting raw converter in Figure 5. We notice thatthe raw converter must send a and b concurrentlybefore receiving any signal.

¤Example 3.12 Corresponding to the EPCP1||eP2 shown in Figure 4, we can generate theraw converter P1||RP2 shown in Figure 6 withq1 = 1 and q2 = 0. The raw converter can bewritten as 〈SR,ΨR, LR, ΣR, δR, iR, fR〉, whereSR = {s1,1,00, s1,1,10, etc}, ΨR = {φ1 : AG(s1,1,00 →AXAFs1,1,00), φ2 : ∀si,j,k ∈ SR, (0 ≤ k1 ≤ 1) ∧ (0 ≤k2 ≤ 1), φ3 : AG(s1,1,00 → AXAF((dout? ∨din!) ∧ d!))}, LR = {s1,1,00 → {φ1, φ2, φ3}, etc},ΣR = {ack, r, d, etc}, δR = {s2,1,00

ack!|τ−→s4,1,00, s2,1,00

ack!|r!a?−→ s4,2,00, s4,2,00dout?|d!−→

s1,1,00, etc}, and iR = fR = s1,1,00.¤

We mentioned earlier that nondeterminism in aprotocol may lead to invalid output being sent to theconverter. We in fact have this problem in the rawconverter in the example above. Before we examinethis example more closely, however, we formally de-fine invalid output in an EPC.Definition 3.13 Invalid outputWe are given a ND state si,j,k ∈ Se in an EPC

P1||eP2 = 〈Se, Ψ, L, Σe, δe, ie〉, and a resulting raw

Figure 6: A raw converter P1||RP2 that cannot handleall inputs

converter P1||RP2 = 〈SR, ΨR, LR,ΣR, δR, iR, fR〉.Assume the state si,j,k is ND because of its outgoingtransitions tlt

′l and tmt′m (both in δe). The set of send

actions for tlt′l can be written as Σa

ls(from P1) and

Σbls

(from P2). Similarly, the set of send actions fortmt′m can be written as Σa

ms(from P1) and Σb

ms(from

P2). The set of send actions in tmt′m that are differ-ent to those in tlt

′l can be written as Σa

o = Σams−Σa

ls

from P1 and Σbo = Σb

ms−Σb

lsfrom P2. Let us assume

the transition labels in tlt′l and tmt′m after reversal

are called t̄l t̄′l and t̄mt̄′m respectively. If t̄lt̄′l ∈ δR

and t̄mt̄′m /∈ δR then every action in Σao (if any) is an

invalid output at si,j,k. Similarly, every action in Σbo

(if any) is an invalid output at si,j,k.¤

Note that the transitions tlt′l and tmt′m generate

states that are twins. The existence of twins is onlya problem if there is any invalid output.

After reversal, send actions in an EPC become re-ceive actions in a raw converter, so invalid outputsin an EPC correspond to invalid inputs in the rawconverter. We define that below.Definition 3.14 Invalid inputIf a ∈ Σa

o (or b ∈ Σbo) is invalid output at si,j,k in the

EPC defined in Definition 3.13, then a (or b) is invalidinput at si,j,k in the corresponding raw converter.

¤We require that for all si,j,k ∈ SR of a raw con-

verter, no invalid inputs occur.Example 3.15 Let us reconsider the EPC from theprevious example, namely P1||eP2 shown in Figure 4.The state s1,1,00 in this EPC is ND because of thetransitions labelled by rin!|r# and rout!|r# (for ex-ample). Applying Definition 3.13 to this EPC, we findtransition tlt

′l = (s1,1,00, rout!, r#, s2,1,00) after re-

versal corresponds to t̄lt̄′l = (s1,1,00, rout?, τ, s2,1,00),which is included in P1||RP2. However, transi-tion tmt′m = (s1,1,00, rin!, r#, s3,1,00) corresponds tot̄mt̄′m, which does not exist in P1||RP2. Hence ac-tion rin! is invalid output at s1,1,00 in the EPC, andrin? is invalid input at s1,1,00 in the raw converterP1||RP2. The conclusion is that the raw converterP1||RP2 is invalid. In fact, the protocols P1 and P2are incompatible.

¤Determining whether a raw converter will handle

all input is an important part of determining correct-ness. We address correctness in the next section.

3.2.1 Correct Raw Converter

In Definition 3.10, we include properties that the userimposes (expressed as formulae), and various otherproperties are implied. For example, invalid inputnever occurs, and the final state is reachable from ev-ery state. We formalise all these properties by defin-ing correctness conditions that a raw converter mustsatisfy.Definition 3.16 Correctness conditions

Given an EPC, a raw converter P1||RP2 =〈SR, ΨR, LR,ΣR, δR, iR, fR〉 with two buffers of sizeq1 and q2 is correct if for each state si,j,k ∈ SR, wherek = (k1, k2), all of the following conditions hold:

c1: user properties The state si,j,k satisfies all for-mulae in ΨR(si,j,k): si,j,k |= ΨR(si,j,k).

c2: final reachability The final state fR is reach-able from state si,j,k.

c3: valid buffer The buffer values 0 ≤ k1 ≤ q1 and0 ≤ k2 ≤ q2 (i.e. there is no buffer overflowor underflow). In both initial state iR and finalstate fR, k1 = k2 = 0 (i.e. every received datawill eventually be sent).

c4: progress From iR, some data or control signaltransaction in ΣR can eventually be executed.

c5: valid input No invalid input occurs at si,j,k.

¤The condition c4 checks fairness and guarantees

that a raw converter makes progress. For example, araw converter that consists of only one state and oneτ self-loop transition could satisfy all the correctnessconditions but it could never communicate with an-other protocol. The condition c5 guarantees that noinvalid input will occur in the raw converter. If a twinstate is invalid, then it will violate one of the condi-tions, as a consequence, both transitions that lead tothe twins will be excluded in the raw converter.

3.2.2 Redundant Raw Converter

Before we derive a converter from a raw converter, wefirst check whether the raw converter is required at all(i.e. it is not redundant). We define a redundant rawconverter formally as follows.Definition 3.17 Redundant raw converter

We are given a raw converter P1||RP2 =〈SR, ΨR, LR,ΣR, δR, iR, fR〉 with two buffers, whereΣR = ΣRa

s ∪ ΣRar ∪ ΣRb

s ∪ ΣRbr as shown in Defini-

tion 3.10. Each transition label (A(tl), A(t′l)) can bewritten as Σa

l,s ∪ Σal,r, Σ

bl,s ∪ Σb

l,r, where Σal,s ⊆ ΣRa

s ,Σa

l,r ⊆ ΣRar , Σb

l,s ⊆ ΣRbs and Σb

l,r ⊆ ΣRbr . If the fol-

lowing conditions:

• For each transition label (A(tl), A(t′l)), we haveΣa

l,s = Σbl,r and Σa

l,r = Σbl,s = ∅; or Σa

l,r = Σbl,s

and Σal,s = Σb

l,r = ∅.• In each state si,j,k ∈ SR where k = (k1, k2), we

have k1 = 0 and k2 = 0.

are both satisfied, then P1||RP2 is a redundant rawconverter.

¤

If a raw converter is redundant then the given pro-tocols are compatible even without the raw converter.Example 3.18 The raw converter Q1||RQ2 shownin Figure 5 is redundant.

¤

3.3 Converter

The raw converter defined in Definition 3.10 may con-tain a very large number of states because the buffervalues are included in the states. Following Avnitet al. (2008), we merge states by extracting thesebuffer values from each state and making them condi-tions in the corresponding transitions. The result ofthis merge operation is the actual converter. In gen-eral, two states si,j,k and si,j,k′ in a raw converter aremerged to one state si,j in the converter. The con-verter has precisely the same behaviour as the rawconverter w.r.t. the given protocols.

Another advantage of this process is that the usercan increase the buffer size to increase the data trans-fer rate (for example), but not increase the numberof states in the converter (this is future work).Definition 3.19 Converter

We are given a raw converter P1||RP2 =〈SR, ΨR, LR,ΣR, δR, iR, fR〉 and 2 buffers with sizeq1 and q2. The raw converter states SR ⊆ S′′ ×K ′,where K ′ = K ′

1 ×K ′2. Each state si,j,k ∈ SR where

k = (k1, k2). As well iR = (i′, 00), fR = (f ′, 00)and ΣR = ΣRa ∪ΣRb as shown in Definition 3.10 andDefinition 3.6. A converter P1||CP2 is defined by anextended FSM 〈Sc, Lc, Σc, δc, ic, f c〉, where:

• Sc = S′′ is a finite set of states, where eachstate si,j ∈ Sc is merged from a set of statesin the raw converter Si,j = {si,j,k|si,j,k ∈SR}, which are called source states. For allstates in Si,j , we write the set of all theiroutgoing transitions as Ti,j = {tltm|∀si,j,k ∈Si,j , δ

R(si,j,k, A(tl), A(tm)) ∈ SR}.• Σc = ΣR is a set of actions.

• Lc is a labelling function: Sc × 2ΣRa × 2ΣRb →(2K′

1 , 2K′2), where for each si,j ∈ Sc we have its

source states Si,j with transitions Ti,j . Then, foreach tltm ∈ Ti,j , we have Lc(si,j , A(tl), A(tm)) =(L1, L2) where L1 = {k1|si,j,k1k2 ∈Si,j , δ

R(si,j,k1k2 , A(tl), A(tm)) ∈ SR}, L2 ={k2|si,j,k1k2 ∈ Si,j , δ

R(si,j,k1k2 , A(tl), A(tm)) ∈SR} are sets of natural numbers.

• δc ⊆ Sc × 2ΣRa × 2ΣRb × (2K′1 , 2K′

2) → Sc. Eachtransition T that starts from si,j is labelled byA(tl) and A(tm) where tltm ∈ Ti,j , and two setsof natural numbers Lc(si,j , A(tl), A(tm)).

• ic = i′ and f c = f ′.

¤Example 3.20 Consider the protocols U1and U2 shown in Figure 7, and the corre-sponding raw converter U1||RU2 shown in Fig-ure 8. We can derive a corresponding converterU1||CU2 = 〈Sc, Σc, Lc, δc, ic, f c〉 shown in Fig-ure 9, where Sc = {s1,1, s1,2, s2,1, s2,2, s4,1, s4,2},Σc = {ack, r, d, rout, dout, a}, Lc = {(s1,1, τ |τ) →{0, 1}, (s1,1, rout?|τ) → {0, 1}, etc}, δc = {s1,1

τ |τ,0..1−→s1,1, s1,1

rout?|τ,0..1−→ s2,1, s2,1τ |τ,0..1−→ s2,1, s2,1

ack!|τ,0..0−→

Figure 7: Protocols U1 and U2 that produce and con-sume data

Figure 8: A raw converter U1||RU2 with q = 1

Figure 9: A converter U1||CU2

Figure 10: The formal derivation of the converter.

Figure 11: The width of data to and from the buffers

s4,1, etc}, ic = f c = s1,1. Here, i..j denotes a value inthe range from i to j.

¤

4 Implementation

In Figure 10 we graphically represent the formalderivation of the converter. In this figure, we present:

1. protocols (Definition 3.1)

2. parallel composition (Definition 3.4)

3. extended parallel composition (Definition 3.6)

4. raw converter (Definition 3.10)

5. correctness conditions (Definition 3.16)

6. converter (Definition 3.19)

To implement the converter, we first need to gener-ate the PC. We then add counter values and temporalformulae to each state in the PC to generate the EPC.The EPC is pruned by enforcing the correctness con-ditions, and placing bounds on the counters, resultingin a raw converter. The width of data in each of theprotocols plays an important role in calculating thebounds on the counters. These bounds determine thesizes of the buffers.

4.1 Buffers

We assume the buffers are arranged between the pro-tocols as shown in Figure 11. In the figure, protocolP1 sends and receives data that is x bits wide, andprotocol P2 sends and receives data that is y bits wide.

Let us consider Buffer1 in this figure. The valuesof x and y will determine the size of the buffer q1, inthe following way:

q1 = 0 if one of the following cases is true:

• at least one of ds and d′r is ∅• x = y, ds and d′r are non-empty, and in the

parallel composition:– ds and d′r always occur together in the

same transition– ds and d′r sometimes occur in the same

transition, and only ds occurs in someother transitions

– ds and d′r sometimes occur in the sametransition, and only d′r occurs in someother transitions

q1 = dy/xe × x if x < y

q1 = x if x > y; or x = y and ds and d′r always occurin different transitions

As x, y are both finite, q1 must be finite. If q1 = 0then this buffer is not necessary of course. We cansimilarly calculate the minimum size q2 of Buffer2.

4.2 Computing the EPC

The number of states in the PC (see Definition 3.4)is |SP1 | × |SP2 |, where |SP1 | and |SP2 | are the (finite)number of states in P1 and P2 respectively. The EPC(Definition 3.6) may contain an infinite number ofstates due to the presence of the buffers. To generatethe EPC, we apply an on-the-fly, depth-first traversalalgorithm to the PC. During the traversal, if we reacha state si,j via a transition labelled with ds (say), thenthe counter k1 = k1 + x because x bits have beenread. Similarly, if the label is d′r, then k1 = k1 − ybecause y bits have been sent. The new counters k1and k2 are added to si,j to produce an EPC statesi,j,k. If si,j,k does not exist in the EPC, the state isadded, otherwise the existing state si,j,k is updatedby adding another outgoing transition. The algorithmterminates when no more changes can be made to thestates, corresponding to a fixed point. The resultingnumber |Se| of states in the EPC will be at most|S′| × q1 × q2.

Checking the correctness conditions for each stateis an important task of the algorithm.

4.3 Checking the correctness conditions

If any state in the EPC violates any of the correctnessconditions c1 . . . c5, then we prune (i.e. remove) thestate together with all of its transitions. We checkeach condition in the following way.

c1 Following Sinha et al. (2006), we apply the tableaumethod to model check the temporal formulae.

c2 We can check that each state eventually reachesthe final state by checking the formula:

φ1 : ∀si,j,k ∈ Se, AG(si,j,k → AXAF(f ′, 00))

c3 The counters are checked whenever they are mod-ified in a state.

φ2 : ∀si,j,k1k2 ∈ Se, (0 ≤ k1 ≤ q1) ∧ (0 ≤ k2 ≤ q2)

The condition that all received data will eventu-ally be sent is checked by φ1.

c4 We check that a raw converter can eventually exe-cute data and control actions using the formula:

φ3 : AG(ie → (AXAFΣa))

where Σa ⊆ Σe is a non-empty set of data andcontrol actions in the EPC.

Figure 12: The relationship between buffer size q andthe number of states |S| for the raw converter U1||RU2with different ratios of data widths

c5 The tableau method cannot verify that invalid out-puts never occur. This is done during the traver-sal. If the current state has twins, then tran-sitions to both states are removed. Note thatstates may have more than one parent, so thestates themselves may need to remain. Laterwe backtrack to the parent states of any prunedstates to check their correctness again.

In this work, φ1, φ2 and φ3 are included in Ψ to syn-thesise a raw converter that satisfies Definition 3.10.For example, we showed in Example 3.7 that formulaefrom Ψ are labels of states.

4.4 Deriving a converter

The result of our on-the-fly EPC construction is anEPC that satisfies the correctness conditions. To nowderive a raw converter, each action needs to be re-versed (see Definition 3.10). As well, the counters k1and k2 are bound by q1 and q2. The number of statesin a raw converter is then |S′| × q1 × q2. We checkthe raw converter to see if it is redundant (see Defi-nition 3.17). Finally we merge states by eliminatingcounters from states and making them restrictions onoutgoing transitions of si,j,k. This results in a con-verter.

5 Experiments

Algorithms corresponding to the definitions in thiswork have been implemented in JAVA 1.6. The sys-tem comprises approximately 3000 lines and runs ona PC with an Intel Pentium CPU 3.40 GHZ. We car-ried out 2 series of experiments. In the first serieswe studied the size of the raw converter for differ-ent protocol data widths and different sizes of buffer.In the second series, we compared the size of a rawconverter synthesised by our model with those fromprevious work.

5.1 Size of the converter

To illustrate the relationship between the size of theraw converter (i.e. |S|) and the size of the buffers (i.e.q) we have synthesised converters for the protocols U1and U2 shown in Figure 7. We do this for 5 differentdata-width ratios: the protocols have the same datawidth (i.e. 1:1), one protocol’s data width is half ofthe other’s (1:2 and 2:1), and one is one third of theother (1:3 and 3:1). We plot the results for the rawconverter U1||RU2 in Figure 12 and for the converterU1||CU2 in Figure 13. We see in Figure 12 that asthe size of the buffer increases, the size of the raw

Figure 13: The relationship between buffer size q andthe number of states |S| for the converter U1||CU2with different ratios of data widths

Figure 14: A producer/consumer protocol from CaseStudy 1

converter increases, ad infinitum. As well, the 1:1case generates a larger raw converter than the 2:1 and3:1 cases, and they in turn generate larger convertersthan the 1:2 and 1:3 cases.

The data in Figure 13 shows that endlessly increas-ing the size of the buffer will not necessarily changethe size of the converter, which in all cases requiresat most 6 states. However, also notice that if thereis no buffer, then a 3-state converter exists for the1:1 case, but no converter exists for each of the othercases. If we use a 1-element buffer, then a converterdoes exist for the 1:2 and 2:1 cases, but still no rawconverter exists for the 1:3 and 3:1 cases (which re-quire minimally a 2-element buffer). This is what wewould intuitively expect.

Note that a raw converter that includes a buffermay require more states than a raw converter withouta buffer. For example, the raw converter in Figure 8,which has a buffer of size 1, has 9 states. If we re-moved the buffer, the raw converter would have just3 states. Clearly, it is not the existence of the rawconverter that determines the minimum size of thebuffer, because there is a raw converter even with nobuffer. The issue here is what factors determine theminimum size? We could for example consider thedata transfer rate as being important, but this is dif-ficult to do with the existing model. We remark thatsome algorithm to minimise the buffer size is requiredto allow a converter to be synthesised.

5.2 Comparison with previous work

We have synthesised converters for protocols takenfrom the literature. The results are presented below.Case Study 1: A producer/consumer protocol usedby Sinha et al. (2006, 2008b) is shown in Figure 14.

The synthesis approach reported in that work ig-nored invalid data that can be generated by protocols.The state s2 in the producer protocol cannot reach the

x y q1 |SR| |Sc|1 1 1 24 191 2 2 31 192 1 2 30 19

Table 1: The sizes of converters for protocols in CaseStudy 2

Figure 15: Two simple protocols from Case Study 3

final state, and hence violates our assumption a3. Aswell, their converter also violates our correctness con-dition c5: for example, a ND state s3,1 in their par-allel composition has twins s0,1 and s0,2. Only one ofthe twins s0,1 is included in their converter however.There is no way for the converter to prevent the othertwin s0,2 from generating the invalid input ack. Wecannot generate a raw converter for these protocolsbecause of this, and consider them incompatible.Case Study 2: Bhaduri & Ramesh (2008), D’Silvaet al. (2004a) studied a pipeline protocol (consistingof 6 states) and a handshake protocol (consisting of4 states). (The protocols are not reproduced here.)We synthesise converters for the data widths 1:1, 1:2and 2:1. The results are shown in Table 1. In thistable, |SR| and |Sc| denote the number of states inthe raw converter and converter (resp.). We see thatif we assume different data widths in the protocols,then we generate a larger raw converter, but this rawconverter results in a converter of the same size. Thevalues of q correspond to the minimum size buffer fora raw converter to exist.

The previous authors synthesise a converter forthese protocols that has only 5 states. However, theydo not deal with data-width mismatches explicitly.Furthermore, their converter is very restricted in thatit has no explicit buffer(s), and they deal with dataand control signals only in a single direction, so theirconverter cannot be compared with ours.Case Study 3: Avnit et al. (2007) synthesised araw converter for the simple protocols shown in Fig-ure 15. If we assume a data-width ratio of 1:1, we cansynthesise a raw converter P1||RP2 using two bufferseach of size 1 (one for data and another for addresses).We also synthesised converters for these protocols as-suming data-width ratios 1:2 and 2:1. We show theresults in Table 2. As in the previous case study, ifwe assume different data widths in the protocols, thenwe generate a larger raw converter, but again this rawconverter results in a converter of the same size.

The column labelled A+ denotes the workby Avnit et al. (2007, 2008) and shows the sizes ofthe converters from these authors. The difference be-tween our converter and theirs is our converter hasone less state. The state we are ‘missing’ is s1,2 intheir work, which is sometimes unreachable: for ex-

x y q1, q2 |SR| |Sc| A+

1 1 1 6 5 61 2 2 8 5 62 1 2 9 5 6

Table 2: The sizes of converters for the protocolsshown in Figure 15

x y q1, q2 |SR| |Sc| A+

1 1 1 0 0 101 1 2 21 10 101 2 2 9 5 101 2 3 31 10 102 1 2 0 0 102 1 4 29 10 10

Table 3: The sizes of converters for ASB and APBprotocols from Case Study 4

ample in the case q = 1 with data widths 1:1. Con-verters synthesised in their work are most general inthat they may contain unreachable states for partic-ular buffer and data-width configurations. Our con-verters are synthesised for a particular configuration,and so do not contain any unreachable states.Case Study 4: Avnit et al. (2007, 2008) also stud-ied the widely-used ASB and APB protocols. Theymodel these protocols to produce state machines with5 states and 4 states respectively. They use a bufferfor data and another buffer for addresses. We syn-thesise converters for these protocols assuming data-width ratios of 1:1, 1:2 and 2:1 as above. The resultsare shown in Table 3. Since both address and dataactions are sent from the ASB and received by theAPB, it is always the case that q1 = q2. Note that wehave synthesised converters for 1:1, 1:2, and 2:1 datawidths, and with various buffer sizes. In two cases wewere not able to generate a converter, but Avnit etal. could.

As in the previous case study, Avnit et al. synthe-sise a converter that is most general in that it includesall possible states appropriate to any configuration ofdata width and buffer size. They do not address theproblem of how to ‘restrict’ the most general con-verter to suit a particular configuration. In practice,this will mean that some states in their converter areunreachable in particular configurations. In this casestudy, we note that all the states in their convertersfor the two cases mentioned above are unreachable,according to our definition of correctness of course.We also note that if we increase the buffer size inthese cases, then we can synthesise converters thatare the same size as theirs.

6 Contribution

The starting point of our research is the work of Sinhaet al. (2007, 2008b,a). Following Sinha et al., we usethe tableau method as a synthesiser of the (raw) con-verter. This aspect is not reported in this work how-ever. The formal framework we have used is different,and we have addressed different issues, as explainedbelow.Protocol and converter representation: Sinha etal. add properties and a clock to their protocol def-inition, which is modelled as a synchronous Kripkestructure, and not as we do, a finite-state machine.We define the buffer and the properties in the rawconverter state; Sinha et al. treats them as separate

entities. They do not consider nondeterminism ex-plicitly.Correctness conditions: We have a stricter defi-nition of correctness, with more conditions. HenceSinha et al. may synthesise a converter that is not cor-rect according to our definition of correctness. Theydo not appear to handle invalid data being sent to theconverter.Remove redundant raw converter: We defineand remove redundant raw converters.Buffers and data width: We defined a raw con-verter with two buffers to deal with the two-way datatransaction, while they have just one. We also ex-plicitly deal with the issue that a buffer may not berequired on a particular channel when the data widthand overall behaviour is taken into account.Converter synthesis: Our theory is based entirelyon finite-state machines. We develop an algorithm tocheck invalid data caused by nondeterminism.The contribution of our work is as follows.Protocol and behaviour composition represen-tation: We build a formal model of a converter thatis based on formal definitions of protocols, nondeter-minism and parallel composition, as well as buffersand temporal properties.Correct behaviour: We list 5 formal conditionsthat define correctness. We solve the problem of in-valid data being sent to the converter. We specificallyaddress the issue of different data widths in the givenprotocols.Buffers: As we have placed the contents of the bufferinto the states of the raw converter, the raw converterhas full knowledge and can disable communication inorder to prevent underflow or overflow. We can easilyextend the model to include more (or less) buffers.We can minimise the size of the buffers in the rawconverter by taking into account the data widths ofthe protocols.Converter synthesis: To synthesise a correct con-verter, we apply a model checker to the CTL for-mulae in the EPC. The model checker is an on-the-fly tableau algorithm based on the works from Sinhaet al. (2006, 2008b). We have modified this algorithmhowever to suit our formal model. As a result, statesin our synthesised converter are all reachable from theinitial state.Converter and redundant raw converter: Wehave defined a converter to minimise the number ofstates in a raw converter and can remove redundantraw converters.

7 Conclusion and future works

In this work we have presented a formal model of aconverter that translates data and control betweentwo protocols. We have presented a detailed deriva-tion of the model, and shown at every step workedexamples. We deal with invalid data, and nondeter-minism explicitly. Buffers and the correctness condi-tions are integrated into our model. The correctnessconditions allow the user to define his own temporalproperties as well. Our model could be further gen-eralised to accommodate any number of buffers.

We have only briefly explained several issues thatare important to the implementation, such as deter-mining the size of buffers. For reasons of space andclarity we have also not reported on the actual syn-thesis algorithm that is based on the tableau method.Details of the implementation, along with the algo-rithms, will be reported elsewhere, as will more sub-stantial experimentation. The aim of this work is to

lay the theoretical foundations on which the algorith-mic layer can be built.

The results of our experiments has shown ourmethodology to be more flexible, and result is smallerconverters (all things considered) than in previouswork. Our ability to handle data-width mismatchesand buffer sizes explicitly means the user can design aconverter with different configurations, different prop-erties, and consequently different performances. Themodel of data width that we have used (shown in Fig-ure 11) is somewhat arbitrary. More complex modelsthat allow different data widths for different data andaddress buffers (say) are also possible.

The algorithm that determines the minimumbuffer size should consider more than just the (ra-tio of) data widths of the given protocols. There areother factors, such as the data transfer rate and pro-tocol behaviours that may mean a converter will ex-ist, or not. Currently, our buffer-size algorithm mayunder- or over-estimate the size that the buffer needsto be. This issue needs to be addressed in the future.

While we have studied the relationship betweennondeterminism and the invalid data problem, wecannot yet identify a priori which nondeterminismresults in ‘bad data’, and which does not.

There are practical issues in using the finite-statemachine formalism: is it expressive enough to modelprotocol (or in general component) behaviour, andsatisfy real chip designers for example? We havenot yet carried out a complexity analysis of our al-gorithms, but do not expect this to be an issue how-ever as the size of typical converters is not expectedto be large. We have plans to extend this work to anasynchronous setting as well.

References

Akella, J. & McMillan, K. L. (1991), Synthesizingconverters between finite state protocols, in ‘Com-puter Design on VLSI in Computer & Processors’,IEEE Computer Society, Washington, pp. 410–413.

Androutsopoulos, V., Brookes, D. & Clarke, T.(2004), ‘Protocol converter synthesis’, IEE Pro-ceedings – Computers and Digital Techniques151(6), 391–401.

Androutsopoulos, V., Clarke, T. & Brookes, D.(2003), Synthesis and optimization of interfaces be-tween hardware modules with incompatible proto-cols, in ‘ISCAS(5)’, pp. 613–616.

Avnit, K., D’Silva, V., Sowmya, A., Ramesh, S. &Parameswaran, S. (2007), Protocol compatibilityand automatic converter synthesis, Technical Re-port 718, School of Computer Science and Engi-neering, UNSW, Australia.

Avnit, K., D’Silva, V., Sowmya, A., Ramesh, S. &Parameswaran, S. (2008), A formal approach to theprotocol converter problem, in ‘Proceedings of theconference on Design, automation and test in Eu-rope (DATE’08)’, ACM, pp. 294–299.

Bhaduri, P. & Ramesh, S. (2008), ‘Interface synthe-sis and protocol conversion’, Form. Asp. Comput.20(2), 205–224.

Clarke, E. M., Grumberg, O. & Peled, D. A. (2000),Model Checking, MIT Press.

D’Silva, V., Ramesh, S. & Sowmya, A. (2004a),Bridge over troubled wrappers: Automated inter-face synthesis, in ‘VLSI Design’, IEEE ComputerSociety, pp. 189–194.

D’Silva, V., Ramesh, S. & Sowmya, A. (2004b),Synchronous protocol automata: A framework formodelling and verification of SoC communicationarchitectures, in ‘DATE’04’, IEEE Computer Soci-ety, pp. 390–395.

Green, P. (1986), ‘Protocol conversion’, IEEE Trans-actions on Communications 34(3), 257–268.

Ihmor, S., Loke, T. & Hardt, W. (2005), Synthesisof communication structures and protocols in dis-tributed embedded systems, in ‘RSP ’05: Proceed-ings of the 16th IEEE International Workshop onRapid System Prototyping’, pp. 3–9.

Keating, M. & Bricaud, P. (1999), Reuse methodol-ogy manual: for system-on-a-chip designs, KluwerAcademic Publishers, Norwell, MA.

Mullane, B. & MacNamee, C. (2008), ‘Develop-ing a reusable IP platform within a System-on-Chip design framework targeted towards an aca-demic R&D environment’, Design and Reuse .http://www.design-reuse.com/news/?id=16039.

Passerone, R., de Alfaro, L., Henzinger, T. &Sangiovanni-Vincentelli, A. (2002), Convertibilityverification and converter synthesis: two faces ofthe same coin, in ‘International Conference onComputer Aided Design’, pp. 132–139.

Passerone, R., Rowson, J. A. & Sangiovanni-Vincentelli, A. L. (1998), Automatic synthesis of in-terfaces between incompatible protocols, in ‘DAC’,pp. 8–13.

Roychoudhury, A., Thiagarajan, P. S., Tran, T.-A.& Zvereva, V. A. (2004), Automatic generationof protocol converters from scenario-based speci-fications, in ‘RTSS’04’, IEEE Computer Society,Washington DC, pp. 447–458.

Shin, D. & Gajski, D. (2002), Interface synthesis fromprotocol specification, Technical Report CECS-02-13, Center for Embedded Computer Systems, Uni-versity of California.

Sinha, R., Roop, P. & Basu, S. (2006), A model check-ing approach to protocol conversion, Technical Re-port 0000482, Department of Electrical and Com-puter Engineering University of Auckland.

Sinha, R., Roop, P. & Basu, S. (2007), A model check-ing based converter synthesis approach for embed-ded systems, Technical Report 0000537, Depart-ment of Computer Science, Iowa State Universtiy.

Sinha, R., Roop, P. & Basu, S. (2008a), A modelchecking based converter synthesis approach forSoCs, in ‘21st International Conference on VLSIDesign’, IEEE Computer Society, pp. 492–499.

Sinha, R., Roop, P. S. & Basu, S. (2008b), ‘A modelchecking approach to protocol conversion’, Electr.Notes Theor. Comput. Sci. 203(4), 81–94.

Watanabe, S., Seto, K., Ishikawa, Y., Komatsu, S.& Fujita, M. (2007), Protocol transducer synthe-sis using divide and conquer approach, in ‘ASP-DAC ’07’, IEEE Computer Society, WashingtonDC, pp. 280–285.