TIMA Lab. Research Reports

Transcription

1 ISSN TIMA Lab. Research Reports TIMA Laboratory, 46 avenue Félix Viallet, Grenoble France

2 Application-Specific Multiprocessor Systems-on-Chip Ahmed Amine Jerraya, Amer Baghdadi, Wander Cesário, Lovic Gauthier, Damien Lyonnard, Gabriela Nicolescu, Yanick Paviot, Sungjoo Yoo System-Level Synthesis Group TIMA Laboratory 46, Avenue Félix Viallet F Grenoble CEDEX Ahmed.Jerraya@imag.fr Abstract It often happens that designers have to integrate different instruction-set processors on a single chip. Typical applications are wireless, image processing, xdsl, network and game processors. This paper deals with the three main problems that make the design of application-specific heterogeneous multiprocessor Systems-on-Chip very hard and expensive: - higher level specification; - software support packages design; - on-chip / communication design. I. INTRODUCTION ITRS roadmap predicts that in 2005, 90% of ASICs will include at least one embedded instruction set processor [1]. In this case, most ASICs will be SoCs (Systems-on-Chip). This prediction is not only confirmed but strengthened: SoCs will include several instruction-set processors in the case of applications such as mobile terminals (e.g. GSM), set-top boxes (e.g. pnx 8500 from Philips), game processors (e.g. PlayStation 2 from Sony) and network processors. All the above designs correspond to mass market products and are (or will be) integrated on a single chip for production cost reasons. It is even expected that these applications act as the main drivers for the semiconductor industry. Most system and semiconductor houses are working on platforms allowing the integration of several cores (CPU, DSP, MCU, co-processors, ) and sophisticated communication networks (hierarchical bus, TDMA-based bus, point-to-point connection and packet routing switch) on a single chip. The trend is then to build large designs as a networked Systemon-Chip. The game is now to interconnect standard components as we used to do for boards a few years ago. This evolution is creating several breaking points in the design process and new challenges for the EDA industry: 1. Systems are complex: they cannot any more be specified manually at a low level such as RTL where clock cycles need to be detailed. Higher-level abstraction models are required to master the complexity. Of course, higher-level synthesis tools are required. 2. Systems are heterogeneous: Experiments with system specification and validation show that several abstraction levels and different computation models need to be combined during the design flow. New validation tools and design models that are able to handle this heterogeneity are required. 3. SoCs will include programmable processors. The designer of these SoCs will have to provide a programming support package that includes the low level software layer. This support package will be the API used by the application programmer to encapsulate some of the architecture details. EDA needs to take into account this software layer. 4. Complex on-chip hardware/software communications are required to implement these SoCs: multiprocessor architectures may require a multi-master communication network. When systems are integrated on a single chip, the hardware and software sides of the communication protocols need to be adapted to each other. This paper will present a systematic approach for the design of application-specific multiprocessor Systems-on- Chip. This includes the definition of a scalable multiprocessor architecture platform, software targeting strategies and executive code from SystemC-like models, hardware/software interfaces, and multi-level validation approach. II. BASICS: MULTIPROCESSOR SYSTEM-ON-CHIP ARCHITECTURE DESIGN A. Multiprocessor SoC applications The expression SoC is used to designate an ASIC combined with other components on the same chip. This is similar to what we were used to see on system boards. A SoC may include heterogeneous components such as CPUs, DSPs, ASICs, memories, buses, etc. A SoC is application specific and imposes tight design and performance constraints. The designed architecture should be tuned, specialized, and optimized to a specific application or a very restricted set of related applications. A SoC generally also imposes tight time-to-market constraints. Thus, the architecture design cycle should be limited. This paper deals with a specific kind of SoCs, these include several embedded processors. Table 1 shows examples of state-of-the-art multiprocessor SoC products. As shown in the table, application-specific operations such as data processing or control are performed by DSPs, MCUs (micro-controller units), or CPUs.

3 TABLE I STATE-OF-THE-ART MULTIPROCESSOR SOC PRODUCTS Components Application Data Processing Control On-chip memory size On-chip communication Size Typical designs Telecom Terminals 1 DSP 1 MCU > MB Bridge (hierarchical bus) > M Gates STEP 1 VDSL (ST) Multimedia A few DSPs 1 MCU >> MB Network switch Cross bar < M Gates TRIMEDIA (Philips) Network Processor Many DSPs A few MCUs >> MB On-chip network > M Gates IXPIZDE (Intel) Game Processor A few DSPs A few MCUs >> MB On-chip hierarchical network >> M Gates PlayStation 2 To meet the required communication bandwidth, several types of communication networks such as hierarchical buses, cross-bar networks, etc. are used. All these designs require more than a megabyte of on-chip memory and in addition to the use of standard components (memory, processors), they all include application-specific hardware that may amount to several million gates. B. Multiprocessor Architecture Fig. 1 shows a typical multiprocessor architecture where heterogeneous processors are connected to the communication network via wrappers. CPU IP (ASIC, Memory) Communication Network Fig. 1. A typical Multiprocessor SoC architecture DSP In most conventional embedded system architectures, a single processor plays the role of master in communication over a shared bus and other components (e.g. ASICs, memory, peripherals, etc.) play the role of slaves. Thus, most of system-design efforts focus on the design of the software running on the master processor and on communication optimization over the shared bus. Compared with conventional embedded systems design, in multiprocessor SoC design, implementation of system communication becomes much more complicated, since (1) heterogeneous processors are involved in communication and (2) complex communication protocols and networks are used: Single-processor architectures are made of a single CPU generally acting as a master and may include several slave peripherals. Multiprocessor architectures allow to integrate more than one CPU of different types. A key difference is that when we have several masters we generally need more sophisticated synchronization. In single-processor architectures, the communication structure is generally based on master/slave shared-bus interconnections. In multiprocessor architectures, it often happens that several complex system buses are used. In single-processor architectures, it is generally the case where the processor controls the communication protocols. This represents a heavy load for the CPU. In multiprocessor architectures, a communication coprocessor is often used to free processors from executing communication code. This also allows to separate computation and communication. With single-processor architectures, communication is generally performed through memory-mapped I/O. In multiprocessor architectures, the use of a communication coprocessor allows the use of high-level primitives (e.g. FIFO, broadcasting, etc.) that may be executed by hardware in parallel with the computation executed on the processor. Classic literature exists about multiprocessor design [2] [3]. They deal with MIMD, SIMD, VLIW architectures. This literature gives all the basic components used in this work, but it is too general to be efficient for SoCs. SoCs are specific to one application and thus require an applicationspecific architecture for communications and memory. These special architecture optimizations are generally implied by the application. Embedded SoCs need application-specific implementation since they have tight resource/performance constraints (e.g. area, power, runtime, etc.). Thus, they have heterogeneous application specific processors and optimized communication networks that have usually irregular structures.

4 C. Multiprocessor SoC Design Automation A schematic view of a multiprocessor SoC hardware/software organization is shown in Fig. 2. In order to master the complexity, the system is decomposed in several layers. The hardware layers: The lowest layer is composed of standard hardware components such as processors, ASICs and memories. The architecture of the SoC is described by the hardware on-chip communication layer. This is the glue required to make the components communicate together. The software part is also decomposed in several layers (They have been simplified for clarity). By increasing level of abstraction, we have: The lowest layer includes the drivers and the low-level architecture controllers. The communication managers; also called CPI (Communication Programming Interface). The resource management layer, i.e. scheduler. It provides higher level primitives such as task and memory management. The highest layer is the application. The first three layers constitute the software communication layer and may require an Operating System (OS). In reality, software interfaces may be much more sophisticated; they may also include resources management. And maybe, power management, reconfiguration / trade- offs Application Communication & resource management Low-level Communication (drivers, I/O, interrupts) OS On-chip Communication Network CPUs, IP, Memory (DSP, MCU) (ASICs, COTs ) Fig. 2. / organization for multiprocessor SoCs In addition to the classical RTL design flow, the design of such multiprocessor SoC requires four additional kinds of design steps. These are: 1. System design: this fixes the global partitioning of the system. This may be based on a formal specification or an informal one. The behavioral part of the application is partitioned in software parts (to be executed on the processors), and hardware parts (ASICs, IPs, peripherals, etc.). 2. System architecture design: this fixes the specification of the hardware components that needs to be used (e.g. selection of existing processors or specific hardware), and the on-chip communication network. 3. Hardware component design and selection: this step includes the design of specific hardware components and the selection of existing blocks (IPs). 4. The design of application software. In current practices for SoC design, hardware designers are in charge of all the hardware layers and software designers handle the software layers. In this scheme, the design of components is mixed with the design of communication layers. This leads to a lack of modularity and flexibility, and makes difficult the reuse of both hardware components and software code. Recently, several works were carried to separate component design from communication design [4] [5] [6] [7] [8] [9]. Fig. 3 shows an ideal design flow where the design of the communication layers is separated from the component design. The design starts with an informal model of the application. This model is used by system designers to fix the system architecture and to decide about the hardware/software partitioning of the application functionality. Then, three teams need to collaborate for the creation of the first high-level specification of the system. Hardware designers need to provide high-level models of the application-specific hardware components. Software designers need to provide a high-level executable model of the software parts. The architecture designer can design the communication part of the system in software and in hardware independently from the behavioral refinement done by software/hardware designers. Such a modular design is enabled by the usage of APIs as a clear interface between communication and behavior. Designer Abstract models Classical code Application API On-chip communication & OS Architecture Designer Abstract OS & on-chip communication network System Designer On-chip communication network API On-chip communication Designer Abstract models Classical code Fig. 3. Separating communication design from component design

5 The key issue in order to enable such a flow is the ability of describing the architecture at an abstract level where communication is separated from component on the hardware side and from the application on the software side. In this scheme, the abstract architecture may be used by the application programmer as an API. On the other side, the abstract architecture may use the hardware components through an abstract API. The next section discusses this issue, i.e. the separation between computation and communication for SoC design. III. SEPARATION BETWEEN COMPUTATION AND COMMUNICATION FOR THE DESIGN OF MULTIPROCESSOR SOCS In multiprocessor SoC design, since multiple heterogeneous processors and various communication protocols are used, system integration becomes a major step in system design. To enable system integration, a design approach called communication-based design is required [4] [22]. The key underlying concept is to enable system integration process, i.e. communication refinement, to be done independently from behavioral refinement. To do that, behavior and communication are separated in system specification. Thus, system communication can be refined independently from the behavioral part of system. Communication refinement consists of (1) wrapper design and (2) communication network design. A wrapper is used to adapt the different protocols of each component to the communication network (e.g. on-chip bus). For instance, to design a communication architecture of a shared bus with multiple components such as CPUs, DSPs, IPs, memory modules; the architecture designer should design interfaces to connect the components with the shared bus, i.e. to adapt the protocol of each component to the shared bus. In the communication-based design methodology, there are two types of approaches: usage of a standard bus protocol [6] or usage of a standard component protocol [5] [7]. For the usage of a standard bus protocol, for instance, IBM presents a bus architecture called CoreConnect [6]. To connect heterogeneous components to the bus architecture, a wrapper is designed to adapt the protocol of each component with that of CoreConnect. In contrary to the usage of standard bus protocol, VSIA [5] presents VCI and FI as standard component protocols. In this case, the designer can choose the protocol of on-chip bus and then design wrappers for components. [10] and [11] also present methods for communication network design in the case of multiprocessor SoCs. Recently, several commercial tools tried to enable the communication-based design concept. CoWare presents the tool N2C [8], Cadence presents VCC (Virtual Component Codesign) [9], Sonics presents SiliconBackplane µnetwork [7]. However, although the current commercial tools help the designer to reduce the design cycle they are still not able to obtain significant reduction in system design cycle and optimized multiprocessor architectures, due to the following limitations: (a) Hardware-oriented IP integration assuming on-chip bus usage: In most existing methods for communication-based design (standard bus/component protocol), wrapper design is required to connect each component to an on-chip bus. In current methods, the wrapper is implemented to achieve oneto-one protocol conversion between the protocol of component and that of on-chip bus considered. However, in practical systems, components can have multiple communication protocols and can be connected with multiple components via multiple communication networks. Thus, the wrapper should play many-to-many protocol conversions (between the protocol(s) of component and that (or those) of communication network(s)). (b) Support of mixed hardware/software wrappers is not handled: Another problem in current wrapper design is that the wrapper is considered only as a hardware interface. In the case that a software processor is connected to a communication network, the functionality of wrapper can be implemented in the form of software, hardware, or mixed software/hardware to achieve more optimal wrapper design in terms of system runtime, power consumption, area cost, etc. More generally, such a hardware/software trade-off can include the implementation of a specific communication network to enable hardware/software trade-off in communication refinement. Fig. 2 illustrates the hardware/software (/) trade-off. In the figure, the implementation of system communication (i.e. wrapper and communication network) can spread over the operating system (OS), the hardware interface, and the communication network. (c) Automatic architecture is not considered: In current wrapper-based system integration, system integration process, i.e. wrapper design and connection of components and communication network with wrappers are performed manually. Thus, the system integration process is time-consuming and error-prone. Such a manual process prevents the designer from trying other choices of system design, i.e. extensive design space exploration cannot be done. To enable design space exploration in system-on-chip design, automatic of wrappers and automatic interconnection of components, wrappers, and communication networks starting from high-level models is required. (d) System validation method lacks to achieve true modular design: Interface-based design enables modular design where a sub-system can be refined from a high abstraction level to a lower level, independently from the other parts of system. After sub-system refinement, the whole system consists of models at different abstraction levels (e.g. models of the

6 refined sub-system at a low level and models of the other parts of the system at a high level). To validate the intermediate implementation of the whole system, mixedabstraction-level (in short, mixed-level) cosimulation is required. However, current interface-based design methods have limitations in supporting mixed-level cosimulation in the case of heterogeneous multiprocessor SoCs. IV. DESIGN MODELS FOR MULTIPROCESSOR SOC DESIGN This section introduces a system design methodology aimed at solving all the limitations of current interface-based design methods. This is a multiprocessor SoC design approach using a communication refinement methodology based on virtual components [12] [13] [14] [15] [16] [17] [18] [19]. In this methodology, the system is described as a set of virtual components interconnected via channels. A virtual component consists of a wrapper and an internal component. The internal component corresponds to a heterogeneous component (e.g. a DSP or an IP) and the wrapper adapts accesses from the internal component to the external world, i.e. channels connected to the virtual component. The internal component and external channel(s) can be different in terms of (1) communication protocol, (2) abstraction level, and (3) specification language. Depending on the difference, the functionality of the wrapper is determined and automatically generated. A. Virtual Architecture Model The starting point is an abstract model of the architecture also called virtual architecture. In this approach, we represent systems as a hierarchical network of modules. Each module consists of a behavior and ports. Modules are connected with each other by connecting their ports via communication channels. The internal ports are specific to the module and the external ports connect the module to external channels. At the system level, channels hide details of protocol, for instance FIFO communication is realized using high-level communication primitives. At present we use an extension of SystemC for describing the abstract architecture. Three new concepts are used: the virtual module, consisting of the module and its wrapper the virtual port, grouping the corresponding internal and external ports having a conversion relationship. Thus, a wrapper may be composed of several virtual ports. the virtual channel grouping several channels having a logical relationship (e.g. channels belonging to the same communication protocol). The parameters of the architecture such as kind of protocol used and physical addresses are captured as attributes. This model is not executable because the internal structure of the wrappers is not yet fixed, only the internal and external ports are given. The main goal of this work is to generate these wrappers to produce (Fig. 4.b) a detailed architecture that can be both synthesized and/or simulated. B. Target Architecture Model When defining this model our goal was to have a generic model that can be customized to fit the specific needs of the application. Both computation and communication may be customized. For computation we may change the number and kind of components and for communication we can select a specific communication scheme. The architecture model is suitable to wide areas of application. A B C A B Communication Network C / wrapper CPU OS CC IP CC wrapper (a) System Specification Fig. 4. Virtual architecture model (b) System Architecture Physical Communication Network Fig. 5. Target architecture for multiprocessor SoC In the case of a heterogeneous specification, channel and module may have different abstraction levels or different communication protocols. In order to enable connection, in this case we use wrappers. The wrapper is composed of an interface, made of two sets of ports (internal and external ports). It constitutes the interface of the module and isolates module's behavior from the rest of the system (Fig. 4.a) We use a generic multiprocessor SoC architecture as shown in Fig. 5. Processors are connected with communication networks via wrappers. In fact, the processors are separated from the communication network by the wrappers that act as communication coprocessors (CC). Such a separation is necessary to free the processors from communication and it enables parallel execution of computation tasks and communication protocols.

7 In the generic architecture, each processor can have its own local architecture. To generate the processor part of the architecture, we use a library of local architecture templates. This architecture assumes a static allocation of tasks to processors and fully distributed control where each processor has its own operating system. Application Task1() {... fifo_write(d); yield2sched(); Task schedule Com. Service As shown in Fig. 6, the wrapper is made of a software part and a hardware part. On the hardware side, the internal architecture of the wrappers consists of processor adapter, channel adapter, and an internal bus. To generate the wrapper, we use the communication library where we have templates for the processor adapter and channel adapter. The number of channel controllers depends on the number of channels that are connected to the corresponding virtual module. On the software side, the wrappers provide the implementation of high-level communication primitives (API) used in the system specification and the drivers to control the hardware. It may also provide more sophisticated services such as task scheduling and interrupt management. DD DD V. MULTIPROCESSOR SOC DESIGN FLOW proc. adapter CA Fig. 6. / wrapper architecture Extended SystemC CA ib_enable ib_data ib_it A B Colif C The overall view of this design environment is shown in Fig. 7. Colif [12] is the only design representation used in our environment, the translation of the extended SystemC specification produces the first Colif model, which represents the virtual architecture, and is annotated with configuration parameters. In this design environment, there are three tools for automatic of wrappers: co-simulation wrapper generator[17], hardware wrapper generator[19], and the software wrapper generator [16]. Co-sim. Co-simulation library Executable co-simulation model wrapper library PA CA (hsk) OS library APIs send recv... PA (ARM7) S (timer) CA (hsk) wrapper OS Comm./Sys. Services fifo TS... Device Drivers wr rd... Proc. Adapter CA CA Fig. 7. Design environment for multiprocessor SoC RTL Architecture µp1 µp2 A B C wr. wr. Comm. network wr. wr. Co-sim. Executable co-simulation model Processor Application APIs Comm./Sys. Services Dev. Drivers

8 The co-simulation wrapper generator produces an executable model that is used to validate the Colif model. In the general case, this executable model is composed of a SystemC simulator that acts as a master for other simulators. A variety of simulators can participate in this co-simulation: SystemC, VHDL, Verilog, Instruction-set simulators (ISS) [17]. In the co-simulation library there are processor adapters for the different simulators that are supported in our cosimulation environment. There are also channel adapters that implement the different communication protocols supported in different languages. The software wrapper generator produces operating systems (OS) streamlined and pre-configured for the application that runs on each target processor. It uses an operating system library that is organized in three parts; APIs, communication/system services, and device drivers. Each part contains elements that will be used in a given software layer in the generated OS. Furthermore, the library contains a dependency graph between the elements which provides a way to decide what are the minimal set of elements necessary to implement a given OS service. This mechanism is used to keep the size of the generated OS at a minimum, by avoiding the inclusion of unnecessary elements from the library. The library used by the hardware wrapper has two parts: the processor library and the protocol library. All models stored in the hardware wrapper library are parameterized, and once configured with the allocation parameters they can be synthesized. The processor library contains processor adapters, template architectures for processors, processor cores, local memories and peripherals (e.g., the S timer in Fig. 7). For instance, the following allocation parameters are used in processor adapter configuration: ports allocated addresses, number of interrupts and their priorities. The protocol library contains channel adapters and communication network models. Channel adapter configuration uses the following allocation parameters: input/output type, master/slave operation, type of data transmitted, buffer size, and interrupt parameters. The of the hardware wrapper proceeds in three steps: (1) configuration of the selected blocks from the processor and protocol library; (2) instantiation of the parameterized blocks; and (3) of the final RTL architecture. VI. PERSPECTIVES The above mentioned design flow was applied to several design examples including a packet routing switch [15] [19], a VDSL application and a WCDMA decoder. The produced wrappers have performances close to the manually handcrafted equivalents. One of the main advantages of the presented design environment is the integration of the implementation protocols into the wrappers, which can be automatically generated. In other approaches, wrappers must be manually coded to adapt components to a standard bus e.g., for the IP-integration methodology of VSIA [20] or to implement protocols conversions between different abstraction levels e.g., in the interface encapsulation approach used in SystemC 2.0 [21]. This approach benefits from the automatic of wrappers by assembling library components, which results in modular design and easy integration. Another advantages of automatic wrapper are: It is possible to explore some trade-offs by moving the frontier between hardware and software wrapper implementation. For instance, a FIFO channel can be implemented fully in hardware, or in software or using a mixed implementation. Easy integration of advanced communication protocols (e.g., broadcasting and multi-master) in the design flow. It takes only the work of writing a channel adapter for master/slave ports, broadcasting, and/or multi-master bus to add these protocols to the design environment. Furthermore, since channel adapters can be instantiated many times during wrapper assembling, the communication network can scale to any size of broadcasting/multi-master elements without a big effort. These case studies have demonstrated its effectiveness for the automatic of a RTL architecture from a virtual architecture description annotated with configuration parameters. Controversially, while the automatic suppresses most error sources by treating itself a huge amount of implementation details, it is yet the designer s responsibility to define the configuration parameters manually. Several of the errors encountered in the case studies were directly related to a bad choice/placement of configuration parameters. VII. CONCLUSION This paper presented an approach for application-specific multiprocessor SoC architecture design. The system specification is a virtual architecture with configuration parameters described in a SystemC like model. tools using a methodology based on the assembling of library components produce an RTL architecture. Results have shown that the automatic generated wrappers have performances close to the commercial/manually handcrafted equivalents. The key issues are: Automatic wrapper eliminates most errors caused by manually managing all details of a multiprocessor SoC architecture and associated operating systems. The use of a virtual architecture model is a step in the right direction by raising the abstraction level when dealing with complex designs like the VDSL modem and the WCDMA decoder; Flexibility is very important in such design environments; fixed communication topologies or restricted set of protocols will hardly be accepted by designers because they want to reuse the internal designs

9 that frequently are tied to in-house (non-public) standards. REFERENCES [1] International Technology Roadmap for Semiconductors, [2] D.E. Culler, J. Pal Singh, "Parallel Computer Architecture", Morgan Kaufmann Publishers, 1999 [3] D.A. Patterson, J.L. Hennessy, "Computer Organization and Design - The Hardware/Software Interface", Morgan Kaufmann Publishers, 1998 [4] J. A. Rowson and A. Sangiovanni-Vincentelli, Interface-Based Design, Proc. of DAC, pp , June, [5] Virtual Socket Interface Alliance, [6] IBM Inc., Blue Logic Technology, [7] D. Wingard, "MicroNetwork-Based Integration for SOCs", Proc. 38 th Design Automation Conference, DAC 2001, Las Vegas, June [8] Coware Inc., N2C, [9] Cadence Design Systems, Inc., Virtual Component Co-design, hcd_l3_index.html [10] J. A. J. Leijten et al., PROPHID : A Heterogeneous Multi-Processor Architecture for Multimedia, Proc. Int l Conference on Computer Design, [11] P. Guerrier and A. Greiner, A Generic Architecture for On-Chip Packet Switched Interconnections, Proc. Design Automation and Test in Europe, [12] W. O. Cesario L. Gauthier, D. Lyonnard, G. Nicolescu, A. A. Jerraya, "An XML-based Meta-model for the Design of Multiprocessor Embedded Systems", VHDL International User's Forum (VIUF) Fall Workshop, Orlando, FL, October [13] P. Gerin, S. Yoo, G. Nicolescu, A. A. Jerraya, Scalable and Flexible Cosimulation of SoC Designs with Heterogeneous Multiprocessor Target Architectures, Proc. of Asia South Pacific Design Automation Conference, Jan [14] K. Svarstad, N. Ben-Fredj, G. Nicolescu, A. A. Jerraya, A Higher Level System Communication Model of Object-Oriented Specification and Design of Embedded Systems, Proc. of Asia South Pacific Design Automation Conference, Jan [15] A. Baghdadi, D. Lyonnard, N-E. Zergainoh, and A. A. Jerraya, An Efficient Architecture Model for Systematic Design of Application- Specific Multiprocessor SoC, Proc. Design Automation and Test in Europe, March [16] L. Gauthier, S. Yoo, and A. A. Jerraya, Automatic Generation and Targeting of Application Specific Operating Systems and Embedded Systems Software, Proc. of Design Automation & Test in Europe (DATE), [17] G. Nicolescu, S. Yoo, and A. A. Jerraya, Mixed-level Cosimulation for Fine Gradual Refinement of Communication in SoC Design, Proc. of Design Automation & Test in Europe (DATE), [18] S. Yoo, G. Nicolescu, D. Lyonnard, A. Baghdadi, A. A. Jerraya, A Generic Architecture for Multi-Processor SoC Cosimulation and Design, Int l Symposium on / Codesign (CODES) [19] D. Lyonnard, S. Yoo, A. Baghdadi, A. A. Jerraya, Automatic Generation of Application-Specific Architectures for Heterogeneous Multiprocessor System-on-Chip, Proc. 38 th Design Automation Conference, DAC 2001, Las Vegas, June [20] C. Lennard, P. Schaumont, G. de Jong, A. Haverinen, P. Hardee, Standards for System-Level Design: Practical Reality or Solution in Search of a Question?, Proc. of Design, Automation and Test in Europe Conference, pp. 576, Paris, France, March, [21] J. Gerlach, W. Rosenstiel, "System Level Design Using the SystemC Modeling Platform," In: R. Merker, W. Schwarz (Eds.), System Design Automation - Fundamentals, Principles, Methods, Examples, VDI Verlag Düsseldorf, [22] M. Sgroi, M. Sheets, A. Mihal, K. Keutzer, S. Malik, J. Rabaey, A. Sangiovanni-Vincentelli, "Addressing the System-on-Chip Interconnect Woes Through Communication-Based Design", Proc. 38 th Design Automation Conference, DAC 2001, Las Vegas, June 2001.