mcf: a metamodeling-based component composition framework—composing systemc ips for executable...

792 IEEE TRANSACTIONS ON VERY LARGE SCALE INTEGRATION (VLSI) SYSTEMS, VOL. 16, NO. 7, JULY 2008

MCF: A Metamodeling-Based ComponentComposition Framework—Composing

SystemC IPs for Executable System ModelsDeepak A. Mathaikutty, Student Member, IEEE, and Sandeep K. Shukla, Senior Member, IEEE

Abstract—Reusing Intellectual Property (IP)-cores accompa-nied by automated generation of the glue-logic, and automatedcomposability checks can help designers to create efficientsystem-level models quickly and correctly for fast design spaceexploration. Furthermore, with the rise of multiple transactionlevel and register-transfer level abstractions, constructing modelswith mixed abstraction levels is also important. A frameworkthat allows designers to: 1) describe the structure of components,their interfaces, and their interactions, with a semantically richvisual frontend; 2) automatically select IPs from a componentlibrary-based on sound-type theoretic principles; and 3) performconstraint based checks for composability, is highly desirable inthis context. A metamodel based framework brings forth furtheradvantages. It helps in: 1) providing rigorous semantics to thevisual models; 2) imposing restrictions on the model and oninteractions between components through constraints expressedin a constraint language; and 3) enabling type-checking and infer-ence-based facilities. Furthermore, using XML-based schemas tostore and process meta-information about the IPs as well as theschematic visual model, allows for an IP selection and integrationmethodology using existing XML processing tools. With thesein mind, we present MCF, a metamodeling-based componentcomposition framework for SystemC-based IP core compositionat multiple and mixed abstraction levels, with all the advantagesstated above.

Index Terms—Architectural template, component compositionmodel, metamodel, metamodeling framework, partial specifica-tion.

I. INTRODUCTION

O NE RECENT industrial trend in system level design isto use high-level programming languages such as C++

to build custom design exploration and analysis models, espe-cially with the increased usage of SystemC. The proliferationof SystemC Intellectual Property (IP) cores necessitates com-puter-aided design (CAD) frameworks that support IP core com-position to build system models. One of our goals is to reducemuch of the software engineering (SE) and C++ programmingburdens that a designer has to face in creating models fromexisting cores. Some of the SE problems arise due to strong

Manuscript received November 3, 2006; revised March 12, 2007. This workwas supported in part by the NSF Project CCR-0237947, by the SRC IntegratedSystems Grant, and by a gift from Intel Corporation.

D. A. Mathaikutty is with Microarchitecture Research Lab (MRL), Micropro-cessor Technology Lab, Intel Corporation, Santa Clara, CA 95054 USA (e-mail:[email protected]).

S. K. Shukla is with the FERMAT Lab, Virginia Institute of Technology,Blacksburg, VA 24061 USA (e-mail: [email protected]).

Digital Object Identifier 10.1109/TVLSI.2008.2000344

Fig. 1. RTL AMBA AHB bus model.

typing requirements, lack of a rigorous compositional seman-tics of SystemC, and the ad hoc mode of reusability associatedwith the compile-link-test methodology. Some reusability stan-dards such as Open Core Protocol (OCP) [1] have been proposedin the industry which ease the compatibility issues between IPcores to an extent, but does not solve the engineering problem ofquick design space exploration without getting bogged down inthe details of SE. Therefore, we need a framework that allowsdesigners to architect the system in terms of components andtheir composition. Such a component composition framework(CCF) helps the designer to be agnostic about the specifics ofthe software language and allows realizing a system through de-sign templates and tool support. The design template may struc-turally reflect the modeling abstractions such as register-transferlevel (RTL), transaction level (TL), and mixed (RTL-TL), aswell as structural hierarchy. The tools facilitate selection andconnection of the correct components, automated creation of thecorrect interfaces and transactors, simulation of the composeddesign and finally validation of the correctness of the composi-tion.

In Figs. 1 and 2, we illustrate the use of design templatesthrough examples such as the RTL model of the AMBA AHB[2] and TL model of the simple bus from the SystemC [3] distri-bution. The AMBA bus model shown in Fig. 1 consists of threemasters and four slaves with similar interface descriptions thatcommunicate through multiplexed signals selected by an arbiterand a decoder. For creating this model as a template and latergenerating an executable from it using reusable components, theCCF should be able to describe the following: 1) RTL compo-nents that would be reused to describe the masters and slaves;2) mux and demux with automatic interface inference for mul-tiplexing and demultiplexing; 3) RTL components that describe

1063-8210/$25.00 © 2008 IEEE

MATHAIKUTTY AND SHUKLA: MCF: A METAMODELING-BASED COMPONENT COMPOSITION FRAMEWORK 793

Fig. 2. TL simple bus model.

the arbiter and decoder; and 4) signal-level connectivity of thecomponents.

Fig. 2 describes the TL model, which consists of threebus masters with distinct protocol-level interfaces (blocking,nonblocking, and direct read-write access) and an arbiter toschedule their transactions. Additionally, the model consistsof two slaves, one with instantaneous read-write access andthe other with slow read-write access due to its clock-basedactivation. For a template description for this model, the CCFshould be able to describe the following: 1) TL componentswith function calls that describe the distinct masters; 2) a busthat depicts the read-write interface of the masters; 3) an arbitercomponent that depicts the arbitration interface; 4) a componentthat represents the read-write interface for the fast slave andreused to describe the slow slave; 5) insertion of clock ports;and 6) transaction-level connectivity.

If the designer wants to explore the simple bus model to an-alyze various tradeoffs, then an alternative description could bereplacing the TL slaves with RTL slaves from the AMBA busin order to determine the loss in simulation efficiency due to thegain in precise timing information from the extra handshakingintroduced. For such an exploration, the framework’s descrip-tion process should allow: 1) customization of the reused slavecomponents from the AMBA bus and 2) insertion of transac-tors that map the TL and RTL interaction of the bus and thenew RTL slaves. Furthermore, for the previous three design sce-narios, the framework should allow design visualization and en-force checks that look for inconsistencies, datatype mismatches,incompatible interfaces, and illegal component descriptions.

To fulfill these requirements, we developed a metamodeling-driven component composition framework (MCF) for IP-reusefrom SystemC IP libraries. Metamodeling is a technique to rep-resent information about models within the same framework asthe models themselves [4]. This can be achieved through reflec-tion/introspection techniques, or by representing model-relatedinformation into the system externally. We use metamodelingas a solution approach to the problem of reusing IP for fastsystem-on-chip (SoC) integration. In the context of SE, espe-cially for domain specific software design, metamodeling hasbeen used in the past (e.g., GME tool from Vanderbilt). In ourwork, we employ metamodeling techniques to build design tem-plates that cater to modeling abstractions and structural descrip-

Fig. 3. MCF design methodology.

tions as well as formulate constraints to enforce as well-definedspecification process. This specification process enables the cre-ation of a component composition model with virtual compo-nents that are placeholders for real implementations. Once thetemplate is correctly created, MCF’s tool support should auto-matically select and compose IPs to arrive at various executablesfor the template. The selection is performed using structural typetheoretic techniques, which provide all plausible implementa-tions that match the component composition model.

We define the problem statement in terms of what is neededfor MCF: 1) visual and textual language for describing compo-nent composition models; 2) formal constraints to enforce thesemantics of the component descriptions and their possible in-teractions in the model; 3) checks to remove inconsistencies atthe specification-level; 4) type-checking and propagation to per-form type inference; 5) library of compiled C++ objects for thedifferent IPs; 6) reflection of structural and behavioral types ofthese IPs; and 7) tool support for IP selection and composition,generation of the appropriate glue-logic, validation of function-ality, and construction of executable models.

A. MCF Design Methodology

The MCF design flow is shown in Fig. 3, where the user be-gins by creating a component composition (CC) model usingthe component composition language. Upon conformance tothe various constraints and completion of the model, it is con-verted to an intermediate representation (XML-IR), which isgiven as input to the introspective composer (IComp). On theother hand, we have an IP library of compiled C++ objects fromwhich the meta-level information (structure, timing, etc.) is ex-tracted through automated reflective mechanism and expressedin XML. The extracted meta-information on the IPs in libraryis also given as input to the introspective composer. It is re-sponsible for constructing executable models by querying thereflected meta-information and selecting the appropriate IPs thatare plugged into the component composition model. The mainfocus of this article is the component composition language.


B. Main Contributions

Our main contributions in this article can be summarized asfollows.

1) Component Composition Language: A visual language(CCL) for component composition is built using the metamod-eling paradigm of the generic modeling environment (GME)[5]. It captures the syntax and interaction rules (semantics) of thevisual composition language into a metamodel. The metamodelis developed as class diagrams using the unified modeling lan-guage (UML) [6]. CCL allows a designer to visually constructabstract architectural templates conforming to the underlyingsemantics of the metamodel. A component composition modelof a system design is also called an architectural template of thesystem.

2) Model Constraints: Modeling-time constraints are en-forced on objects and connections in a component compositionmodel. The constraints are expressed as Boolean predicatesusing the object constraint language (OCL) [7] and are cap-tured as a part of the metamodel. These constraints check forthe well-formedness of the modeling practice and enforce acorrect-by-construction approach for modeling.

3) Analysis Engines: We develop three different interpretersas plug-ins for our CCF, which performs various kinds of anal-ysis to detect system-level inconsistencies, type mismatches, in-terface incompatibilities encountered during modeling. The firstengine is a consistency checker that performs static analysisof the component composition model. It is similar to a “lint”checker for a hardware description language. The second en-gine is meant for data-type checking at the interface level andenforces that the data communicated between the different com-ponents is consistent. We developed algorithms to resolve thetype-mismatch at the interface by type assignment such thatthere is no loss of data. Finally, a type propagation engine thatderives the types for a partially-specified interface of a compo-nent based on architectural connections and the properties of theinteracting components. Type inference algorithms have beendeveloped for this purpose.

4) Translator: This engine translates the CC model into anintermediate XML [8] representation that will be given as inputto the downstream tools. Note that this capability allows MCFto take an alternate route for an input specification without em-ploying the visual language. The XML representation of themodel can be imported into the modeling framework for visual-ization and model analysis, which does not limit the user to thevisual language.

TCCL is a textual language that maps the visual constructs inthe CCL to textual constructs. It is developed such that it has aone-to-one correspondence with the CCL. It is a way to addressthe scalability issue with the visual modeling framework and al-lows the designer to specify a textual architectural template ofthe system design. This template is converted into the XML-IRthrough a simple XML parser and imported into the modelingframework for visualization and application of the various con-straints and checkers.

C. Organization

The rest of this paper is organized as follows. In Section II,we provide the necessary background on metamodeling lan-

guages and frameworks. In Section III, we distinguish MCFfrom related work on CCF, component-based design environ-ment for software reuse and metamodeling-driven design envi-ronments. Section IV describes the component composition lan-guage, metamodel, and model in detail. In Section V, we discussthe consistency checker, type-checker, type-propagation engine,and the XML translation. Section VI discusses a selected casestudy from our library of case studies performed on the AMBAand simple bus. Finally, we conclude by summarizing our mod-eling experience and discussing our future work.

II. RELATED WORK

In this section, we distinguish MCF from related work onCCF and component-based design environment for softwarereuse.

A. Component Composition Frameworks

The BALBOA framework [9], [10] provides a CCF forbuilding architectural design models. Components are con-nected and their interface specified via the component in-tegration language (CIL). Before beginning simulation, theframework performs type inference to select appropriate im-plementation based on the port-connectivity. The CIL is ascript-like language used to manipulate and assemble C++components with constructs that provide an abstraction overC++. Our CCL uses UML class diagrams for describingmodeling constructs and OCL to enforce the semantics. Ourcheckers perform different kinds of static analysis and in-ference to remove inconsistencies. As a result, our CCL isfar more expressive than the BALBOA CIL. It also providesdesign templates for various abstraction levels as opposed toBALBOA, which is meant for RTL. Furthermore, we envisionMCF to select components based on behavioral types of thecomponents in the system.

BALBOA uses its BALBOA Interface Description Lan-guage (BIDL) to describe IP implementations, very similar toCORBA IDLs. Originally IDLs provide the system with typeinformation, but BALBOA extends this further by providingstructural information about the component such as ports, portsizes, number of processes, etc. This information is stored at ameta-layer (a data structure representing the reflected character-istics). The reflection mechanism through the BIDL descriptionis both inconvenient and time consuming. In our framework, weextract the structural information through automated reflectionin a unified manner by preprocessing SystemC models. Thereis no need for writing BIDLs by component designers.

SPIRIT [11] enables system design using a generic metadatamodel [12] that captures configuration and integration relatedspecifics (interoperability metadata) of an IP into an XML li-brary. This enables an SoC design flow in which the modelerinstantiates and characterizes these IPs to create the system de-sign. The modeler is required to perform the tedious character-ization process, which could be automated by a CCF throughselection and composition techniques. As a part of the SoC de-sign flow, SPIRIT provides API standards that should be im-plemented to export the design and configure the actual IPs tocreate the executable. Therefore, SPIRIT is not a tool, instead itprovides the standards for the metadata capture and the config-


uration and integration APIs. For interoperability of MCF andSPIRIT-based tools, we plan to develop a generic metamodelthat imports the SPIRIT metadata and implements the respec-tive APIs as plugs-ins to facilitate the IP integration, as partof our CCF. SPIRIT does not have a type inference problembecause they depend on user-level characterizations. However,an interface-level type compatibility problem does exist, whichthey handle in their design flow. For MCF, the type compati-bility problem is a subproblem of the type inference problem.

The Liberty Simulation environment [13] is a framework forconstruction of micro-architectural simulation models. A modelis structural and concurrent consisting of a netlist of connectedinstances of components, which communicate through ports.The Liberty framework has a language similar to our CCL, butis devoid of any rigorous formalism. They perform type infer-ence and support polymorphic types for their components [14],which is also handled as a part of our modeling framework. Fur-thermore, they do not allow different modeling abstraction be-sides RTL.

Ptolemy II [15] follows an inequality formulation, becausethe type conversion performed using their type system [16] nat-urally maps to inequality relations among types. In a componentcomposition framework like MCF, where components are spec-ified at the architectural-level devoid of an implementation de-tail, the framework does not have enough information about thecomponent’s behavior, so the components must provide theirtype information as either type-bindings to their ports, or bymapping undeclared ports to UN, which implies that the type isunknown. Similar to MCF, Ptolemy II requires its actors to ei-ther provide the type information on their declared ports or typeconstraints on their undeclared ports. However, during type in-ference, MCF begins with UN on the undeclared ports of com-ponents in the architectural template and automatically createstype-binding on the resolved ports and type constraints on theunresolved ones. This type inference is achieved using informa-tion of architectural connectivity as well as the static propertiesof the instantiated communication primitives (bus, switch, etc.)in the template. The advantage is a rapid specification processallowing the modeler to create partially specified architecturaltemplates, thereby shifting the complexity to the framework ininferring and constraining the template for IP composition.

B. Component-Based Design Environments

Component-based software engineering (CBSE) [17] is anapproach to constructing software programs using a library ofcomponents. The idea is to build programs by composing var-ious library components, rather than building the program fromscratch. Since CBSE encourages software reuse, there are po-tential savings on development time and costs. We compareMCF with a few design environments that enable componentreuse for component-based software development.

SPARTACAS [18] is a framework for specification-basedcomponent retrieval and adaptation of software for embeddedand digital signal processing systems. The objective of SPAR-TACAS is to retrieve possible solutions to a problem from alibrary of components. The behavior of the components in thelibrary is specified without stating the implementation details.The component and problem specifications are done in the

same language Rosetta [19]. Being able to retrieve componentsthat match a problem implies that the implementation of thecomponent can be reused to implement the problem. If a com-ponent that partially satisfies the requirements of a problem isretrieved, then the component is adapted before reuse. MCFdiffers from SPARTACAS in many respects. First, the IP libraryconsists of SystemC-based IPs, from which the meta-infor-mation necessary for IP composition will be automaticallysynthesized into XML schemas. The problem specification isin the form of an architectural template, which is described ina component composition language with design templates andmultiple abstractions that are geared towards SystemC-basedIP integration. Furthermore, the component composition lan-guage allows for an architectural description of componentsand their interactions, which does not include any behaviorannotations. The objective of MCF is to solve a problem in theform of an architectural template given a library of SystemCIPs or predict the impossibility of the task. In SPARTACAS,the problem and components in the library are specified in thesame language. In MCF, the architectural template needs tobe converted to an intermediate representation (XML) so as toallow for IP matching based on extracted meta-information.This is necessary to enable a design flow that ties an arbitrarySystemC IP library.

ARBIE [20] provides a visual environment to describe archi-tectures using components and connectors, which contain a de-scription of its properties. ABRIE uses a semi-automated ca-pability to submit the architecture elements to a reuse engine.Existing components that match the properties of the elementscan be reused and instantiated in the architecture. MCF employsa meta-modeling paradigm to define its component composi-tion language with architectural elements as well as differenthardware abstractions. ABRIE’s specification capability is moretiered toward software reuse and uses the model proposed byShaw et al. [21] for architectural description. MCF automatesthe construction and instantiation of architectures with matchingimplementations from a SystemC IP library to satisfy a designproblem.

III. CC LANGUAGE, META-MODEL, AND MODEL

MCF is used to describe an architectural template of a systemdesign that will be instantiated with SystemC IPs from an IPlibrary to create executable specifications. It is built on top ofGME [5] using its meta-modeling language and framework [4].It captures the syntax and semantics of a visual composition lan-guage (CCL) into an abstract notation called the CC metamodel(CCMM). It allows different design templates that facilitate adescription in terms of component instantiations, characteriza-tion and their composition that we call the CC model (CCM).The CCMM is developed using UML class diagrams and OCLconstraints which is translated into visual syntax by GME. Thevisual design environment allows a modeler to construct modelsconforming to the underlying semantics of the CCMM.

A. CCL

In order to enable SystemC-based IP integration, the CCL ofMCF must reflect the hardware-related features allowed throughSystemC. We show the mapping between the CCL of MCF and


the SystemC language, in order to shed light on the underlyingmodeling constructs provided by CCL. MCF facilitates the cre-ation of components and media at the architectural-level, wherecomponents are computational blocks and the media are usedfor communication. The component instantiations that the lan-guage allows are leafs, hiers, and transactors. A leaf componentis a representation of a hardware block without embedding othercomponents. A hier component is a hierarchical hardware blockthat embeds other leaf or hier components. The structural inter-face of these component instantiations depends on the level ofabstraction.

The component composition language has both RTL and TLabstractions similar to SystemC, which are captured throughthe meta-modeling concept aspect in GME. A leaf compo-nent at the RTL abstraction in MCF, is described using anSC_MODULE instantiation in SystemC. It is allowed to havea set of input, output and clock ports that map to the ,

, , and constructs in SystemC.These SystemC constructs are used to describe the input,output, and clock ports. The RTL components in MCF com-municate with each other through connections that map to the

construct in SystemC used to express signal-levelcommunicating. SystemC does not provide a straightforwardway of (de)multiplexing ports. Demultiplexing is facilitatedby reusing the same signal instance and multiplexing throughsharing common signals across the communicating ports.This results in contention scenarios, which require the IP tohave resolution logic to handle these scenarios. Furthermore,multiplexing and demultiplexing are common approachesto propagate the same data across IPs. Therefore, to enablemultiplexing and demultiplexing at the RTL abstraction, MCFprovides mergers and splitters as communication media. Amerger medium is a configurable MUX with input ports, oneoutput port, and selection/driver ports. A splitter medium isa configurable DEMUX with one input port, output ports,and selection/driver ports.

At TL, MCF allows the modeler to describe interface skele-tons, which are contained by one or more media. The interfaceskeleton maps to abstract classes in SystemC that derive fromsc_interface construct. The media and other TL componentshave interface ports for communication that map to theconstruct in SystemC. The different media at TL map to channelimplementations in SystemC that derive from the sc_channelconstruct.

It is a common practice to use specialized communicationmodels to enable component interaction, such as buses andswitches. In large systems, communication inevitably becomesa bottleneck and on-chip bus configurations and protocols sig-nificantly improve overall system performance. Therefore, weprovide the capability to create bus media at the template-levelin MCF. A bus medium is used to structurally portray con-tention and arbitration interfaces. In SystemC, a TL bus modelis described using the sc_channel construct. Designing arraysof interconnected processors for multi-processor SoC platformshas led to the evolution of a design methodology based on a newparadigm called network-on-a-chip (NoC) [22]. The commoncharacteristics of an NoC-based system are that the processorand storage cores communicate with one another through

intelligent switches. To cater for these kinds of architectures,we introduce a switch medium. A switch facilitates bothpoint-to-point connections as well as complex message-passingprotocols. At SystemC, a switch implementation at RTL isan SC_MODULE instantiation and at TL it is an sc_channelinstantiation.

The concept of transactor has been proposed in SystemC toallow a TL-RTL mixed simulation [23], [24]. A transactor worksas a translator from a TL function call, to an RTL sequence ofevents, i.e., it provides the mapping between transaction-levelrequests, made by TL components, and detailed signal-levelprotocols on the interface of RTL IPs. Therefore, MCF also pro-vides a mixed abstraction, where part of the structural interfaceof a component is at RTL and the other part is at TL. A compo-nent that exists at this abstraction in MCF is called a transactor.In MCF, the transactors specified at the architectural templateare automatically synthesized during IP composition and are notsubjected to IP selection.

A component in MCF is also allowed to contain other com-ponents and media, which enable hierarchical components. InSystemC, hierarchical descriptions are allowed by having mul-tiple SC_MODULE s within a SC_MODULE. SystemC allowsfor different TL abstractions, MCF only captures the TL abstrac-tions which are structurally distinguishable. Therefore, the TLcapability provided through the CCL is called the programmerview (PV) of the abstraction [24].

SystemC allows for polymorphic modules and channelsusing C++ templates. A polymorphic module/channel canrender its ports or/and parameters generic by binding themto type variables. It can also have polymorphic sub-moduleinstantiations, which indeed render their internals (port or/andparameters) polymorphic. MCF allows for a generic compo-nent/medium through partial specification, where it has portsor/and parameters which are UN. This implies that the typesof the ports or/and parameters are not specified. MCF tries toinfer these types during type propagation by looking at thearchitectural connections and the static properties. It can alsobe inferred during IP selection, when an IP implementation isused to instantiate the partially-specified component/medium.

B. CCMM

CCMM is represented as ,where is a collection of entities and is a collection of re-lationships that relate two objects. is a collection of con-straints described on the entities, whereas is a collection ofconstraints on the relationships in the meta-model. Real-worldobjects are often represented and analyzed in different ways(e.g., multiple views). Similarly, a meta-model can also havemultiple aspects, where each aspect reveals a different subset ofentities and their relations. is the set of aspects that define thepossible visualizations for the CCMM.

The modeler instantiates an entity to characterize it by spec-ifying its attributes and internals. The modeler instantiates a re-lationship to associate two or more instances of an entity or en-tities. The association is visually specified by connecting them.

1) Definition 3.1: The allowable characterizations and pos-sible containments of an entity and the relations that it can par-


Fig. 4. UML diagram of an LEAF object.

ticipate in, defines its static-requirement, which is fulfilled bythe modeler and enforced by the meta-model.

We discuss a few entities, relations, entity constraints, re-lation constraints, and aspects defined in the CCMM in thissection. The complete description of the CCMM is providedin [25]. The two main entities in the CCMM are LEAF andCHANNEL, which belong to . In Fig. 4, we show the classdiagram of a LEAF entity. Note that in the following figures, atriangle means inheritance and a black dot represents a connec-tion stream, which has two links to denote the source (src) anddestination (dst) of the connection and the third link denotesthe construct associated with the stream. Thelink with a black diamond at one of its end means containment,where the object at the other end (child) has a containment re-lation with the object at the diamond-shaped end (parent).

The LEAF entity acts as a containment of four kinds of ob-jects namely IOPort, RWPort, CLKPort and Parameter. The IO-Port does not have an internal structure and is defined using theconstruct . It acts as a place holder for two specializedtype of ports, namely INPUTPORT and OUTPUTPORT. Theserepresent the input and output ports of an RTL component. Thecharacteristics of such a port are captured through attributesnamely portname, datatype, and size, which are specified in theformat (attribute name: attribute type). The other requirementsof the IOPort object are expressed through its relationships. TheIOConnection is one such relation that asso-ciates two instances of the LEAF entity and belongs to . Thisrelation is used to portray the interaction between two RTL com-ponents via their input-output ports.

The second type of object that a LEAF can contain is RWPort.It is of two types READPORT and WRITEPORT that describesthe read-write function calls of a TL component. These objectshave an internal structure that allows the object to act as a con-tainer for objects of type Argument and therefore defined usingthe construct. These internals capture the static-re-quirements of read-write function calls namely function argu-ments and return type. The attributes that characterize an Argu-ment are parmname, datatype, and iotype.

The third object that a LEAF can contain is a CLKPort,which is also of two types namely ICLKPORT and OCLK-PORT, which portrays the clocking ports of an RTL/TLcomponent. The CLKConnection that belongsto is used to relate the clock ports of two instances in thetemplate. Finally, the Parameter entity that is defined using an

construct. It is used to represent the configurablefactors of a component. The characteristics of a Parameter arecaptured through attributes namely parmname, datatype andinitial_value.

At the top, we have an Architectural_Template entity that isdefined as a . It is instantiated by the modeler for cre-ating an architectural template of the system design. It has an ab-straction attribute that captures the abstraction level at which theinstantiated template will be created. The possible values for theenumerated attribute abstraction are RTL, TL, and RTL_TL. TheArchitectural_Template entity acts as the container for all pos-sible components that a modeler is allowed to instantiate and thecommunication styles and legal interactions that are allowed.The constraints defined in the CCMM that enforce metamod-eling rules on a LEAF instantiation are specified in [25]. Twoof the other entities that belong to on which most of the OCLconstraints attached to a LEAF entity apply are the HIER andTRANSACTOR. The UML diagrams and OCL constraints onthese entities are provided in [25].

A transaction interface in SystemC is an abstract class that in-herits from the sc_interface class. It contains the declaration ofvirtual functions that describe the skeleton of the possible trans-actions allowed through the interface. The interface can be im-plemented by one or more classes that inherits from sc_channelclass. During this implementation, the interface functions aredefined in terms of what data is exchanged as well as how thedata is exchanged through the interface using them.

We employ the INTERFACE object to depict a transaction in-terface and the CHANNEL entity to portray its implementationusing the UML description shown in Fig. 5. The INTERFACEobject is allowed to contain RWPort objects to describe the readand write transaction calls. The INTERFACE instantiations arecollected by the Interface_List entity. The CHANNEL entityacts as a container for two types of ports, naming RWPort andCLKPort, therefore a CHANNEL instantiation is only allowedat the TL abstraction of the template. We capture “a channel im-plements one or more interfaces,” using a containment and as-sociation relation. A CHANNEL instance is allowed to containone ore more INTERFACE instantiations and the RWPort ob-jects in these INTERFACE instantiations are connected to theRWPort objects contained in the CHANNEL using the INTF-Connection . Therefore, the drag-and-drop ofan INTERFACE instance (intf) into a CHANNEL instance (ch)and connecting their RWPort objects imply that ch implementsintf.

With such a non-simple way to describe how a channel im-plements an interface, the modeler is certain to make mistakes.Therefore, we have a set of OCL constraints written to enforcea correct interface and channel description shown in [25].

In SystemC, TL components communicate through transac-tion ports that are hooked on to one or more channels. A transac-tion port allows the component to use read and write functions


Fig. 5. UML diagram of a CHANNEL object.

defined by the channel. These functions are declared by an in-terface. The interface is implemented by a channel, which pro-vides the definition for the functions declared in the interface.Therefore, TL components connect to channels that implementthe interface they use to perform their transactions. We allowa similar description capability through the CCMM to facili-tate transaction-level depiction. A TL LEAF instance interactswith other TL LEAF instances using CHANNEL instances con-taining the necessary INTERFACE instantiations. This impliesthat for two TL LEAF instances and interacting througha CHANNEL instance ch, the RWPort ports of and arealso contained in ch. These RWPort ports of ch are connectedto RWPort ports of the INTERFACE instances contained in chthrough a INTFConnection . Therefore, to rep-resent the interaction between and ch as well as and ch,we provide RWConnection . This connection isunderstood as a transaction port and allows and to use thetransaction functions defined by ch.

Note the following. 1) INTFConnection is used to con-nect a READPORT/WRITEPORT object in a CHANNELinstance to a READPORT/WRITEPORT object in an IN-TERFACE instance, where this connection depicts that theCHANNEL instance implements the INTERFACE instanceby defining its functions. 2) RWConnection is used to connecta READPORT/WRITEPORT object in a LEAF instance to aREADPORT/WRITEPORT object in a CHANNEL instance,where this connection depicts that the LEAF instance usesthe read/write function defined by the CHANNEL. In orderto enforce the correct usage of the RWConnection and INTF-Connection ’s, we have constraints attached tothem.

For a CHANNEL instance, we check for interface compati-bility at the datatype-level along the RWConnection and INT-FConnection ’s. The constraint that checks forcompatibility on READPORT objects and the same constrainthas a part for WRITEPORT objects. In order to formulate thisconstraint, we employ the uniqueness feature of the Argumentobject.

Some of the other entities not discussed so far are MERGER,SPLITTER, BUS, and SWITCH. The MERGER and

SPLITTER instantiations are only allowed at the RTL ab-straction of the template. Their instantiations represent MUXand DEMUX components at hardware-level. They are neededin the CCMM to allow multiplexing and demultiplexing ofconnections, since the IOPort objects of a LEAF instance areonly allowed point-to-point connections. One of the static-re-quirement of a MERGER (MUX component) is that all itsinput multiplexing ports and the output multiplexed port musthave type consistent datatype requirements. This requirementis enforced through OCL constraints and similar constraints areenforced on a SPLITTER instantiation based on its static-re-quirement. The BUS entity is provided to allow bus-styleinteraction, where a bus port is allowed to be driven by multipleports. The SWITCH entity is provided to allow different topo-logical interactions such as mesh-based, tree-based, etc. Thestatic properties of both these entities are also enforced throughconstraints.

When modeling a system, it is important that the requirementsbe captured in a unified set of models. This unified model set isthen partitioned based on the system’s overall behavior, whichfacilitates an examination of the system focusing on specific as-pects. The model design space is partitioned into aspects, whereeach aspect encloses a part of the design space within a partic-ular model. Depending on the aspect chosen, certain modelingparts, and/or relationships may or may not be allowed. Morethan one aspect can exist within a particular model. Aspect par-titioning is also a way to handle model complexity with visualmodeling tools. Some of the aspects developed for CCMM areshown in the following:

Point2PointView is meant for RTL-specific visualization, Chan-nelView is for TL-specific visualization, and MixedView is forRTL_TL visualization. The aspect DesignView allows in visu-alizing the complete architectural template of the system as aflat model.

C. CCM

A CCM is the instantiation, characterization, and connectionof entities from the CCMM to create an architectural templateof the system. It is represented as .is the set of instantiations of the different entities in the CCMM.

collects the activated constraints on the instances. We hadillustrated some of the OCL constraints formulated as a part ofthe CCMM in Section III-B. The constraint attached to an entityis activated as soon as the entity is instantiated and configuredor characterized. A constraint violation will undo the incorrectmodeling step performed by the modeler, thereby promoting amodeling process that is correct-by-construction. is a set ofconnections, where a connection associates two objects througha relationships defined in the CCMM. We use connections inour CCM primarily for modeling different kinds of interactionsbetween instances. collects the activated constraints on theconnections, which are also enforced by CCMM and checkedat modeling-time. These constraints are activated when the in-stantiated entities are connected using the s on


Fig. 6. Abstract TL example. (a) TL SystemC model. (b) TL CCM.

which they are attached. Finally, the variable “ ” is initializedwith a value from giving the CCM a particular visualization.

Every instance of an entity is associated with a name thatis predefined with the name of the entity been instantiated.The user characterizes this instance with a unique name as apart of its description; unless an already existing instance isbeing reused. The instances in the CCM are grouped into threedistinct categories namely components ( ), medium ( ),and clock generators. is the collection of LEAF, HIER,and TRANSACTOR instances, whereas is a collectionof MERGER, SPLITTER, CHANNEL, BUS, and SWITCHinstances. We provide examples to explain the CCM creation.

During modeling, say the user begins by instantiating theLEAF entity to describe a component and proceeds to describethe internals. Based on whether the user wants an RTL or TL de-scription, the internals would be described by instantiating oneor more IOPort or RWPort objects. These internal are then char-acterized by filling in their attributes, which describe the type ofdata communicated through these ports. Furthermore, the com-ponent can be clocked by instantiating CLKPort objects. Eventhough the LEAF instance in the CCM can contain three dif-ferent types of objects, at modeling-time it is not allowed to haveboth IOPort and RWPort objects, since a component can eitherbe at RTL or at TL.

Each IOPort instantiation is characterized by their attributesnamely portname (id), datatype (dt), and size (sz). Let be thetype-system, then and . The size attribute is usedto capture the bitwidth of the port. The functions , , andare used to assign the attributes with user-defined values. Thefunction takes two arguments namely an object and a valueand places the value in the datatype attribute of the object. Atmodeling-time, the user selects the instantiated entity that needsto be characterized within the visual framework and textuallyspecifies the values for its attributes.

During characterization, the modeler specifies a value for thedatatype attribute of an IOPort object. This value must be alegal C++/SystemC datatype and a part of the allowable types

in MCF. The complete set of C++ and SystemC datatypes sup-ported by MCF are provided in [25]. Note that for all C++datatypes the size attribute is predefined. Some of the SystemCtypes are configurable with respect to (w.r.t.) to its bitwidthas and that capability is enabled through the size attribute. At-taching a datatype to an IOPort object is referred to as providinga type-binding. The datatype specification of every IOPort ob-ject of a LEAF instance is called its type-contract. The modeleralso has the choice of not specifying the datatype attribute of anIOPort object. In which case, the datatype attribute is assignedwith UN, which implies that the datatype is not known at thispoint.

1) Definition 3.2: The type-contract of an instance at theRTL abstraction describes the type-bindings of all its IOPortobjects.

At the TL abstraction, a LEAF instance is allowed to con-tain RWPort objects to depict read-write functions. A read/writefunction has a set of arguments, which are read from or writtento during the transaction. A read function reads from its argu-ments, whereas a write function modifies its arguments. We en-able this capability in our CCMM, by allowing each RWPort in-stantiation to contain Argument objects. An Argument object ischaracterized by their attributes namely argname, datatype, andiotype. During characterization, the modeler specifies a valuefor the datatype attribute of an Argument object in an RWPortobject. This value must be a legal C++/SystemC datatype and apart of the allowable types in MCF. Attaching a datatype to anArgument object is referred to as providing a type-binding. Thedatatype specification of every Argument instance in every RW-Port object of a LEAF instance is called its type-contract. In casethe modeler does not want to specify a datatype, the datatype at-tribute is assigned with UN.

2) Definition 3.3: The type-contract of an instance at theTL abstraction describes the type-bindings of all the Argumentobjects in all its RWPort objects.

3) Definition 3.4: An instance is partially typed, when thetype-contract consists of at least one UN type-binding. An in-stance is untyped when all its type-bindings in the type-contractare UN.

Consider the example of a producer and consumer communi-cating through a FIFO. Its TL description in SystemC is shownin Fig. 6(a). The corresponding CCM is shown in Fig. 6(b)with two LEAF instances namely Producer and Consumer thatinteract through a CHANNEL instance first-input–first-output(FIFO). Note that both the Producer and Consumer connect tothe FIFO using RWConnection instantiations.

The characterization of the READPORT object in Consumerand the WRITEPORT object in Producer is shown as follows.

and

and


Fig. 7. TL interfaces. (a) SystemC Description. (b) CCM of FIFO internals.

In this example, we instantiate a READPORT read with anArgument object Data of type character. The Data is read fromduring the transaction, for which the iotype attribute is set tooutput. We also instantiate a WRITEPORT write with an Ar-gument object Data of type character. It is modified during thetransaction, for which the iotype attribute is set to input. A func-tion call could be bidirectional, in which case some of its argu-ments are read from and some others are written into, in whichcase we denote the direction of these arguments through the io-type attribute. This characterization follows from the interfacedescription in Fig. 7(a). The interface that the FIFO implementsin the producer-consumer model is shown in Fig. 7(a).

Note that in order to implement the read_if and write_if inter-faces, the FIFO first inherits from them and then provides thedefinition for the read and write virtual functions. We mimicthis description, by using INTERFACE instances to describeboth the read_if and write_if interfaces. These INTERFACE in-stances are then dragged and dropped into the FIFO CHANNELinstance, which maps to the FIFO inheriting the interfaces inthe SystemC description. Then, we connect the RWPort ob-jects in these INTERFACE instances (read_if.read and write_if.write) with the RWPort objects in the FIFO CHANNEL in-stance (FIFO.read and FIFO.write) using INTFConnection in-stantiations. This maps to the FIFO defining the read and writefunction in the SystemC description. The internals of the FIFOCHANNEL instance in the CCM is shown in Fig. 7(b). The par-allelograms with a centered I are INTERFACE instances thatrepresent the read_if and write_if interfaces. The dashed linesrepresent INTFConnection instantiations. The R and W boxesrepresent the RWPort objects of the CHANNEL instance.

IV. CC ANALYSIS AND TRANSLATION

Developing a CCL using a UML-based visual languagebrings forth the advantages associated with visualization andobject-oriented features. However, the flip-side is that thedesigner’s intent and the language expressiveness must be care-fully and explicitly captured for such a framework. Preciselycapturing these requirements, disallow any unwanted or illegaldescription through the CCL. Some of the requirements ofthe CCL are formalized and enforced using OCL. Some other

requirements entail analysis of the complete model throughinference techniques and we enforce these through checkers.We have implemented three different engines. First, a consis-tency checker that disallows any discrepancies in the CCM.Second, a type-checker that looks for type mismatches betweeninteracting components in the CCM. We also developed a typepropagation engine that performs type derivations through typeinference and type checking. Finally, a translator that convertsthe visual CCM into an intermediate representation based onan XML schema. This XML representation of the model isprocessed by the down stream tools to enable IP composition.

A. Consistency Checking

Some of the HDL related consistency checks performed arewhether connected components match in terms of port sizes, in-terface calls, whether unbounded ports or duplicate ports exist,etc. In this respect, the checker is similar to a linting tool for anHDL language. The components in the CCM are devoid of animplementation and therefore behavioral syntax and semanticchecks cannot be performed by this checker. On the other hand,automatic selection of an implementation from the IP library re-quires the component to be annotated with sufficient metadata.For example, if the user wants to perform selection of IPs basedon the nomenclature, then the components must have a uniqueidentity which is enforced by the checker. If two componentshave identical names, then they are inferred as instances of thesame component that is reused and checked for structural equiv-alence.

1) Definition 4.1: Two instances are said to be structurallyequivalent when their type-contracts are identical.

A consistency checker is an important part of the CCF; it findsinconsistencies early in the specification that reduces the mod-eling-time. Furthermore, some of the tedious tasks are also au-tomated through this checker, such as naming the relation in-stances. We do not require the user to name theinstantiated for connecting the instances. It is tedious and anerror-prone task, which at the RTL in SystemC maps to using

constructs for connecting the modules. We automatethe task of uniquely naming all the relation instances throughthe checker.

B. Type Inference

Systems described with a strong-typed language such as C++requires components to be implemented using interfaces thatare type compatible. While composing IPs in C++, manuallyensuring such type compatibility results in significant design-time overhead. In this section, we discuss inference techniquesthat employ type-checking and type propagation to simplify thestrong typing requirements of the target design language (C++).

1) Type-System: In order to allow for type-checking and typepropagation, we capture the relevant types of the target languageinto a type-system that is given as input to the different checkersand engines. Fig. 8 shows the MCF type-system.

2) Definition 4.2: Type-System: It is a directed acyclic graph,which represents the hierarchy for the basic types supported bythe design domain.

The type-system is a way of dividing the datatypes providedin the design domain into equivalence classes. The notion of


Fig. 8. MCF type-system.

equivalence is derived from the context of usage and an equiva-lence class contains types that are approximations of each other.For example, char and string belong to one class, whereas intand long belong to another class. This is because the type stringis an expansion of the type char. The set of types from C++and SystemC supported by MCF is provided in [25]. First, wedistinguish between the C++ types and the SystemC types andthen define equivalence classes in both. In Fig. 8, the equiva-lence classes separated using vertical bars are shown.

Note that none of the C++ types are configurable in terms oftheir bit or byte size. However, some of the SystemC types areconfigurable such as , where is the number of bits. Inorder to capture the type bitwidth configurability, we provide anattribute size with all objects that has a datatype attribute in theCCMM. However, if the datatype attribute is characterized witha C++ type, then the size attribute has a predefined value whichis enforced through a constraint. Currently, MCF’s type-systemconsists of basic C++ and SystemC types and does not includecomposite or user-defined types.

3) Type-Checking: The type-system is used to perform twotypes of checking that are defined as follows.

4) Definition 4.3: Type Equivalence: Two types are said tobe type equivalent, if they map to the same node of the MCFtype-system.

5) Definition 4.4: Type Subsumption: A type is subsumedby if both belong to the same connected sub-graph of the MCFtype-system and there exists atleast one path from to .

The OCL constraints perform type equivalence checks, wherethe datatypes being matched are type equivalent if they map tothe same node of an equivalence class. On the other hand, typesubsumption provides more flexibility within the same equiva-lence class, for which the datatypes being matched, must satisfyDefinition 4.4. If type is subsumed by , then this physicallymeans an output port of type can be legally connected to aninput port of type .

If the datatypes being matched belong to different equiva-lence classes then type-checking fails on both accounts. Cur-rently, we do not support type-checking using the notion of sub-typing. For example, one could consider the type char to be asubtype of the type int. This requires connecting the sub-graphsof the different equivalence classes to arrive at a lattice with thetop element being the most general type and the bottom elementbeing UN. This construction may or may not be possible andis part of our future work. A type-lattice construction from thetypes used in the embedded software domain has been shown inthe context of Ptolemy’s work [16].

A component’s interface description using our CCMM is de-pendent on the abstraction level and so are our checks. At RTL,type-compatibility boils down to checking whether output andinput ports of the communicating components match in terms of

Fig. 9. Examples to illustrate constraints.

datatype and bitwidth. At TL, type-checking resorts to verifyingthat the read/write calls match in terms of function signatures(return value, argument types, and number of arguments).

We perform type-checking during modeling using OCL con-straints and during CC analysis using our type-checker. The typechecks expressed as OCL constraints are attached to entities andrelations. These at the RTL abstraction enforce that the portsof connected instances are type equivalent. Fig. 9 illustrates anRTL component connected to in Ex1 and a bus mediawith an input port driven by output ports of componentsand in Ex2.

The OCL constraints enforced by the framework checks arethe following.

1) For Ex1: and.

2) For Ex2: ( and) and ( and).

Constraint 1 enforces a rule on out and in that both these portsmust have identical datatypes and bitwidths. This is an exampleof an association-constraint because the it is activated as soonas the port out is connected to the port in. Constraint 2 enforcesa rule on ( and ) as well as ( and ), which says thatboth components communicating through a common bus portmust have their ports ( and ) bound to the same type orunspecified. In Ex2, the ports and are not connected, butthe Constraint 2 applies an association-constraint between them.Constraints 2 is an example of static-requirement-constraint.Some of the entities in the meta-model have a specific set of typeproperties that are mapped to static-requirement-constraints. Ina very abstract sense, they can be thought of as constraints onassociation constraints. They constrain two different port-con-nections of an instance (that may or may not share ports) basedon the properties of the instance. The OCL constraints catch as-sociation- and static-requirement-constraint violations at mod-eling-time rather than have the type-checker catch these duringanalysis.

The type-checking at the TL resorts to verifying that functionsignatures match without failing using OCL constraints. Con-sider the example of the FIFO CHANNEL instance shown inFig. 10 that interacts with a LEAF instance . The connections

and enforce that the Argument objects of the RWPort ob-jects fifo_read and num_available are type equivalent to those ofthe RWPort objects read and size. This is expressed as an OCLconstraint in [25]. The Argument object are matched and typechecked using their distinct argname attribute. Furthermore, theRWPort objects must match in the number of Argument objects.


Fig. 10. FIFO CHANNEL example.

Let S denote the function signature, then the following must betrue for the RWConnection instantiation

and

and

and

and

where is the number of Argument objects in theRWPort object fifo_read. Note that a similar constraint is en-forced on the RWConnection instantiation .

The OCL constraints attached on the entities and relationsin the metamodel are limited to type-checking based on typeequivalence. Consider a SystemC example, where an adder’soutput of type is connected to the input of a multiplierof type . The activated OCL constraints will flag aviolation; however, the types can be equated through subsump-tion. Therefore, if the modeler wants to use the subsumptionrelation instead of type equivalence, then the failing of the OCLconstraints serves as a notification that the user has connectedtwo ports that are not type equivalent. The checking based ontype subsumption is performed by our type-checker that derivesthe type relations from the MCF type-system. If a type relationcannot be derived for the two specified types, then a violation isreported by the checker.

The type-checking engine also tries to infer and propagate atype onto untyped/partially typed components in the template.The inference step utilizes association-constraints as well asstatic-requirement-constraints on the instances in the templateto derive new type-bindings for an untyped/partially typed com-ponent. The propagation step assigns these type-bindings on thepartially typed/untyped port(s) of the component. These stepsare followed by a new round of type-checking to ensure that theassignment has not resulted in any inconsistencies. Before, weprovide the details of our inference algorithm; we explain theneed for type inference at the architectural-level in MCF.

6) Partial Specification: During the architectural specifi-cation in MCF, a component’s interface is bound to a set ofdatatypes that are collected to create its contract. The contractdescribes type-bindings that the component must conform toduring its interaction. MCF also allows a partial architecturalspecification to enable the description of flexible components.During which, a component is made typeless by binding it toUN. On the other hand, if a component is bound to a type-con-tract, then its behavior is derived from its contract; therebyrestricting its flexibility. Therefore, partially specified architec-

tural templates provide an easy and fast specification process.If the modeler wants to specify a generic RTL adder, then allits ports have their datatype attribute characterized as UN.Consider the generic adder (Adder_2_1) shown in Fig. 8, wherebased on the usage, the port bindings are derived differently.

Another reason for allowing partially typed compo-nents/media is to avoid the tediousness associated with charac-terizing every component in the CCM. The types for some ofthese can be inferred based on their static-requirements or fromtheir associations. For example, the CCMM provides mediaentities such as SPLITTER and MERGER for multiplexingand de-multiplexing connections. Their input-output datatypescan be inferred from their static-requirements. Being able toinfer the datatype of one port of the SPLITTER/MERGERinstance requires the other ports to conform to it through typeequivalence or subsumption.

Note that the specification of partially typed or untyped in-stances in the CCM may be such that the type inference failsto provide assignments that fully type the instances. This doesnot mean that a modeling error exists; rather sufficient type in-formation is not provided by the modeler. This kind of incom-plete specification is allowed through the CCMM. The advan-tage is that a polymorphic implementation is structural depictedusing this capability of the CCMM. In C++ based HDLs suchas SystemC, an IP block built using C++ template is polymor-phic and has type variables as place holders for concrete types,which are resolved during instantiation. Some examples of suchimplementations are buffers, fifos, memories and switches. Themodeler uses the CCMM for modeling a generic template of thesystem, into which IPs are substituted to construct various ex-ecutable models. The automatic exploration of alternatives forthe generic template is furthered through an incomplete CCMspecification, because the untyped or partially typed instancesare generic enough to match with a large number of implemen-tations.

Consider the example of the generic component comp inFig. 12, which the modeler wishes to instantiate with an IP fromthe library. Two of the implementations from the IP librarynamely float_Multiplier and int_Adder are also shown alongwith their reflected type-contracts.1 Both of these can be usedto instantiate the generic template of comp through a selectionbased on structural equivalence. However, the behaviors ofthese two IPs are different and one results in an incorrect sub-stitution by the IComp after selection. This cannot be avoidedunless the modeler provides more type-information for theinterface of the component, since an untyped RTL componentmatches structurally with almost every IP with the same numberof input and output ports. Hence, there is a tradeoff betweenthe rapid specification of the system template and the quality ofthe selected IPs for substitution.

7) Type Propagation: The type propagation engine begins byextracting the instances in the architectural template and pop-ulating data-structures that are SETs. The extraction allows foran easy analysis and uniform treatment of similar instantiations.It also avoids multiple traversal of the model. The engine ap-plies inference techniques to statically derive datatypes for a

1The reflected type-contract of an implementation is simplified for illustra-tion.


Fig. 11. Generic Adder_2_1.

Fig. 12. Instantiating a template from the IP library.

partially typed instance based on its association- and static-re-quirement-constraints. Upon inference, the engine plugs in theinferred type and calls the type-checker to guarantee that thepropagated type is consistent. The inference algorithms differfrom entities to media and they are detailed in [25]. The typepropagation fails to convert a partially typed instance into a fullytyped entity on the following two accounts:

1) type information is not sufficient to fully type the instance;2) type-checker detects an inconsistency during type propa-

gation.In the second case, the algorithm terminates by stating that thearchitectural template is not correct and there is a type inconsis-tency w.r.t. the specification of certain instances in the template.The modeler needs to go back to the architectural template andrework the type-contract to remove the conflicting scenario.

C. XML Translation

The translator generates an intermediate representation forthe CCM using XML. This XML representation (XML-IR) isvalidated against a Document Type Definition (DTD) for well-formed-ness. The translator uses a templated code generator thatwhen given a visual component or media prints out the corre-sponding XML fragment. The XML-IR serves as input to theintrospective composer. Note that instead of using our XML-IR,the SPIRIT [11] XML format can be used for exporting themodel.

V. CASE STUDIES

We discuss the CCM created for the AMBA AHB bus [2].

A. AMBA AHB RTL Bus Model

The AMBA AHB has three master components with identicalinterface, four slave component with identical interface, an ar-biter and a decoder as shown in Fig. 1. The master componentscommunicate with the slave components through MUXes, DE-MUXes, and a set of signals. The multiplexing is driven by thearbiter and the decoder. In order to quickly model the architec-tural template of the AMBA bus using our CCL, the reusable

Fig. 13. Visual canvas and subtype instance.

modules in the system are identified. The reusable componentsand media are created on the visual canvas (part of the modelingframework), which are instantiated through a copy-paste actionand characterized to create the CCM for the system. For the de-scription of the AMBA CCM, we create a master, slave, genericMUX and DEMUX, which are placed on the canvas to facilitatereuse.

1) Visual Canvas: The master is modeled as a LEAF in-stance with three IO ports namely HADDR, HRDATA, andHWDATA. The HRDATA is an input port receiving dataof type int, whereas HWDATA is an output port similar toHRDATA. The HADDR is a 32-bit sc_uint output port. Thesetype-bindings are used to characterize the master’s interface,there by producing a fully typed component (type-contractis complete). This is possible for the AMBA CCM, becausethe master components are identical. However in general, thecomponents and media on the canvas are modeled generically,which provide more flexibility in terms of reuse. The slavecomponent on the canvas is modeled similar to the master withthree IO ports namely HADDR, HRDATA, and HWDATA,where HADDR and HWDATA are input ports and HRDATAis an output. A fully specified type-contract is also provided forthe slave component that is similar to the master component’stype-contract. On the other hand, the MUX and DEMUX on thecanvas are modeled generically, because their type-contractsdiffer based on the (de)multiplexed signal. The MUX is mod-eled as a MERGER instance with three input ports ( , , and

) and an output port ( ) for multiplexing, which structuraldepict the requests from the three masters that are processedone at a time. The MUX also has an external input port ( ) forthe driver that select the signal to be multiplexed. The DEMUXis modeled as a SPILTTER instance with one input port ( )and four output ports for demultiplexing ( , , , and ),which describe the read-write accesses being demultiplexed toone of the four slaves components. The visual canvas with thecomponents and media that is used for the CCM description ofthe AMBA AHB is shown in Fig. 13(a).

2) AMBA CCM: The CCM of the AMBA AHB bus isconstructed in the following manner: The master componentfrom the visual canvas is instantiated thrice and the namecharacterization Master_1, Master_2, and Master_3 are pro-vided for the three instances. Similarly, the slave componentis instantiated four times and characterized. We create newcomponents namely Arbiter and Decoder to model the arbiterand decoder in the AMBA AHB, since none of the componentsfrom the canvas can be reused for this purpose. Finally tocompose these components, we need to model the signals by


instantiating the MUX and DEMUX from the canvas. To multi-plex the HADDR of the three masters, the MUX is instantiatedand characterized as ADDR_MUX. Connecting Master_i’sHADDR port to the ADDR_MUX port ( ) activates aconstraint on as well as all the other multiplexing ports.The port is automatically renamed as HADDR_Master_ithrough the consistency checker, which is also part of thecharacterization. For example, creating a connection suchas leadsto the following automatic characterization through the typepropagation engine:

and

and

and

The connection not only binds the associated input ports, butalso the other multiplexing port due to the static-requirement ofa MERGER that requires each of its instance to have type equiv-alent or subsumed ports for multiplexing. While connecting theHADDR port of the other masters, the type-bindings createdfrom Master_1 will enforce a type check. In this case study, themasters have identical interfaces, therefore this check will notbe violated. However during the connection of components withdistinct boundaries, the characterization of a MERGER instancefrom a single component can be used to detect type inconsis-tencies among the other components communicating through it.These inconsistencies are detected by the type-checker.

The external input of ADDR_MUX is connected to theArbiter and characterized accordingly. Another MUX isinstantiated to multiplex the HWDATA port of the masters.This instance is named WDATA_MUX and is similar to theADDR_MUX with the difference that the type-binding prop-agated is int. This points out the need for a generic MUX thatcould be reused, as opposed to having a fully typed MUX inthe canvas.

Besides promoting a reuse-based modeling flow of fixedblocks, the visual canvas also allows reuse through flexibleblocks. A fixed block is an instance of the component/mediumdescribed on the canvas, which is reused and characterized inthe CCM without changing its internals. On the other hand,a flexible block is an instance which is reused in the CCMafter modifying its internals. The modification is limited toaddition of objects and relations to the instance, but deletionof existing objects/relations within the instance is not allowed.This allows the modified instance (child) to be a subtype ofthe instance being modified (parent). Therefore, the OCLconstraints on the parent are propagated onto the child, whichenforces its consistent usage in the CCM. In the AMBA busmodel, consider the HRDATA input port of a master. Thisinput to the master is obtained by multiplexing the output ofthe four slaves based on the the decoder’s input that addressesthe master whose request is being processed. In order to modelthe HRDATA multiplexing, the MUX instance from the canvasis reused (WDATA_MUX), after extending it to handle fourinputs as shown in Fig. 13(b). Furthermore, connecting theWDATA_MUX ports to the slaves ports ( , , , and )

Fig. 14. AMBA AHB CCM.

and the port of the Decoder derives its type-contract throughinference. In this case, the parent (MUX) is generic, therefore,the type-bindings of the subtype is consistent. Similar to themultiplexing, the DEMUX is instantiated and characterized tocreate the complete ABMA CCM as shown in Fig. 14.

VI. CONCLUSION AND FUTURE WORK

Our experience from using the modeling framework in MCFis summarized as follows: 1) it is a drag-and-drop environmentwith minimal effort in modeling systems; 2) it allows for rapidmodel development through a visual canvas of reusable ele-ments; 3) it provides for modeling-time checks to enforce cer-tain correctness constraints, (iv) it is easy to model at differentabstractions as well as across abstractions; 4) it provides a nat-ural way to describe hierarchical systems; and 5) it is highlyextensible and customizable for future requirements, since it isbuilt using the meta-modeling language of GME.

A. Future Work

In order to capture the behavior of the interacting compo-nents as a part of the architectural template, we will extend theCCMM to allow for interface automata (IA) [26] style specifi-cation. The interface automata formalism describes the compo-sition of components described as input and output actions bysynchronizing these actions. We will provide UML constructsto describe a component’s behavior as actions and OCL con-straints to define when two components are compatible in an en-vironment based on the composition of their actions. We wouldalso equip our CCL with the Open Core Protocol (OCP) to ex-press a large variety of hardware communication behaviors thatpromote reusability at different abstraction levels within RTLand TL. Furthermore, extend the MCF framework to be SPIRITcomplaint so as to enable interoperability with industrial tools.

We developed the other two ingredients of MCF namely theautomated reflective mechanism and the introspective composerto provide a full fledge CCF. The reflective mechanism extractsmeta-information on the structural type of all the IPs in the li-brary and constructs a data structure containing this informa-tion. We employ a SystemC XML parser to annotate the Sys-temC-based IP with XML tags and an XML parser to extractthe required metadata and populate our structures. These datastructures and the IR of the CCM from our visual front-end isgiven as input to the introspective composer to allow automaticIPs selection based on structural type theoretic techniques. Theextraction of meta-information on behavioral types for IP selec-tion and composition is part of our future work.


ACKNOWLEDGMENT

The authors would like to thank the anonymous reviewers fortheir constructive suggestions.

REFERENCES

[1] OCP International Partnership Association, Inc., “OCPIP home page,”2001 [Online]. Available: www.OCPIP.org

[2] ARM, Cambridge, London, U.K., “AMBA specification 2.0,” 1999[Online]. Available: http://www.arm.com

[3] OSCI Group, “SystemC website,” 2000 [Online]. Available:http://www.systemc.org/

[4] D. A. Mathaikutty, H. D. Patel, S. K. Shukla, and A. Jantsch, “EWD:A metamodeling driven customizable multi-MoC system modelingframework,” Proc. ACM Trans. Des. Autom. Electron. Syst., vol. 12,no. 3, Aug. 2007, Article 33.

[5] A. Ledeczi, M. Maroti, A. Bakay, G. Karsai, J. Garrett, C. Thomason,IV, G. Nordstrom, J. Sprinkle, and P. Volgyesi, “The generic modelingenvironment,” presented at the Workshop Intell. Signal Process., Bu-dapest, Hungary, May 2001.

[6] O. M. Group, “Unified modeling language,” 2001 [Online]. Available:http://www.uml.org/

[7] J. Warmer and A. Kleppe, The Object Constraint Language: GettingYour Models Ready for MDA, 2nd ed. Boston, MA: Addison-Wesley,2005.

[8] B. DuCharme, XML: The Annotated Specification. Upper SaddleRiver, NJ: Prentice-Hall, 1998.

[9] F. Doucet, S. Shukla, M. Otsuka, and R. Gupta, “BALBOA: A com-ponent based design environment for system models,” IEEE Trans.Comput.-Aided Des., vol. 22, no. 12, pp. 1597–1612, Dec. 2003.

[10] F. Doucet, S. Shukla, M. Otsuka, and R. Gupta, “An environment fordynamic component composition for efficient co-design,” in Proc. Des.Autom. Test Conf. Eur. (DATE), Mar. 2002, pp. 1530–1591.

[11] SPIRIT, “Spirit consortium, SPIRIT schema working group,” 2005[Online]. Available: http://www.spiritconsortium.org/

[12] C. K. Lennard and E. Granata, “The meta-methods: Managing designrisk during IP selection and integration,” in Proc. Eur. IP Conf., Nov.1999, pp. 285–199.

[13] M. Vachharajani, N. Vachharajani, D. Penry, J. Blome, and D. August,“Microarchitectural exploration with liberty,” presented at the 35th Int.Symp. Microarch. (MICRO), Istanbul, Turkey, Nov. 2002.

[14] M. Vachharajani, N. Vachharajani, S. Malik, and D. August, “Facili-tating reuse in hardware models with enhanced type inference,” in Proc.IEEE/ACM/IFIP 2nd Int. Conf. Hardw./Softw. Codes. Syst. Synth., Sep.2004, pp. 86–91.

[15] J. Eker, J. W. Janneck, E. A. Lee, J. Liu, X. Liu, J. Ludvig, S. Neuen-dorffer, S. Sachs, and Y. Xiong, “Taming heterogeneity—The Ptolemyapproach,” Proc. IEEE Special Issue Modeling Design EmbeddedSoftw., vol. 91, no. 1, pp. 127–144, Jan. 2003.

[16] Y. Xiong, “An extensible type system for component based design,”Ph.D. dissertation, Dept. Elect. Eng. Comput. Sci., Univ. CaliforniaBerkeley, Berkeley, 2002.

[17] A. C. Wills, “Modeling for component based development,” presentedat the Eur. Conf. Object-Oriented Program. (ECOOP), Brussels, Bel-gium, 1998.

[18] B. Morel and P. Alexander, “SPARTACAS: Automating componentreuse and adaptation,” IEEE Trans. Softw. Eng., vol. 30, pp. 587–600,Sep. 2004.

[19] P. Alexander, D. Barton, and C. Kong, “Rosetta usage guide,” TheUniv. Kansas, Lawrence, 2000.

[20] Y. Chen and B. Cheng, “Facilitating an automated approach to archi-tecture-based software reuse,” in Proc. 12th IEEE Int. Conf. AutomatedSoftw. Eng., Nov. 1997, pp. 238–245.

[21] M. Shaw, R. DeLine, D. Klein, T. Ross, D. Young, and G. Zelesnik,“Abstractions for software architecture and tools to support them,”IEEE Trans. Softw. Eng., vol. 21, no. 4, pp. 314–335, Apr. 1995.

[22] A. Jantsch and H. Tenhunen, Networks on Chip. San Francisco, CA:Morgan Kaufmann, 2003.

[23] F. Ghenassia, Transaction-Level Modeling with SystemC. New York:Springer, 2005.

[24] C. N. Ip and S. Swan, “A tutorial introduction on the new SystemC ver-ification standard,” 2003 [Online]. Available: www.systemverilog.org

[25] D. A. Mathaikutty and S. K. Shukla, “MCF: A metamodeling basedvisual component composition framework,” Virginia Institute of Tech-nology, Blacksburg, Tech. Rep. 2005-12, 2005.

[26] L. D. Alfaro and T. A. Henzinger, “Interface automata,” in Proc. 9thAnnu. Symp. Foundations Softw. Eng. (FSE), 2001, pp. 109–120.

Deepak A. Mathaikutty (S’04–M’08) received theB.S. degree from the National Institute of Tech-nology, Trichy, India, in 2003, and the M.S. degreefrom Virginia Institute of Technology, Blacksburg,in 2005, where he is currently pursuing the Ph.D.degree in computer engineering.

He is a Research Scientist with the Microarchi-tecture Research Lab (MRL), Intel Corporation,Santa Clara, CA. His research interests includeESL modeling, formal verification, and dynamicvalidation of CPU and SoC. His current work

includes metamodeling-driven design and validation of system-level modelsfor microarchitectures and SoCs and a customizable multi-MoC modelingenvironment for system design. He has published around 35 articles in journalsand conference proceedings. His work is supported by the National ScienceFoundation (NSF), Semiconductor Research Corporation (SRC), and IntelCorporation.

Sandeep K. Shukla (M’99–SM’02) is an AssociateProfessor with the Department of Computer Engi-neering, Virginia Institute of Technology (VirginiaTech), Blacksburg. He is also a founder and DeputyDirector of the center for embedded systems forcritical applications (CESCA), and Director of theFERMAT Research Lab. He has published morethan 125 articles in journals, books, and conferenceproceedings. He recently coauthored SystemCKernel Extensions for Heterogeneous Modeling(Kluwer, 2005) and coedited Nano, Quantum and

Molecular Computing: Implications to High Level Design and Validation(Kluwer, 2004) and Formal Methods and Models for System Design: A SystemLevel Perspective (Kluwer, 2004).

Dr. Shukla was a recipient of the PECASE Award for his research in designautomation for embedded systems design, which in particular focuses on systemlevel design languages, formal methods, formal specification languages, prob-abilistic modeling and model checking, dynamic power management, applica-tion of stochastic models and model analysis tools for fault-tolerant nanoscalesystem design, and reliability measurement of fault-tolerant nanosystems. Hehas been elected as a College of Engineering Faculty Fellow at Virginia Techand a senior members of the ACM. He also chaired a number of internationalconferences and workshops, edited a number of special issues for various jour-nals, and is on the editorial board of IEEE Design and Test of Computers andIEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS.

mcf: a metamodeling-based component composition framework—composing systemc ips for executable...

Documents