UML and SystemC

Their Roles in SoC Codesign

Pao-Ann Hsiung
Department of Computer Science & Info. Eng.
National Chung Cheng University
Chiayi, Taiwan, ROC.
http://www.cs.ccu.edu.tw/~pahsiung/

SoC Design Flow and Tools, March 2005 1

Contents

„ Introduction
„ UML/SystemC-based SoC Codesign Flows
‰ UML Extension-based Design Flows (x 5)
‰ UML Profile-based Design Flows (x 1)
‰ Platform Model-based Design Flows (x 2)
„ Conclusions
„ References

2
Contents

„ Introduction
„ UML/SystemC-based SoC Codesign Flows
‰ UML Extension-based Design Flows (x 5)
‰ UML Profile-based Design Flows (x 1)
‰ Platform Model-based Design Flows (x 2)
„ Conclusions
„ References

3
Introduction

„ Unified Modeling Language (UML)

‰ An industry standard
‰ Driven by OMG “www.omg.org”
‰ Widely adopted by Software Engineers
‰ Currently still version 1.5
‰ Version 2.0
„ Lots of enhancements
‰ Especially for system-level design
ƒ deployment,
ƒ timing,
ƒ sequence diagram control flow,

4
Introduction

„ UML was considered for system design by

Cadence in 1999
‰ However, it was a consensus then that UML was
insufficient for system design
‰ Nevertheless, now UML 2.0 is much more
enhanced for system design
‰ Several design companies have already adopted
UML in their SoC hw-sw codesign flows
„ STMicroelectronics, Fujitsu, NEC, Alcatel, IBM, etc.

5
Why UML? Why SystemC?

„ There is a rapidly growing trend of using

‰ UML as a system-level design language, and
‰ SystemC as a system-level implementation
language
„ Why UML?
‰ Platform independent,
‰ Implementation independent,
‰ Customizable for any application domain,
‰ Easily extensible (stereotypes, profiles, tags, etc.)

6
Why UML? Why SystemC?

„ Why SystemC?
‰ Can implement HW and SW and interfaces
‰ Multiple abstraction levels
‰ Executable (directly simulatable)
‰ Reuse of large base of C/C++ reference
implementations (JPEG, MPEG, …)
‰ Synthesizable
„ Under some restrictions
‰ Synopsys System Studio

7
UML versus SystemC?

„ UML vs. SystemC

‰ Users need to only deal with UML diagrams
„ SystemC code can be generated (semi-)automatically
‰ A high-level view of everything
„ Simulation, step-by-step debugging
„ Makes complex system designs more manageable
‰ UML is a platform independent language
‰ System is a platform specific language
‰ Facilitates transaction-level modeling (TLM)
„ Accelerated functional and performance evaluations

8
UML versus SystemC

2.1 2.0

Overlap of Concepts between SystemC and UML 2.0

9
Contents

„ Introduction
„ UML/SystemC-based SoC Codesign Flows
‰ UML Extension-based Design Flows (x 5)
‰ UML Profile-based Design Flows (x 1)
‰ Platform Model-based Design Flows (x 2)
„ Conclusions
„ References

10
UML/SystemC-based
SoC Codesign Flows
„ Several design flows have been proposed by
several different organizations and research
results
„ Our classification
‰ UML Extension-based Design Flow
„ NUS, NEC (ACES), Alcatel (OWL), Fujitsu (SLOOP)
‰ UML Profile-based Design Flow
„ STMicro, Fujitsu, U.Catania (Italy)
‰ Platform Model-based Design Flow
„ INRIA (Gaspard2, France), U. Applied Sci Mittweida,
Freiberg U. (MOCCA, Germany)

11
Contents

„ Introduction
„ UML/SystemC-based SoC Codesign Flows
‰ UML Extension-based Design Flows (x 5)
‰ UML Profile-based Design Flows (x 1)
‰ Platform Model-based Design Flows (x 2)
„ Conclusions
„ References

12
UML Extension-based Design Flows

„ Some UML diagrams are chosen as system

input models
‰ Class, Statechart, Sequence, Collaboration, …
„ Extensions defined as stereotypes
‰ Mainly modeling the functional and timing
constructs in SystemC
„ System modeled using the Extended UML
„ UML models mapped to SystemC code
‰ Automatic generation of code
13
UML Ext-based Flow (1)
Models Used:
NUS • Class Diagram
Version • Statecharts
(1)
Tools Used:
• Rhapsody
• Velocity
• Synopsys
System Studio

NUS: RTSS’2004, uSoC’2004, ASPDAC’2005 14

UML Ext-based Flow (1)

„ Class Diagram

15
UML Ext-based Flow (1)

„ Statechart

16
UML Ext-based Flow (1)
„ SystemC Block Diagram

17
UML Ext-based Flow (1)

„ Generated SystemC complies with the

Synopsys SystemC compiler restrictions,
hence is synthesizable
„ The input UML is translated into SystemC
code and then the SystemC code is
synthesized

18
UML Ext-based Flow (2)
Models Used:
NUS • Class Diagram
Version • Statecharts
(2) • Structure Diag.

Tools Used:
• Rose RT
• RT2SystemC
• Synopsys
System Studio
NUS: RTSS’2004, uSoC’2004, ASPDAC’2005 19
 U. Lugano
UML Ext-based Flow (3) NEC

20
UML Ext-based Flow (3) Functional
Specification

21
UML Ext-based Flow (3)

„ Models used
‰ Object Model Diagram
‰ State Diagram
‰ Sequence Diagram
„ Tools used
‰ front-end tools (self-developed)
„ Rhapsody
„ Translator, Code Generator
‰ Back-end tools
„ CYBER, CysimGen, Classmate, C compiler

22
UML Ext-based Flow (3)
„ Object Model Diagram

HW-SW
Partitioning

23
UML Ext-based Flow (3)
„ State Diagram for Module AveControl

24
UML Ext-based Flow (3)
„ Sequence Diagram

25
UML Ext-based Flow (3)

26
UML Ext-based Flow (4)

„ OWL (OFDM Wireless LAN) Project

‰ Wireless LAN chipset
„ Orthogonal Frequency Division Multiplexing (OFDM)
modulation technique
„ Models used
‰ Vision Document, Class, Sequence diagrams
„ Tools used
‰ Matlab, Rational Unified Process, …

27
UML Ext-based Flow (4)

„ OWL Project Iterations

28
UML Ext-based Flow (4)

„ Using Matlab as test data I/O for SystemC

models

29
UML Ext-based Flow (5)
„ SLOOP (System-Level design with OO Process)

SLOOP employs
four models to
develop SoC
incrementally
before software
and hardware
implementation

30
UML Ext-based Flow (5) 4 Models
used in
SLOOP
„ Conceptual Model
‰ To grasp functional and nonfunctional
requirements
„ Functional Model
‰ Computation and communication workloads
„ Architectural Model
‰ Processing and communication resources
„ Performance Model
‰ Maps: process Æ processing resources,
communication Æ communication resources
31
UML Ext-based Flow (5)
Realizing each model
„ Modeling phase: specifies results of analysis and
design using UML
„ Implementation phase: implements the UML model
into C++/SystemC as an executable model

32
UML Ext-based Flow (5)

„ Tools used:
‰ ObjecTime ROOM
‰ Rose RT
„ UML Extensions
‰ Module
‰ Port
‰ Interface
‰ Channel

33
UML Ext-based Flow (5) — A Case Study

Application of the SLOOP design process

to an image decoding system

34
 Conceptual Model

„ Use case diagrams

‰ Boundary of target
system
‰ Associate the external
stimulus actors
„ Class diagrams
‰ Describe the data
structure
„ Sequence diagrams
‰ Represent scenarios of
use case

35
Functional Model

36
Executable Functional Model

„ The functional model is also implemented

with SystemC as an executable model
„ The computation workload and
communication workload
‰ Obtained by execution of the functional model
‰ Help designer to decide the initial parameters of
the architectural model

37
Computation Workload and
Communication Workload

38
Architectural Model
„ Modeled using deployment diagram of UML

39
Performance Model

40
Performance Model (Cont.)

„ Map the functional model onto the

architectural model
„ Implementation of the performance model
with SystemC
‰ Obtain the performance evaluation results
‰ Satisfied the performance requirement or not
‰ Bottleneck analysis can help us to improve the
selected architecture

41
Performance Evaluation Metric

„ Performance metric
=> Throughput (frames per second)

„ Requirement of performance
=> 30 frames per second

42
Experiment 1

„ ‘decoder’ & ‘compositor’ => processor

„ Other modules => hardware components
„ The communication channel
=> realized with RAM and bus
„ Simulation results:
‰ Throughput = 12 frames per second
‰ Bus utilization = 57%

Throughput well below the requirement !

43
Utilizations of Modules in Experiment 1

44
Utilization of Channels in Experiment 1

45
Experiment 2

„ Remove the module ‘decoder’ from processor

=>Map it onto a new hardware component
„ Evaluated this modified architecture in order to see
how the performance had changed
„ Simulation results:
‰ Throughput = 24 frames per second
‰ Bus utilization = 73%

The bus was the bottleneck !

46
Experiment 3

„ Connected ‘decoder’, ‘huffmandecoder’, and

‘iq’ directly without utilizing bus
„ Expand the bus width to 64 bits
„ Simulation results:
‰ Throughput = 30 frames per second
‰ Bus utilization is 50%

Decided to select this architecture for implementation!

47
Contents

„ Introduction
„ UML/SystemC-based SoC Codesign Flows
‰ UML Extension-based Design Flows (x 5)
‰ UML Profile-based Design Flows (x 1)
‰ Platform Model-based Design Flows (x 2)
„ Conclusions
„ References

48
UML Profile-based Design Flow

„ Bridging the gap between UML and SystemC

Approach 1: reverse engineer Approach 2: define a UML
SystemC libraries to create a profile to capture central
library of classes that can be used SystemC constructs – module,
when modeling – does not take process, port–interface,
advantage of UML graphical channel, event
capabilities

49
UML Profile-based Design Flow
Defining a SystemC Profile in UML
•UML lacks a set of Provide stereotypes for the
predefined data types– most commonly used
reuse the ones from constructs–«module»,
SystemC (and C++) – «process», «port»
define your own datatypes

50
 UML Profile-based Design Flow
A Simple Example
int sc_main(int, char*[]) {
// declare channel
sc_fifo<int> fifo(10);
// instantiate blocks
writer w(”writer”);
reader r(”reader”);
// connect to channel
w.out (fifo);
r.in (fifo);

sc_start(-1); // run forever

return 0;
}

51
UML Profile-based Design Flow

„ A SystemC Metamodel

WiSME’2004, DATE’2005 52
UML Profile-based Design Flow

„ 4 Parts in a SystemC Profile

‰ Structure and Communication
„ UML stereotypes for SystemC Core Layer structures
‰ modules, ports, interfaces, channels
‰ Data Types
„ UML classes for SystemC data types
‰ Behavior and Synchronization
„ UML stereotypes of SystemC Core Layer behavior
‰ Predefined Channels, Interfaces, Ports
„ Library model or profile

WiSME’2004, DATE’2005 53
UML Profile-based Design Flow

„ SystemC Profile Architecture

WiSME’2004, DATE’2005 54
55
56
Conventional SoC Design Flow

WiSME’2004, DATE’2005 57
UML Profile-based Design Flow

WiSME’2004, DATE’2005 58
UML Profile-based Design Flow

„ A simple communication modeling example

‰ From SystemC 2.0 package
„ Producer module
„ Consumer module
„ FIFO channel
‰ write_if (blocking write)
„ write(char)
„ reset()
‰ read_if (blocking read)
„ read(char&)
„ num_available()

WiSME’2004, DATE’2005 59
UML Profile-based Design Flow
class write_if : virtual public sc_interface {
public:
virtual void write(char) = 0;
virtual void reset() = 0; };
class read_if : virtual public sc_interface {
public:
virtual void read(char &) = 0;
virtual int num_available() = 0; };

read_write_if.h 60
UML Profile-based Design Flow
#include "read_write_if.h"
class producer: public sc_module {
public:
sc_port<write_if> out;
void main();
SC_HAS_PROCESS(producer);
producer(sc_module_name mn): sc_module(mn)
{ SC_THREAD(main); } };

producer.h

61
UML Profile-based Design Flow
#include "producer.h"
void producer::main() {
const char *c = "Visit www.systemc.org\n";
out->reset();
while (*c)
out->write(*c++); }

producer.cpp

62
UML Profile-based Design Flow
// file fifo.h
#include "read_write_if.h"
class fifo : public sc_channel, public write_if,
public read_if {
public:
fifo(sc_module_name mn): sc_channel(mn) {
num_elements = first = 0; }
void write(char);
void reset();
void read(char&);
int num_available();
private:
enum e { max = 10 };
char data[max];
int num_elements, first;
sc_event write_event, read_event;
};

fifo.h 63
 UML Profile-based Design Flow
// file fifo.cpp
#include "fifo.h"
void fifo::write(char c) {
if(num_elements == max)
wait(read_event);
data[(first+num_elements)%max] = c;
++ num_elements;
write_event.notify(); }
void fifo::read(char& c){
if(num_elements == 0)
wait(write_event);
c = data[first];
-- num_elements;
first = (first + 1) % max;
read_event.notify(); }
void fifo::reset() { num_elements = first = 0; }
int fifo::num_available() { return num_elements;}

fifo.cpp 64
UML Profile-based Design Flow
class top: public sc_module
{
public:
top.cpp fifo * fifo_inst; //a fifo instance
producer * producer_inst; //a producer instance
consumer * consumer_inst; //a consumer instance
top(sc_module_name mn):sc_module(mn) {
fifo_inst = new fifo("Fifo1");
producer_inst= new producer("Producer1");
consumer_inst= new consumer("Consumer1");
producer_inst->out(*fifo_inst);
consumer_inst->in(*fifo_inst);
}
};

65
Contents

„ Introduction
„ UML/SystemC-based SoC Codesign Flows
‰ UML Extension-based Design Flows (x 5)
‰ UML Profile-based Design Flows (x 1)
‰ Platform Model-based Design Flows (x 2)
„ Conclusions
„ References

66
Platform Model-based Design Flow

67
Platform Model-based Design Flow

Y-Model
& TLM
& RTL

INRIA DART

68
Application PIM

„ UML 2 Component based

‰ Component models some computation
‰ Ports model input and output capabilities
„ Three kinds of components
‰ Compound component
„ Task parallelism as a dependency graph
‰ Data parallel component
„ Potential concurrent computations
‰ Elementary component
„ Basic computation unit
„ May be implemented by an IP
„ Hierarchical description
69
Application Metamodel

70
Application PIM Example

71
Hardware Architecture PIM

72
HW Architecture PIM
(Classification Refinement)

73
HW Architecture PIM: Example

74
HW Architecture PIM:
Repetitive Component Example

75
Association PIM

76
Model to Model Transformation

„ Transformer from the INRIA DART group

‰ http://www.lifl.fr/west/mdaTransf
‰ Open source and customizable
‰ Others can use it, improve it, provide other rule
representation, …
‰ Takes into account the remarks on OMG-QVT
proposals

77
Model to Model Transformation

ISP = Intensive Signal Processing (a project by INRIA DART) 78

Platform Model-based Design Flow

„ The INRIA DART group used the following

development tools
„ Models
‰ UML 2 tool (Tau G2)
„ Visual tool for development
‰ Eclipse plugin (home made):
„ from models to code generation
„ Model to model transformation
(Code generation)
‰ MDA Transf
79
Platform Model-based Design Flow

Gaspard2:
An IDE for
SoC visual
co-modeling

(INRIA
DART)

80
 Platform Model-based Design Flow (RTR)

„ Model of Reconfigurable HW Architecture for

RTR systems used by MOCCA team

RTR = Run-Time Reconfigurable

MOCCA = Model Compiler for reConfigurable Architectures
MOCCA: FDL’2003, uSoC’2004, MoDES’2004 81
Platform Model-based Design Flow (RTR)

82
MOCCA: FDL’2003, uSoC’2004, MoDES’2004
Platform Model-based Design Flow (RTR)

„ Relationships among the models

83
MOCCA
„ UML 2.0 Model Compiler
„ Automated transition from platform
independent application design to
platform specific implementation
„ Automated Design Partitioning
‰ Support for partially or completely
manually specified partitioning
‰ Estimation of Execution and
Implementation characteristics
„ Type and Message Analysis
„ Scheduling, Allocation, Binding
„ Branch Prediction
„ Automated Synthesis of Platform
Dependent Implementation
„ RTR-Manager and Broker
84
Contents

„ Introduction
„ UML/SystemC-based SoC Codesign Flows
‰ UML Extension-based Design Flows (x 5)
‰ UML Profile-based Design Flows (x 1)
‰ Platform Model-based Design Flows (x 2)
„ Conclusions
„ References

85
Conclusions

„ Before UML 2.0, there were several

extensions of UML for SystemC modeling
and MDA design flow
„ Now, we have
‰ “profiles”
‰ “platform models”
‰ “model compilers,” “model transformers,” …
„ UML models are “SYNTHESIZED” into HW!!!

86
Contents

„ Introduction
„ UML/SystemC-based SoC Codesign Flows
‰ UML Extension-based Design Flows (x 5)
‰ UML Profile-based Design Flows (x 1)
‰ Platform Model-based Design Flows (x 2)
„ Conclusions
„ References

87
References (Ext-based, NUS)

„ K. D. Nguyen, Z. Sun, P.S. Thiagarajan, “Model-

driven SoC Design Via Executable UML to
SystemC,” 25th IEEE International Real-Time
Systems Symposium (RTSS), pp. 459-468,
December 2004.
„ W.H. Tan, P.S. Thiagarajan, W.F. Wong, Y. Zhu,
and S.K. Pilakkat, “Synthesizable SystemC Code
from UML Models,” International Workshop on UML
for SoC Design (uSoC), DAC’2004 workshop, USA.
„ Z. Sun, W.-F. Wong, Y. Zhu, S.K. Pilakkat, “Design
of Clocked Circuits Using UML,” Asia & South
Pacific Design Automation Conference (ASPDAC),
pp. 901-904, January 2005.

88
 References (Ext-based, ACES, OWL,
SLOOP)
„ M. Lajolo, NEC Laboratories, USA, M. Prevostini, University of
Lugano, Switzerland, “UML in an Electronic System Level Design
ACES Methodology,” International Workshop on UML for SoC Design
(uSoC), DAC’2004 workshop, USA.
„ Y. Vanderperren, G. Sonck, P. van Oostende, M. Pauwels, W.
Dehaene, T. Moore, “A Design Methodology for the Development
OWL of a Complex SoC using UML and Executable System Models,”
Forum on Specification and Design Languages (FDL), Marseille,
France, September 2002.
„ Q. Zhu, A. Matsuda, M. Shoji, “An Object-Oriented Design
Process for System-on-Chip using UML,” 15th International
Symposium on System Synthesis (ISSS), Kyoto, Japan, October
2002.
SLOOP

89
References (Profile-based, Italy, STM)

„ E. Riccobene, A. Rosti, P. Scandurra,

“Improving SoC Design Flow by means of
MDA and UML Profiles,” 3rd Workshop on
Software Model Engineering (WiSME)@UML,
October 2004.
„ E. Riccobene, P. Scandurra, A. Rosti, S.
Bocchio, “A SoC Design Methodology
Involving a UML 2.0 Profile for SystemC,”
Design Automation and Test Europe (DATE),
March 2005 (to appear).

90
 References (Platform-based, INRIA,
MOCCA)
„ P. Boulet, A. Cuccurru, J.-L. Dekeyser, C. Domoulin, P. Marquet, M.
Samyn, R. De Simone, G. Siegel, T. Saunier, “MDA for SoC Design:
INRIA UML to SystemC Experiment,” International Workshop on UML for
SoC Design (uSoC), June 2004.
„ T. Beierlein, D. Fröhlich, B. Steinbach, “UML-based Co-design for
Run-Time Reconfigurable Architectures,” Forum on Specification
and Design Languages (FDL), Germany, September 2003.
„ T. Beierlein, D. Fröhlich, B. Steinbach, “UML-Based Development of
Applications for Run-Time Reconfigurable Architectures,”
International Workshop on UML for SoC Design (uSoC), June 2004.
„ T. Beierlein, D. Fröhlich, B. Steinbach, “Model-Driven Compilation of
UML-Models for Reconfigurable Architectures,” 2nd RTAS
Workshop on Model-Driven Embedded Systems (MoDES), Toronto,
Canada, May 2004.
MOCCA

91
Links

„ OMG http://www.omg.org (for UML)

„ SystemC http://www.systemc.org
„ A UML SoC Workshop sponsored by DAC
2004 (presentations available)
‰ http://www.c-lab.de/uml-soc/uml-soc04/
„ INRIA DART
‰ http://www.inria.fr/recherche/equipes/dart.en.html
„ MDA Transf
‰ http://www.lifl.fr/~dumoulin/mdaTransf/

92