1. Structured Component Composition Frameworks for Embedded System Design Sandeep Shukla, Virginia Tech. Frederic Doucet, Rajesh Gupta University of California, San Diego.

2. 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. 3 A CCF Provides the Basis for Composition components Structured composition C++ Class library

4. 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. 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. 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. 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. 8 C++ Semantic Gap B1B2 7 7 Hardware elements: How to connect? B1 sc_in Port Protocol B2* b2_ptr; Int write(int); … B2 Software models:

9. 9 C++ Composability Implementations BW Composition Strategy Delegation from W to B B and W: two identities Reference W A A and W: common identity Inheritance Strategy Inheritance Sharing of W to A

10. 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. 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. 12 Component Integration, CIL Split-Level Interface/BIDL C++, SystemC System designer Compiled 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. 13 BALBOA Key Technical Decisions 1. A development and runtime environment 1. 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. 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 C3C2 Interpreter

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

16. 16 template class Producer { kind BEHAVIORAL; public: Queue * 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

17. Language and Run-time Layers Interpreter BIDL Compiler Split Level Interfaces GCC Compiled objects LanguageToolsRun-time structure GCC Introspection BIDL C++ CIL SLI/Type system extension Reflection

18. 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 O1O3O2 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. 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. 20 Using the Environment

21. 21 mem_sys CIL Script Example #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 L1 Mem r_q

22. 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 10 Manipulate only the script! Code generation most useful at high abstraction

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