Scalable and Flexible Cosimulation of SoC Designs with Heterogeneous Multi-Processor Target Architectures Patrice Gerin
Sungjoo Yoo
Gabriela Nicolescu
Ahmed A. Jerraya
SLS Group, TIMA Laboratory 46 Avenue Felix Viallet, 38031 Grenoble, France fPatrice.Gerin,Sungjoo.Yoo,Gabriela.Nicolescu,
[email protected]
Abstract In this paper, we present a cosimulation environment that provides modularity, scalability, and flexibility in cosimulation of SoC designs with heterogeneous multi-processor target architectures. Our cosimulation environment is based on an object-oriented simulation environment, SystemC. Exploiting the object orientation in SystemC representation, we achieve modularity and scalability of cosimulation by developing modular cosimulation interfaces. The object orientation also enables mixed-level cosimulation to be easily implemented thereby the designer can have flexibility in trade off between simulation performance and accuracy. Experiments with an IS-95 CDMA cellular phone system design show the effectiveness of the cosimulation environment.
1 Introduction As embedded systems are requiring more complex computations, their target architectures are required to support efficient concurrent execution of multiple complex computations. To meet such a requirement, heterogeneous multi-processor target architectures are getting more popular [1][2][3]. In SoC (System-on-Chip) designs with heterogeneous multi-processor architectures, due to the complexity of target architectures as well as that of system functionality, system validation can become much more difficult than conventional embedded systems design with uni-processor and coprocessor target architectures. Thus, system validation can require majority (50 to 80%) of system design efforts [4]. To investigate the specific requirements of cosimulation in SoC design with heterogeneous multi-processor target architectures, Figure 1 exemplifies a case of an IS-95 CDMA (Code Division Multiple Access) cellular phone system design [5][6] with a heterogeneous multi-processor target architecture. Figure 1 (a) shows a hierarchically structural description of the system. It consists of two CDMA baseband modems (Tx and Rx), CELP (Code Excited Linear Prediction) voice encoder (ENC) and decoder (DEC), and a call processor (CAP). Sub-modules in the CDMA Tx (Rx) modem perform modulation (demodulation) functions (e.g. convolutional encoding/decoding, orthogonal modulation, pseudo-noise (PN) code generation, etc). Figure 1 (b) shows a target architecture that consists of four (possibly different) processors and HW interface (HIF) modules that constitute point-to-point communication channels. Mapping of functional modules are exemplified in the figure. For instance, three modules A, B and C are mapped onto processor P1 . Compared with the conventional embedded systems design with uni-processor and co-processor target architectures, SoC designs with heterogeneous multi-processor architectures require, especially,
CDMA baseband signal CDMA baseband signal
Modem: Rx A
B
C
DEC
CAP
Modem: Tx D
E
F
voice out dial pad display panel
ENC
voice in
(a) An IS-95 CDMA cellular phone system: a structural representation (A,B,C)
(DEC,CAP)
P1
P2
- Beh. model, e.g.
P1
P2
HIF
HIF
HIF
HIF
P3
P4
SystemC model
- C/A model, e.g. ISS, HW sim.
- Channel model
P3
P4
(D,E,F)
(ENC)
(b) A heterogeneous multi-processor target architecture
e.g. RPC, FIFO
- C/A model, e.g. BFM, HW IF (C or HDL)
(c) Simulation models in cosimulation
Figure 1: An example of SoC system design with a heterogeneous multi-processor target architecture. team efforts for sub-system designs and easy integration of the whole system on the complex target architectures. Consider a case that two design teams (one for modem design and the other for vocoder and call processor design) implement the system on the multi-processor target architecture. For efficient system cosimulation of SoC designs with heterogeneous multi-processor target architectures, both teams will require the following features. (1) Modularity and Scalability For sub-system design, it should be easy to simulate the sub-system with the practical testbench in the system context, i.e. cosimulation should have modularity. For the cosimulation of the whole system, the integration of simulation models of refined sub-systems to the whole system simulation should be easy, i.e. cosimulation should be scalable from sub-system design to the whole system design. (2) Flexibility In validating the refined sub-systems or the integration of the whole system, the designer should not always be obliged to perform cosimulation at a fixed abstraction level, e.g. functional simulation or cycle-accurate simulation of the whole (or sub-)system. Especially, in the case of multi-processor target architecture, cycle-accurate cosimulation with multiple instruction set simulators (ISS’s) and HW simulator(s) can be extremely slow. For fast cosimulation, the designer should be able to perform cosimulation at the highest ab-
straction level as possible. Thus, cosimulation should be flexible to enable the designer to trade-off between cosimulation performance and timing accuracy through mixed-level cosimulation. In Figure 1 (c), available simulation models (with different abstraction levels) are exemplified for processors and communication modules in the case of cosimulation of the IS-95 system. For the simulation of functionality mapped on a processor, the designer can run cosimulation with behavioral models like SystemC models or a cycleaccurate model like ISS or HW simulator. For the case of communication modules, (s)he can use a high-level simulation model like remote procedural call (RPC) function, a channel model like SystemC channel, or a cycle-accurate HW interface model like synthesizable VHDL models. Thus, the designer should be able to select the abstraction levels of simulation models to his/her purposes of cosimulation. In this paper, we present a cosimulation environment that provides modularity, scalability, and flexibility in cosimulation of SoC designs with heterogeneous multi-processor target architectures. This paper is organized as follows. We give a review of related work in Section 2. We explain briefly our SoC design flow in Section 3. In Section 4, we explain the cosimulation environment in detail. In Section 5 and 6, we give experimental results and conclusion.
2 Related Work Cosimulation methods and environments have been actively presented in academic areas and by EDA vendors. A. Ghosh et. al. present a distributed cosimulation environment where multiple simulators run in a lock-step manner synchronization [7]. Valderrama et. al. present a tool called VCI for the automatic generation of cosimulation interface in C-VHDL cosimulation [8]. Coste et. al. present a tool called MCI that enables multi-language cosimulation [9]. Hines et. al. present a cosimulation environment called Pia where (geographically) distributed cosimulation can be performed and a performance optimization method called selective focus can be used [10]. Albrecht et. al. present comparisons of cosimulation performance for the cases where multiple ISS’s and a hardware simulator are involved in cosimulation [1]. As commercial tools, Mentor Graphics Seamless CVE [11] and Synopsys Eaglei [12] provide cosimulation environments based on ISS’s and HW simulators. Coware N2C [13] enables C-based cosimulation as well as conventional one based on ISS’s and HW simulators. As a study of cosimulation based on single simulation environment, Polis [14] provides a uniform simulation environment (based on Ptolemy Discrete Event (DE) domain [15]) from high-level system simulation (with C and Esterel descriptions) to cycle-accurate simulation of synthesized SW and HW parts. Sung and Ha [16] present a backplane concept (as an extension of Ptolemy DE domain) that enables (cycle-accurate) cosimulation of the system with heterogeneous computation models (e.g. (cycle-accurate) cosimulation with Synchronous Data Flow and Finite State Machine models). In [17], Semeria and Ghosh present cosimulation methods based on SystemC [18]. In the viewpoint of abstraction levels of simulation models, there can be several abstraction levels adopted in cosimulation [19]. Among them, bus functional models (BFM’s) are widely used in mixed-level cosimulation, especially to debug the HW-SW interface part [17]. For more timing accuracy with still fast execution, cycle-approximate cosimulation [14] can be performed with behavioral simulation models that are annotated with delay information. In [18], BCASH (bus cycle accurate shell) enables mixedlevel cosimulation between RPC and (bus) cycle-accurate communication models. In the previous studies and commercial tools, their main focus has been embedded systems design with uni-processor and co-
Message level
Abstract channel
F1
Send (M, F3,C1)
Write (port C1, val) Wait until ack
F4
F5 Access
SW
Driver level
F3
F2
F1
HW F3
Comm. control
F4
F2
F5
Logical Ports
Logical connection
RT Level
syscall (adr, val)
Sw
OS SW
F1,F4
µP
IP
HW Interface
Interface
HW Physical Ports
Physical connection
Figure 2: An overview of SoC design flow for heterogeneous multiprocessor target architectures. processor architectures. Compared to them, we focus on SoC designs with heterogeneous multi-processor target architectures. In this paper, our main contribution is to satisfy the above mentioned requirements of cosimulation in SoC designs with heterogeneous multi-processor target architectures: scalability (easy integration of simulation models of sub-systems) and flexibility (in terms of enabling the trade-off between performance and accuracy). Among the related work, Semeria and Ghosh’s work [17], Takemura et. al.’s work [20], and BSASH concept in SystemC 1.1 are similar to ours in that they present a BFM [17], a BCA (Bus Cycle Accurate) module [20], and a BSASH module [17] as the basic elements for the composition of mixed-level cosimulation. Compared to them, we focus on mixed-level cosimulation between two specific abstraction levels (driver level and register transfer level to be described in Section 4) and present how to construct a cosimulation environment to meet the requirements of scalability and flexibility utilizing the presented modular cosimulation interfaces.
3 An Overview of SoC Design with Heterogeneous MultiProcessor Target Architectures Figure 2 exemplifies our SoC design flow with heterogeneous multiprocessor target architectures. In the figure, we divide the abstraction levels of system representation, in the viewpoint of communication aspects, into three levels: message level (ML), driver level (DL), and register transfer level (RTL). Through those levels, the system is represented by (hierarchical) modules and connections of modules. Each module has behavioral contents that can be described in different languages (e.g. C, SDL, VHDL, etc), and ports that connect the module to other modules via communication channels. At ML, the designer develops a high-level hierarchically structural system specification. At this level, no assumption of communication implementation is made. Thus, communication channels have not yet their specific communication protocols. If specific protocols are already assigned to the ports (e.g. IP cores), communication channels can perform protocol conversion between two associated ports. Thus, we call a communication channel at ML an abstract channel. Communication details (e.g. protocol conversion) of the abstract channel are encapsulated in high-level communication primitives (e.g. send, receive, put, get, etc). Such communication primitives are called using remote procedural call (RPC) mechanism by the ports of the modules. The high-level structural system specification is refined down to RTL via several refinement steps: processor allocation/mapping,
communication protocol selection, communication synthesis, operating system (OS) synthesis, SW compilation, and HW synthesis. In the refinement from ML to DL, communication protocol selection and processor allocation/mapping are performed. Especially, in communication protocol selection, an abstract channel is refined to a specific channel like a FIFO, and the details (e.g. FIFO size, blocking or non-blocking read/write, etc.) of the specific channel are determined. Figure 2 shows an example of DL representation after the refinement. In the figure, the DL representation is described as an abstract architecture made of a set of modules interconnected through logical interconnections. The behavior of selected protocols is executed by a communication controller. For instance, in the case of SystemC representation, the communication controller corresponds to channels in SystemC that implement specific (FIFO) communication protocols. The logical interconnections transfer data with fixed data types (e.g. integer, real, fixed, etc) among logical ports of modules. The logical ports of modules access the logical interconnections with device driver-level functions. That is why we call the abstraction level driver level. In the final refinement from DL to RTL, SW modules are targeted onto specific processors through OS synthesis and SW compilation. Through communication synthesis, the communication protocols are implemented into HW interfaces and SW routines (e.g. dedicated FIFO, shared memory, interrupt service routine, etc). The logical ports/interconnections are refined to physical ports/interconnections (of signals). HW modules (including the HW interfaces) are refined by HW synthesis. Figure 2 also exemplifies the RTL components generated in the refinement. Cosimulation can be performed at each abstraction level. For instance, after the refinement from ML to DL, cosimulation at DL can be performed to validate the protocol selections made in the refinement. Mixed-level cosimulation can also be performed. For instance, SW simulation models can be selected from RTL, e.g. ISS’s and HW simulation models can be selected from DL, e.g. SystemC simulation models (with annotated delays).1 The details of cosimulation including mixed-level cosimulation will be described in Section 4.
4 Cosimulation of SoC Designs with Heterogeneous MultiProcessor Target Architectures In our work, we perform cosimulation based on SystemC simulation environment [18].2 The main advantage of utilizing SystemC simulation environment is that we can validate system specification from specification capture to low-level system implementation in a uniform environment. Object orientation in SystemC enables the requirements of cosimulation (scalability and flexibility) to be easily satisfied. Exploiting object-oriented SystemC representation, we achieve modularity and scalability of cosimulation by developing modular cosimulation interfaces. The object orientation also enables mixed-level cosimulation to be easily implemented since the abstraction level of each simulation model of system functionality can be easily selected and the modular cosimulation interface can be adapted to the selected abstraction level of simulation model.
4.1 SystemC Simulation Environment as a Cosimulation Backplane We use SystemC simulation environment as a cosimulation backplane. Figure 3 illustrates how it is used as a cosimulation back1 In this paper, when we address timing accuracy of simulation (model), we use two terms, RTL and cycle-accurate, interchangeably. 2 Although our current implementation of cosimulation environment is based on SystemC, it can be easily extended to other simulation environments as far as they provide (1) object orientation in the representation of simulation codes and (2) cyclebased simulation engines.
ISS HW simulator
IPC
ISS
IPC
IPC BFM BFM BFM BFM
HIF
SystemC model BFM MIF
TIF
HIF
SystemC Backplane
Figure 3: SystemC as a cosimulation backplane. plane in the case of the target architecture shown in Figure 1 (b). Recall that the target architecture has four processors and point-topoint communication channels. Figure 3 shows a case of cosimulation where two ISS’s, a HW simulator, and SystemC models are involved. In cosimulation, the SystemC environment plays a role of cyclebased simulation engine, i.e. it transfers events among all the modules in SystemC. In terms of SystemC modules, cosimulation can involve three types of modules described in SystemC as shown in Figure 3: cosimulation interface modules, (cycle-accurate or behavioral) simulation models of HW interface (HIF) modules in the target architecture, and high-level simulation models of system functionality. The cosimulation interface module performs two kinds of event transfer: (1) event transfer between an external simulation model (e.g. an ISS or a HW simulator) and SystemC simulation and (2) event transfer between two simulation models of different abstraction levels. For an example of cosimulation interface module, a BFM is used for the communication between an ISS and SystemC simulation as shown in Figure 3. The figure also shows simulation models of HIF modules and high-level (SystemC) simulation models of system functionality. The details of cosimulation interface module will be given in Section 4.2. In the implementational viewpoint, cosimulation is initiated by first executing the SystemC simulation. Each external simulator is initiated by its specific SystemC cosimulation interface module. Each external simulator exchanges events with the SystemC interface module at every system cycle of its own. For the communication between external simulators and cosimulation interface modules, interprocess communication (IPC) can be used. In Figure 3, three cases of IPC are shown: two IPC’s between BFM’s and ISS’s and one IPC between a HW simulator and its cosimulation interface module.
4.2 Modular Cosimulation Interfaces In our cosimulation environment, there are three types of cosimulation interface: transfer interface (TIF), bus functional model (BFM), and mixed level interface (MIF). A TIF module is used for the communication between SystemC simulation and an external simulator that generates all the cycle-accurate interface events. For instance, a HW simulator can generate all the cycle-accurate events of the HW module simulated in it. In this case, the TIF module just transfers the events between the HW simulator and SystemC simulation. A BFM is used to transform a functional memory access (e.g. read a data item at a specific physical address) to a sequence of cycle-accurate memory accesses (e.g. cycle-accurate
DL
DL
DL
A
Tx
A
DL channel
(b)
MIF
A
CAP
(a) DL
Modem: Rx
Base station model
B
channel
RTL
DL
B
A
RTL MIF
channel
voice out
DEC
CAP
E
F
User I/F model
ENC
voice in
(a) An IS-95 behavioral simulation model in SystemC Base station model Tx
Modem: Rx A
CAP
B
BFM (ARM)
C
MIF
Modem: Tx D
Rx
simulation of address/data bus signals and control signals). For instance, most ISS’s do not generate all the cycle-accurate events at the processor interface, instead they may call memory access functions. In this case, BFM’s are used to generate all the cycle-accurate events at the processor interfaces for each memory access. An MIF module is used for the communication between two modules of different abstraction levels. In this paper, we focus on the communication between two abstraction levels: DL and RTL. Since the MIF module is connected to both DL and RTL modules, it has two types of ports: channel ports and signal ports. Channel ports (signal ports) are connected to the DL (RTL) module. Figure 4 shows examples of using MIF modules. Figure 4 (a) shows a case that two DL modules are connected by a DL channel. We assume that DL module B is refined to RTL in Figure 4 (b) and (c). Depending on the abstraction levels of communication channel, MIF modules are inserted into two types of boundaries between DL and RTL. In the case that the abstraction level of communication channel is DL as shown in Figure 4 (b), an MIF module is inserted between the DL channel and RTL module B. The DL channel is connected to the MIF channel port and a processor (where module B is executed) is connected to the MIF signal ports. In the case that the abstraction level of communication channel is RTL, an MIF module is inserted between DL module A and the RTL channel as shown in Figure 4 (c). The operations of MIF modules are transferring channel access requests (e.g. channel read/write, channel availability checks) between RTL and DL. In the case of Figure 4 (b), the MIF module is the interface of the DL channel to RTL. It transforms channel accesses at RTL (e.g. memory accesses) from the RTL module into DL channel accesses (e.g. channel read/write, channel availability checks). Since it is connected to the RTL processor where module B runs, to notify the arrival of data at the DL channel, it can also generate an interrupt to the RTL processor if the SW processor takes an interrupt. In the case of Figure 4 (c), the MIF module is the interface of the DL module A. In this case, it receives DL channel accesses from DL module A and transforms them to RTL accesses (e.g. memory accesses). To receive the notification of new data arrival from the RTL channel, it can have an interrupt service routine (ISR) to receive the notification if DL module A is mapped to a SW processor. In general, the automatic generation of MIF modules for any types of communication channel implementation may be difficult. As a practical way, we apply a library concept to the selection of MIF modules from a mixed-level cosimulation interface library. Note that the difference between BFM (BCASH) and MIF module is that the BFM (BSASH) transforms functional memory accesses (RPC’s) into cycle-accurate memory accesses and vice versa while the MIF module transforms DL channel accesses into cycle-accurate memory accesses and vice versa. By exploiting the MIF module, the communication interfaces of DL module and DL channel, i.e. channel access functions, are not changed for mixed-level cosimulation. Due to the limitation of paper length, more detailed explanation of the MIF module operation is not be given in this paper. Instead, in this paper, we focus on its usage (and the usage of other cosimulation interface modules) in
D
Rx
B
Figure 4: Two cases of using MIF modules.
C
Modem: Tx
RTL
(c)
B
E
MIF
F
HIF
MIF CIF
HIF
MIF
User I/F model
BFM (ARM)
(b) Cosmulation with two ISS’s and SystemC models Base station model Tx
BFM (68K)
BFM (ARM)
MIF
HIF
HIF
MIF
MIF
HIF
HIF
MIF
BFM (68K)
BFM (ARM)
CAP Rx
User I/F model
(c) Cosimulation with four ISS’s and SystemC models
Figure 5: An example of IS-95 cellular phone design. mixed-level cosimulation.
4.3 Scalability from Modular Cosimulation Interfaces In terms of SystemC representation, cosimulation interface modules are instantiated as objects in the SystemC representation of cosimulation. Such object orientation enables modularity and scalability in cosimulation. Figure 5 illustrates how modularity and scalability are obtained in the case of the IS-95 cellular phone system design. In the figure, three cases of simulation are shown from behavioral SystemC simulation of the system (including the simulation models of environment such as base station model and user interface model in Figure 5 (a)) to the cycle-accurate cosimulation of the system on a four-processor (two 68000 processors and two ARM7 processors) target architecture in Figure 5 (c). In Figure 5 (a), the system is described at DL, i.e. its modules (ENC, DEC, CAP, Tx, Rx, base station and user interface models) are connected with each other by SystemC channels. Figure 5 (b) shows a case of cosimulation where a sub-system refinement is validated. As shown in the figure, the vocoder and call processor parts are executed on two ISS’s of ARM7 processor and the other parts of the whole system are still described in SystemC. The same applies to the other sub-system design (in this case, modem parts). Such modular validation of the refined sub-system is easily done by substituting the original behavioral models of the sub-system by its refined models and the cosimulation interface modules. In Figure 5 (b), note that two BFM’s are used for two ISS’s and four MIF modules for the communication between the simulation models of real HW interface (HIF) modules at RTL and SystemC simulation models at DL. Modular cosimulation interfaces make it easy to integrate the simulation models of sub-systems and to perform cosimulation of the whole system. Figure 5 (c) shows the integration of cycleaccurate simulation models (i.e. ISS’s and HW interface modules) of two sub-systems. In this case, four BFM’s (two for ARM ISS’s and two for 68000 ISS’s) and four MIF modules are used. Note that cosimulation still utilizes the SystemC simulation to execute the other part of IS-95 system (e.g. the base station and user interface models). As shown in the figure, MIF modules play a key role to enable cosimulation of the whole system. In the view point of real code generation of cosimulation models, such extension to the cosimulation of more refined system and more complex target architecture is just substituting/removing the
instantiations of required/substituted SystemC modules and the declarations/removals of required/unused signals in the SystemC code of cosimulation.
4.4 Flexibility from Performance and Accuracy Trade-o Providing trade-off between simulation performance and accuracy can give the designer flexibility in cosimulation. In fact, full cycleaccurate cosimulation of SoC systems with heterogeneous multiprocessor architectures can give poor performance since multiple low-level simulators are involved and cycle-accurate synchronization is required between them. On the other side, full behavioral simulation is much faster but may not provide the required accuracy. To enable such trade-off, mixed-level cosimulation should be supported since, in mixed-level cosimulation, the designer can speed up cosimulation by raising the abstraction levels of sub-systems that are not his/her major concerns of cosimulation.3 Figure 6 shows various cases of cosimulation, in the view point of abstraction levels, which are possible in our cosimulation environment: from full functional simulation in SystemC (Figure 6 (a)) to cycle-accurate simulation (Figure 6 (d)). The designer can choose the abstraction level of each simulation module to his/her purposes. For instance, behavioral simulation with MIF modules (shown in Figure 6 (b)) can be used to validate the implementation of HW interface modules between processors. In the case shown in Figure 6 (c), the designer can speed up timing simulation by annotating the delay information to the behavioral models (in this case, two modules SC1 and SC3 ) whose timing delays can be statically analyzed. In the figure, two MIF modules connect the behavioral modules to the other modules at RTL. Note that, in Figure 6 (b) and (c), HW simulators (HWS’s) are connected to SystemC backplane via TIF modules. In our cosimulation environment, since cosimulation interfaces and SystemC simulation models are modular, the selection of abstraction levels of simulation models can be done at a module basis. In this mixed-level cosimulation, the abstraction level of each module is statically determined at the module instantiation. Performance results related with mixed-level cosimulation will be given in the next section.
5 Experiments
SC1
SC2
SC3
MIF
SC3
BFM
MIF
HIF
HIF
SC3
SC4
MIF
MIF
MIF
MIF
HIF
HIF
HIF
HIF
SystemC backplane (C/A)
(a) Full functional simulation ISS2
SC2
SC4
SystemC backplane
SC1
SC1
HWS4
TIF
SystemC backplane (C/A) (c) Cycle-approximate cosimulation
(b) Cosimulation w/ MIF’s ISS1
ISS2
BFM
BFM
HIF
HIF
HWS3
HWS4
TIF
TIF
SystemC backplane (C/A) (d) Cycle-accurate cosimulation
Figure 6: Performance and accuracy trade-off in cosimulation. As a heterogeneous multi-processor target architecture to implement the IS-95 system, we use two ARM7 processors and two 68000 processors which are connected via point-to-point channels. We implement the vocoder and call processor on two ARM7’s and the CDMA modems on two 68000’s. Modular cosimulation interfaces enable to run cosimulation of the IS-95 system easily from behavioral system simulation to mixedlevel cosimulation, and to cycle-accurate cosimulation by substituting simulation models at a higher abstraction level (DL) to lower level (RTL) simulation models in SystemC code. Table 1 shows cosimulation runtimes (on a Sun UltraSparc IIi, 333 MHz and 262 MB main memory) obtained from some of our mixed-level cosimulation experiments. In the table, four sub-systems are shown to have two types of simulation model: behavioral (DL) model, i.e. SystemC model and cycle-accurate (RTL) model, i.e. ARM7 or 68000 processor. For instance, in Case 1, all sub-systems are simulated with SystemC simulation models, i.e. full functional simulation at DL is performed in this case. In Case 2, only the encoder part is simulated at RTL with a ARM7 ISS and the other sub-systems at DL with SystemC models. Correspondingly, in Case 6, each sub-system is simulated at RTL with its specific ISS, i.e. full cycleaccurate simulation is performed. Note that, in all the cases, the other parts (base station and user interface models) of the system are simulated at DL with SystemC simulation models. As shown in the table, modular cosimulation interfaces enable the designer to trade off between simulation performance and accuracy by performing mixed-level cosimulation.
We implemented modular cosimulation interfaces, i.e. MIF modules, BFM’s and TIF modules, in SystemC. In the case of BFM, interprocess communication (IPC) based on shared memory is used for the communication between external simulators and BFM’s. In the experiments, we run cosimulation of the IS-95 mobile phone system (shown in Figure 1 and 5). In the IS-95 system, as shown in Figure 5, voice data (68 Kbps) spoken by the mobile phone user are encoded to four types of data rate (9.6 Kbps, 4.8 Kbps, 2.4 Kbps, and 1.2 Kbps) by the encoder part (ENC) of vocoder. Then, they are sent to the base station via the CDMA modem transmitter (Tx). The encoded voice data of the other correspondent in the conversation are sent by the base station, received by the CDMA modem receiver (Rx), and decoded by the decoder part (DEC) of the vocoder. The base station and mobile station communicate with each other on a frame basis (20 ms per frame). In our cosimulation, we run 20 frames (0.4 second in reality) of voice conversation.
6 Conclusion
3 In practical cases, apart from the trade-off between performance and accuracy, there are also cases where mixed-level simulation is inevitable. For instance, in the case that the designer uses an IP block whose abstraction level is fixed at a level, mixed-level cosimulation is inevitable. In another case that the designer refines a subsystem from a high abstraction level (behavioral level) down to a lower abstraction level (RTL) and (s)he has only the behavioral model of the environment of the subsystem, mixed-level cosimulation is also inevitable.
References
In this paper, we presented a cosimulation environment that provides modularity, scalability, and flexibility in cosimulation of SoC designs with heterogeneous multi-processor target architectures. Modularity in cosimulation is achieved by modular cosimulation interfaces. It enables (1) sub-systems to be validated with the practical testbench in the system context, (2) easy integration of simulation models of sub-systems, and (3) flexible cosimulation to the designer’s purposes by mixed-level cosimulation.
[1] T. W. Albrecht, J. Notbauer, and S. Rohringer, “HW/SW CoVerification Performance Estimation & Benchmark for a 24 Embedded RISC Core Design”, Proc. Design Automation Conf., pp. 808–811, June 1998.
Case # 1
Table 1: Comparisons of cosimulation runtimes. Abstraction Levels Runtimes ENC DEC Tx Rx (sec) DL
DL
DL
DL
42
DL
DL
DL
13,068
RTL (ARM7)
DL
DL
26,606
DL
4,604
3
RTL (ARM7) RTL (ARM7)
4
DL
DL
5
DL
DL
6
RTL (ARM7)
RTL (ARM7)
2
RTL (68000) RTL (68000) RTL (68000)
RTL (68000) RTL (68000)
11,072 72,744
[2] I. Karkowski and H. Corporaal, “Design Space Exploration Algorithm For Heterogeneous Multi-processor Embedded System Design”, Proc. Design Automation Conf., June 1998. [3] Qualcomm, Inc., “MSM3300”, available at http://www.qualcomm.com/cdmatechnologies/products/msm3300.html. [4] M. Keating and P. Bricaud, Reuse Methodology Manual, Kluwer Academic Publishers, 1999. [5] S. Yoo, J. Lee, J. Jung, K. Rha, Y. Cho, and K. Choi, “Fast Prototyping of an IS-95 CDMA Cellular Phone: a Case Study”, Proc. the 6th Conference of Asia Pacific Chip Design Languages, pp. 61–66, Oct. 1999. [6] TIA/EIA-95A, “Mobile Station-Base Station Compatibility Standard for DualMode Wideband Spread Spectrum Cellular Systems”, 1995. [7] A. Ghosh, M. Bershteyn, R. Casley, C. Chien, A. Jain, M. Lipsie, D. Tarrodaychik, and O. Yamamoto, “A Hardware-Software Co-simulator for Embedded System Design and Debugging”, Proc. Asia South Pacific Design Automation Conference, 1995. [8] C. Valderrama, F. Nacabal, P. Paulin, and A. Jerraya, “Automatic VHDL-C Interface Generation for Distributed Cosimulation: Application to Large Design Examples”, Design Automation for Embedded Systems, vol. 3, no. 2/3, pp. 199– 217, Mar. 1998. [9] P. Coste, F. Hessel, Ph. Le Marrec, Z. Sugar, M. Romdhani, R. Suescun, N. Zergainoh, and A. A. Jerraya, “Multilanguage Design of Heterogeneous Systems”, Proc. Int. Workshop on Hardware-Software Codesign, May 1999. [10] K. Hines and G. Borriello, “Dynamic Communication Models in Embedded System Co-Simulation”, Proc. Design Automation Conf., pp. 395–400, June 1997. [11] Mentor Graphics, Inc., “Seamless CVE”, available at http://www.mentorg.com/seamless/ . [12] Synopsys, Inc., “Eaglei”, available at http://www.synopsys.com/products/ hwsw/eagle ds.html . [13] Coware, Inc., “N2C”, available at http://www.coware.com/cowareN2C.html. [14] F. Balarin et al., Hardware-Software Co-Design of Embedded Systems, Kluwer Academic Publishers, 1997. [15] J. T. Buck, S. Ha, E. A. Lee, and D. G. Messerschmitt, “Ptolemy: a framework for simulating and prototyping heterogeneous systems”, Int. Journal of Computer Simulation, special issue on Simulation Software Development, vol. 4, pp. 155–182, Apr. 1994. [16] W. Sung and S. Ha, “Efficient and Flexible Cosimulation Environment for DSP Applications”, IEICE Trans. on Fundamentals of Electronics, Communications and Computer Sciences, vol. E81-A, no. 12, pp. 2605–2611, Dec. 1998. [17] L. Semeria and A. Ghosh, “Methodology for Hardware/Software Co-verification in C/C++”, Proc. Asia South Pacific Design Automation Conference, Jan. 2000. [18] Synopsys, Inc., “SystemC, Version 1.1”, available at http://www.systemc.org/. [19] J. A. Rowson, “Hardware/Software Co-Simulation”, Proc. Design Automation Conf., pp. 439–440, 1994. [20] K. Takemura, M. Mizuno, and A. Motohara, “An Approach to System-Level Bus Architecture Validation and its Application to Digital Still Camera Design”, Workshop on Synthesis and System Integration of Mixed Technology (SASIMI), pp. 195–201, Apr. 2000.
