uml profiles for embedded systems

System-on-Chip DesignUML Profiles

Pierre Boulet – DaRT project-team

Télécom Lille 1 – Septembre 2011

Profils UML pour l’embarquéTrends Towards ModelingUML for Embedded SystemsSysMLElectronic System LevelMARTE

ReuseÉ IP

É IP = Intellectual PropertyÉ HW or SW blockÉ designed for reuseÉ need of standards (VSIA, IP-Xact)

É platform based SoC designÉ organized methodÉ to reduce cost and riskÉ by heavy reuse of HW and SW IPs

É steps in reuseÉ block → IP → integration architecture

Raising the Abstraction LevelÉ ESL (Electronic System Level)

É from RTL to TLM or higherÉ from VHDL to SystemC to UML

É HW/SW co-designÉ need new toolsÉ consider the whole systemÉ large optimization potentialÉ combination of formal, semi-formal and non

formal techniques

Separation of concernsÉ by metamodeling

É metamodel = domain specific languageÉ one metamodel for one goalÉ hide the unneeded details for the task at hand

É allows reuseÉ unavoidable considering the required

productivityÉ at the heart of platform based design

É design team managementÉ each team member has its own viewÉ on shared modelsÉ rely on a common language to ease

communication

AutomationÉ handling the complexity

É habit of the semiconductor industryÉ capitalize the knowledge in the tool

É through model transformationsÉ separation of buisness logic from technologyÉ automatic verification

É tool integrationÉ simulation / test / analysis

É automatic code generation

UML 2.0http://www.uml.org/

É adopted in 2005É superstructure (definition of the diagrams)É infrastrucutre (base classes of UML 2.0 and

MOF 2.0), OCL, diagram exchange formatÉ new features with respect to UML 1.x

É more abstractionÉ clear separation of structure (static) and

behavior (dynamic)É new diagrams: composite structure, activity +

action languageÉ more automation

É more precise semanticsÉ diagram exchange format (XMI 2.0)

http://www.uml.org/

Profiles for SoC ModelingÉ System level

É SysMLÉ MARTE

É Electronic System LevelÉ UML for SoCÉ UML for SystemCÉ others (YAML, UMLSC, ...)

SysMLÉ system engineering modeling language

É domain specific (SysML) vs general purpose(UML)

É remove the software bias from UMLÉ remove part of UMLÉ add system specific constructs

É as a UML profile

SysML Diagrams (1/2)

OMG SysMLTM Adopted Specification 11

SysML stereotypes define new modeling constructs by extending existing UML 2.1 constructs with new properties and constraints. SysML diagram extensions define new diagram notations that supplement diagram notations reused from UML 2.1. SysML model libraries describe specialized model elements that are available for reuse. Additional non- normative extensions are included in Annex C: Non-normative Extensions.

The SysML user model is created by instantiating the metaclasses and applying the stereotypes specified in the SysML profile and subclassing the model elements in the SysML model library. Chapter 17, “Profiles & Model Libraries” describes how profiles and model libraries are applied and how they can be used to further extend SysML.

4.4 SysML Diagrams

The SysML diagram taxonomy is shown in Figure 4.4. The concrete syntax (notation) for the diagrams along with the corresponding specification of the UML extensions is described in Parts II - IV of this specification. The Diagram Annex A describes generalized features of diagrams, such as their frames and headings.

Figure 4.4 - SysML Diagram Taxonomy

SysMLDiagram

StructureD iagram

BehaviorD iagram

Use CaseDiagram

ActivityDiagram

Internal BlockDiagram

Block DefinitionDiagram

SequenceDiagram

State MachineDiagram

ParametricDiagram

Requirem entDiagram

Modified from UML 2

New diagram type

Package Diagram

Same as UML 2

SysML Diagrams (2/2)

OMG SysMLTM Adopted Specification 11

SysML stereotypes define new modeling constructs by extending existing UML 2.1 constructs with new properties and constraints. SysML diagram extensions define new diagram notations that supplement diagram notations reused from UML 2.1. SysML model libraries describe specialized model elements that are available for reuse. Additional non- normative extensions are included in Annex C: Non-normative Extensions.

The SysML user model is created by instantiating the metaclasses and applying the stereotypes specified in the SysML profile and subclassing the model elements in the SysML model library. Chapter 17, “Profiles & Model Libraries” describes how profiles and model libraries are applied and how they can be used to further extend SysML.

4.4 SysML Diagrams

The SysML diagram taxonomy is shown in Figure 4.4. The concrete syntax (notation) for the diagrams along with the corresponding specification of the UML extensions is described in Parts II - IV of this specification. The Diagram Annex A describes generalized features of diagrams, such as their frames and headings.

Figure 4.4 - SysML Diagram Taxonomy

SysMLDiagram

StructureD iagram

BehaviorD iagram

Use CaseDiagram

ActivityDiagram

Internal BlockDiagram

Block DefinitionDiagram

SequenceDiagram

State MachineDiagram

ParametricDiagram

Requirem entDiagram

Modified from UML 2

New diagram type

Package Diagram

Same as UML 2

UML for SoCÉ concepts very close to SystemC

É allow automatic SystemC skeleton codegeneration

É abstraction levelÉ from transactional level modeling (TLM)É to register transfer level (RTL)

É mainly uses the composite structure diagram

StereotypesStructural Modeling

2004/10/26 21:16

3

<<metaclass>>Class

<<stereotype>>SoCModule

<< profile >>

SoC

<<stereotype>>Data

<<stereotype>>Controller

<<stereotype>>SoCPort

<<stereotype>>SoCChannel

<<stereotype>>

SoCClock

<<stereotype>>

SoCReset

<<stereotype>>SoCClockChannel

<<stereotype>>SoCResetChannel

<<stereotype>>SoCInterface

<<stereotype>>SoCConnector

<<stereotype>>SoCProtocol

<<stereotype>>

SoCProcess

<<metaclass>>Interface

<<metaclass>>Connector

<<metaclass>>Collaboration

<<metaclass>>

Operat ion

<<metaclass>>Port

direction : direct ionKindmaxProcesses : UnlimitedNaturalmaxChannels : UnlimitedNatural = 1

transportMethod : transportBy

<< enumerat ion >>transportBy

Copy

Pointer

<< enumerat ion >>directionKind

INPUTOUTPUT

/ isPrimitive : Boolean

connectIndex : OpaqueExpression

clockDomain : String

clockDomain : String resetSpec : String

resetSpec : String

<< metaclass >>Property

<< stereotype >>SoCModuleProperty

<< stereotype >>SoCChannelProperty

baseClass

basePort

baseCollaboration

baseInterface

baseConnector

baseOperation

baseClass

baseClass

baseClass

baseProperty

<< metaclass >>Dependency

<< stereotype >>SoCDataType

baseDependency

baseProperty

Fig. 1 SoC Profile Stereotypes

StereotypesCommunication Modeling

2004/10/26 21:16

3

<<metaclass>>Class


<< profile >>

SoC

<<stereotype>>Data




<<stereotype>>

SoCClock

<<stereotype>>

SoCReset






<<stereotype>>

SoCProcess




<<metaclass>>

Operat ion

<<metaclass>>Port




Copy

Pointer


INPUTOUTPUT





resetSpec : String




baseClass

basePort

baseCollaboration

baseInterface

baseConnector

baseOperation

baseClass

baseClass

baseClass

baseProperty



baseDependency

baseProperty


StereotypesOperation and Property Modeling

2004/10/26 21:16

3

<<metaclass>>Class


<< profile >>

SoC

<<stereotype>>Data




<<stereotype>>

SoCClock

<<stereotype>>

SoCReset






<<stereotype>>

SoCProcess




<<metaclass>>

Operat ion

<<metaclass>>Port




Copy

Pointer


INPUTOUTPUT





resetSpec : String




baseClass

basePort

baseCollaboration

baseInterface

baseConnector

baseOperation

baseClass

baseClass

baseClass

baseProperty



baseDependency

baseProperty


Example: Communication by FIFOStructure Diagram2004/10/26 20:52

5

fifo:sc_fifo<data2>

port name : ininterface direction : input

protocol interface name : sc_fifo_in_if<data1>

class name : parent

process function :

class name : child1

instance name : func1

process function : entry

port name : out

interface direction : out

protocol interface name : sc_fifo_out_if<data2>

class name : child2

instance name : func2process function : entry

port name : in

interface direction : inprotocol interface name : sc_fifo_in_if<data2>

port name : out

interface direction : output

protocol interface name : sc_fifo_out_if<data3>

init ialization parameter : 0

Fig. 17 Structure diagram and attribute of each object, tagged value

The channel is described in the UML diagram as shown below. Here the FIFO channel of SystemC

(sc_fifo) is used as a channel with buffer size = 16 (default value of sc_fifo class). The buffer size is given

as an initialization parameter at the instantiation of the channel. (In the figure below, attributes, and/or

template arguments of buffer size are not shown.)

sc_interface

<<SocInterface>>

sc_fifo_in_if

{direction=INPUT}

T

<<SocInterface>>

sc_fifo_out_if

{direction=OUTPUT}

T

<<SocChannel>>

sc_fifo

T

Fig. 18 FIFO Protocol Interface and Channel

The generated SystemC source code from the UML diagram above is shown below. Please note that the

user specified portion and the portion automatically generated using the tool are not distinguished here

using comments. And also, the include statements which usually exists in the header file are ommited.

(parent.h)

#include "child1.h"

#include "child2.h"

#include "data_type_data1.h"

#include "data_type_data2.h"

Example: Clock and ResetStructure Diagram

Example: Shift RegisterStructure Diagram2004/10/26 20:52

13

ShiftReg

I O

M : reg[N]

C : sc_fifo<int> [N- 1]

N : int

I O

inv: N > 1

inv: M[0].I.sc_fifo_in_if<int>- >exists(I) - - (a)

inv: Sequence{ 1..N- 1 }- >forAll(n | M[n].I.sc_fifo<int>- >exists(C[n])) - - (b)

inv: Sequence{ 0..N- 2 }- >forAll(n | M[n].O.sc_fifo<int>- >exists(C[n]) - - (c)

inv: M[N- 1].O.sc_fifo_out_if<int>- >exists(O) - - (d)

(a)

(b)

(c)

(d)

Fig.24 Example of template module

The SystemC description corresponding to the diagram is shown below, (note that include statements or

any declarations, that is required but not relevant to the explanation of the notation, are abbreviated).

template <int N>

struct ShiftReg : public sc_module {

sc_port< sc_fifo_in_if<int> > I;

sc_port< sc_fifo_out_if<int> > O;

reg *M[N];

sc_fifo<int> *C[N-1];

ShiftReg(sc_module_name name) : sc_module(name) {

assert(N>0);

for (int i = 0; i < N; i++) {

stringstream regname;

regname << "reg[" << i << "]";

M[i] = new reg(regname.str().c_str());

}

for (int i = 0; i < N-1; i++) {

C[i] = new sc_fifo<int>;

}

for (int i = 0; i < N; i++) {

if (i == 0) {

M[i]->I(I);

}

if (i > 0) {

M[i]->I(*C[i-1]);

}

for (int i = 0; i < N; i++) {

UML for SystemCÉ allow to generate complete SystemC code

É expose all SystemC concepts in the UML profileÉ structure (similar to UML for SoC profile)É behaviour (actions in state machines)

É tool specific implementationÉ takes advantage of the tool’s code generation

capacity

Modeling and Analysis of Real-Timeand Embedded systems

Request for ProposalÉ http://www.omg.org/cgi-bin/

doc?realtime/2005-2-6É published February 2005

Current statusÉ Version 1.0 available since November 2009É http://www.omg.org/spec/MARTE/

http://www.omg.org/cgi-bin/doc?realtime/2005-2-6

http://www.omg.org/cgi-bin/doc?realtime/2005-2-6

http://www.omg.org/spec/MARTE/

RequirementsÉ Scheduling, Performance and Time profile

evolutionÉ designed for UML 1.xÉ influence of the QoS and Fault Tolerance profile

É Real-Time and Embedded System modelingÉ embedded system programming

É limited resources, subject to constraints,heterogeneity, distributed

É reactivityÉ cyclic behaviour, modes of operation

É control/commandÉ intensive data flow

É systematic signal processingÉ intensive data processing

RTES Specific NeedsÉ standard language

É to ease communication in the design teamÉ common paradigm for hardware and software

modelingÉ Y-model approach (application, hardware

architecture, allocation)É Model Driven Engineering

É time modelingÉ asynchronous/causalÉ synchronous/clockedÉ real/continuous

Schedulability and PerformanceAnalysis

É rich set of measuresÉ response time, delays, resource utilisation,

demandÉ statistical measures or bounds

É schedulability analysisÉ WCET, ACET, BCET

É need for variables and expressionmanipulation (see SPT)

Current Version

See the official tutorial(http://www.omgmarte.org/Tutorial.htm).

http://www.omgmarte.org/Tutorial.htm

ConclusionÉ SoC modeling: an active research area

É several proposalsÉ at different abstraction levels

É basic constructsÉ composite structure diagram

É hierarchicalÉ component based

É profiles

uml profiles for embedded systems

Education

prols uml

soc uml

uml extensions

sysml diagrams

sysml diagram taxonomy

system specic constructsas

diagram annexms

new diagram type figure