240 likes | 404 Views
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
E N D
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.. • Component Composition Framework (CCF)
C++ components Class library Structured composition A CCF Provides the Basis for Composition
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 > ...
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
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
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
sc_in<int> sc_in<cData> Port<char> Protocol<event> B2* b2_ptr; Int write(int); … Software models: B2 B1 C++ Semantic Gap Hardware elements: 7 7 B1 B2 How to connect?
Inheritance Strategy Composition Strategy W W Reference B Inheritance A Sharing of W to A Delegation from W to B A and W: common identity B and W: two identities C++ Composability Implementations
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
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
System designer Interpreted Component Integration, CIL Split-Level Interface/BIDL Compiled C++, SystemC 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
BALBOA Key Technical Decisions • A development and runtime environment • Layered architecture • Use an interpreted language for • Architecture description • Component integration • Use delegation is used instead of inheritance for component wrapping • Split-level interfaces between interpreted and compiled domains • Use an interface definition language (IDL) to • Describe and generate the split-level interface • Implements the composition and object model • Extends the type system
Interpreter SLI SLI SLI C1 C2 C3 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
Language Layers: CIL • Producer P • Consumer C • Queue Q • P query attributes • queue_out C query attributes • queue_in P.queue_out query methods • bind_to read P.queue_out bind_to Q … • 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
Language Layers: BIDL 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) • 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
Introspection SLI/Type system extension Reflection Language and Run-time Layers Language Tools Run-time structure CIL Interpreter BIDL BIDL Compiler Split Level Interfaces GCC C++ Compiled objects GCC
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 Interpreter 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
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
#load the AMRM component library load ./libamrm.so Entity mem_sys Cache mem_sys.L1 Memory mem_sys.Mem Queue mem_se.r_q L1.upper_request link_to ms.r_q Mem.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 CIL Script Example mem_sys L1 r_q Mem
Number of C++ classes Number of Script lines Number of BIDL line IP vs Generated C++ code size ratio Code generation most useful at high abstraction 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) Manipulate only the script! Script size vs C++ ratio: 1 is to 10 Design Example Statistics: AMRM
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.
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)