Automatic Generation of Transaction-Level Models for Rapid Design Space Exploration

Transcription

1 Automati Generation of Transation-Level Models for Rapid Design Spae Exploration Dongwan Shin, Andreas Gerstlauer, Junyu Peng, Rainer Dömer and Daniel D. Gajski Center for Embedded Computer Systems University of California Irvine CA USA {dongwans, gerstl, pengj, doemer, ABSTRACT Transation-level modeling has been touted to improve simulation performane and modeling effiieny for early design spae exploration. But no tools are available to generate suh transation-level models from abstrat input desriptions. Designers have to write suh models manually, whih is a tedious and error-prone task, and one of bottleneks in improving designer s produtivity. In this paper, we propose a method to generate transation-level models from virtual arhiteture models where omponents ommuniate via abstrat message-passing hannels. We have applied our approah to a set of industrial-strength examples with a wide range of target arhitetures. Experimental results show that signifiant produtivity gains an be ahieved, demonstrating the effetiveness and benefits of our approah for rapid, early exploration of ommuniation design spae. Categories and Subjet Desriptors J.6 [Computer-Aided Engineering]: CAD General Terms Design, Alogithms Keywords ommuniation synthesis, transation-level model 1. INTRODUCTION As system-on-hip (SoC) designs grow in omplexity and size, on-hip ommuniation is beoming an inreasingly important fator. In order to explore the ommuniation design spae, designers use models whih are evaluated through simulation. Typially, these models are manually written, whih is a tedious, error-prone and time-onsuming proess. Furthermore, to ahieve required auraies, models are written at low levels of abstration with resulting slow Permission to make digital or hard opies of all or part of this work for personal or lassroom use is granted without fee provided that opies are not made or distributed for profit or ommerial advantage and that opies bear this notie and the full itation on the first page. To opy otherwise, to republish, to post on servers or to redistribute to lists, requires prior speifi permission and/or a fee. CODES+ISSS 06, Otober 22 25, 2006, Seoul, Korea. Copyright 2006 ACM /06/ $5.00. simulation performane. Together, this severely limits the amount of design spae that an be explored in a reasonable time. Reently, a lot of researh on defining ommuniation models at different levels of abstrations has been proposed in order to improve simulation performane. This trend is now leveraged by the transation-level model () paradigm, whih provides system-level bus interfaes at higher levels of abstration. In this paper, we propose an approah for automati generation of s from an abstrat desription of the partitioned system proessing arhiteture. The rest of the paper is organized as follows: We show a brief overview of related work in Setion 2. Setion 3 introdues the overall design flow and the inputs and outputs of the ommuniation synthesis. Setion 4 will present the details of the ommuniation refinement proess. Finally, experimental results are shown in Setion 5 and the paper onludes with a summary in Setion RELATED WORK There is a wealth of system-level design languages (SLDL) like SystemC [4], or SpeC [5] available for modeling and desribing systems at different levels of abstration. However, the languages themselves do not define any details of atual onrete design flows. More reently, SLDLs have been proposed as vehiles for so-alled transation-level modeling for ommuniation abstration [1, 4, 6, 9]. However, no speifi definition of the level of abstration and the semantis of transations in suh models have been given. Furthermore, proposals so far fous on simulation only and lak the path to vertial integration of models for implementation and synthesis. Historially, a lot of work has foused on automating the deision making proess for ommuniation design [7, 8, 10] without, however, providing orresponding design models or a path to implementation. More reently, work has been done to target automati generation [11, 15] of ommuniation, but in all ases, the approahes are usually limited to speifi target arhiteture templates or narrow input model semantis. Reently, some ommerial tools [2, 3] are beginning to apture designs at the transation-level. In ontrast to suh existing shemati entry tools that simply provide an interfae for plugging existing base models together graphially, the ontribution of this paper is to generate onrete, detailed s from abstrat virtual arhiteture models of a system. 64

2 GUI Design deisions: Arhiteture model HW IP B1 B B3 B4 Bus alloation Protool seletion Connetivity Channel mapping Address mapping Interrupt mapping Arbitration Communiation refinement Transation -level model Bus/CE base pubus B r IPBus int v1[100]; double v2; OS Model HW1 HW2 Figure 2: Arhiteture model example. Bus1 Bus2 TX Ctrl HW IP MBus HW1 HW2 Figure 1: Communiation design flow. 3. COMMUNICATION DESIGN FLOW Figure 1 shows the proposed ommuniation design flow. Design deisions are made by the user and entered into the system through a graphial user interfae (GUI). With the design deisions, the user speifies the desired target arhiteture and the mapping of ommuniation onto this arhiteture. Based on these deisions and given the design model at the input of the flow, refinement tool synthesizes the respetive implementation of the ommuniation and generate the resulting design model at the output of the flow. In the proess, refinement tool relies on a set of bases that provide models of ommuniation elements (CEs), busses and other ommuniation strutures. Our ommuniation design flow starts with a virtual arhiteture model of the system in whih proessing elements (PEs) ommuniate via abstrat hannels. During ommuniation synthesis, the global system network is designed and end-to-end ommuniation between PEs is mapped into point-to-point ommuniation between stations (PEs and CEs) of the network arhiteture. Then, logial links between adjaent stations are grouped and implemented over an atual ommuniation medium. As a result of the ommuniation design proess, a transation-level model of the system is generated. The [1, 4, 6] abstrats pin-level ommuniation to the level of individual bus protool transations in order to aelerate model simulations. 3.1 Input Arhiteture Model The arhiteture model is the starting point for ommuniation design. This input arhiteture model may be manually oded or an be automatially generated by virtual arhiteture generation tools [12]. It follows ertain predefined semantis (see Setion 4.1) and reflets the intended virtual proessing arhiteture of the system with respet to the PEs that are present in the design. Eah omponent in the virtual arhiteture is a PE that exeutes a speifi appliation behavior in parallel with other PEs. Communiation inside a PE takes plae through its loal memory. It is thus not a onern for system ommuniation synthesis. Inter-PE ommuniation by the appliation in the arhiteture model takes plae through abstrat, high-level hannels of untimed message-passing or shared memory semantis. Figure 2 shows an example of an arhiteture model. The appliation has been mapped onto a system arhiteture onsisting of a proessor ( ), a ustom hardware oproessor (HW1 ), a ustom hardware peripheral (HW2 ) and a system memory ( ). Inside the, tasks are dynam- Figure 3: Target arhiteture for Figure 2. ially sheduled under the ontrol of an operating system model [16]. In addition to ommuniating via hannels (1, 2 and 3 ), PEs exhange by aessing variables (v1 and v2 ) stored in the shared memory ( ) and exported by the memory through its external hannel interfae. At its interfae, the memory provides methods to read and write the value of eah variable in the memory. 3.2 User Deisions Design deisions inlude alloation of system busses, protool seletion, alloation and seletion of CEs (routers and bridges), definition of the onnetivity between omponents and busses, mapping and routing of abstrat ommuniation over busses, delaration of masters and slaves, and assignment of bus addresses, interrupts, and aess priorities for eah message. Through the user deisions, the target arhiteture for the design is defined. In our ase, the target arhiteture is limited to networks of busses in a forest of trees topology, i.e. there are no yles. Figure 3 shows the target arhiteture hosen for the previously introdued example (Figure 2). In this example, we alloate three busses: a bus Bus1 as the main system bus, a memory bus MBus, and a peripheral bus Bus2. and HW1 PEs are diretly onneted to the system bus. A memory ontroller CE Ctrl is alloated and onneted to bridge between the system and memory bus protools. Finally, a router CE TX is inserted to onnet and translate between system and peripheral busses. 3.3 Databases The bases onsist of a transation-level bus base and a CE base. The bus base ontains models of busses inluding assoiated protools. Bus models in the base implement the primitives defined by the bus protool for transfers and arbitration. They provide an abstration of external ommuniation into links and memory aesses by using and ombining bus primitives to regulate media aesses and slie abstrat into bus words. Eah bus model an have two separate sides with different implementations for bus masters and bus slaves. The CE base ontains bridge and transduer omponents that inlude attributes like name, type and assoiated bus protools. The models of CEs in the base, however, are empty shells that are void of any funtionality. will be synthesized by the refinement tool. They 65

3 TX reeiver Bus1 ma ma Bus2 write write reeiver reeiver reeiver Ctrl ma inta intb ma ma notify read notify read write read notify Mbus M L1 L3 inta L3 M L1 ak har[4k] B1 OS Model B2 ISR HW1 B3 HW2 Figure 4: Transation-level model example. 3.4 Transation-level Model At the output, refinement produes a. The aurately desribes the system ommuniation arhiteture down to the level of individual bus protool read and write transations. In our transation-level modeling of a system, the omputation is estimated time-aurate and the ommuniation is bus-yle aurate (Programmer s View + Timing) [14]. Figure 4 shows the generated for the input arhiteture model example from Figure 2. Refleting the originally defined target arhiteture (Figure 3), omponents ommuniate via bus protool transation hannels for Bus1, Bus2 and MBus. Transation-level implementations from the bus base together with automatially generated implementations of higher protool staks are inserted into eah onneted omponent. For the programmable PE ( ), its transation-level implementation is taken from the base, onneted at the media aess level, ustomized by generating appropriate interrupt handlers and filled with the PE s appliation ode. 4. COMMUNICATION REFINEMENT In this setion, we will look at details of model transformations that are performed during refinement. 4.1 Input Communiation Channels Four different types of abstrat ommuniation are supported in an arhiteture model at the input of refinement: synhronous and asynhronous message passing, shared memory aesses and events. The ommuniation semantis of these hannels are shown in the form of state diagrams in Figure 5. In synhronous message passing, as shown in Figure 5(a), both the and the reeiver meet in a rendezvous fashion to safely exhange. More speifially, the stores its into the hannel, notifies the reeiver that the is ready, and then s for the reeiver to aknowledge the reeipt of the. The reeiver, on the other hand, first s for notifiation of arrival, then gets it and aknowledges the reeption. In short, synhronous message passing oneptually utilizes a two-way handshake mehanism to ensure reliable transport. This way, annot get lost or dupliated. However, both the reeiver and the may be bloked in their exeution. In asynhronous message passing, as shown in Figure 5(b), only the reeiver may be bloked if is not available. The B4 (a) syn. MP (b) asyn. MP () memory (d) event Figure 5: Semantis of ommuniation hannels is not bloked. To avoid the loss of, sent is stored in a queue hannel until it is piked up by the reeiver. As a onsequene, asynhronous message passing is also reliable, but the annot make any assumptions about the point of time when the reeiver atually retrieves the. The third type of ommuniation, a shared memory aess as shown in Figure 5(), exhibits non-bloking ommuniation for both the and the reeiver. The simply writes into a shared storage element from where the an be read by the reeiver at any time. Sine there is no built-in synhronization between the ommuniating parties, this type of transfer is unreliable. Thus, may get lost due to overwriting, or ould get dupliated due to multiple read aesses. Finally, an event hannel, as shown in Figure 5(d), exhibits pure synhronization semantis without any transfer. Here, the reeiver simply s for an event from the before proeeding in its exeution. No is exhanged. In other words, event ommuniation is non-bloking for the, but bloking for the reeiver. Note that this event hannel an be easily ombined with a memory hannel to ahieve reliable ommuniation in shared memory fashion. 4.2 Channel Implementation Given the input arhiteture model, the ommuniation refinement tool will automatially generate an implementation of the abstrat input hannels on the given ommuniation arhiteture. The tool automatially generates and inserts the neessary bus drivers and bus interfaes into the system omponents of the system. The automati generation of bus drivers and interfaes inside omponents adapts aesses from the appliation tasks into transations over the bus hannels onneted to the omponents. The protool staks are ustomized and optimized in terms of (a) station type of the omponent on the bus (master/slave) (b) ommuniation protool, () hannel semantis (Setion 4.1), (d) types of message transfered, and (e) synhronization between omponents Synhronous message passing Synhronous message passing implements two-way blok handshaking, whih does not require any buffers to transfer messages between omponents. In order to preserve the semantis of hannels in the input models, synhronization between omponents has to be introdued whenever neessary. In a bus-based system, we distinguish between master and slave omponents for eah transfer. A master ompo- 66

4 _HAL _OS addr1 addr2 rdyb rdya MasterMAC ID MasterWrap Bus CustomHW addr 1 SlaveMAC addr 2 PE1 () PE2 (reeiver) Queue synmp synmp Figure 7: An implementation of asyn. MP. OSModel intb inta ICL inta intb _HAL _OS addr 1 ID CustomHW addr1 Master link layer Interrupt handler SlaveReady == false A0 Slave link layer MasterMAC MasterWrap Bus SlaveMAC Flag SlaveReady == true I/O ports are not vailable S0 IRQ = false; OSModel I/O ports are not available A1 2 IRQ == false I0 I/O ports are available inta intb ICL inta intb A2 A3 I/O ports are available Reserve I/O ports; MasterRead / Write(Slave#, msg); SlaveReady = false Release I/O ports; I1 IRQ == true SlaveReady = true; Figure 6: Synhronization by interrupts. 3 1 S1 S2 Reserve I/O ports; IRQ = true; SlaveRead/ Write(slave#, msg); Release I/O ports nent will for synhronization from slaves before performing the atual transfer. On the slave side, a slave will notify the master before starting to listen for inoming transfer requests. In ase of busses with inherent two-way synhronization built into their transfer protools (e.g. RS232), no expliit synhronization needs to be implemented by the refinement tool. The synhronization from slave to master in a bus-based ommuniation arhiteture has to been done through interrupts and/or polling. The deision about whih synhronization mehanism to use is done by user. In ase of synhronization via interrupts, the user has to assign interrupt lines for eah transfer (message passing hannel). Transation-level models for programmable omponents in the PE base inlude a definition of their interrupt apabilities. The top-level shell defines the interrupt ports available at the physial omponent interfae, and the hardware abstration layer (HAL) provides orresponding empty interrupt handler templates. During model refinement, interrupt ports from slaves are onneted to the interrupt ports of programmable omponents and interrupt handlers and interrupt tasks are generated in the HAL and operating system, respetively, by filling the orresponding templates of the proessor model. Figure 6 shows the state mahines synthesized inside master and slave omponents whih are synhronized by interrupts. When a slave proess reahes the ommuniation point, it notifies the master that it is ready to start the transfer by sending an interrupt (1). Upon reeiving the interrupt event, the master suspends its exeution and the interrupt handler in the master sets a SlaveReady flag. The master side proess s until the flag is set (2) to initiate the bus transfer. Finally, the slave omponent s for the master to initiate the bus transfer by heking the address bus (3). This mehanism retains the two-way bloking property of any original synhronous message passing ommuniation. One the transfer is omplete, the master omponent resets the SlaveReady flag to prepare for the next slave request. In ase of interrupt sharing due to an insuffiient number of interrupts in the master, interrupt handling is extended to first determine the soure of eah interrupt request via Figure 8: An implementation of event. polling of slaves. Due to spae limitations, implementation of interrupt sharing and polling [13] is not shown here Asynhronous message passing In asynhronous message passing, is stored in a storage element suh as a buffer or queue for reliable transfers. Otherwise, the may get lost when the reeiver is not ready. Asynhronous message passing hannels an have 3 types of implementations depending on whih omponent has the storage element. Users an hoose one of these implementations by assigning asynhronous message passing hannels to orresponding PEs: 1. Stored in : implements the storage element from whih the reeiver gets. Data transfers on the bus happen between the storage element and the reeiver. 2. Stored in reeiver: reeiver implements the storage element. Data transfers on the bus happens between the and the storage element. 3. Stand-alone storage element: the storage is implemented in a separate omponent whih buffers the between and reeiver (Figure 7). As shown in Figure 7, asynhronous message passing hannels are refined down to omponents and synhronous message passing hannels in between. The synhronous message passing hannels are then implemented as explained in Setion Memory aesses The abstrat models of memory aesses need to be replaed with transation-level implementations of memory omponents, taken out of the base. The model refinement will automatially detet orresponding implementations of memory aesses. In ase of memory or register (memory-mapped I/O) aesses, slave omponents are assumed to be always ready and no extra synhronization is neessary. In addition, refinement tool inserts memory drivers that perform formatting from abstrat memory aesses to aesses (based on slie and offset) of the memory over the bus Events Event hannels are used for synhronization only. They do not arry any. An event hannel an be implemented by asynhronous message passing with a flag (1 bit ) through whih a notifies a reeiver that the is ready (Figure 8). As with asynhronous message passing hannels, the reeiver implements the buffer 67

5 BUS1 Router BUS1MAC ID sr dest message state mahine state mahine BUS2MAC BUS2 System delay (ms) PAM Run time (se) PAM 10 MP3.A1 MP3.A2 MP3.A3 MP3.A4 Arhitetures 1 MP3.A1 MP3.A2 MP3.A3 MP3.A4 Arhitetures Figure 9: Routing of message in CEs. to store the value of a flag on the reeiver side. When an interrupt-apable proessor is the reeiver, event hannels are implemented by reeiving an interrupt from the (similar to synhronous MP in Figure 6). 4.3 Arbitration If a omponent internally has multiple tasks whih aess a transation-level bus hannel onurrently, the interfae has to be proteted to avoid potential bus onflits of bus aesses (state A2 and S1 in Figure 6). Therefore, we implement mutual exlusiveness at the interfae of the omponent (MasterWrap adapter in Figure 6 and Figure 8). Arbitration among multiple masters on the bus is implemented as part of transation-level bus hannel. Externally, master omponents have to provide identity information to the bus hannel. For this, the adapter inside the master interfae transfers the identity (ID in MasterWrap adapter in Figure 6 and Figure 8). 4.4 Bus Bridging and Routing If two different bus systems are onneted to eah other, additional CEs suh as bridges and transduers are introdued. CEs split and segment the system of onneted PEs in the arhiteture model into several bus subsystems. Bridges transparently translate between two bus protools diretly at the protool level. A bridge state mahine is generated as the produt of the two bus protool state mahines [13]. In the proess, the two protools are properly interleaved suh that dependenies and timing onstraints are observed. A bridge is always a master on one side and a slave on the other. Between listening for and serving transations on the slave side, it interleaves orresponding mirror transations on its master side (bloking the slave side in the proess, if neessary). In ases where simple bus bridges are not suffiient, transduers are neessary. Transduers operate on pakets using a store-and-forward priniple, routing pakets between their inoming and outgoing links. Transduers an onnet any two bus protools and they an be master or slave on either side. In ontrast to a bridge, transduers internally buffer eah individual bus transations on one side before performing the equivalent transation on the other side. As shown in Figure 9, a transduer model generated by refinement ontains orresponding state mahines for eah diretion of eah hannel rossing the transduer [13]. Note that eah state mahine ontains its own loal buffer, i.e. buffers are not shared, avoiding potential deadloks and looks up the address mapping table to route the messages over the two different busses. 5. EXPERIMENTAL RESULTS In order to demonstrate the feasibility and benefits of our approah in terms of design spae exploration for a wide variety of designs, we applied our design flow and refinement (a) Simulated delays (b) Simulation performane Figure 10: MP3 Exploration results. tool to the design of four industrial-strength examples: a voie ode (Vooder), a JPEG enoder (JPEG), an MP3 deoder (MP3) and a baseband platform example (Baseband) whih is ombination of a voie ode and JPEG enoder. Different arhitetures using Motorola DSP56600 proessors (DSP), Motorola ColdFire proessors (CF ), ARM proessors (ARM ) and ustom hardware units (HW, I/O, DCT, QN, FIL) were generated and various ommuniation arhitetures (DSP bus, CF bus, AMBA bus and simple handshake bus) were tested. Table 1 summarizes the features and parameters of the different design examples we tested. For eah example, the target ommuniation arhiteture, the total number of abstrat hannels and the total traffi in the design are shown. Target arhitetures are speified as a list of masters plus slaves for eah bus in the system where the bus type is impliitly determined to be the protool of the primary master on the bus. For example, in the ase of the MP3 design, the ARM proessor ommuniates with dediated hardware units over its AMBA bus whereas the HW units ommuniate with eah other through separate handshake busses. For simpliity, routing, address and interrupt assignment deisions are not shown in this table. Overall model omplexities are given in terms of ode size using lines of ode (LOC) as a metri. Results show signifiant differenes in omplexity between input and generated output models due to extra implementation detail added between abstration levels. To quantify the atual refinement effort, the number of modified lines (Mod. LOC) is alulated as the sum of lines inserted and lines deleted whereas ode oming from base of predefined ommuniation odes (DB LOC) is exluded 1. We optimistially assume that a person an write 30 lines of orret (tested and debugged) ode per day. Thus, manual refinement would require hundreds of man-days for reasonably omplex designs. Automati refinement, on the other hand, ompletes in the order of seonds. Note that in all ases, arhiteture modes at the input do not have to be hanged, i.e. input models remain the same throughout exploration 2. Results therefore show that a produtivity gain of about 1000 times an be ahieved using the presented approah with automati model refinement. Figure 10 shows the results of exploration of the design spae for the MP3 deoder example. We used four different arhitetures for the MP3 deoder as shown in Table 1. We 1 Our experimental DB inludes models of ARM, ColdFire and Motorola DSP inluding assoiated busses. On average, DB models have omplexities of 1000 LOC per proessor/bus ombination. 2 In both ases, design deisions about the target arhiteture are assumed to be given, i.e. time required for deision making is the same and hene not onsidered further. 68

6 Table 1: Experimental results for different exploration examples. Examples Busses Chnls Traffi Model (LOC) DB Mod. Refine. Time (Masters Slaves) (no.) (bytes) Arh (LOC) (LOC) Tool Manual Vooder A1 DSP 2 I/Os < 1 s 35 days A2 DSP HW, 2 I/Os < 2 s 63 days A1 CF < 1 s 20 days A2 CF DCT, < 1 s 41 days JPEG A3 CF DCT, DMA DMA, DCT < 2 s 55 days A4 CF DCT, QN, DMA DMA, DCT, QN < 3 s 71 days A1 ARM I/O < 2 s 40 days A2 ARM I/O, FIL1, FIL < 5 s 117 days ARM FIL1, FIL2 MP3 A3 I/O FIL < 5 s 116 days I/O FIL2 ARM FIL1, FIL2 A4 I/O Q1 FIL1 I/O Q2 FIL < 6 s 135 days DSP BIO,SIO,HW,TX Baseband A1 CF DMA,TX,BR DMA,BR BR DCT < 8 s 144 days measured whole system delay of eah arhiteture and the simulation time of eah model. As shown in Figure 10, as the number of system omponents inreases with eah arhiteture, the overall performane of the system is improved. In addition, s are as aurate as pin-aurate models (PAMs) but improve simulation speed by around 1000 times ompared to PAMs. Given the design deisions made by the user, it took less than 1 hour to obtain 4 different ommuniation models from an exeutable speifiation model by arhiteture exploration [12] and ommuniation design. 6. CONCLUSION In this paper, we presented an approah for generation of s for SoC ommuniation designs from a partitioned virtual arhiteture model of a system. A orresponding transation-level refinement tool has been developed and integrated into our SoC design environment. Using industrial-strength examples, the feasibility and benefits of the approah have been demonstrated. Automating the tedious and error-prone proess of refining a high-level, abstrat desription of the design into an atual implementation results in signifiant gains in designer produtivity, thus enabling rapid, early exploration of the ommuniation design spae. In the future, we plan to integrate IP omponents with fixed, pre-defined ommuniation protool interfaes and add algorithms for automated design making for optimization. 7. REFERENCES [1] M. Coppola, S. Curaba, M. Grammatikakis, and G. Maruia. IPSIM: SystemC 3.0 enhanements for ommuniation refinement. In Pro. of DATE 03. [2] CoWare Platform Arhitet. Available at http: // [3] ARM MaxSim Tools. Available at [4] T. Grötker, S. Liao, G. Martin, and S. Swan. System Design with SystemC. Kluwer Aademi Publishers, Mar [5] D. D. Gajski, J. Zhu, R. Dömer, A. Gerstlauer, and S. Zhao. SpeC: Speifiation Language and Methodology. Kluwer Aademi Publishers, Jan [6] L. Cai, and D. D. Gajski. Transation Level Modeling: An Overview. In Pro. of CODES+ISSS 03. [7] T. Y Yen, and W. Wolf. Communiation synthesis for distributed embedded systems. In Pro. of ICCAD 95. [8] R. B Ortega, and G. Borriello. Communiation synthesis for distributed embedded systems. In Pro. of ICCAD 98. [9] S. Pasriha, N. Dutt, and M. Ben-Romdhane. Extending the transation level modeling approah for fast ommuniation arhiteture exploration. In Pro. DAC 04. [10] K. Lahiri, A. Raghunathan, and S. Dey. Effiient exploration of the SoC ommuniation arhiteture design spae. In Pro. ICCAD 00. [11] D. Lyonnard, S. Yoo, A. Baghdadi, and A. A. Jerraya. Automati generation of appliation-speifi arhitetures for heterogeneous multiproessor system-on-hip. In Pro. DAC 01. [12] J. Peng. System-Level Automati Model Refinement. PhD thesis, University of California, Irvine, Information and Computer Siene, April [13] A. Gerstlauer, G. Shirner, D. Shin, and J. Peng. Neessary and suffiient funtionality and parameters for SoC Communiation. CECS, Univ. of California, Irvine, Teh. Rep. CECS-TR-06-1, May [14] G. Shirner, and R. Dömer. Quantitative analysis of transation level models for the AMBA bus. In Pro. of DATE 06. [15] A. Wieferink, R. Leupers, G. Asheid, H. Meyer, T. Mihiels, A. Nohl and T. Kogel. Retargetable generation of bus interfaes for MP-SoC platforms. In Pro. of CODES+ISSS 05. [16] H. Yu, A. Gerstlauer, and D. D. Gajski. RTOS sheduling in transation level models. In Pro. of ISSS