Multi-Clock SoC Design using Protocol Conversion Roopak Sinha, Partha S. Roop University of Auckland New Zealand rsin077,p.roop@ec.auckland.ac.nz Samik Basu Iowa State University USA sbasu@cs.iastate.edu Zoran Salcic University of Auckland New Zealand z.salcic@auckland.ac.nz Abstract The automated design of SoCs from pre-selected IPs that may require different clocks is challenging because of the following issues. Firstly, protocol mismatches between IPs need to be resolved automatically before IPs are integrated. Secondly, the presence of multiple clocks makes the protocol conversion even more difficult. Thirdly, it is desirable that the resulting integration is correct-by-construction, i.e., the resulting SoC satisfies given system-level specifications. All of these issues have been studied extensively, although not in a unifying manner. In this paper we propose a frame- work based on protocol conversion that addresses all these issues. We have extensively studied many SoC design prob- lems and show that the proposed methodology is capable of handling them better than other known approaches. A significant contribution of the proposed approach is that it nicely generalizes many existing techniques for formal SoC design and integrates them into a single approach. 1. Introduction A system-on-a-chip (SoC) consists of multiple compo- nents (IPs) that collaborate and communicate with each other to achieve system behaviour. The SoC design process is affected by several issues like the selection of IPs, their interconnection into overall system, and validation of cor- rectness of the overall system. The main problems with the integration of preselected IPs are, (a) the possibility of con- trol, data or clock mismatches [9] between IP protocols that prevent proper inter-IP communication, and, (b) the prob- lem of ensuring that IPs (after mismatches are resolved) in- tegrate such that desired high-level behaviour is met. The focus of this paper is to provide a unifying solution for the automatic resolution of protocol mismatches and the correct-by-construction design of SoCs that use multiple clocks. Some preliminary ideas of the approach were first published in [11]. These have been substantially extended and reformulated in [10]. The proposed algorithm can au- tomatically generate a converter that can integrate two or more IPs such that mismatches are resolved and the con- verted system satisfies desired specifications. The main contributions of this paper are as follows. Firstly, an automatic design technique for multi-clock (which also includes single clock systems as a special case) SoCs is proposed. Precise conditions for the existence of converters are identified. Furthermore, it is shown that SoCs can be constructed in a single-step or by the successive (in- cremental) addition of new IPs, called successive conver- sion. 1.1. Related Work A number of protocol conversion approaches for SoC have been proposed earlier [2, 5, 9]. In [5], a correct-by- construction SoC design technique is presented. The work identifies precise conditions under which two IPs are com- patible, and an automatic algorithm is used to generate an interface to make them compatible. A protocol conversion approach based on [5] is presented in [2]. The main contri- butions of this approach are the precise modelling of com- mercial bus protocols, a protocol conversion algorithm that always yields converters that can be translated to HDL, and converter sizes that are bounded by the size of the given protocols. However, this approach generates converters for protocol pairs only and bridges data-width mismatches on an abstract level by avoiding unbounded data operations on any path in the converted system. Furthermore, both [5] and [2] are restricted to single-clock systems and as the notion of compatibility is limited to ensuring that IPs detect and re- spond to actions performed by each other, the approach can- not guarantee that a given system satisfied high-level func- tional specifications. Passerone et al [9] present a game- theoretic formulation for protocol conversion but no algo- rithm is provided, data or clock mismatches are not handled, and only uni-directional IP communication is allowed. Tab. 1 presents a comparison between existing formal approaches. It shows that each technique uses different representations for protocols and algorithms to find a con- verter 1 . Furthermore, some approaches like [5] and [12] do 1 The following abbreviations are used in Tab. 1. LTS = labelled tran-