Accelerating High-Level SysML and SystemC SoC Designs

By Waseem Raslan, Mentor Graphics Egypt
Ahmed Sameh, The American University in Cairo

Abstract

SysML, the dedicated system level UML-based notation proposed by the OMG, is gaining a lot of momentum as a system level design standard. Design productivity is one of the main challenges facing the semiconductor design roadmap for >= 32 nm technology as stated by the ITRS. Increasing the level of abstraction and automation are two of the methodologies suggested by the ITRS to address the design productivity challenge. Producing executable specifications is another methodology to increase the productivity. This research suggests that the automatic mapping of SysML, the system level UML based notations adopted by the OMG to SystemC, that was standardized by the IEEE, can raise the level of design abstraction in an automated environment and produce executable files.

1. INTRODUCTION

In its 2005 design report, ITRS [20] has listed a number of challenges that are facing the EDA design in the near future. Among those challenges was the need to raise the design productivity. Raising the level of design abstraction is one key design methodology that has been suggested by the ITRS to overcome the design productivity challenge.

Electronic Design Automation, EDA, tools are very powerful at the register transfer level of abstraction and the abstraction levels below. Being detailed and slow by nature, these levels of abstraction are not suitable for validating a whole system that could be further implemented in software or hardware. In today’s tight schedules and tough time to market competition, the ability to validate the whole system at a higher level of abstraction is becoming a mandatory for designers to avoid unpleasant surprises at critical phases of the system integration. Emerging System Level languages, like SystemC and SystemVerilog, have erupted to raise the level of abstraction level above the RTL one. Yet those languages still have upper limitations in terms of visual descriptions and ease of use at the system level. In addition, Martin shows in [5] that those new languages can't, by themselves, be used to close the gap between hardware and software designers.

UML has been the software notations standard for years and has been widely adopted and used for the software community. Several researches have suggested that UML, especially after its 2.0 standard, could be used as a hardware requirement and description notation as well. Since SystemC is considered the language that could be best used for describing the system at a very high level of abstraction, and since it's a C++ based library, SystemC is considered the natural language to follow the UML in the abstraction level hierarchy. In addition, SystemC models produces an executable that can be run to simulate the system it models. If SystemC is modeling a system at a very high level of abstraction, this executable can be considered the executable specification of the system, which is one of the methodologies that are suggested by the ITRS to address the design productivity challenge. Since raising the automation level is one of the methodologies suggested by the ITRS to overcome the productivity challenge, automated translation from UML to SystemC has been a hot of subject of research in the last four years. Several system level UML profiles have proposed in the context of those researches.

Realizing the importance to standardize these system level notation profiles, a request for proposal, RFP, have been presented to the OMG group to standardize a system level UML profile that can be best used to model a system. SysML has been proposed for the OMG group and its 1.0 draft revision has a great potential to become the standard system level UML profile. The goal of this research is to analyze the mapping between SysML and SystemC, propose and suggest the SystemC modeling techniques that should result in modeling both the structure and behavioral SysML diagram to produce a single executable that represents the system behavior. A prototype for a translation tool, a SysML model compiler, has been implemented using a UML editing tool that supports SysML. Un-timed TLM SystemC models have been generated to model the expected behavior of the SysML.
This paper is organized as it follows: section 2 presents related work to this research, section 3 presents the prototype that has been implemented, section 4 presents the mapping between SysML and

SystemC through a practical SysML example, and finally conclusions and future work are presented in section 5.

1. RELATED WORK

Thiagarajan et al. have proposed a system in [18] that parses the UML design produced from Rhapsody tool in its XMI format to produce an abstract tree of the design that is fed to the Velocity template based code generation engine. The proposed system is fed also with a set of SystemC templates to generate the SystemC code based on them. Their work was mainly targeting the class and state chart diagrams.

In a later research, Thiagarajan et al. have proposed a system in [16] which they have called RT2SystemC translator. In this research, they have used Rational Rose Real Time UML editing tool to model the whole system. To generate the SystemC code, the C++ generated code from Rational Rose was converted into XML using the GCC_XML utility. The XML output is then preprocessed and parsed using JDOM, then translated into SystemC code.

Prevostini et al. have proposed in [9] the ACES design flow that is a complete design flow that starts from the UML level. ACES design flow grabs the system specifications through the class, state machine, activity, sequence and use case diagrams edited by the Rhapsody tool. Then extracts the function and structure information through traversing Rhapsody data model, accessed through Rhapsody APIs, to generate the SystemC models. ACES design flow takes the SystemC generated code down the way through the software, hardware and interface synthesis procedure.

In an attempt to create a formal bridge between UML and SystemC, Snook et al. have proposed in [13] translating UML design into the formal B language where formal B validation tools can be applied to the design. This step was done by creating a tool called U2B. After validating the design in the B domain, it’s translated to SystemC using a created tool called B2SystemC. Snook et al. have created a specialized UML profile called UML-B and focused their work on the package, class and state chart diagrams.

Mellor et al. have proposed in [6] an executable and translatable system that allows the designers to model debug, and validate their UML model through model execution regardless of the actual implementation. After model validation, the model gets translated into algorithmic C or C++ by applying a set of translation rules on it. Mellor et al. are convinced, [7],that only the class, state chart and the action diagrams are fair enough for modeling hardware. In addition they are convinced that round trip engineering is not needed in this particular design domain, i.e. generated code shouldn’t be manually edited by the designers. The generated algorithmic C or C++ code is then fed to the synthesis tools that are able to implement the hardware part of the system.

Other researches have been conducted targeting SystemC code generation targeting mainly the class and state machine diagrams as in [19], [10], [11], [12] and others. All the previous translators were targeting a subset of the UML diagrams, mainly class diagrams and state machine diagrams, using a proposed UML profile to match system level modeling. The current research is targeting SysML profile proposed by OMG to be the system level standard. The current research is not focusing on specific diagrams. On the contrary this research is attempting to benefit from most of the SysML diagrams during the SystemC transformation phase.

All of the previously related researches have created their own UML profile to be suitable for system level modeling. Some researchers have gone the extra-mile and created a SystemC specific UML profile. Realizing the importance of standardization, THALES and others have submitted, in March 2003, a RFP “Request For Proposal” to the OMG “Object Management Group” to standardize a UML specific profile for system modeling. A working group has been formed and created a Systems Modeling Language Forum called SysML [15]. The forum has proposed a SysML notation, based on UML 2.0 version, to address the issues raised in the SE RFP. Like UML, SysML is on its way to become an OMG standard especially that a lot of UML editing vendor tools have actively participated in the forum and are competing to support the SysML in their tools even before it’s fully standardized. SysML is designed to be effective in specifying requirements, system structure, functional behavior, and allocations during specification and design phases of system engineering. SysML uses some UML 2.0 diagrams as is, extends some other UML 2.0 diagrams, and introduces new diagrams to achieve its goals. Figure 1 shows the SysML diagram architecture.



Figure 1 SysML 1.0 Diagram Architecture

UML 2.0 diagrams that are reused without changes: Use Case diagram, Sequence diagram, and State Machine dia­gram. UML 2.0 diagrams that are reused and extended: Activity diagram (extends UML 2.0 Activity diagram), Block Definition dia­gram (extends UML 2.0 Class diagram), Internal Block diagram (extends UML 2.0 Composite Structure diagram), and Pack­age diagram (extends UML 2.0 Package diagram).

New diagrams that have been introduced are: Parametric Constraint diagram, Allocation diagram/Allocation Trace ability Table, and Require­ments diagram.

SystemC, as defined by OSCI, is a library of classes and a simulation kernel that extend standard C++ to enable the modeling of systems by providing hardware constructs within the context of standard C++. Being built on standard C++ closes the gap between SW and HW designers in addition to providing a stable platform for development of system-level tools. Most of the EDA vendors are competing to support SC simulation, synthesis in their design flows. Many semiconductor and systems companies began to use SystemC in their design flows. SystemC Language Reference Manual (LRM) has been standardized as IEEE 1666 by the IEEE. SystemC has gained the fame of being superior at architectural design and architectural verification & HW/SW co-verification as suggested by Arnout et al. in their SystemC-SystemVerilog comparison in [1]. This superiority at architecture level, in addition to being C++ based language, recommended SystemC to be the next level design language to the UML level.

Figure 2 SystemC Language Architecture

The different layers of which the SystemC language is composed are shown in figure 2. SystemC provides the following to the designer:

1. A kernel for event-driven simulation that is the base infrastructure upon which the events and processes will be handled.
2. The ability to add any data type using the C++ ability of inheritance.
3. A set of primitive channels that can be used to describe primitive communication between different modules.
4. A set of very useful libraries to do verification and perform transaction level modeling.
5. Several system level design building blocks. In addition to supporting a number of predefined hardware data types.

SystemC design building blocks, as defined by its LRM [14] and illustrated in [4], are mainly: modules, ports, interfaces, channels and processes.

Modules are the main building blocks of the SystemC design. Basically any module is a C++ class derived from SC_MODULE SystemC class. Any module should contain a set of ports to communicate with other modules, a set of processes that describe the functionality of each module. Internal data and channel for holding the model state and communication among internal processes. In addition modules can contain other modules to model the design hierarchy. Interfaces are used to define the set of operations, parameters types and return values without specifying how these operations are actually implemented. These interfaces are used to allow for easy exploration of different implementations, having the same interface, without having to do many changes to the original models.

The means for a module to interact with other modules through well-defined boundaries is usually referred to by the notion of port. Channels are the implementation of the SystemC interfaces, they define how the channels behave and how they are implemented. We can have many different implementations of the of the same interface, thus giving ways for the designers to explore different communication protocols, having the same interface, by just changing the interface implementation without affecting the module functionality. Defined as member functions in the modules, processes are the basic unit of functionality in SystemC. SC_MODULE methods must be registered, via SC_METHOD or SC_THREAD call, in the scheduler to be considered SystemC blocks.

3. PROPOSED SysML TO SystemC CODE GENERATION

A dedicated survey has been conducted on both commercial and open source UML/SysML editing tools to select the appropriate tool for this research. ARTiSAN Studio, Rhapsody and Telelogic TAU G2 were considered to be used in this research. According to the survey results, and given that Rhapsody has been used in a couple of strong similar researches [18] and [9], Rhapsody 6.1 tool of I-Logix [3] matched our selection criteria.

Many design alternatives were investigated to be able to implement the automatic SystemC code generation from SysML designs:

1. Classic UML model approach

This approach depends on generating XMI model of the Rhapsody design that is based on UML 1.2 notations. Where the UML 2.0 and SysML constructs are represented by stereotypes. The XMI model can then be directly read by one of the template based code generation environments, [2], where appropriate templates should be applied to it to generate user customized SystemC code. The Eclipse fostered project, OpenArchitectureWare [8], has been identified as a candidate environment to perform the code generation step, but unfortunately it OAW wasn’t ready to communicate easily with Rhapsody 6.1 tool.

2. Eclipse UML2 model approach

The Eclipse fostered UML2 project, [17], has created a lightweight complete UML 2.0 data model that is

expected to be adopted as the common data model between most of the UML vendor tools. OpenArchitectureWare can read and generate Eclipse UML2 data model and generate code out of it via templates as well. But unfortunately, Rhapsody 6.1 tool doesn’t generate Eclipse UML2 equivalent models of its designs. So the second approach is to traverse the Rhapsody data model through its API’s and generate the equivalent Eclipse UML2 data model that could be then fed to OpenArchitectureWare to apply the templates for code generation. This approach would have doubled the effort towards generating the SystemC code.

3. Rhapsody API and a visitor based approach

This approach depends on accessing Rhapsody 6.1 data model information through its COM API interface. Rhapsody provides various ways to access its APIs: through Visual Basic, VB scripts, VC++, and Java. Accessing the APIs through VC++ has been selected.

Having accessed Rhapsody SysML design information through its API’s, a visitor based mechanism, [2], has been selected to traverse the SysML design data model, through Rhapsody COM API interface, and generate the appropriate SystemC model for each component.

Although the third approach is heavily dependant on Rhapsody data model and API’s, it has been selected to conduct this research and produce the SystemC models. Yet the system has been designed to separate Rhapsody data model traversal from the code generation to allow for immediate Eclipse-UML2 data model generation in preparation of adopting the second approach to be less dependent on a specific vendor tools. A prototype has been created to show the visibility of the third approach. The prototype is currently able to generate SystemC code for the structure SysML specifications, while work is on going to generate the SystemC code for the behavioral SysML specifications. Aspiring to benefit from the SysML different diagrams in visualizing, designing, documenting and validating the system model no restrictions have been placed on the types of the diagrams that will be translated into SystemC. The implemented prototype also creates a makefile as well as a Microsoft Visual Studio 7.1 project for the generated SystemC code to be able to compile and link the generated SystemC code with the SystemC libraries to produce an executable without the need of the designer manual intervention. In other words the output of the system is a SystemC executable that can be run to validate the whole system, not just a set of SystemC generated files. The automatic generation of this makefile and the Microsoft project files adopts a template based code generation, [2], methodology. Semantically correct transformation between SysML design and SystemC generated models will be validated by testing the SystemC executable and ensuring that it behaves as expected for sample SysML code.



Figure 3 SysML/SystemC Translation Tool

4. Mapping SysML to SystemC

A prototype that has been implemented using one of Rhapsody provided SysML design examples, the Mobile HandSet example. This SysML example has three main blocks: the ConnectionManagementBlock, the MobilityManagementBlock and the DataLinkBlock, in addition to two actors the Mobile unit, MMI, and the Network. Figure 4 shows the high level architecture of the of the Mobile Handset SysML design with its high level blocks and actors. The prototype is able to generate an executable that models both the structure and behavioral diagrams of the SysML design. The generated SystemC executable was run the sequence of events method calls were compared to the expected sequence of events and methods calls listed in the provided sequence diagrams to find them matching. The prototype was run on another SysML design provided by Rhapsody, the Radar system design, and produced also a successful SystemC specification of the design.


Figure 4 High Level Architecture of Mobile HandSet SysML Example provided by Rhapsody tool

The connectivity is done in SystemC via creating internal SystemC channels like the following code snippet shows the generated SystemC code the represents this module.

ConnectionManagementBlock::ConnectionManagementBlock(sc_module_name nm) : sc_module(nm) {
// Channel/Submodule allocations and connectivity
_CallControl = new CallControl("_CallControlInst");
_CallControl->setitsConnection(_Connection);
_CallControl->setitsCallList(_CallList);
_CallControl-> setitsSupplementaryServices(_SupplementaryServices);
_CallControl->setitsSMS(_SMS);
_CallControl->cc_mm(network);
_CallControl->cc_in(call_req);
_CallList = new CallList("_CallListInst");
_CallList->setitsCallControl(_CallControl);
_Connection = new Connection("_ConnectionInst");
_Connection->setitsCallControl(_CallControl);
_SMS = new SMS("_SMSInst");
_SMS->setitsCallControl(_CallControl);
_SupplementaryServices = new SupplementaryServices("_SupplementaryServicesInst");
_SupplementaryServices-> setitsCallControl(_CallControl);
…
}



Figure 5 Connection Management Block Diagram

The connectivity of ports is done through SystemC ports through code like:

_CallControl->cc_mm(network);
_CallControl->cc_in(call_req);

While each sub-module has setter methods to represent the associations between CallControl module and the rest of the modules.

The dynamic behavior of the SysML can be represented in various diagrams: StateMachine, Activity, Sequence, and Use Case diagrams as illustrated in Figure 6. The following figure represents the state machine diagram that specifies the dynamic behavior of the CallControl SysML block. The following code snippet represents the main method that is generated to model the behavior described in the SysML state machine diagram shown above. The transition and state action code in the above figure is written in the SysML action language as specified by Rhapsody. This action language is translated to its equivalent SystemC code. For example the SysML action statement OUT_PORT(cc_mm)->GEN(Disconnect); is translated to cc_mm.write(“Disconnect”); while each SystemC module has a dedicated code to intercept the incoming messages like “Disconnect” and fire an internal event that SystemC block behavior code will act upon.

void CallControl::processStatechartOfCallControloutputs() {
switch(_currentStatechartOfCallControlstate) {
case Active:
// Indicates call is in progress, or is in the process of being set up
_nextStatechartOfCallControlstate.write(ConnectionConfirm);
next_trigger();
// State Active Action
break;
case Connected:
// currently in a voice or data call
if (ConnectionManagement::_eventDisconnect.event() == true) {
_nextStatechartOfCallControlstate.write(Idle);
//Action that will be translated
cc_mm.write("Disconnect");
next_trigger(SC_ZERO_TIME);
next_trigger();
break;
}



Figure 6 State Machine Diagram of CallControl Block

// State Connected Action
_itsCallList->operationaddToCallList();
next_trigger(SC_ZERO_TIME);
_itsConnection->operationaddConnection();
next_trigger(SC_ZERO_TIME);
cc_in.write("ConfirmIndication");
next_trigger(SC_ZERO_TIME);
next_trigger( ConnectionManagement::_eventDisconnect.default_event());
break;
case ConnectionConfirm:
// we are waiting for a connection on the remote parte
if (ConnectionManagement::_eventConnectConfirm.event() == true) {
_nextStatechartOfCallControlstate.write(Connected);
next_trigger();
break;
}

if (timed_out()) {
_nextStatechartOfCallControlstate.write(Idle);
next_trigger();
break;
}

if (ConnectionManagement::_eventDisconnect.event() == true) {
_nextStatechartOfCallControlstate.write(Idle);
//Actions
cc_mm.write("Disconnect");
next_trigger(SC_ZERO_TIME);
next_trigger();
break;
}
// State ConnectionConfirm Action
next_trigger(30000, SC_MS, ConnectionManagement::_eventConnectConfirm.default_event() | ConnectionManagement::_eventDisconnect.default_event());
break;
case Idle:
// Indicates no call in progress
if (ConnectionManagement::_eventPlaceCallReq.event() == true) {
_nextStatechartOfCallControlstate.write(Active);
//Actions
cc_mm.write("PlaceCallReq");
next_trigger(SC_ZERO_TIME);
next_trigger();
break;
}
// State Idle Action
next_trigger( ConnectionManagement::_eventPlaceCallReq.default_event());
break;
}
};

In modeling the SysML Activity diagram, each activity is modeled as a SystemC process while the action language that triggers each activity is translated into the proper SystemC events that control process activation. If all the behavior description of the design is modeled in either the state machine or the activity diagrams, the information that reside in the sequence diagrams is considered redundant and represent another the sequence of events and operations that the design should go through when a specific event is triggered. This redundant information can be used to make sure the overall design is intact and goes through the specified sequence of operations as specified in the set of sequence diagrams. The following figure shows the sequence of events and messages that are generated when placing a call is requested.

The generated SystemC code is simply storing the events and operations called throughout the SystemC design execution in a proper data structure. After the execution, the sequence diagrams events and messages are traversed and compared with the sequence of events and operations produced by running the design. If both sequences map to each other, this will mean that SysML/SystemC design is correct.

5. CONCLUSION

In this research, we have highlighted that the use of UML notation to model and design a system at a very high level has gained a lot of popularity on the recent years. Several UML profiles have been created to help in bridging the gap between the UML notation and System level design. OMG is fostering SysML as a dedicated system level UML 2.0 profile. SystemC represents the natural next level of system abstraction after UML/SysML. SystemC has already become an IEEE standard in late 2005. In this research, a SysML/SystemC model transformation prototype has been created with very promising results. A lot of work has been done before to make use of UML and SystemC to create system level design environment. As far as we know this research is the first dedicated SysML/SystemC model transformation. A study of the SysML/SystemC mapping and a model transformation prototype has been created with very promising results.

6. REFERENCES

[1]Guido Arnout and Dennis Brophy, “SystemC and SystemVerilogDesigning SoC Together”. Presentation given at the Open SystemC Technology Symposium. San Diego, CA. DAC 2004.

[2] Krzysztof Czarnecki and Simon Helsen. “Classification of Model Transformation Approaches”,OOPSLA’03 Workshop on Generative Techniques in the Context of Model-Driven Architecture.

[3] www.ilogix.com

[4] Thorsten Grother, Grant Martin, Stan Liao, Stuart Swan, “System Design with SystemC”. Kluwer Academic Publishers 2002.

[5] Martin, Grant, “SystemC and the Future of Design Languages: Opportunities for Users and Research”, Proceedings of the 16th Symposium on Integrated Circuits and Systems Design (SBCCI ’03), © IEEE 2003.

[6] Stephen Mellor, Balcer M., “Executable UML: A Foundation for Model-Driven Architecture”, Addison-Wesley, 2003.

[7] Stephen Mellor, John Wolfe, Campbell McCausland, “Why Systems-on-Chip needs More UML like a Hole in the Head”, Design, Automation, and Test Conference in Europe, DAC, 2005.

[8] http://www.eclipse.org/gmt/oaw/

[9] Ananda Shankar Basu, Marcello Lajolo, Mauro Prevostini. “A Methodology for Bridging the Gap between UML and Codesign”, UML for SoC Design Book by Kluwer/Springer, 2005.

[10] Riccobene E., Scandurra P., Rosti A. and Bocchio S., “A UML 2.0 Profile for SystemC: Toward Highlevel SoC Design”, 5th ACM international conference on Embedded software, 2005.

[11] Rosenstiel W., Kuhn T., Schweizer T., Winterholer M., Schulz-Key C.. “Object-Oriented Modeling and Synthesis of SystemC Specifications”, © IEEE 2004.

[12] Riccobene E., Scandura P., Rosti A., Bocchio S., “A SoC Design Methodology Involving a UML 2.0 Profile for SystemC”, 5th ACM international conference on Embedded software, 2005.

[13] Michael Butler, Colin Snook “UML-B: Formal modeling and design aided by UML”, ACM Transactions on Software Engineering and Methodology, 2006.

[14] http://www.systemc.org

[15] www.sysml.org

[16] Tan W. H., Thiagarajan P.S., Wong W. F., Zhu Y., Pilakkat S.K., “Synthesizable SystemC Code from UML Models”, RTSS'04, 2004.

[17] http://www.eclipse.org/uml2/

[18] Kathy Dang Nguyen, Zhenxin Sun, P.S. Thiagarajan, Weng-Fai Wong, “Model-driven SoC Design Via Executable UML to SystemC”, RTSS'04, 2004.

[19] Qiang Zhu, Akio Matsuda, Shinya Kuwamura, Tsuneo Nakata, Minoru Shoji. “An Object-Oriented Design Process for System-on-Chip using UML”. In The 15th Int’l Symp. on System Synthesis. Copyright 2002 ACM.

[20] www.itrs.org, International Technology Roadmap for Semiconductors – Design Report - 2005