Structured Component Composition Frameworks for Embedded System Design

Sandeep Shukla, Virginia Tech.

Frederic Doucet, Rajesh Gupta

University of California, San Diego.

2

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.. Component Composition Framework (CCF)

3

A CCF Provides the Basis for Composition

components

Structured composition

C++

Classlibrary

4

BALBOA: A Composition Workbench

Module as a top-level class Member functions:

model blocks create compound blocks connect component objects set parameters

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> ...

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> ...

5

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

6

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

7

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

8

C++ Semantic Gap

B1 B27 7

Hardware elements:

How to connect?B1

sc_in<int> sc_in<cData>Port<char>Protocol<event>B2* b2_ptr;Int write(int);…

B2

Software models:

9

C++ Composability Implementations

BW

Composition Strategy

Delegation from W to B

B and W: two identities

ReferenceW

A

A and W: common identity

Inheritance Strategy

Inheritance

Sharing of W to A

10

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

11

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

12

ComponentIntegration, CIL

Split-Level Interface/BIDL

C++, SystemC

System designerC

ompiled

Interpreted

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

13

BALBOA Key Technical Decisions

1. A development and runtime environment1. Layered architecture

2. Use an interpreted language for 1. Architecture description

2. 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. Describe and generate the split-level interface

2. Implements the composition and object model

3. Extends the type system

14

BALBOA System Implementation

CIL Script Provides: Delayed and inferred typing Introspection capabilities

The split-level interface do not rebuild, but uses the compiled structure as model instance

Built using Object Tcl for the composition environment C1

SLI SLI SLI

C3C2

Interpreter

15

Producer PConsumer CQueue Q

P query attributes queue_outC query attributesqueue_in

P.queue_out query methodsbind_to read

P.queue_out bind_to Q…

Language Layers: CIL

Script-like language 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

C o m p o n e n tI n t e g r a t i o n , C I L

S p l i t - L e v e l I n t e r f a c e / B I D L

C + + , S y s t e m C

S y s t e m d e s i g n e r

16

template<class T>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)

Language Layers: BIDL

Component description language to export

Attributes Methods, Relationships Characteristics

Used to generate the split-level interface

Used to extend the type system in the environment

C o m p o n e n tI n t e g r a t i o n , C I L

S p l i t - L e v e l I n t e r f a c e / B I D L

C + + , S y s t e m C

S y s t e m d e s i g n e r

Language and Run-time Layers

Interpreter

BIDL Compiler

Split Level Interfaces

GCC Compiled objects

Language Tools Run-time structure

GCC

Introspection

BIDL

C++

CIL

SLI/Type system

extension

Reflection

18

Split-level Interface

Links the interpreted and 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 O3O2

Interpreter

• Parts of the type system–Maintains type compatibility–Perform type evaluation heuristics

Note: SLI is a EDA tool organization issue, not a programming issue.

19

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

20

Using the Environment

21

mem_sys

CIL Script Example#load the AMRM component libraryload ./libamrm.so

Entity mem_sysCache mem_sys.L1Memory mem_sys.MemQueue mem_se.r_q

L1.upper_request link_to ms.r_qMem.request_in link_to ms.r_q

Tb add_stimuli 100 read 0x399

Tb add_tcl_callback ms.r_q.activity { simulator.do_monitoring this; }

simulator run 200

L1

Mem

r_q

22

Design Example Statistics: AMRM

1437/880

(1.63)

87< 1507 C++

with SystemC

1512/1002

(1.51)

84< 408 C++

with SystemC

812/809

(1.01)

60< 307 C++

IP vs Generated C++ code size ratio

Number of BIDL line

Number of Script lines

Number of C++ classes

Script size vs C++ ratio: 1 is to 10Manipulate

only the script!

Code generationmost useful at

high abstraction

23

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.

24

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)