Download - 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
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
Profils UML pour l’embarquéTrends Towards ModelingUML for Embedded SystemsSysMLElectronic System LevelMARTE
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)
Profiles for SoC ModelingÉ System level
É SysMLÉ MARTE
É Electronic System LevelÉ UML for SoCÉ UML for SystemCÉ others (YAML, UMLSC, ...)
Profils UML pour l’embarquéTrends Towards ModelingUML for Embedded SystemsSysMLElectronic System LevelMARTE
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
Profils UML pour l’embarquéTrends Towards ModelingUML for Embedded SystemsSysMLElectronic System LevelMARTE
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
<<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
StereotypesOperation and Property 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
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
Profils UML pour l’embarquéTrends Towards ModelingUML for Embedded SystemsSysMLElectronic System LevelMARTE
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/
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).
ConclusionÉ SoC modeling: an active research area
É several proposalsÉ at different abstraction levels
É basic constructsÉ composite structure diagram
É hierarchicalÉ component based
É profiles