Structured Component Composition Frameworks for Embedded System Design

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

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

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

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

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

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

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

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

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

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

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

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

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

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)