See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/224672800

A unified HW/SW interface refinement approach for MPSoC design

Conference Paper · July 2006

DOI: 10.1109/NEWCAS.2006.250917 · Source: IEEE Xplore

CITATIONS READS

3 550

6 authors, including:

Wassim Youssef Patrice Gerin

11 PUBLICATIONS   108 CITATIONS   
École Nationale Supérieure d'Informatique et de Mathématiques
17 PUBLICATIONS   284 CITATIONS   
SEE PROFILE
SEE PROFILE

Frédéric Pétrot Ahmed Jerraya

École Nationale Supérieure d'Informatique et de Mathématiques Atomic Energy and Alternative Energies Commission
210 PUBLICATIONS   1,996 CITATIONS    413 PUBLICATIONS   5,971 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Work in Pamtras University for cosimulation View project

Nanoelec IRT3D View project

All content following this page was uploaded by Frédéric Pétrot on 31 May 2014.

The user has requested enhancement of the downloaded file.

 ISSN 1292-862

CNRS INPG UJF

TIMA Lab. Research Reports

A UNIFIED HW/SW INTERFACE REFINEMENT

APPROACH FOR MPSoC DESIGN

BOUCHHIMA, A. , KRIAA, L., YOUSSEF, W., PETROT, F.

JERRAYA A.A.

TIMA Laboratory, 46 avenue Félix Viallet 38000 Grenoble France

FirstName.LastName@imag.fr

ISRN TIMA--RR-06/06-01--FR

TIMA Laboratory,
46 avenue Félix Viallet, 38000 Grenoble France
 A Unified HW/SW Interface Refinement Approach
for MPSoC Design
Aimen Bouchhima, Lobna Kriaa, Wassim Youssef, Patrice Gerin, Frédéric Pétrot, Ahmed A. Jerraya
TIMA laboratory, 46 Ave Felix Viallet 38031 Grenoble CEDEX, France
FirstName.LastName@imag.fr
Abstract- We introduce the service based component model as a The implementation step consists then in refining each abstract
unifying concept to specify and refine the HW/SW interface in HW/SW interface, taking into account the specificities of each
MPSoC designs. The model allows encompassing the intricate
dependencies between hardware components and low level system subsystem. The refined HW/SW interface is composed of two
software in a structured, component based approach. Based on parts: the hardware-dependent software (HdS) and the CPU
this model, we propose a method and tools to automate the subsystem hardware architecture (Fig. 1-c).
refinement of abstract HW/SW interfaces using a predefined HW/SW interface design has been studied by different
component library. The main benefit of such refinement communities, each focusing on different components of the
methodology is a seamless HW/SW integration allowing efficient
customization of the HW/SW interface. The approach was HW/SW interface. [1] and [2] propose automatic generation of
successfully applied to the design of an MPEG-4 video encoder. wrappers to connect hardware components. In [3], a driver can
be synthesized from a formal specification of the target device
I. INTRODUCTION
for a platform-independent virtual environment, and then the
Multiprocessor System-on-chip designs (MPSoC) integrate virtual environment is mapped to a specific platform to
an increasing number of heterogeneous programmable units complete the driver implementation. CoWare presents an
(CPU subsystems), hardware intellectual property (IP) blocks, approach to codesign the CPU and its hardware adaptation layer
memories, and sophisticated communication interconnects. [4]. In Metropolis, designers can define communication
Designing and programming such complex devices is now primitives and execution rules suitable for design exploration of
becoming a major challenge for several reasons. In conventional bus architectures and memory access during synthesis [5]. In
SoC design approaches, hardware and software are usually [6], a component-based design approach generates an
considered separately as two “monolithic” blocs with the CPU application-specific operating system including device drivers
as ultimate interface between the two (Fig. 1-a). This traditional and network interface based on a fixed CPU subsystem
view of the SoC architecture has many disadvantages in a architecture. In COSY, the specification is a set of tasks
heterogeneous MPSoC context. In fact, the monolithic aspect communicating through lossless blocking FIFOs, which are
makes the dependences inside and across the two sides (HW and implemented using pre-defined schemes [7]. [8] proposes a
SW) implicit, very mangled and dispersed among unstructured service-based interface composition method as an alternative to
elements. This hardly limits the flexibility (i.e the ability to cope the conventional layered software architecture of the OSI
with new architectures) and leads, generally, to inefficient network protocol stack.
designs with multiple stacks and huge overhead. As opposed to these approaches that focused separately either
Ideally, one would like to separate low level implementation on the hardware part or the software part, we propose, in this
issues from high level application related aspects. The abstract paper, a unified model that generalizes the service-based
architecture concept (Fig. 1-b) allows such decoupling by component approach to encompass the entire HW/SW interface.
describing SoC architecture as a set of hardware and software This allows (1) efficient HW/SW architecture implementation
subsystems communicating through abstract communication through fine-grained composition, (2) flexible
channels. The abstract HW/SW interface is viewed as the hardware/software partitioning and (3) automatic architecture
container that wraps the application software of each software generation.
subsystem allowing the interaction with the rest of the system. This paper is organized as follows. Section 2 introduces the
HdS
service-based component model used to abstract the HW/SW
ApplicationHW
& low-level HW HW
SW compatible
modules with Hardware
modules
Application
modules
software
fifo write ... comm. interface. Section 3 describes the HW/SW interface generation
CPU & HW platform cxt. sched. ... system
tool based on this model. Section 4 presents results of a
write reg. ... ... drivers
CPU API case-study design. Finally, section 5 concludes this paper and
CPU subsystem
HW platform
Abstract CPU
CPU Memory
memory
gives some insight on future work.
Hardware HW & inf. interface
Hardware
to CPU BUS

Hardware interconnects Abstract comm. channels network inf. other periph. II. SERVICE-BASED COMPONENT MODEL
(a) Traditional view of SoC (b) Abstract architecture (c) Refined HW/SW interface
The abstract HW/SW interface is defined by specifying two
Fig. 1. HW/SW interface refinement for a general System-on-Chip architecture
set of services: one that is related to the application software
(API) and the other one related to interconnect (communication (1) C ' ⊆ (C I T (i P )), S ' ⊆ (S I T (i P )), S ' r ⊆ S r , S ' p ⊆ S p
services). The HW/SW interface itself may be modeled as a set
of interdependent components. Fig. 2 shows the metamodel (2) ∀ s ∈ S ' , C p (S ) ≤ 1
view of a service-based component in the abstract HW/SW (3) i P = I P ( ARCH )
interface using a UML-like class diagram notation. Each (4) i R ⊇ I R ( ARCH )
component is modeled by an interface declaration and an
implementation tree. The interface declaration specifies the (5) There dosn' t exist ARCH ' ⊃ ARCH satisfying 1,2,3 and 4
services provided and required by the component. It defines the
way to connect with other components. The component Stated differently, ARCH is a resolved sub-graph of SDG,
implementation describes its behavior using macrocode that will maximal in SDG*, with iR and i P as required and provided
be later expanded to create software code, hardware model, or interfaces respectively. It can be shown that the existence of
functional model (used for simulation). ARCH depends on the compatibility of the two interfaces iR
and i P , i.e. (T (i P ) ∩ I R ( SDG )) ⊆ i R , where T (i P ) = U T ( s ).
1..* 1 1 s∈iP
Provided Component

1 According to this definition, starting from the same SDG,

1..* 1
Required Declaration
Interface Implementation 1..* Source multiple ARCH instances may satisfy the above constraints. Fig.
3-b shows a possible instance derived from the SDG partially
1
Description depicted in Fig. 3-a. In this figure, service s2 is provided by two
different components (c2 and c5) in the SDG. This multiple
Fig. 2. Metamodel view of service-based component model. dependency has been resolved in the ARCH instance by
choosing component c2. The choice between the possible
A. The Service Dependency Graph implementations may be driven by application constraints like
The dependency relations between the components of an latency, cost, power, etc.
abstract HW/SW interface model can be represented as a graph, Provided Application software
as shown in Fig. 3-a. The nodes are services and components service
s1
Component
and the edges indicate service dependences. We call the s1
Service- based
component
Component c1
resulting graph a service dependency graph (SDG). This graph c1
library c4 Service

corresponds actually to a component library that can be used to Required s4

generate different architectures. Service
s2
s4 s2
c2
Formally, a service dependency graph can be defined as
follows: Component c5 Component c2 s3

SDG = C , S , S r , S f where s3
Hardware interconnects

(a) Service dependency graph (b) Example of ARCH instance

C : finite set of components
S : finite set of services
S r ⊆ (C × S ) : finite set of arcs ⇒ required services
S p ⊆ (C × S ) : finite set of arcs ⇒ provided services
Furthermore, we note by C p (s ) the set of all components
providing the service s, i.e.
C p ( s ) = {c ∈ C ∃ s p ∈ S p ∧ s p = ( s, c ) } .
The graph SDG is said to be resolved if and only
if C p ( s ) ≤ 1 , ∀ s ∈ S .
Given two sub-sets i R ⊆ I R (SDG ) and i P ⊆ I P (SDG ) ,
the refinement of the abstract interface defined by i R and i P
with respect to the original SDG consists in finding the minimal
resolved sub-graph “connecting” the two sub-sets. We call this
sub-graph ARCH.
We note by SDG* = C , S , T the transitive closure of the
graph SDG and by T(s) the set of all vertices (components and
services) that have a transitive relation with a given service s i.e.
T ( s ) = { c ∈ C ( s, c) ∈ T }∪ { s ' ∈ S ( s, s ') ∈ T } . Under these
notations, ARCH could be defined as follows:
ARCH = C ' , S ' , S ' r , S ' p , where :
Fig. 3. Component library of HW/SW interface.
B. HW/SW Interface Components
The granularity of the components constituting the HW/SW
interface is a key issue to enable both effective reuse and
efficient architecture implementation. From a HdS point of
view, software components are basic entities that provide
system related services (e.g. synchronization, scheduling, etc.).
The mutex component is an example of such software
component. It offers lock/unlock services and may require other
specific services to implement the needed atomic behavior (e.g.
enable/disable interrupts). These services may be provided by
dedicated hardware component inside the CPU subsystem, such
as the interrupt controller.
III. HW/SW INTERFACE GENERATION
The use of an abstract HW/SW interface model enables a
two-step SoC design flow as shown in the shadowed boxes in
Fig. 4. The first step includes high-level architecture design and
task level HW/SW partitioning, and results in an abstract
architecture model of SoC. In this model, there are three basic
elements: software modules, hardware modules with global
communication interconnect and abstract HW/SW interfaces. communication architecture is chosen, consisting in a
The second step is to implement each element described in this point-to-point DMA engine.
abstract model. The benefits of the two-step SoC design method
include enabling system architecture exploration and dividing Fn I
Motion Motion
DCT Quant VLC
Coded
(current) P
the whole SoC design into several simpler design steps. Estimate Compensate Stream
Fn-1 Motion P
(ref.) Prediction IDCT IQuant
System specification
I Encoder
Transform Module Module
High level HW/SW partitioning
(a) Functional model
architecture design at task level
Trans.1
HW
Trans.2 Enco Comb HW HW SWSw SW
Abstract Architecture Model (Comb
der iner (Input) (DMA) (P(P1)
1..4) (Pvlc)
Trans.3 iner)
Input
Abstract HW/SW Interface HW/SW Trans.4 Interface Interface Interface Interface Interface
SW module - API for SW modules HW module interface DMA Abstract communication
specification - abstract interfaces for HW modules specification exploration
- CPU subsystem specification (b) Architecture design (c) Abstract architecture model

Fig. 6. MPEG-4 encoder architecture design.

HW/SW interface generation
Embedded - CPU subsystem design HW Module
SW design - Hardware-dependent software design For this case study, we relied on an existent (previously
design
designed) service-based component library (partially depicted
Back-end hardware prototype in Fig. 8) to which we added few components to meet the
specific requirements of the application. More particularly, for
SoC each transform module, we used a double-bank memory
Fig. 4. Proposed HW/SW interface design flow. architecture to allow parallel computation and data transfer. At
the application level, the “switch_banks()” service is used
The generation tool (Fig. 5) takes the specification of the (required) to exploit this feature (Fig. 7). Given that the original
abstract HW/SW interface and the service-based component library does not contain such feature, we added the needed
model as input. The first step corresponds to the resolution of hardware (MBMC) and software (PAPMBMC) components.
the dependency graph, given the services specified by the The added components are designed so that their respective
abstract HW/SW interface, and results in a subset of selected interfaces (required and provided services) match the original
components. The second step creates instances of each selected service dependency graph library. The generated architecture is
component by configuring the parameterized components depicted in Fig. 7.
according to the value of parameters specified in the abstract Application software: encoder module Application software: transform module
taskvlc::task_behavior(), … task1::task_behavior(), …
HW/SW interfaces.
Hardware-dependent software Hardware-dependent software
get_bank_address(), wait_event(), … switch_banks(), wait_event(), …
Application software

Abstract HW/SW interface

HW/SW interface Video stream SRAM SRAM Coded Stream
Ctrl

Ctrl
generation tool Application software Pvlc P1..4
Hardware interconnectes Component Hardware-dependent SRAM
selection Software CPU Hw NI CPU Hw NI
Input subsystem subsystem Combiner
Component
CPU subsystem
configuration
Component Hardware interconnectes
Service-based integration DMA
Component library
Fig. 7. Implementation of MPEG-4 encoder.
Fig. 5. Proposed HW/SW interface generation tool.
Table 1 presents some results relative to the generated CPU
IV. EXPERIMENT subsystem hardware. The results are obtained with ARM7
based architectures running at 60 MHz.
This section describes the application of our HW/SW
interface design method to a MPEG-4 [9] encoder application TABLE 1: Results of generated CPU subsystem.
as a case study. The functional specification of the MPEG-4
encoder is shown in Fig. 6-a. On each step, a video frame (Fn) Interface results Transform module Encode module
is processed to produce a compressed bit stream. The encoder # of gates (periph) 3626 3430
main functions are mapped to software for higher flexibility. OS footprint 3,4 Kb 2,9 Kb
ISR latency 0,96 us 0,82 us
Because the transform module is in charge of the most intensive
(worst case)
computation part, during architecture design, we decided to use
four such instances running in parallel for each quarter of the Comparing to our previous experience with standard
video frame, as shown in Fig. 6-b. An abstract architecture architectures and operating systems, these results show a
model is used to capture these high-level architecture design substantial increase in implementation efficiency in terms of
decisions, using abstract interfaces to connect all software and both space and time overheads.
hardware modules, as shown in Fig. 6-c. At this level, a global

CPU
subsystem
Figure 8. The service based component library used by the MPEG-4 encoder.
V. CONCLUSION
This paper presented a service-based component model to
describe the elements of HW/SW interfaces. An abstract
architecture model that abstracts HW/SW interfaces is used to
enable high-level design decisions and a systematic process is
introduced to specify and refine this abstract model.
Service-based component libraries are used by a HW/SW
interface generation tool for the refinement of HW/SW
interfaces. An experiment is presented that demonstrates the
effectiveness of using the proposed method to achieve
automated HdS and CPU subsystems codesign.
While the composition process guarantees a minimal
functional implementation with respect to specific application
requirements, no particular measures are currently taken to
ensure that such implementation satisfy other non functional
constraints such as real-time behavior, quality of service, power
consumption, etc. Part of our future work will focus on this
aspect by extending the basic concept of service dependency
graph.
ACKNOWLEDGMENT
This work is supported by European projects SPRINT and
SHAPES, MEDEA+ project LOMOSA+ and ITEA project
MERCED.
View publication stats
Hardware-
dependent
software
References
[1] Smith, J., De Micheli, G., Automated Composition of Hardware
Components, Proc. 35th Design Automation Conf. (DAC’98), ACM Press,
San Francisco, CA, 1998.
[2] Passerone, R., Rowson, J., Sangiovanni-Vincentelli, A., Automatic
Synthesis of Interfaces between Incompatible Protocols, Proc. 35th
Design Automation Conf. (DAC 98), ACM Press, San Francisco, CA,
1998.
[3] Wang, W., Malik, S., and Bergamaschi, R.A., Modeling and Integration of
Peripheral Devices in Embedded Systems, Design, Automation and Test in
Europe Conference and Exhibition (DATE’03), Munich, Germany, 2003.
[4] Vercauteren, S., Lin, B., De Man,.H., Constructing Application-Specific
Heterogeneous Embedded Architectures from Custom HW/SW
Applications, Proc. 33rd Design Automation Conf. (DAC’96), ACM Press,
Las Vegas, NV, 1996.
[5] Balarin F., Watanabe Y., Hsieh H., et al., Metropolis: An Integrated
Electronic System Design Environment, IEEE Computer, April 2003.
[6] Cesário, W., Baghdadi, A., Gauthier, L., et al., Component- Based Design
Approach for Multicore SoCs. . Proc. 39th Design Automation Conference
(DAC’02), ACM Press, New Orleans, LA, 2002.
[7] Brunel, J-Y., Kruijtzer, W. M., Kenter, H. J. H. N., et al. COSY
Communication IP’s, Proc. 37th Design Automation Conf. (DAC’00),
ACM Press, New York, NY, 2000.
[8] Zitterbart, M., Stiller, B., Tantawy, A.N., A Model for Flexible
High-Performance Communication Subsystems, Selected Areas in
Communications, IEEE Journal on, vol. 11, no. 4, May 1993
[9] Bhaskaran, V., Konstantinides, K., Image and Video Compression Standards:
Algorithms and Architectures, Kluwer Academic Press, 1997