An Environment for Dynamic Component Composition for Efficient Co-Design

Frederic Doucet, Sandeep Shukla, Rajesh Gupta Masato Otsuka

Center For Embedded Computer Systems Fujitsu Ltd, Japan
University of California at Irvine [email protected]
fdoucet,skshukla,[email protected]

Abstract inheritance and polymorphism. Often, such concerns are

quite orthogonal to the hardware system architectures and
This article describes the Balboa component integration design issues, thus actually adding to the time and effort
environment that is composed of three parts: a script lan- in the system design process. However, there is a defi-
guage interpreter, compiled C++ components, and a set of nite need to leverage the advantages of programming lan-
Split-Level Interfaces to link the interpreted domain to the guages (executable complete system models) in faster and
compiled domain. The environment applies the notion of easier system level model construction. In this work, our
split-level programming to relieve system engineers of soft- goal is two fold: relieve the system designer/integrator of
ware engineering concerns and to let them focus on system the problems of dealing with software engineering and C++
architecture. The script language is a Component Integra- programming issues to enable them to concentrate on hard-
tion Language because it implements a component model ware system co-design issues, and create a component in-
with introspection and loose typing capabilities. Compo- tegration environment that allows the designer to efficiently
nent wrappers use split-level interfaces that implement the add or delete components, dynamically change design con-
composition rules, dynamic type determination and type figuration, and quickly run simulation to test functionality
inference algorithms. Using an interface description lan- and performance. In this context, we aim at:
guage compiler automatically generates the split-level in-
terfaces. The contribution of this work is two fold: an ac- 1. Creating an abstraction layer to separate concerns
tive code generation technique, and a three-layer environ- about hardware system architecture, software design
ment that keeps the C++ components intact for reuse. We artifacts and EDA tool integration/setup,
present an overview of the environment; demonstrate our 2. Creating a rapid design space exploration environment
approach by building three simulation models for an adap- which avoids a time consuming and programming in-
tive memory controller, and comment on code generation tensive compile-link-test cycle of a fully compilation
ratios. based environment,

3. Providing an abstraction from the class library imple-

1. Introduction mentation to the designer/system integrator,

4. Creating a component integration environment that has

There is currently a trend of research on using general introspection capabilities to dynamically query types
purpose programming languages in building digital hard- and attributes of components, to create architecture
ware systems, as exemplified by the proliferation of C++ maintaining type compatibility in the underlying com-
based design languages [21, 19, 26, 16, 13, 23, 8]. The ma- piled object layer.
jor advantage of existing methodologies with C++ is that
the designers can easily build components that can become In this paper we present our approach to the construc-
a part of intellectual property (IP) libraries. However, de- tion of executable system models that builds upon C++ class
sign composition with C++ is still tedious and reuse is ad library-based approaches to system modeling. The Balboa
hoc in the current compile-link-test methodologies. A ma- [2] composition environment relies on ”smart wrappers”
jor barrier to adoption of system-level design using C++ is that contain information about the types and object mod-
that hardware designers need to understand significant soft- els of the components, and assemble them through an inter-
ware engineering issues related to components and need to preted environment with a ”loose” typing. The paper is or-
be thoroughly versed in programming abstractions such as ganized as follows. The related work is reviewed in Section

Proceedings of the 2002 Design, Automation and Test in Europe Conference and Exhibition (DATE’02)
1530-1591/02 $17.00 © 2002 IEEE
 2. The key techniques of the Balboa environment presented parameterized (template) component types [4], component
in Section 3 are layering, component-based design, wrapper navigation is impossible because we cannot go inside en-
generation, scripting based split programming, introspec- capsulated component hierarchies.
tion and typing. Section 4 presents a moderately complex Split programming refers to generation of class hierar-
real design implementation in the environment of the Adap- chies in multiple programming environments with hooks
tive Memory AMRM [1] system followed by a discussion that enable their combined manipulation. NS (network sim-
and interpretation of the results of using this approach. ulator) uses a split-programming model to create a network
simulation environment, with two layers of programming
2. Related Work facilities: one for building objects, and the other for com-
posing them [6]. A script language is used for network
model composition, and the C++ language is used for build-
This work builds upon ongoing work in the areas of
ing components. In NS, a C++ design object used in split-
component technology, split-programming and specifica-
programming has to inherit from a class that is visible to the
tion language design. A component is a unit of composi-
scripting layer. Unlike network simulation, where scripted
tion be it a function, object, library or a complete program.
models are simulated, in hardware system co-design mod-
Component-based design is the activity of assembling small
els, simulation efficiency is an important criterion.
components focused on one task into a more complex com-
ponent with a richer functionality. Dynamic composition is System level and hardware specification languages are
performed at run-time when objects acquire references to active areas of research. Most approaches are looking to
other objects. The advantage of dynamic composition over raise the level of abstraction above the RTL level into ei-
static composition is that the behavior of a new system will ther the architectural or the behavioral design space. In
depend on object relationships being defined at runtime, in- system level models, there are many levels of abstraction
stead of being defined and hard-coded in the files. Com- that are not yet clearly layered, but the understanding is im-
ponent technology is emphasized as a key element [14] in proving [13] [9]. At functional levels of abstraction, models
the development of complex software systems. Component of computation are clear, and in many cases, efficient only
integration can be done in three different ways: by program- for specific application domains. Most of current system
ming, graphically, or by scripting. level languages are strongly typed, with the exception of
Programming based composition is tedious because the Ptolemy framework that has an elaborate type system
many syntactical details (that are not necessary from an ar- [15] that statically resolves data types to the most specific
chitect viewpoint) must be resolved. Also, many program- type that meets all specified constraints.
ming decisions independent of the nature of a system model
have to be addressed. For example, when building a special
3. The Balboa Composition Environment
adder, a hardware designer should not necessarily be con-
cerned with inheritance, virtual function, friends and other
C++ specific constructs, but rather focus on hardware spe- In the current C++-based hardware design methodolo-
cific characteristics such as bit width, propagation delays, gies, the design components and the simulation kernel are
genericity etc. Architecture description languages (ADL) in compiled C++. However, in order to separate the con-
have addressed parts of these problems in the software en- cerns of tool and design setup/control, many design tools
gineering [18], but for system design, they are often focused use a scripting interface. In the Balboa environment, there
on specialized tasks [25], and interoperability can be diffi- is a custom interpreter for a special script language that can
cult to achieve [12]. Graphical integration is easy with in- execute a number of commands to do component composi-
tuitive block diagrams as in VCC [3], but it is difficult to tion, simulation control, test bench creation, and event mon-
manage for very large designs. The use of UML has been itoring. The script language used is named Component Inte-
used also suggested [17] to specify component integration gration Language (CIL). Figure 1 shows the UML use case
and object interoperability. diagram for the environment. The system architect builds
The third component integration method is by using the model of the system using the CIL to direct the compo-
scripting. Scripting has been used for many years in soft- sition, by manipulating sets of objects and establishing re-
ware component integration in CAD frameworks. Ouster- lationships. The library component engineer builds compo-
hout argues that a script language interpreter for component nents in C++, and exports their interfaces to the upper layer
integration is essential for API abstraction and reuse [20]. by using the Balboa Interface Definition Language (BIDL).
Script interfaces for compiled code can be generated using The BIDL is basically similar to the CORBA IDL [11], but
wrapper generators such as SWIG [22] [10]. However, cur- it has been customized [5] for the needs of composability.
rent wrapper generator technology presents two problems: The environment is implemented through the following lay-
script syntax is very difficult to generate for complex and ered architecture:

Proceedings of the 2002 Design, Automation and Test in Europe Conference and Exhibition (DATE’02)
1530-1591/02 $17.00 © 2002 IEEE
 Component Integration Environment 3.1. The Runtime Structure
System
Architect CIL
Interpreter

<<uses>> Composition Commands

Interpreter
C++ Simulation Commands
<<builds>>
SLI Design
Model

SLI
<<uses>> <<controls>> SLI
SLI
C1
Library SLI DES
Component C++/BIDL DE Simulator C2
Simulator
Engineer IP
Libraries C3

Figure 1. Balboa environment has two user

roles: the system architect and the library Figure 2. Runtime composition structure of
component engineer the environment: each design component
has a SLI wrapper to process CIL script com-
mands, and runs compiled discrete event
simulation
1. Scripting layer: Designs are assembled from compo-
nents configured by using the Component Integration
Language (CIL). Figure 2 presents a snapshot of the environment at run-
time where there are three compiled C++ design compo-
2. Wrapper layer: C++ objects are contained and ma- nents: C1, and C2, which is composed of C3. Each of
nipulated inside the component by the Split-Level In- the components has a split-level interface. There is also a
terfaces (SLI) that implement the split-programming box for a compiled discrete event simulation kernel, such
model. as SystemC simulation kernel, which also has a split-level
interface.
3. Component library layer: IP repository where the
C++ classes/objects are stored. This layer is indepen- 3.2. Component Design
dent of the two layers described below. Any compiled
C++ object can be placed in this layer. Figure 3 illustrates the tool flow and design process for
the component designer. The lower part of the figure illus-
The design of library component has to be done by a de- trates the flow for component implementations in C++. The
signer who understands C++, the split-level interface gen- upper part of the figure shows the flow for the component
eration is automated, and the design composition is done by characterization and the exportation of the interface of the
a system architect with the CIL. components to the interpreted domain. The BIDL compiler
The difference between the previous work and the Bal- generates C++ code to create and configure the split-level
boa environment is the component model driven through interface of a component and to generate the type system
a split-programming model through the separation of the information and the specific code for the delayed instanti-
component and its split-level interface. Unlike other im- ation and delayed typing. The delayed type instantiation
plementations where a component inherits a class interface mechanism is explained in Section 3.5. The BIDL com-
implementing the wrapper behavior, in our environment, the piler also generates the object model configuration specific
SLI wrappers aggregates the design components. This is to to the component. The principal steps for using BIDL to
have composition and reuse less dependent from the class export a C++ class to the interpreter are the following: the
interface of the internal object, by using object composition designer uses the header of the class into the BIDL descrip-
and delegation instead of class inheritance. The motivation tion and removes the part to be hidden from the interpreted
for the separation of the wrapper from the component is to domain. Keywords are also added to configure the genera-
avoid an inheritance dependency [24]. In other words, reuse tion, such as component families, versioning and template
by class interface precedes the design of the class, while classes handling and specification of available types. From
reuse with the BIDL succeeds the design of the class. This the point of view of system architect, the component and
is because the types are compiled in the type system through the split-level interface can be the same entity, as shown in
the BIDL. the Figure 3 by the dashed rectangle.

Proceedings of the 2002 Design, Automation and Test in Europe Conference and Exhibition (DATE’02)
1530-1591/02 $17.00 © 2002 IEEE
 Component
Interface and BIDL BIDL C++ C++ SLI
Characterization Language Compiler Compiler
Exports

C++ with
Component Class Library
C++ Compiled
Implementation Translator C++ Compiler Component IP
HDL with
Keywords Libraries

Figure 3. Component design tool flow: write the component in C++, use the BIDL to character-
ize/export it and generate a SLI

Component and GUI/script level interactions layer because interpreted command execution in the SLI can
be slower. However, the SLI layer can also interact with the
simulation. For example, in our libraries we have a number
of stimuli generators and monitors that use the interpreter
Split Interpreted control flow to compute stimuli and check assertion during
level variables &
Interface methods
the simulation.

3.4. Component Integration Language

compiled objects
Type Internal interactions
The component integration language is between a mod-
system compiled
information design ule interconnection language and an architecture descrip-
object tion language. This is because the CIL is used from connec-
tions, and to build new components or compose attributes
or behaviors to existing ones. The basic composition unit
Figure 4. Internal architecture for a Balboa in CIL is an entity. For example, a component called c1 is
component instantiated with the command:
Entity c1
This component can be composed of a subcomponent c2
by the command:
Figure 4 illustrates the internal architecture of a Balboa Entity c1.c2
component where there are four blocks: the internal object The result of this command is the instantiation of an entity
(for example, such as a SystemC object or any other C++ named c2 inside c1. The syntax for the composition is the
object or component), the type system information (with an dot “.” operator, which is also used to navigate hierarchies.
object model), the interpreted attributes/methods (that can The CIL also features introspection [7], which is the
be a reflection of the compiled attributes/methods), and the capacity of an object to query itself to know its struc-
split-level interface routines. ture, attribute and methods. It is similar to self-inspection.
For instance, Tcl provides introspection capabilities with
3.3. Interpreted vs. Compiled Domains the “info” procedure, and Java also provides introspection
through the reflection packages. The Balboa environment
As shown in Figure 4, the split-level interfaces are the implement and extend these models to add introspection us-
links of the interpreted domain with the compiled domain. ing a query method to the split-level interfaces where the
But they also have a state and execute commands. The solid following characteristics of a component can be queried:
lines on Figure 2 illustrate composition requests from the name, SLI type, C++ type, kind, attributes and methods.
CIL script language that are only interpreted in the SLIs. For example, the following query:
However, the simulation commands showed by the dotted c1 query attributes
lines are delegated to the compiled components. Usually, => c2
the simulation control flow is kept only in the compiled returns the list of attributes for component c1. In this case,

Proceedings of the 2002 Design, Automation and Test in Europe Conference and Exhibition (DATE’02)
1530-1591/02 $17.00 © 2002 IEEE
 there is only the c2 attribute that is returned as result of [1] that can have its properties dynamically changed by
the command. This attribute is visible in the interpreted do- software. For example, associativity and line size can be
main, but other attributes might be present in the compiled changed by the compiler. The hardware part of the design
domain, but not visible if they were not exported. Complex is a regular cache subsystem, with a modified controller that
commands can be built to query each subcomponent for in- can execute the extra instructions for cache adaptation.
formation. For example, a command in our environment
that query a component for a full characteristics introspec- Component Abstract
tion returns the following: Integration Association
Name: c1
Class: Entity
Communication
Type: Entity Imp Refinement
Method
Kind: STRUCTURAL
Attributes: c2
Queue
Methods:
Tool behavior for design assembly is built through intro-
spection, looking for attributes or methods, and them intro- Signal
specting them further to find out the composition possibili-
ties according to an internal object model. Figure 5. AMRM models in different levels of
abstraction
3.5. Type System and Type Resolution

As illustrated in Figure 4, the type system is distributed Figure 5 shows the outline of the procedure we followed
into all the components. The type system is used to deter- for the component integration and communication refine-
mine the data type for template components. For example, ment. The first step is to integrate and link them with ab-
a queue between two components will be specified with no stract associations in a conceptual model. We implement
data type, and the system will infer a type according to the the concrete message passing semantics and do commu-
data types of the components to which the queue will be nication refinement. Figure 6 shows the UML class dia-
connected. Consider the following example in the compo- grams and the block diagrams for the component integration
sition domain: and the communication refinements. The following script
Producer p1 shows the CIL file used at all refinement levels:
Queue q
Consumer c1
1 # Load the AMRM component library
p1.queue out link to q 2 load ./libamrm.so
c1.queue out link to 1 3
The queue q data type is inferred by the type system through 4 # Component instantiations
introspection of the date type of the queue out. This is 5 Cache L1
subdivided in two tasks: verify if types are compatible when 6 Cache L2
relationships are set; delay a component instantiation when 7 Memory Mem
the component is untyped. When an entity is untyped in a 8
script, the system delays its instantiation inside the SLI until 9 # Testbench instantiation
the type is solved. For example, when instantiating a port, 10 Testbench CPU
11
the data type of the port is unknown. The type system will
12 # Procedure calls to connect components
select which data type to use, and look in a type hash table 13 connect_cpu2cache CPU L1
to find a compiled allocator to instantiate a port for this data 14 connect_cache2cache L1 L2
type. The allocators are generated by the BIDL compiler. 15 connect_cache2memory L2 Mem
In the current implementation, a type is not guaranteed to
be solved if two type incompatible.
Lines 5 to 7 instantiate two cache controller components
named L1 and L2, and a memory controller component
4. Experimental Results named Mem. Line 10 instantiates a test bench that aggre-
gates a configurable stimuli list. Line 13 to 15 are proce-
In this section, we describe an implementation of a mod- dure calls that set the associations between the components
erately complex system model in the BALBOA environ- for communication. The process is to re-implement these
ment. The AMRM is an adaptive cache memory system procedures, as the abstract associations are refined.

Proceedings of the 2002 Design, Automation and Test in Europe Conference and Exhibition (DATE’02)
1530-1591/02 $17.00 © 2002 IEEE
 1 <<abstract>>
<<active>>
Memory_Base
l_requests <<abstract>>
<<active>> clock: Inport
0,1 l_answers 2 Mem_Bus u_req: Inport
<<abstract>> Memory_Base
Memory_Base req: Signal u_mode: Inport
proc() mode: Signal u_address: Inport
read() Queue
lower_memory 2 addr: Signal u_din: Inport
write() read() din: Signal u_dout: Outport
write() dout: Signal u_ack: Outport
u_requests ack: Signal proc()
1 u_answers
Cache Memory 1
2
2 1
Cache Memory
Cache
1 l_req: Outport Memory

l_mode: Outport
l_addr: Outport
l_din: Inport
(a) (b) l_dout: Outport (c)
l_ack: Inport

L1 Queue Bus
link objects link objects
L1 L1

L2 L2

L2
MEM
MEM

MEM
(d) (e) (f)

Figure 6. AMRM component integration models with communication refinement: the upper row is for
the class diagrams, and the lower row is for the corresponding block diagrams: (a) and (d) refinement
1, (b) and (e) refinement 2, (c) and (f) refinement 3

4.1. First Refinement pointers between two caches in structure that was exported
to the SLI:

The first implementation is to use method invocations 1 proc connect_cache2cache { u_c l_c } {
to implement the message passing in a sequential model. 2 $u_c set_association lower_memory $l_c
In the class diagram of Figure 6(a), Memory Base is 3 }
the base class for the Cache and Memory classes. The
Memory Base has read and write virtual methods that 4.2. Second Refinement
are implemented in the Cache and Memory classes to im-
plement the behavior. The Cache class has an associa- Let us refine the association implemented through
tion named lower memory that is used to navigate to the method calls into two associations with queues as shared
lower level of memory. For example, on an L1 cache read link objects: one queue for the requests and one queue
miss, the L1 cache will use this association to call read for the answers. The class diagram on Figure 6(b) illus-
method of L2 cache. The block diagram on Figure 6(d), trates this change. This refinement introduces concurrency
shows how these lower memory associations implement with the addition of a reactive process named proc to the
the control flow between the two levels of cache and the Memory Base class. This process is triggered by an event
main memory. The following procedure sets the association on clock input port and it transitively calls the read and

Proceedings of the 2002 Design, Automation and Test in Europe Conference and Exhibition (DATE’02)
1530-1591/02 $17.00 © 2002 IEEE
 write methods. The following script lists the procedure to 15 ${L_Cache}.u_mode bind_to ${cb}.mode
connect two caches together with queues as link objects: 16 ${L_Cache}.u_addr bind_to ${cb}.addr
17 ${L_Cache}.u_din bind_to ${cb}.din
1 proc connect_cache2cache { U_Cache 18 ${L_Cache}.u_ack bind_to ${cb}.ack
2 L_Cache } { 19 ${L_Cache}.u_dout bind_to ${cb}.dout
3 # instantiate queues 20 }
4 Queue ${U_Cache}to${L_Cache}_requests_q
5 Queue ${U_Cache}to${L_Cache}_answers_q
6 Please note that we use the bind to method of the port
7 # connect queues to upper cache object instead of the set association command of the
8 ${U_Cache} set_association l_requests \ object model. Line 3 instantiates a cache bus named cb.
9 ${U_Cache}to${L_Cache}_requests_q Lines 6 to 11 connect the ports of the upper cache to the bus
10 ${U_Cache} set_association l_answers \ signals, and lines 14 to 19 connect the lower cache to the
11 ${U_Cache}to${L_Cache}_answers_q bus signals.
12
13 # connect queues to the lower cache
14 ${L_Cache} set_association u_requests \ 4.4. Interpretation of Results
15 ${U_Cache}to${L_Cache}_requests_q
16 ${L_Cache} set_association u_answers \
17 ${U_Cache}to${L_Cache}_answers_q
18 } Refinement # Classes # Script # BIDL Ratio of IP
lines lines vs. Generated
Lines 3 and 4 instantiate the queue components (from C++ lines
a class library). The data types of the queues will be set 1st 7, C++ only < 30 60 812/809
(1.01)
according to the types of the associations to which they are
connected. Lines 7, 9, 13 and 15 establish the associations
2nd 8, C++ < 40 84 1512/1002
w/ SystemC (1.51)
between the caches and the queues. Figure 6(e) shows the 3rd 7, C++ < 150 87 1437/880
architectural view, where each cache level is separated by w/ SystemC (1.63)
two queues.
Table 1. Design statistics of AMRM models:
4.3. Third Refinement
code generation ratio higher at higher ab-
stractions
The lowest level of abstraction in our AMRM models
uses signal handshakes as association link classes. Figure
6(c) shows the class diagram for this model. The queue be- Table 1 shows the design statistics of the various file
havior is still in the design, but implemented through ports sizes and code generation ratio for the AMRM implementa-
beginning by “l” for the lower memory, and by “u” for the tions. As we refine the models, the script sizes grow larger
upper memory. These ports are bound to the Mem Bus link
but not the number of C++ classes (except for the queue data
class, which encapsulates the signal objects. Figure 6(f)
type class in the second refinement). This is because the
shows the block diagram with the memory hierarchy and granularity of the communications gets smaller, and there
the busses. The following script lists the procedure to con- are more connections to be established.
nect two caches through a bus:
The programming efforts to write BIDL files in this ex-
1 proc connect_cache2cache {U_Cache perimentation were non-intrusive and of low effort: we used
2 L_Cache} { the parts of the header of the classes we wanted visible to the
3 # instantiate a cache bus interpreter, and we added characterizations as behavioral or
4 Cache_Bus cb structural components. The ratio of the IP vs generated code
5 # connect bus signals to upper cache sizes shown in the rightmost column is increasing as the ab-
6 ${U_Cache}.l_req bind_to ${cb}.req straction is lowered. However, the size of BIDL file and the
7 ${U_Cache}.l_mode bind_to ${cb}.mode
generated code does not grow linearly with the size of the
8 ${U_Cache}.l_addr bind_to ${cb}.addr
IP code. The environment does not take design decisions
9 ${U_Cache}.l_dout bind_to ${cb}.din
10 ${U_Cache}.l_ack bind_to ${cb}.ack for the designer in the communication refinement (which is
11 ${U_Cache}.l_din bind_to ${cb}.dout supported by the AMRM library we wrote), except for the
12 type propagation. Work is in progress to investigate what
13 # connect bus signals to lower cache ratios of code generation are obtained in different design
14 ${L_Cache}.u_req bind_to ${cb}.req context.

Proceedings of the 2002 Design, Automation and Test in Europe Conference and Exhibition (DATE’02)
1530-1591/02 $17.00 © 2002 IEEE
 5. Summary and Future Work [6] L. Breslau, D. Estrin, K. Fall, J. Heidemann, A. Helmy,
P. Huang, S. McCanne, K. Varadhan, Y. Xu, and H. Yu. Ad-
In this paper, we presented the Balboa composition en- vances in Network Simulation. IEEE Computer, May 2000.
[7] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and
vironment model. It is composed of three layers: an in-
M. Stal. Pattern Oriented Software Architecture: A System
terpreter where a component integration language (CIL) is of Patterns. John Wiley and Sons, 1996.
used to assemble and configure designs; automatically gen- [8] Cadence Design Systems. VCC. home page:
erated split-level interface (SLI) wrappers around each C++ http://www.cadence.com/products/vcc.html.
component; and C++ component libraries. The internal ar- [9] W. Cesario, G. Nicolescu, L. Gauthier, D. Lyonnard, and
chitecture of a component implements a type system, an ob- A. Jerraya. Colif: a Multilevel Design Representation for
ject model, a reflective layer and a split-level interface for Application-Specific Multiprocessor System-on-Chip De-
a split-programming usage model. The CIL implements in- sign. In Proc. Int. Workshop on Rapid System Prototyping,
trospection and loose typing. This effort is to facilitate the 2001. systemc.
[10] P. Chen, D. A. Kirkpatrick, and K. Keutzer. Fast Integra-
composition activity for the system architect building mod-
tion of EDA Tools and Scripting Language. In IEEE/DATC
els with C++ based languages by using code generation and
Electronic Design Processes Workshop, 2001.
scripting. The usage of the CIL has the advantage of mak- [11] CORBA website http://www.corba.org.
ing the code working set much smaller to implement the [12] F. Doucet, R. Gupta, M. Otsuka, P. Schaumont, and
changes by taking advantage of guided code generation. S. Shukla. Interoperability as a Design Issue in C++ Based
The environment features an intermediate language Modeling Environments. In Proc. Int. Symposium on System
named BIDL to describe exported interfaces of the compo- Synthesis, 2001.
nents and generate the SLIs. Our initial experiments suggest [13] D. Gajski, J. Zhu, R. Domer, A. Gerstlauer, and S. Zhao.
that the usage of the BIDL significantly reduce the program- SpecC: Specification Language and Methodology. Kluwer
ming effort by the component designer. While the total size Academic Publishers, 2000.
[14] J. Hopkins. Component Primer. Commun. ACM, Oct. 2000.
of the design description is not smaller, the designer works [15] E. A. Lee and Y. Xiong. System-Level Types for
with a much smaller description to make the changes in the Component-Based Design. Technical Report ERL M00/8,
full model. As future work, we would like to work fur- UCB, Febuary 2000.
ther on making the intermediate language independent of [16] S. Liao, S. Tjiang, and R. Gupta. An Efficient Implementa-
the underlying simulation class library by formalizing the tion of Reactivity in Modeling Hardware in the Scenic Syn-
simulation semantics in the BIDL. thesis and Simulation Environment. In Proc. IEEE/ACM De-
sign Automation Conf., 1997.
[17] G. Martin, L. Lavagno, and J.-L. Guerin. Embedded UML:
6 Acknowledgments A Merger of Real-Time UML and Co-Design. In Proc. Int.
Workshop on Hardware/Software Codesign, 2001.
We gratefully acknowledge the support for this research [18] N. Medvidovic and R. N. Taylor. A Classification and Com-
from the National Science Foundation (grant CCR-98- parison Framework for Software Architecture Description
06898), the Semiconductor Research Corporation (SRC Languages. IEEE Trans. on Software Engineering, January
Graduate Fellowship), the Fond pour la Formation de Cher- 2000.
[19] G. D. Michelli. Hardware Synthesis from C/C++ Models.
cheurs et l’Aide à la Recherche (FCAR PhD Scholarship)
In Proc. Design Automation and Test in Europe Conf., 1999.
and from DARPA/ITO (contract DABT63-98-C-004).
[20] J. K. Ousterhout. Scripting: Higher-Level Programming for
the 21st Century. IEEE Computer, March 1998.
References [21] L. Semeria and A. Ghosh. Methodology for Hard-
ware/Software Co-verification in C/C++. In Proc. High
[1] AMRM. Adaptive Memory Platform. Home Page: Level Design Validation and Test Workshop, 1999.
http://www.cecs.uci.edu/amrm. [22] Simplified wrapper and interface generator (SWIG) home
[2] Balboa Project. Component Composition Environment. page: http://www.swig.org.
Home Page: http://www.ics.uci.edu/balboa. [23] SystemC. OSCI. Home page: http://www.systemc.org.
[3] M. Baleani, A. Ferrari, A. Sangiovanni-Vincentelli, and [24] C. Szyperski. Component Software: Beyond Object Ori-
C. Turchetti. HW/SW Codesign of an Engine Management ented Programming. Addison-Wesley, 1998.
System. In Proc. Design Automation and Test in Europe [25] H. Tomiyama, A. Halambi, P. Grun, N. Dutt, and A. Nico-
Conf., 2000. lau. Architecture Description Languages for System-on-
[4] D. Berner, D. Jansen, and D. Gajski. Development of a Vi- Chip Design. In Asia Pacific Conference on Chip Design
sual Refinement and Exploration Tool for SpecC. Technical Language, 1999.
Report TR-01-12, UCI, 2001. [26] C. Weiler, U. Kebschull, and W. Rosenstiel. C++ Base
[5] A. Borgida and P. Devanbu. Adding more DL to IDL: to- Classes for Specification, Simulation and Partitioning of a
wards more knowledgeable component inter-operability. In Hardware/Software System. In CS Workshop on VLSI, 1995.
Proc. Int. Conf on Software Engineering, 1999.

Proceedings of the 2002 Design, Automation and Test in Europe Conference and Exhibition (DATE’02)
1530-1591/02 $17.00 © 2002 IEEE