1. Structured Component Composition Frameworks for Embedded System Design
2/19/2019
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++
Class
library

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
2/19/2019
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
So, let us dive in to the subject. The C++ programming language is increasingly being considered for system level or digital hardware system modeling for many reasons.
It’s an accessible programming language. It is convenient because most of the needed tools are inexpensive or free. But most importantly, the language supports powerful abstraction paradigms that can be used to elegantly simplify a structure. The main one is object orientation, which is good to manage system complexity, because the structure of a design can be reflected in the structure of an abstracted object hierarchy.
However, while using C++ enables higher abstraction levels, it does not automatically guarantee an increase in design productivity.
There are many reasons for that. One of the reason is that the C++ language gives enormous modeling choices of a representation. And so, if we take two components, even though it may be straightfoward to connect two ports electrically or behaviorally in their protocols, but not necessarily in C++ because of the different types used in the component interfaces.
We call this problem, inadequate composability. For efficient design we want to construct your C++ based models such that they are interoperable, in designs which may not exists today.

6. High Design Efficiency Requires New “abilities”
2/19/2019
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
Interoperability is the ability to compose systems consisting of descriptions of multiple levels, using C++, using different libraries or different versions of the library. There are two components to interoperability: composability and reusability. Composability refers to the inherent ability of being able to take the objects described in C++ and compose them into bigger objects without changing the internals.
Reusability is the ability to use the same object without changing the internals content and use into diverse designs. Reusability has many methodological implications, and I will not discuss that here. In this talk, I will focus instead on what makes a C++ modeling system composable.
There are two parts to composability: one, model compatibility across modeling dimensions, and the other, ability to quickly and accurately build models with out changes to the component codes. While the issue related to modeling dimensions is discussed in the paper, I will briefly touch upon them now, and later focus instead on how the designer can quickly put together complete system models using underlying C++ libraries and component descriptions.

7. Modeling Dimensions and Composability
2/19/2019
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
There are four different concerns of interoperability when building system level models that go beyond the languages, into model semantics.
The first one is how is the composition of different models of computation is supported?
The second one, is how does one compose systems containing parts described at very different levels of abstraction?
The third concern is that composition of different data types can be problematic without conversion.
And last but not least, assembling models with different class libraries may not be straightforward. Note that in C++, this is a extension of the typing concerns since a class is also type, but with associated behaviors.
These issues are discussed in the paper, and I won’t go into them here. Instead, focus on how a system designer can put together complete systems without being bogged down in object oriented programming details related to typing and problems associated with the class interfaces.

8. C++ Semantic Gap How to connect? Hardware elements: 7 7 B1 B2 B1
2/19/2019
C++ Semantic Gap
Hardware elements: 7 7 B1 B2 B1
sc_in<int>
sc_in<cData>
Port<char>
Protocol<event>
B2* b2_ptr;
Int write(int); … B2
Software models:
One of the reasons, model composability is a difficult issue is because of a semantic gap between the composition of hardware elements and their software models. For instance, consider two blocks: one has a 7-bit output and the other has a 7-bit input. When you connect these ports, at the electrical level it is clear what the composition means and what its requirements are. However, their software models need not be composable given the specific choice of the data type used to model the input/output ports.
While this particular problem can actually be addressed in many ways, the difficulty that it points to is the fact that a system designer must also pay attention to C++ programming details (for example, choice of the types and class libraries, polymorphism, exceptions etc) even when the equivalent hardware composition is relatively straightforward. As a result, a system designer using C++ is called upon to take into account many object oriented and C++ programming details that can be orthogonal to system, or, to hardware design. Interoperability is not an issue of multiple design languages or even multiple design libraries, it is the a use of the same design library by different designers that may not have any relationships to each other, in different design environments.
How to
connect?

9. C++ Composability Implementations
2/19/2019
C++ Composability Implementations W A
A and W: common identity
Inheritance Strategy
Inheritance
Sharing of
W to A B W
Composition Strategy
Delegation from W to B
B and W: two identities
Reference
Let us now focus on what makes systems composable in C++. There are two primary implementation strategies to achieve composability in the context of C++.
Now to understand why system composition is distinct from object oriented programming, consider how a model could be reused in an object oriented programming environment. One way to do this (and it is commonly done) is by inheritance.
The left side the this slide, shows the inheritance strategy. This diagram is a very simple class diagram, in a UML notation. Each box symbolize a class, and the thick black arrow going from class A to class W means that the definition of class A inherits characteristics of the definition of class W.
This means that both classes have common methods, attributes (in other words functions and variables). This also implies that an object of class W can be substituted by an object of class A in a program. This means that an instance of class A has a double identity, because it can pass for an instance of class W. We say that instances of A and instances of W have a common identity.
This is how many software program are composed by the way, and, a priori, there is nothing wrong a with that, its very useful in a numerous situations.
The other way and second implementation strategy is what we call dynamic composability.
The right side of the slides show another class diagram, but now there is small arrow going from class W to class B. This arrow means that class W can refer to a class B in the execution of the program. There are many ways to implement this, but one ways is that at run-time where an object of class W acquires a reference to an object of class B, and will delegate behavior execution to that object.
(note to Rajesh from Fred: I would like to do an animation for this slide, such as hiding the right part when I discuss the left part. Should I make two slides? What do you think?) THIS EXPLANATION IS VERY GOOD. IF YOU LIKE ANIMATION, GO AHEAD AND USE IT.

10. C++ Composability Implementations (cont’d)
2/19/2019
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
(re-arrange for the new slide)
It can be said that in both of these approaches, classes A and B are wrapped into class W. The main difference between them is at runtime.
In the inheritance strategy, an instance of class A, is also an instance of class W. In the dynamic composition strategy, the two instances are separated.
I would like to point out that, in object oriented speak, we say that A has an inheritance dependancy to W, while class B has an association dependency to class W. Inheritance dependencies are stronger than association dependencies. In certain context, this does not really matter.
However, dependencies should be minimal in order to broaden composability. Therefore, we think that for hardware, and for systems which contains hardware, dynamic composability could be a better solution.

11. Dynamic Composition What is dynamic composition? Key ideas:
2/19/2019
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
So, let me summarize this. Dynamic composition is when objects acquire references to each other at run-time. Usually, there might be a notion of containment involved. In the last slide, there was.
When assembling new object structures to build new design structure through dynamic composition, there can be no recompilation necessary and it would be possible to use a set of predefined IP blocks, either textually or graphically.
But this is difficult to implement without relying on the following key ideas:
Use the delegation instead of inheritance for model reuse. This means that from the designer view point, the reuse should not necessarily rely on a set of class interfaces; avoid to define or duplicate a new class just to inherit an interface that the tool can understand.
This is possible if the wrapper (the interface class) is separated from the component. In this way, code can be automatically generated to implement a wrapper for a new component, and compile this into the library.
One way to do this is through an interface definition language to generate and configure a wrapper to specifically suits the need for composition, according to the component description. (
Note to Rajesh from Fred: I would like to say something like that:
The key idea is to automate the process of interface characterization, after that the class has been design…YES, THAT IS GOOD. MENTION AUTOMATIC GENERATION OF INTERFACE.

12. BALBOA CCF Layered composition
2/19/2019
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
Component
Integration, CIL
Split-Level
Interface/BIDL
C++, SystemC
System designer
Compiled
Interpreted
So, how do we achieve dynamic composability?
We take a layered software approach to realize dynamic composability where the system construction is done in an environment which supports easy composition of blocks, their parameterization and modification in a script-like language, but it automatically connects to a detailed and efficient C++ programming environment. Thus it reduces the degree of struggle that a system designer has to do with the programming nuances just to get their system modeled right.
This is implemented in our BALBOA framework.
This framework builds upon existing class libraries to add a layers for manipulation and configuration.
Let me illustrate this by the picture on the right side of the slide.
Here is a designer,
and here is an intermediate layer,
here is a system library.
The upper layer consist of a component integration language, (point to CIL box)
The middle layer has of an interface definition language to describe the components, (point to BIDL box)
and the lower layer is a set of system libraries with C++ components. (point to C++ ellipse)
By using the component integration language, the system architect can compose the library elements. To ease system construction, CIL is a script language that allows loose or delayed typing information and quick complete system assembly.
CIL is connected to the detailed and compiled C++ or SystemC models, through an intermediate layer of software.
So we propose a composability framework that consists of design entry domain in an interpreted environment that allows for loose, or delayed typing determination and quick complete system assembly.
The chief contribution is to make sure that the design entered in the integration environment can automatically be translated into detailed C++ or SystemC software models.
The key technique of this framework is the split level interface between the interpreted and the compiled domain.

13. BALBOA Key Technical Decisions
2/19/2019
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. BALBOA System Implementation
2/19/2019
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
Interpreter C1
SLI C3 C2
The BALBOA framework implements a split-programming model. That means that the designer will use a higher abstraction composition scripting language in order to manipulate the more detailed structure that are implemented in C++. The interpreter and the split level interface layer do not rebuild the design structure, but rather use the compiled structure as the model instance.
A thing I did not mention earlier is that the component integration script language provides delayed and inferred typing, but it also provides design introspection capabilities. This means that the split-level interfaces know the structure and characteristics of the component. This information can be queried by the designer or by a tool.
The diagram on the right side of the slides provide the runtime picture of the environment. The split-level interfaces boxes in red provide the link between the compiled and the interpreted domain. The composition commands are dispatched to the split level interfaces by the interpreter. This means that it is these red boxes that do the work on composition, rather than the components themselves. The full arrows on the diagram indicate this. The dashed arrows indicate something else: it shows the execution flow of the model. When a simulation run is started, the control flow is usually kept in the compiled domain for efficiency. However, it can also go to the interpreter and do composition during the run.
The composition language in BALBOA is implemented using Object Tcl with a number of extensions to support the two features of the language.
Object Tcl is an object oriented extension of the very popular Tcl language that is used in many EDA and non-EDA tools.
YOU CAN ALSO MENTION THE GUI.
(note to Rajesh: the implementation details do not seem to fit well here. Maybe they should be mentionned before the conclusion?) THIS IS FINE. YOU CAN TAKE TIME HERE TO DESCRIBE HOW YOU HAVE IMPLEMENTED BALBOA.

15. Language Layers: CIL Script-like language based on Object Tcl
2/19/2019
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 Component description language to export
2/19/2019
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)
INSTANCE (SmallPacket)
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
2/19/2019
Language and Run-time Layers
Language
Tools
Run-time structure
CIL
Interpreter
Introspection
BIDL
SLI/Type system extension
BIDL
Compiler
GCC
Split Level
Interfaces
Reflection
C++
Compiled
objects
GCC

18. Split-level Interface
2/19/2019
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
2/19/2019
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. 2/19/2019
Using the Environment

21. CIL Script Example L1 r_q mem_sys Mem #load the AMRM component library
2/19/2019
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
mem_sys L1
r_q
Let me now show you a part of an example of a design we modeled in the environment. This is design of an Adaptive Cache Memory Controller or AMRM that we have modeled, simulated, and built into board-level hardware.
The left side of the slide indicates the structure of a portion of the AMRM model, and the right part the script to setup that structure and run it.
(move the pointer on the left part of the figure)
The outer box of the figure is a frame entity called mem_sys that contains the other components, a L1 cache and a memory array. The modules communicate together through queues.
(as I go here, move the pointer again)
The first line loads the IP library for the classes that are written in C++- some of them using the SystemC class library.
The second line instantiate a frame entity, to hold the system structure.
The next step is to instantiate a cache system inside the memory system.
For this, we use a dot operator that we defined in the Otcl extensions. This operator is used to navigate structures in the same fashion as a schematic navigation.
Next we instantiate a memory array, and a queue. The next lines connect the queue to the queue references of the L1 cache and Mem object.
When connecting this queue, the data format of the queue will be decided depending of the data formats of the components that will use the queue. In this case, we use a special class with all the request information, then the queue will use that type.
The next lines are to set up a stimuli and a Otcl call back on an activity condition of the queue. Then, we start the simulation by invocating the simulator with this command.
In this example, we use the interpreter during the simulation to do something when the queue is active (such as monitoring) .
Mem

22. Design Example Statistics: AMRM
2/19/2019
Design Example Statistics: AMRM
1437/880
(1.63) 87
< 150
7 C++
with SystemC
1512/1002
(1.51) 84
< 40
8 C++
812/809
(1.01) 60
< 30
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
The previous example was a very simplified version of an Adaptative Cache System Design (called AMRM) model that we implemented in the environment.
The AMRM system is used to explore adaptive memory behavior in cache memory, and it’s a platform for research applications. A board has been built and is used in the lab.
Basically, it has many levels of cache that are parametrizable.
In the BALBOA environment, we implemented the model of this system at three levels of abstraction, starting from a very abstract sequential model with function calls to a model with signal interfaces with handshakes. This slide shows a table with the design statistics for the implementations. What we mesure in this table are
the sizes of the component integration scripts relatively to the BIDL and the C++ code size. We also look at the ratios of the size of the IP code against the size of the code generated for the split-level interfaces layer.
Let me walk you through this table.
The first model is a sequential model that use 1 thread of control, and a static ordering of the function calls. There are 7 C++ classes, and a little bit less than 30 lines of composition script. The interface description file is 60 lines, and the C++ size is 812 lines. The BIDL generated 809 lines of C++, for a ratio of 1.
The second model uses queues, and the script code grows to 40 lines, while the BIDL grows to 84 lines. However, the ratio of generated code does not grow as fast as the ratio of the IP code. This is because we added a class for the data type being used by the queues, but also because the level of details is smaller, and the composition code seems smaller than the behavior code.
The third model is the one with the signal level interfaces. The script grows considerably because we have to enumerate all the signal connections, but the generated code does not grow so much. This is because composition code is being reuse to connect the signals- in other word, we do not emit C++ code twice to do a signal connection with two different ports.
The ratio of IP code grows faster than the ratio of generated code for the composition in that experiment.
However, what is to be demonstrated is that when we build, run and debug the system, we use the script, and not the IP code so much. This is because once the IP code is of acceptable quality (I mean somewhat bug free), we can use only the script to try different architectural combination and build complicated test bench and monitoring. We manipulate only a minimal amount of code to do the exploration, which has a gross ration of 1 to 10 the size of the C++ IP code.
Finally, to give an order of magnitude, the RTL code for the model is eight thousand lines of VHDL, and the RTL SystemC is 11 thousand lines long.

23. Closing Remarks Good IP-model composability requires
2/19/2019
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.
So, let me add a few closing remarks on the BALBOA experiment. Our goal of this system is to build a composability framework to relieve the designer of programming concerns that are orthogonal to system design tasks of design exploration, partitioning, mapping etc. To accomplish this goal, we chose a split-programming model to have an option of assembling the model with a script language that has a higher abstraction than the C++ language. We also chose to separate the interface wrapper from the component, in other words to use dynamic composition instead of inheritance. This decision has enabled us to have some typing abstraction for the data types of communication objects.
We also used code generation from an interface description language.
Like systemC and C++, many levels of abstraction can be integrated in the framework.
The implementation is about 12 thousand lines of C++ code, and uses many external packages such as Otcl.
(CHECK HERE IF ITS GOOD TO MENTION IT ABOUT THE IMPLEMENTATION)

24. Related Work System level language Component frameworks
2/19/2019
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)