Transcript An Environment for Dynamic Component Composition for

Structured Component
Composition Frameworks for
Embedded System Design
Sandeep Shukla, Virginia Tech.
Frederic Doucet, Rajesh Gupta
University of California, San Diego.
The Context
 Platform Based Design (PBD)


a platform is a partial design consisting of IP blocks
a platform is an IP at the next level of abstraction
 A platform is a realized design pattern



Any given space has a limited number of good solutions to its basic
problems.
A platform captures the good solutions to the important design challenges
in that space.
A platform reuses architectures within architectural constraints
 IP design needs a framework consisting of
component libraries, composition glue, validation, synthesis..
2
Component Composition Framework (CCF)

A CCF Provides the Basis for
Composition
C++
Class
library
components
Structured composition
3
BALBOA: A Composition Workbench
 Module as a top-level class
 Member functions:




model blocks
create compound blocks
connect component objects
set parameters
 A glorified schematic entry
> set design [new Module]
> set C0 [$design Component]
> $design connect C0 C1
> $design attach_list
> $design copy_interface
> $design attach_behavior
> ...
4
Components and Composition
 C++ is increasingly being considered for
system modeling

Accessible and good for managing system complexity
through object orientation
 While use of C++ enables higher abstraction
levels, it does not per se guarantee increases in
design efficiency and productivity

Enormous modeling choices in typing
 Higher productivity requires ability to reuse
system components

Need for ‘adequate’ composability
5
High Design Efficiency Requires
New “abilities”
 Model Interoperability

The ability of the IP models to compose
 Language and environments

The ability of the IP models to be reused
 Methodological implications
 We focus on composability here
 There are two aspects to composability:


Compatibility across modeling dimensions
Ability to quickly and accurately build complete system
models
6
Modeling Dimensions and
Composability
 System Level Semantics Concerns




Different models of computation
Different levels of abstraction
Different data types
Different class libraries
 Primary obstacle to composability

Semantic gap between hardware components and their
software models
7
C++ Semantic Gap
Hardware elements:
7
7
B1
Software models:
B1
B2
sc_in<int>
sc_in<cData>
Port<char>
Protocol<event>
B2* b2_ptr;
Int write(int);
…
How to
connect?
B2
8
C++ Composability
Implementations
Inheritance Strategy
Composition Strategy
Reference
W
W
B
Inheritance
A
Sharing of
W to A
A and W: common identity
Delegation from W to B
B and W: two identities
9
C++ Composability
Implementations (cont’d)
 In both approaches, wrappers are implemented


Inheritance: wrapping established during programming
time
Composition: wrapping established at run-time
 Both approaches have dependencies

Inheritance has a stronger dependency than composition
 We think that composition could be a better
solution for system models which contains
hardware
10
Dynamic Composition
 What is dynamic composition?


Objects acquiring references at run-time
No recompiling necessary: usage of compiled IP libraries
 Key ideas:



Use delegation instead of inheritance for model reuse
Wrapper has a separate identity from the component
Relies on a specialized Interface Definition Language
(IDL) to generate the wrapper
11
BALBOA CCF
 Layered composition



Built upon existing class libraries,
to add a software layer for
manipulation and configuration of
C++ IP models
Ease software module
connectivity
Run-time environment structure
System designer
Component
Integration, CIL
Split-Level
Interface/BIDL
C++, SystemC
12
BALBOA Key Technical Decisions
1. A development and runtime environment
1.
Layered architecture
2. Use an interpreted language for
1.
2.
Architecture description
Component integration
3. Use delegation is used instead of inheritance for
component wrapping
1.
Split-level interfaces between interpreted and compiled domains
4. Use an interface definition language (IDL) to
1.
2.
3.
Describe and generate the split-level interface
Implements the composition and object model
Extends the type system
13
BALBOA System Implementation
 CIL Script Provides:


Delayed and inferred typing
Introspection capabilities
Interpreter
 The split-level interface
do not rebuild, but uses
the compiled structure as
model instance
 Built using Object Tcl for
the composition
environment
SLI
SLI
SLI
C1
C2
C3
14
based on Object Tcl
 Compose an architecture




Instantiate components
Connect components
Compose objects
Build test benches
 Introspection

Query its own structure
 Loose typing

Strings and numbers
Producer P
Consumer C
Queue Q
Compiled
 Script-like language
Interpreted
Language Layers: CIL
System designer
Split-Level
Interface/BIDL
Component
Integration, CIL
C++, SystemC
P query attributes
queue_out
C query attributes
queue_in
P.queue_out query methods
bind_to read
P.queue_out bind_to Q
…
15
language to export




Attributes
Methods,
Relationships
Characteristics
 Used to generate the
split-level interface
 Used to extend the type
system in the
environment
Compiled
 Component description
Interpreted
Language Layers: BIDL
System designer
Split-Level
Interface/BIDL
Component
Integration, CIL
template<class T>
C++, SystemC
class Producer {
kind BEHAVIORAL;
public:
Queue<T>* queue_out;
unsigned int packet_count;
void packet_generator process();
};
INSTANCE (int)
OF_CLASS (Producer)
INSTANCE (BigPacket)
OF_CLASS (Producer)
INSTANCE (SmallPacket)
OF_CLASS (Producer)
16
Language and Run-time Layers
Language
CIL
BIDL
C++
Tools
Run-time structure
Introspection
SLI/Type
BIDL
system
Compiler
extension
GCC
Reflection
GCC
Interpreter
Split Level
Interfaces
Compiled
objects
Split-level Interface
 Links the interpreted and
Interpreter
the compiled domain

Each compiled object has a
split-level interface
 Implements:

Composition model
 Full control on the internal
object

Reflection and the
introspection
SLI
SLI
SLI
O1
O2
O3
Note: SLI is a EDA tool organization
issue, not a programming issue.
• Parts of the type system
–Maintains type compatibility
–Perform type evaluation heuristics
18
Type System
 Compiled types are weakened in the CIL

Data types are abstracted from signal and ports
 Algorithm for data type inference

If a component is not typed in the CIL
 The SLI delayed the instantiation of the compiled internal
object
 Interpreted parts of the component are accessible

Verify if types are compatible when a relationship is set
 If a compatible type is found, the SLI allocates the internal
object and sets the relationship
 If not, the link command is delayed until the types are solved
 Approach similar to ML

However, full type resolution is not guaranteed
19
Using the Environment
20
CIL Script Example
#load the AMRM component library
load ./libamrm.so
Entity
Cache
Memory
Queue
L1
mem_sys
mem_sys.L1
mem_sys.Mem
mem_se.r_q
L1.upper_request link_to ms.r_q
Mem.request_in
link_to ms.r_q
r_q
Tb add_stimuli 100 read 0x399
Mem
Tb add_tcl_callback ms.r_q.activity {
simulator.do_monitoring this; }
simulator run 200
mem_sys
21
Design Example Statistics:
AMRM
Number of
C++ classes
Number of
Script lines
Number of
BIDL line
IP vs
Generated
C++ code size
ratio
7 C++
< 30
60
812/809
(1.01)
8 C++
with SystemC
< 40
84
1512/1002
(1.51)
7 C++
with SystemC
< 150
87
1437/880
(1.63)
Script size vs C++ ratio: 1 is to 10
Code generation
most useful at
high abstraction
Manipulate
only the
script!22
Closing Remarks
 Good IP-model composability requires


focus on system-level design tasks while using
programming environments
minimization of reliance on programming details to
accomplish these tasks.
 Our approach is to use a split-programming
model for dynamic composition


where the design is entered in an interpreted domain
while at the same time avoiding need to separate
languages and description by using a layered software
architecture and automatic generation of SLI wrappers.
23
Related Work
 System level language


Process-port-signal architectural style (SystemC, SpecC)
Architecture description languages (ADL)
 Component frameworks


Type systems (Ptolemy, Colif)
Distributed programming
 Skeletons generated from interface definition language
(Corba IDL)
 Split-level programming

Separate composition concerns from programming
 e.g. NS, or scripting

Wrapper generation (SWIG)
24