UML-SoC 2005

DAC 2005 Workshop
UML-SoC 2005
UML for SoC Design
Anaheim Convention Center
Anaheim, CA, USA
June 12, 2005
edited by:
Luciano Lavagno, Politecnico di Torino, Italy
Wolfgang Mueller, Paderborn University, Germany
UML for SoC Design
Table of Contents
Welcome Address from the Organizers ___________________________________III
I. Keynote Address
SysML and Systems Engineering Applied to UML-Based SoC Design ___________1
Y. Vanderperren, W. Dehaene, KU Leuven, Belgium
II: Emerging OMG Profiles for SoCs and Embedded Systems
UML Profile for System-on-Chip (SoC)____________________________________9
S. Rajan, Fujitsu Laboratories of America, USA,
T. Hasegawa, M. Shoji, Q. Zhu, N. Tsuneo, Fujitsu Limited, Japan
MARTE: A New OMG Profile RFP for the Modeling and Analysis of
Real-Time Embedded Systems _________________________________________16
Ch. André1, S. Cuccuru2, J.-L. Dekeyser2, R. De Simone1, C. Dumoulin2,
J. Forget3, Th. Gautier3, S. Gérard4, F. Mallet1, A. Radermacher4,
L. Rioux5, Th. Saunier5, Y. Sorel1,
1
INRIA/I3S, 2INRIA/LIFL, 3INRIA, 4CEA–LIST, 5Thales, France
III. Synthesis and Execution of UML Models
Interface Problems: What We Have Here is a Failure to Communicate __________21
S. Mellor, J.R. Wolfe, C. McCausland, Mentor Graphics, USA
Synthesis of UML-Models for Reconfigurable Hardware ____________________24
Ch. Dorotska, B. Steinbach, D. Fröhlich,
Technische Universität Freiberg, Germany
Using UML Activities for Synthesis on Reconfigurable Hardware _____________30
T. Schattkowsky, J.H. Hausmann, A. Rettberg,
Paderborn University, Germany
IV. Models of Computation for SoC Design
On the Integration of UML Sequence Diagrams and Actor-Oriented
Simulation Models ___________________________________________________34
L.S. Indrusiak, A. Thuy, M. Glesner, TU Darmstadt, Germany
UML Based Modelling of Process Classes for System Level Design ____________37
A. Goel, K.D. Nguyen, A. Roychoudhury, P.S. Thiagarajan,
University of Singapore, Singapore
DAC Workshop, Anaheim, June 12, 2005
I
II
UML for SoC Design
V. HW/SW Design Methodologies
Design and Synthesis of Reusable Platforms with Programmable
Interconnects________________________________________________________43
A.S. Basu, M. Lajolo, NEC Laboratories, USA,
M. Prevostini, AlaRI, University of Lugano, Switzerland
A SoC Design Flow Based on UML 2.0 and SystemC _______________________49
S. Bocchio, STMicroelectronics, E. Riccobene, Università di Milano,
A. Rosti, STMicroelectronics, P. Scandurra, Università di Catania, Italy
VI. Performance Analysis Based on Abstract UML Modeling
Performance Analysis of Sequence Diagrams for SoC Design _________________55
A. Viehl, O. Bringmann, FZI Karlsruhe,
W. Rosenstiel, University of Tübingen, Germany
Embedded SW Design Exploration Using UML-based Estimation Tools ________62
M.F. da S. Oliveira, L. Brisolara, F.R. Wagner, L. Carro,
Federal University of Rio Grande do Sul (UFRGS), Brazil
DAC Workshop, Anaheim, June 12, 2005
UML for SoC Design
Welcome Address from the Organizers
UML 2.0 was finally adopted as an OMG standard in March 2005. Meanwhile it
already received significant interest by a steadily increasing number of industrial and
academic groups from the EDA, embedded software and hardware systems. We
observe that design communities around the world have already started to apply it to
System-on-Chip (SoC) designs through the last years. After the successful first SoC
Design workshop at DAC 2004, this second workshop aims in continuing to be a
forum to coordinate UML efforts, to initiate discussions, and to exchange
experiences and information between the various groups in the SoC community.
We received many interesting submissions from Asia, Europe, and North and South
America again, out of which we have selected the program. An invited contribution
presents the SysML profile and its application to systems engineering. Other selected
contributions present System-on-Chip design with reference to the SoC profile and
the upcoming MARTE profile; Models of Computation for SoC; performance
analysis using abstract UML models; and HW/SW interface and reconfigurable
system modeling with UML. We think that the selected presentations give a
representative overview of current UML activities in SoC design and will lead to
many fruitful discussions during the workshop. We hope that the workshop will
identify some undiscovered existing solutions and future challenges in UML tools,
applications to SoC design, and general hardware-related and embedded software
aspects.
Hereby, we would like to thank the Design Automation Conference, which accepted
this UML workshop to be held in conjunction with DAC 2005 in Anaheim, which
provided us with the organizational infrastructure. In particular, we acknowledge
Ellen Sentovich, Regina Pistilli, and Kathy MacLennan for all their support and help.
Special thanks go to Nanette V. Collins (NVC Marketing & Public Relations) who
volunteered as a publicity chair for this workshop.
Luciano Lavagno, Politecnico di Torino, Italy
Wolfgang Mueller, Paderborn University, Germany
DAC Workshop, Anaheim, June 12, 2005
III
IV
UML for SoC Design
DAC Workshop, Anaheim, June 12, 2005
UML for SoC Design
SysML and Systems Engineering Applied to
UML-Based SoC Design
Yves Vanderperren, Wim Dehaene
Katholieke Universiteit Leuven,
EE Department (ESAT-MICAS)
Abstract. UML is gaining increased attention as a system design language. This is confirmed by several reported experiences and current
standardization activities such as the SysML initiative, which extends
UML toward the Systems Engineering domain. This paper summarizes
the main features of SysML and analyzes the synergies between Systems
Engineering and complex SoC design using UML. In particular, the application of Requirements Engineering is illustrated in the SoC context,
and suggests possible improvements to existing SoC design processes
based on UML.
1
Introduction
UML is attracting growing interest as a system level visual language to support
the tasks of analyzing, specifying, designing, verifying and validating systemson-a-chip (SoC) [1]. Indeed UML presents the particular advantage of allowing
customization for specific application domains, such as SoC design, while providing unification [2]:
– across historical notations: UML 2 is the result of a long evolution from the
’method wars’,
– across development life cycles: despite its primary focus at system level,
UML can be used in other phases of the SoC development lifecycle, such as
prototype test [3, 4],
– across application domains: UML has the capability of providing a unified
view of a heterogeneous SoC,
– across development processes: UML can be associated with any particular
design method of choice,
– across design languages: several synergies between UML and existing SoC
design languages at different abstraction levels have been reported in the
recent years, such as UML/SystemC [5–7] or UML/VHDL [8, 9].
However the semi-formal aspect of UML and its lack of clear semantics constitute a well-known issue. Moreover, UML still has strong roots in the software
domain despite its official and domain-neutral definition [10]. SysML [11] is an
extension of UML which allows modeling a system from a Systems Engineering
(SE) point of view. Strong similarities exist between the methods used in the
DAC Workshop, Anaheim, June 12, 2005
1
2
UML for SoC Design
area of SE and complex SoC design, such as the need for precise requirements
management, heterogeneous system specification and simulation, system validation and verification. This paper gives an overview of SysML and identifies
the opportunities to improve UML-based SoC development processes with the
successful experiences from the SE discipline.
2
SysML: UML for Systems Engineering
The Systems Modeling Language (SysML) is the result of a joint initiative of
OMG and the International Council on Systems Engineering (INCOSE). SysML
is a (draft) profile extending the UML 2.0 Superstructure Specification and provides a standard modeling language to support the specification, analysis, design,
verification and validation of a broad range of complex systems which are not
necessarily software based.
SysML is based on the minimal subset of UML that satisfies the needs of
systems engineers, and adapts UML only when it is necessary. One of the major
improvements SysML brings to UML is the support for representing requirements and relating them to the model of a system, the actual design and the
test procedures. Indeed UML does not address how to trace the requirements
of a system from informal specifications down to the individual design elements
and test cases, although this activity is crucial. Use Cases help build up a sound
understanding of the expected behavior of the system and validate the proposed
architecture. However requirements are often only traced to the use cases but
not to the design. Adding design rationale information capturing the reasons for
design decisions made during the creation of development artifacts and linking
these to the requirements helps to analyze the consequences of a requirement
change. SysML therefore introduces the requirement diagram and defines several kinds of relationships for improving the requirement traceability. The purpose is not to replace the available commercial tools dedicated to this subject,
but to provide a standard way of linking the requirements to the design and
the test suite within UML. Requirements can be decomposed by means of the
containment relationship in a similar way to that for class diagrams. The trace
dependency relates derived requirements to source requirements. The system designed and the requirements are linked by a satisfaction dependency. Finally, the
verification dependency associates a requirement with the test case used to verify this requirement. Requirement diagrams contribute to the rigorous transfer
of specifications and related information among tools used by systems, software
and hardware engineers.
SysML enhances the UML diagrams used to represent the structural aspects
of a system. It introduces the concept of assembly, a stereotyped class which
describes a system as a structure of interconnected parts. An assembly provides
a domain neutral modeling element that can be used to represent the structure
of any kind of system, regardless of the nature of its components. In the context
of a SoC, these components can be hardware or software based as well as analog
or digital. An assembly model, the SysML version of the composite structure
DAC Workshop, Anaheim, June 12, 2005
UML for SoC Design
diagram, shows the interconnection of the parts of a system and supports information flows between components, as present for example in the datapath of a
heavy signal-processing oriented SoC.
The concept of allocation in SysML is a more abstract form of deployment
than in UML. It is defined as a design time relationship between model elements
which maps a source into a target. An allocation provides the generalized capability to allocate one model element to another. For example, it can be used
to link requirements and design elements, to map a behavior into the structure
implementing it, or to associate a piece of software and the hardware deploying
it.
As a consequence, SysML abandons the use of the communication diagram.
The SysML support for flows between assemblies is meant to provide an equivalent and domain-neutral modeling capability. The same argument applies to the
deployment diagram. It is considered too specific to the software domain as it
is limited to the deployment of software artifacts onto hardware components,
while the SysML allocation provides a more flexible deployment mechanism.
Finally, SysML provides several enhancements to activity diagrams. In particular the control of execution is extended such that running actions can be
disabled. In UML 2 the control is limited to the determination of the moment
when actions start. In SysML a behavior may not stop itself. Instead it can
run until it is terminated externally. For this purpose SysML introduces control
operators, i.e., behaviors which produce an output controlling the execution of
other actions.
These new features from SysML can be applied to SoC design [12]. SysML
provides therefore a bridge between the domains of Systems Engineering, UML,
and SoC design. This important point needs to be carefully understood, however:
– SysML does not solve the question of the lack of semantics in UML. SysML
does also not define always precise semantics for the modeling elements it
introduces: although the concept of assembly allows unifying the representation of heterogeneous systems, this achievement comes at the cost of increased abstraction and weaker semantics. Abstraction is a double-edged
sword since it is necessary in order to deal with increasing complexity but
can cause interpretation issues.
– When considering the particular aspects of complex SoCs, the ability to navigate both horizontally and vertically through the system architecture is of
major importance. SysML allows the integration heterogeneous domains in a
unified model at a high abstraction level. The semantic integrity of the model
of a heterogeneous SoC could be ensured if future tools supporting SysML
take advantage of the concept of allocation and provide facilities to navigate
through the different abstraction layers into the underlying structure and
functionality of the system.
– SysML, like UML, is neither a methodology nor does it dictate any particular
development process to be used. SysML provides systems engineers with
modeling means to enhance the communication of the design intent, but it
does not tell how these can be best applied within a design flow. This is
DAC Workshop, Anaheim, June 12, 2005
3
4
UML for SoC Design
the role of a development process, the backbone of any project based on
UML/SysML.
This last comment is of paramount importance and is further detailed in the
remainder of this paper. Several synergies can indeed be identified between the
disciplines involved in Systems Engineering, complex SoC design flows, and aspects related to the definition of a design process based on UML/SysML.
3
Systems Engineering and UML/SysML-based SoC
design processes
INCOSE [13] defines Systems Engineering as an ”interdisciplinary approach and
means of enabling the realization of successful systems. It focuses on defining
customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem. Systems engineering integrates
all the disciplines and speciality groups into a team effort forming a structured
development process which proceeds from concept to production to operation.”.
This definition is analyzed in the context of SoC design in the following sections.
Systems Engineering as an interdisciplinary approach. Fabless system
providers generally lack expertise in designing state-of-the-art submicron VLSI
circuits. On the other hand, silicon providers often do not have the global visibility and the overall system knowledge required to define a complex SoC. However,
the successful construction of such systems requires a cross-functional team with
system design knowledge combined with an experienced SoC design team from
hardware and software domains [14].
The Essential Role of Requirements Engineering. Requirements Engineering (RE) constitutes a branch of Systems Engineering which must span the
gap between the informal world of the stakeholders needs and the formal world
of the system’s behavior. RE for SoC can be performed in different contexts,
such as market-driven product development (ASSP) or for a specific customer
(ASIC, FPGA), and leads to a particular choice of possible requirements elicitation techniques (see figure 1) [15]. Four of these techniques suit especially the
domain of RE for SoC using UML/SysML. Model-driven SoC design flows, where
an executable model of the system is built early in the project lifecycle using an
electronic system languages (ESL), share similar principles as the prototyping requirements elicitation technique. Executable UML could support new approaches
at system level, in particular for control-oriented and software-dominated embedded systems. Goal-oriented techniques [16] stress the question why a system
is needed, regardless of the details of how to achieve the goals. These correspond
to the services to be provided (functional concerns) as well as the required quality
of these services (non functional concerns, typically throughput, execution time
DAC Workshop, Anaheim, June 12, 2005
UML for SoC Design
Fig. 1. Requirements Elicitation Techniques
and power consumption in the SoC context). Such techniques can be applied
in conjunction with approaches structuring use cases with goals [17, 18]. Structured elicitation techniques based on scenarios and mapping techniques based
on data flow diagrams are supported by the behavioural diagrams available in
UML/SysML and can be applied to SoC design. Scenarios generated by any of
the previous techniques help to validate the SoC requirements and verifying their
completeness. The object-oriented aspects of UML are actually not required at
this stage, where the system is seen as a black box, and several techniques from
the structured systems development and Systems Engineering methodologies are
applicable.
Defining requirements not only involves the task of requirements elicitation,
but also the modeling of requirements, which is concerned with the efficient representation of the accumulated information. The SysML requirements diagram
fills here the gap of UML.
Besides the requirements definition, managing change and evolving requirements is another fundamental RE activity. This task calls for cross-compatible
tools which can exploit the standard SysML traceability links between requirements as well as from requirements to design and test, in order to facilitate
the analysis of the consequences of a requirement change. Requirements can not
only evolve in time, but across product families as well. Platform-based designs
[21, 22] can benefit substantially from the experience of RE in this domain, as
they need a dedicated attention to the definition of core and differentiating requirements. Different platform instances share indeed similar requirements and
architectural characteristics, but differ in certain key requirements depending on
the target application.
Managing inconsistencies is an essential concern when defining requirements.
Viewpoint modeling [19] can be used not only as a requirements validation
method, but also to organise a multi-perspective SoC development technique
so that the specification process remains a coordinated effort. Viewpoints allow
constructing the description of large and complex systems from different perspectives and are supported by SysML. Examples of possible applications in the
DAC Workshop, Anaheim, June 12, 2005
5
6
UML for SoC Design
SoC domain include the verification of a hardware-software interface, or the integration of an intellectual property (IP) block within a system. In these cases,
it is essential to focus not only on specifying the functionality of the (sub)system
under consideration, but also on modeling the properties of the environment and
what the (sub)system should achieve in this environment. This is one of the motivations for goal oriented techniques, which decrease the emphasis on modeling
information flow and system state, and concentrate instead on capturing the
system’s purpose within its context.
Systems Engineering and SoC Development Processes. It is crucial to
adapt the development process to the particular needs of the given application
domain, much the same way as UML requires customization toward the area
in which it is used. In the SoC context, characterized by severe first time right
requirements and exponentially increasing mask costs which prevent successive
physical implementations, executable models provide a means to support iterative development processes. As an example, a customized version of the RUP [20]
was applied in [14]. The importance of a system model makes SoC development
processes based on UML [14, 18, 21, 23] resemble Systems Engineering processes,
such as SIMILAR [24] or HARMONY [25]. As illustrated by the experience reported in [3] compared to [23], re-evaluation and continuous improvement of
the development process, one of the most important phases of SIMILAR, plays
a crucial role in the successful integration of UML into SoC design processes.
Moreover, the reported experience indicated that 55% of the errors detected were
related to inconsistencies in the specification during the analysis and modeling
phase, while another 21% were discovered during to black box implementation
tests based on scenarios derived from use cases. These results confirm the benefits of a clear requirements management procedure and the applicability of UML
at different phases of the design flow.
These SoC development processes based on UML could be improved by integrating further the requirements management as a lifecycle task running in
parallel with the design and verification activities, as recommended by the underlying principles of the Requirements-Based UML (RBU) process [26]. Another aspect which deserves more attention concerns the investigation of design
alternatives, as stressed in a dedicated phase of SIMILAR. This task requires
the definition of clear performance and cost figures of merit, and the possibility to proceed fast with the design synthesis of the alternatives. The former
might however be particularly difficult to estimate accurately at system level, in
particular power related aspects, while the latter motivate programmable and
reconfigurable architectures as well as improved support for automatisation.
4
Conclusions
The recent advances in UML and SysML present a valuable milestone for the
application of UML to modern chip design. However, it is essential to remember
that SysML, like UML, only provide standard modeling means. Neither UML
DAC Workshop, Anaheim, June 12, 2005
UML for SoC Design
nor SysML solve the difficulty associated with systems analysis, but they allow
efficient communication between the project stakeholders. A sound development
process which suits the peculiarities of SoC design is necessary to complement
the use of UML/SysML for SoC design. Regardless of the specific characteristics
of the particular adopted process, it is beneficial to extend SoC engineering from
its focus on hardware and software technologies to an engineering discipline of
system development. A multi-disciplinary approach is indeed crucial to coping
with increasing product complexity and the need for reduced design time. In
particular, SoC designers can capitalize on the experience accumulated in the
domain of Requirements Engineering in order to improve substantially product
quality and design productivity.
References
1. Martin, G., Müller, W. (Eds.): UML for SoC Design. Springer, 2005.
2. Holt J.: UML for Systems Engineering. Institution of Electrical Engineers, 2004.
3. Zhu, Q., Oishi, R., Hasegawa, T., Nakata, T.: Integrating UML into SoC Design
Process. Proc. Design, Automation and Test in Europe (DATE), 2005, pp. 836–837.
4. Vanderperren, Y., Dehaene. W.: UML for SoC: Added Value or Hot Topic?. Tutorial.
DAK-forum, 2004.
5. Vanderperren, Y., Pauwels, M., Dehaene, W., Berna, A., Özdemir, F.: A SystemC
Based System On Chip Modelling and Design Methodology. In ”SystemC: Methodologies and Applications”, Chapter 1, Mueller, W., Rosenstiel, W., Ruf, J. (Eds.),
Kluwer Academic Publishers, 2003.
6. Baresi, L., Bruschi, F., Di Nitto, E., Sciuto, D.: SystemC Code Generation from
UML Models. In ”System Specification & Design Languages”, Chapter 13. Kluwer
Academic Publishers, 2003.
7. Nguyen, K.D., Sun, Z., Thiagarajan, P.S.: Model-Driven SoC Design Via Executable
UML to SystemC. Proc IEEE International Real-time Systems Symposium (RTSS),
2004.
8. Björklund, D., Lilius, J.: From UML Behavioral Descriptions to Efficient Synthesizable VHDL. Proc. IEEE Norchip Conference, 2002.
9. McUmber, W.E., Cheng, B.H.C.: UML-Based Analysis of Embedded Systems Using a Mapping to VHDL. Proc. IEEE International Symposium on High-Assurance
Systems Engineering (HASE), 1999, pp. 56-63.
10. OMG: UML 2.0 Infrastructure Specification. http://www.omg.org.
11. SysML Forum: SysML Specification (Draft), 2005. http://www.sysml.org
12. Vanderperren, Y., Dehaene, W.: UML 2 and SysML: An Approach to Deal with
Complexity in SoC/NoC Design. Proc. of the conference on Design, Automation and
Test in Europe (DATE), 2005, pp. 716–717.
13. INCOSE: What is Systems Engineering? http://www.incose.org
14. Vanderperren, Y., Sonck, G., Van Oostende, P., Pauwels, M., Dehaene W., Moore
T.: A Design Methodology for the Development of a Complex System-on-Chip Using UML and Executable System Models. Proc. Forum on Specification and Design
Languages (FDL), 2002.
15. Darke, P., Shanks, G.: User Viewpoint Modelling: Understanding and Representing
User Viewpoints During Requirements Definition. Information Systems Journal, 7:3,
1997.
DAC Workshop, Anaheim, June 12, 2005
7
8
UML for SoC Design
16. van Lamsweerde, A.: Goal-Oriented Requirements Engineering: A Guided Tour.
Proc. 5th IEEE International Symposium on Requirements Engineering, 2001, pp.
249-263.
17. Cockburn, A.: Use Cases, Ten Years Later. Software Testing and Quality Engineering Magazine (STQE), 4:2, 2002, pp. 37-40.
18. Vanderperren, Y., Dehaene, W.: A Model Driven Development Process for Low
Power SoC Using UML. In [1], Chapter 10.
19. Easterbrook, S., Nuseibeh, B.: Managing Inconsistencies in an Evolving Specification. Proc. 2nd IEEE International Symposium on Requirements Engineering, 1995,
pp. 48–55.
20. Kruchten, P.: The Rational Unified Process: An Introduction (3rd Ed.). AddisonWesley, 2003.
21. Green, P. N., Edwards, M. D.: Platform Modelling with UML and SystemC. Proc.
Forum on Specification and Design Languages (FDL), 2002.
22. Sangiovanni-Vincentelli A., Martin, G.: Platform-Based Design and Software Design Methodology for Embedded Systems. IEEE Design and Test of Computers, 18:6,
2001, pp. 23–33.
23. Zhu, Q., Matsuda, A., Kuwamura, S., Nakata, T. , Shoji, M.: An Object-Oriented
Design Process for System-on-Chip Using UML. Digest of IEEE Int. Solid-State
Circuits Conf., 2002, pp. 249-254.
24. Bahill, A.T., Gissing, B.: Re-evaluating Systems Engineering Concepts Using Systems Thinking. IEEE Trans. Systems, Man, and CyberneticsPart C: Applications
and Reviews, 1998, pp. 516-527.
25. Hoffmann, H.-P.: UML 2.0-Based Systems Engineering Using a Model-Driven Development Approach. I-Logix White Paper, 2004.
26. Schulz, J.: Requirements-based Unified Modeling Language. Borland White Paper,
2003.
DAC Workshop, Anaheim, June 12, 2005
UML for SoC Design
9
UML Profile for System-on-Chip (SoC)
Sreeranga Rajan1, Takashi Hasegawa2, Minoru Shoji2, Q. Zhu2, and Nakata Tsuneo2
1
Fujitsu Laboratories of America, Sunnyvale, CA, USA
[email protected]
2
Fujitsu Limited, Kawasaki, Kanagawa 211-8588, JAPAN
{thasegawa,shoji.minoru,shu.kyuo,nakata.tsuneo}@jp.fujitsu.com
1
Introduction
Existing UML semantics have a strong focus on software requirements
specification and therefore cumbersome to use for supporting modeling and
specification of SoC designs in most cases. In order to directly enable modeling and
specification of SoC designs, we have developed a UML profile for SoC. The context
and positioning of the profile is shown in Figure 1. The profile consists of special
notations (icons) for SoC design elements, stereotypes corresponding to SoC
elements, and a constraint specification associated with the stereotypes. Stereotypes
corresponding to SoC elements are derived from existing UML metaclasses. SoC
designers specify a design using both SoC class diagrams based on the stereotypes
and SoC structure diagrams based on the special structural notation (icons) introduced
by the UML profile. In this presentation, we provide an overview of our proposal on
UML Profile for SoC that has recently been issued as RFC by OMG [14]. The
proposal has been developed over the past two years by the UML for SoC forum that
consists of three categories of expertise:
1.
2.
3.
Semiconductor: Fujitsu, Toshiba, and NEC Laboratories
Systems: Canon and RICOH
Software: IBM (Rational), CATS, and Metabolics
SoC Design Methodology
SoC Modeling
Profile for SoC
Extension for SoC
Existing Standard
Figure 1: Context and Positioning of UML Profile for SoC
DAC Workshop, Anaheim, June 12, 2005
10
UML for SoC Design
2
Profile for SoC: Overview of Stereotypes
Each element of the SoC model corresponds to the stereotyped UML metaclasses
as shown in Table 1 and Figure 2. The stereotypes may be associated with constraints
described using OCL. In this Section we provide a brief description for each SoC
element.
1. Data is the target of communication between modules.
2. Controller class’ member function is the module’s process.
3. Module is the base class for describing SoC hierarchy; it may own
channels/other modules.
4. Port defines the protocol interface used for communication external to
modules.
5. Protocol Interface defines the communication between modules and provides
an abstraction for the method of communication.
6. Channel element corresponds to structures used for handling information
transfer.
7. Connector links a member module’s port and a channel, or a port of another
module and a member module’s port.
8. Protocol describes the relationship between protocol interface and channel.
9. Process is a member function of the module that describes its behavior.
10. Module Part (sub-module) is a kind of property (part) typed by the module
class.
11. Channel Part is a kind of property (part) typed by the channel class.
12. Clock and Reset Ports are inherited from port.
13. Clock Channel is a property (part) defining the channel instance that transmits
the execution events to synchronous processes.
14. Reset Channel is a property (part) defining the channel instance that transmits
the reset events to processes.
15. Data Type is an extension of UML dependency, pointing to Data class.
DAC Workshop, Anaheim, June 12, 2005
UML for SoC Design
11
SoC Model element
Stereotype
UML metaclass
Data
Data
Class
Controller
Controller
Class
Module
SoCModule
Class
Port
SoCPort
Port/Class
Protocol Interface
SoCInterface
Interface
Channel
SoCChannel
Class
Connector
SoCConnector
Connector
Protocol
SoCProtocol
Collaboration
Process
SoCProcess
Operation
Module Part
SoCModuleProperty
Property
Channel Part
SoCChannelProperty
Property
Clock Port
SoCClock
Port
Reset Port
SoCReset
Port
Clock Channel
SoCClockChannel
Property
Reset Channel
SoCResetChannel
Property
Data Type
SoCDataType
Dependency
Table 1: SoC model elements, Stereotypes, and their corresponding UML
Metaclasses
DAC Workshop, Anaheim, June 12, 2005
12
UML for SoC Design
Figure 2: System Description using Component Diagrams
DAC Workshop, Anaheim, June 12, 2005
UML for SoC Design
3
Profile for SoC: Overview of Structure Diagram
SoC structure diagram is used to describe the structure of SoC. Special notations
corresponding to SoC model elements listed in Table 1 are used in a SoC Structure
diagram. An example of hierarchical module is shown in Figure 3, where the notation
explicitly depicts the submodules within the hierarchy. In Figure 4, the denotation of
hierarchy is by using an icon within a child module that allows one to avoid depicting
submodules explicitly.
Figure3: SoC Structure Diagram: Example illustrating Hierarchy: Explicit
depiction of submodules
Figure 4: SoC Structure Diagram: Example illustrating Hierarchy: Notation that
avoids explicit depiction of submodules
DAC Workshop, Anaheim, June 12, 2005
13
14
UML for SoC Design
4
Example of the Modeling using UML Profile for SoC
An SoC design modeled using UML Profile for SoC can be realized by generating
executable code in a language such as System C. Shown in Figure 16 is the UML
class diagram. Here func() member function of user_class1 and func() member
function of user_class2 are processes. And data1, data2, data3 are input/output data
between the processes. In this class diagram, <<Data>> <<Controller>> stereotypes
are specified.
<<data>>
data1
<< data> >
data2
<<data>>
data3
<< co ntroller>>
use r_class1
<< controlle r> >
user_class2
+func(in : d ata1): data2
+func(in: data2): data3
Fig.16 Class diagram after the stereotype specified
port name: in
interface direction: input
protocol interface name: sc_fifo_in_if<data1>
initialization
parameter: 0
port name: out
interface direction: out
protocol interface name: sc_fifo_out_if<data3>
class name: parent
process function:
fifo:sc_fifo<data2>
class name: child1
instance name: func1
process function: entry
port name: in
port name: out
class name: child2
interface direction: output
instance name:func2 interface direction: in
protocol interface name: sc_fifo_out_if<data2> process function: entry protocol interface name: sc_fifo_in_if<data2>
Fig. 17 Structure diagram and attribute of each object, tagged value
Figure 17 shows the structure diagram wherein the necessary values and attributes
are specified as notes.
DAC Workshop, Anaheim, June 12, 2005
UML for SoC Design
5
Conclusions and Future Work
In this work we have described our proposal for UML profile for System-on-Chip
(SoC) designs. This proposal has been issued as an RFC by OMG [14]. The profile
will introduce a systematic model-driven methodology for designing SoCs. In the
next few months, we plan to continue to work for the final adoption of this profile as a
standard.
References
1.
OMG home page, http://www.omg.org/
2.
Jacobson, Object-Oriented Software Engineering: A Use Case Driven Approach,
Addison-Wesley Toppan, 1995.
3.
Q. Zhu, A. Matsuda, S. Kuwamura, T. Nakata, and M. Shoji, "An object-oriented
design process for System-on-Chip using UML", Proc. of the 15 th Int.
Symposium on System Synthesis (ISSS 2002), 1-4 October, Kyoto, Japan, pp.
249-254.
4.
Q. Zhu, R. Oishi, T. Nakata, and T. Hasegawa, "System-On-Chip Validation
using UML and CWL", ISSS+CODES 2004.
5.
Q. Zhu, T. Nakata, and T. Hasegawa, "Integrating UML into the SoC Design
Process", DATE 2005.
6.
SystemC OSCI, http://www.systemc.org.
7.
Press Release of Fujitsu Microelectronics America Inc.,
http://www.fujitsu.com/us/news/pr/fma_20040330-02.html.
8.
G. D. Hachtel, F. Somenzi, Logic Synthesis and Verification Algorithms,
Kluwer Academic Publishers, 1996.
9.
S. Tasiran, Y. Yu, B. Batson, “Using a Formal Specification and a Model
Checker to Monitor and Direct Simulation”, In Proc. 2003 Design Automation
Conference, 40th DAC, pp. 356-361, 2003.
10. G. Graw, P. Herrmann, and H. Krumm, “Verification of UML-based real time
system designs by means of cTLA”, Proc. of 3rd IEEE International Symposium
on Objectoriented Real-time distributed Computing (ISORC2K), pp 86-95, 2000.
11. Press release from Fujitsu, "Fujitsu Develops New SoC Design Methodology
Based on UML and C Programming Languages",
http://pr.fujitsu.com/en/news/2002/04/16-2.html.
12. Press release from Fujitsu, Rational, CATS, "Fujitsu Establishes Forum
Promoting UML Standards for SoC Design",
http://pr.fujitsu.com/en/news/2002/11/19.html.
13. Q. Zhu, T. Nakata, and T. Hasegawa, "Integrating UML into the SoC Design
Process", DAC 2004, http://www.c-lab.de/uml-soc/uml-soc04/.
14. UML Profile for SoC, draft RFC http://www.omg.org/cgi-bin/doc?realtime/200504-12.
DAC Workshop, Anaheim, June 12, 2005
15
16
UML for SoC Design
MARTE: a new OMG profile RFP for the
Modeling and Analysis of Real-Time Embedded
Systems
Charles André1 , Arnaud Cuccuru2 , Jean-Luc Dekeyser2 , Robert De Simone1 ,
Cédric Dumoulin2 , Julien Forget, Thierry Gautier3 , Sébastien Gérard4,
Frédéric Mallet1 , Ansgar Radermacher4 , Laurent Rioux5 , Thierry Saunier5 ,
and Yves Sorel1
1
2
INRIA/I3S – project AOSTE
INRIA/LIFL – project DaRT
3
INRIA – project Espresso
4
CEA – LIST
5
Thales
Abstract. A new RFP invitation for an UMLTM profile on Real-Time
and Embedded systems modeling and analysis (codename: MARTE) was
recently voted at OMG.
While of broader scope than strictly SoC design, many objectives of
MARTE are highly relevant to the domain (defining time structures,
concurrency and communication models, mixing control-flow and dataflow, modeling architectural platforms and adopting Y-chart approaches
for allocation of application functions onto architectural resources).
We describe the RFP content, stressing its relation to SoC design, as well
as others connected activities in the domain, such as SysML, AADL, and
UML4SoC.
1
Context
The MARTE (Modeling and Analysis of Real-Time Embedded systems) RFP
(Request For Proposals) [1] was voted at the OMG Technical Meeting held in
Burlingame (CA) in January 2005. The proposal has been initiated from two
main sources:
– First, a joint French project named CARROLL/PROTES, between Thales,
CEA and INRIA (basically the authors of this position paper) aiming at providing modeling elements with a fine understanding of (logical or physical)
timing issues at this level;
– Second, a will and a demand from the authors and the users of the previous
SPT [2] (Schedulability, Performance & Time) profile to extend it and align
it to the more recent UML 2.0 standard.
Since the vote of the RFP, several new partners, both from academia and
industry, have considered joining the initial group to submit reponses to the
RFP.
DAC Workshop, Anaheim, June 12, 2005
UML for SoC Design
The MARTE RFP bears strong connections with other OMG standardization attempts (some already accepted as standards, some only proposed) such as
SysML [3] (a general purpose systems modeling language, response to the UML
for Systems Engineering RFP [4]), AADL (The SAE Architecture Analysis &
Design Language [5]), and UML4SoC. The latter, also presented in this workshop [6], is now in a request for comments process (RFC [7]) issued in April 2005
and concerning an UML Ext. profile for SoC. UML4SoC focuses on the structural description of hierarchical interconnect media, and the behavioral elaboration phase of simulation model. MARTE, which addresses embedded systems in
general, has a broader scope. MARTE and UML4SoC are complementary and
both should be used for SOC design.
2
Overview
MARTE is divided in three subparts (some would say subprofiles):
– TCR (Time & Concurrent Resources) is meant to provide the ”infrastructure” notions of logical/discrete and physical/real time, and the basic concurrency and communication models relevant to the profile. It should extend
in many ways the corresponding parts of the SPT profile, in particular in
adding the notions of synchronous/clocked systems (with events simultaneity
and well-defined priorities).
– SPA (Schedulability and Performance Analysis) is rather self-explanatory. It
should provide with features allowing the non-functional performance evaluation and static or dynamic scheduling policies of systems.
– RTEM (Real-Time Embedded Modeling) promises to take these time information into account to provide for behavioral definitions of hierarchical
models, as in state and activity diagrams for instance. It also claims for independent high-level modeling of architectural platforms, with the goal of
adopting a platform-based design methodology. The two previous subprofiles
provide information necessary for building optimized allocation relationships
between applications and architectures. RTEM should also provide specific
constructs for frequently encountered structures in real-time and embedded
systems.
3
The main requirements for MARTE
In this section we list the main requirements for the RFP. Some are general,
others address the three subprofiles (TCR, SPA, RTEM) individually. We put
emphasis on aspects we find particularly relevant to SoC design, by writing
them in italics. For convenience, we keep the requirement numbers such as they
appear in the RFP. The reader may access to all requirements in the original
proposal [1], and may note that several emphasized points are not covered by
ULM4SoC.
DAC Workshop, Anaheim, June 12, 2005
17
18
UML for SoC Design
3.1
General requirements
1) Proposals shall provide a UML profile to support modeling and analysis of
real-time and embedded systems (RTES) including software and abstract hardware aspects.
2) Proposals shall allow independent extensions of the parts that support software and hardware modeling.
5) Proposals shall define the normative modeling and analysis metamodels of
RTES as a basis for tool integration.
7) Proposals shall include an XMI description of the proposed profile.
3.2
Requirements for the Time, and Concurrent Resources (TCR)
10) Proposals shall support at least the following time models: Asynchronous/
Causal models, Synchronous/Clocked models, Real/Continuous time models or
their equivalents.
11) In the context of synchronous time model, proposals shall define expressions
for time dependencies and support the combination of simultaneous events, considering event absence and priority in behavior diagrams/models.
12) Proposals shall support a rich set of measures related to schedulability
and performance, which can be expressed by statistical measures (such as average, variance, percentile values, histograms, distributions, and deterministic
values). . .
15) Proposals shall define modeling entities to specify tasking models including
concurrency and scheduling mechanisms.
16) Proposals shall support modeling of software deployment on heterogeneous
platforms.
17) Proposals shall define a resource model to describe an abstract view of
hardware architecture including active/passive elements (e.g., CPU, Memories,
FIFO, etc.) and communication media (e.g., Busses, Crossbar, etc.). In addition,
it shall support hierarchical models of hardware (e.g., SMP, multi-processors,
etc.).
3.3
Requirements for Real-Time and Embedded Modeling (RTEM)
Embedded requirements
DAC Workshop, Anaheim, June 12, 2005
UML for SoC Design
18) Proposals shall support at least fully static allocation of resources to the
application. That is, the application is completely known before its execution
in real-time and its processing does not depend on the values of the data it
consumes.
19) Proposals shall define specific QoS (i.e., non-functional requirements) of
systems related to both their real-time constraints (e.g., deadline, ready time,
period, etc.) and their embedded constraints (e.g., power consumption, program
size, data size, memory size, number of processors, etc.).
Behavior requirements
20) Proposals shall provide the means to specify computation models in relation
to a specific time model for both data-flow (e.g., SDF [8], KPN [9], Dataflow Procedure Language [10]) and control-flow (e.g., state-machine modeling, discrete
event systems). . .
21) Proposals shall provide the means to express concomitant use of data flow
and control flow models and their interactions.
22) Proposals shall support deterministic behavior modeling of RTES. Determinism is an important property to guarantee unambiguous and reproducible
behaviors, so that models can be fully trusted as a formal basis for analysis,
implementation, etc.
Structure requirements
23) Proposals shall define high-level modeling constructs for factorization of
repetitive structures for both hardware and software and their allocation. Proposals should not make any assumption on how the factorized structure will be
implemented or executed (sequential, parallel, etc.).
24) Proposals shall support modeling allocation of software capabilities to an
abstract view of the hardware for RTE applications. . .
25) Proposals shall support component-based modeling for RTES hardware architectures.
3.4
Requirements for Schedulability and Performance Analysis
(SPA)
30) Proposals shall support modeling of timed-utility functions which describe
the cost of delay and the relative importance or urgency of responses (if this is
different from priority).
DAC Workshop, Anaheim, June 12, 2005
19
20
UML for SoC Design
31) Proposals shall support analysis of component-based models, by attaching performance and schedulability measures to services offered or required at
interfaces/ports.
4
Perspectives
Now that the MARTE RFP is accepted as RFP at OMG, we are in a stage
similar to when a Call for Paper is issued for a (prestigious) conference, with
a precise focused topic. It is our hope that as many people as possible with a
true interest in the field, including academics, industrials, and tool vendors, will
gather around the response proposal, to make it complete, simple and useful.
References
1. OMG: UML profile for Modeling and Analysis of Real-Time and Embedded Systems
(MARTE) RFP. OMG Document – realtime/05-02-03 (2005)
2. OMG: UML Profile for Schedulability, Performance, and Time. Version 1.1 OMG
Document – formal/05-01-02 (2005)
3. SysML Partners: Systems Modeling Language (SysML) Specification. (Updated
SysML revised submission) OMG Document – ad/05-01-03 (2005)
4. OMG: UML for Systems Engineering RFP. OMG Document – ad/03-03-41 (2003)
5. SAE Standards: Architecture Analysis & Design Language (Aadl). SAE Document
– AS5506 (2004)
6. T. Hasegawa, S.P. Rajan. Introduction to the new standard of UML4SOC. DAC
2005 Workshop, Anaheim (CA) (2005)
7. OMG: A UML Profile for SoC RFC Submission. OMG Document – realtime/0504-12 (2005)
8. E. A. Lee and D. G. Messerschmitt. Synchronous Data Flow. Proceedings of the
IEEE, vol 75 (1987)
9. G. Kahn. The semantics of a simple language for parallel programming. In J. L.
Rosenfeld, editor, Information Processing 74. Proc. IFIP Congress 74, IFIP, pp 471475, North Holland, Stockholm (1974)
10. J. B. Dennis, First Version of a Dataflow Procedure Language. Lecture Notes in
Computer Science, Springer-Verlag, vol. 19 pp. 362-376, (1974)
DAC Workshop, Anaheim, June 12, 2005
UML for SoC Design
Interface Problems:
What We Have Here is a Failure to Communicate
Stephen J. Mellor, John R. Wolfe, Campbell McCausland
Mentor Graphics, 7400 N. Oracle Road, Suite 365,
Tuscon, AZ 85704 USA
{Stephen_Mellor, John_Wolfe, Campbell_McCausland}@mentor.com
It is typical to describe the interface between hardware and software with pointby-point connections, such as “write 0x8000 to address 0x3840 to activate the
magnetron;” and “when the door opens interrupt 5 is activated.” This approach
requires that each connection between hardware and software be defined, one
by one, even though there is commonality in the approach taken. Using a
software example, each function call takes different parameters, but all function
calls are implemented in the same way. At present, two teams of developers
(hardware and software) must construct each interface by hand, both at
specification and implementation time. Only convention and repeated review
enforce agreement between the two halves of the specification. This is an
invitation to a failure to communicate. We must separate the kinds of interface
(making function calls) from each interface (the parameters for each call) and
apply the kinds of interface automatically like a compiler.
1 Capturing the Design: xtUML
We assume the existence of an executable (UML) modeling language. The language
must be defined so that models produced in the language can be stored completely in
some formalism. A model of that formalism (i.e. the language) is called a metamodel.
The language must be defined so that it does not presume an implementation. Hence,
sets (represented as classes) can be used to define required data, since sets can be
translated into lists, arrays, etc. Similarly, a state machine can be used to define
behavior, so long as it can be translated into an arbitrary implementation, hardware or
software. Examples of such translations follow. One such language is Executable
Translatable UML, xtUML [1].
There is a single model for the system-on-a-chip (SoC) incorporating both
hardware and software. There is no possibility of a failure to communicate between
hardware and software teams because there is only one implementation-free model.
DAC Workshop, Anaheim, June 12, 2005
21
22
UML for SoC Design
2 Rules and Rule Languages
If we assume a metamodel populated with types from the developer’s application
model, we can write rules against it that produce text that can be compiled into
software and silicon. One rule might take a set and produce a class declaration.
Different rules could produce a struct for a C program or a VHDL entity.
Similarly, we may define rules that turn state machines into arrays, lists, switch
statements, etc.
These rules let us separate the application from the architecture. The xtUML model
captures the problem domain graphically in UML, and represents it in the metamodel.
The rules read the application as stored in the metamodel and turn that into an SoC.
A collection of rules and supporting mechanisms is called a model compiler, which
encapsulates the architecture of the generated system. For example, a model compiler
for an object-oriented architecture will likely translate each UML class to a C++ class
or a C struct, with each associated UML attribute being translated to a data
member of the class or a member of the struct.
For hardware implementations, we could translate each UML class into a
collection of registers, one for each attribute in the class. Each state machine of the
application model could be mapped to a VHDL case statement. There are, of course,
many other possible implementations. UML classes can be mapped into blocks of
RAM, and state machines can be translated into a data-driven and gate-conservative
dispatcher.
The interfaces between hardware and software are just a part of the architecture
encapsulated within the model compiler. Suppose there are two UML classes in a
microwave oven called CookingStep and Oven, where CookingStep is translated to
software and Oven is translated to hardware. In this case, the hardware architecture
for Oven is a collection of memory-mapped registers. The generated interface for an
action in CookingStep that accesses an attribute of Oven is then a simple memory
access of the address allocated for the register in question.
In a slightly different hardware architecture, the UML class Oven is mapped to
only two addresses, one representing a control register and one for a data register.
Accesses to attributes of the class would then be accomplished by writing the attribute
identifier and the type of access (read or write) to the control register and then
manipulating the data register accordingly (reading it after writing to the control
register or writing it before writing to the control register).
2.1 Communication
The interface between the hardware and software is defined by the model compiler.
The model compiler has sufficient information to generate the interface between
hardware and software, and will do so correctly, every time, without succumbing to
the ambiguities of a natural language specification. Because the implementation is
generated, there can be no interface mismatches, and because we no longer have two
separate teams of people working from a natural-language interface specification, the
generated implementation is guaranteed to have exactly zero interface problems.
(This does have the unfortunate side effect of reducing the number of opportunities
DAC Workshop, Anaheim, June 12, 2005
UML for SoC Design
for logic designers and software engineers to spend long nights together in the
integration lab fixing interface problems.)
The existence of automated tools to cause the generation of the system with
interfaces known to be correct completely removes any interface problems that can
lead to a failure to integrate the system and removes any possibility of failure to
communicate.
References
1. Mellor, Stephen and Balcer, Marc: Executable UML: A Foundation for Model-Driven
Architecture, Addison-Wesley, 2002.
DAC Workshop, Anaheim, June 12, 2005
23
24
UML for SoC Design
Synthesis of UML-Models for Reconfigurable
Hardware
Christina Dorotska, Bernd Steinbach, and Dominik Fröhlich
Technische Universität Freiberg
Institute of Computer Science
Germany
Abstract. The Unified Modeling Language (UML) is becoming an important competitor language for the development of hardware/software
systems. The capability of transforming UML-models into hardware/software implementations is a key to this approach. While the generation of
software from UML-models ist state-of-the-art, this article presents a
novel approach to the direct synthesis for reconfigurable hardware.
1
Introduction
Reconfigurable architectures are an important class of hardware architectures,
which combines the flexibility of traditional microprocessors with the performance of customized datapaths. Systems-on-chip (SoC) is the main application
of such architectures, besides high performance computing. Reconfigurable architectures enable the acceleration of the overall system whilst cutting development
and manufacturing costs.
Another trend in the SoC domain is the development on increasingly higher
levels of abstraction and the integration of modelling technology into the development flow. In this area object-oriented system-level modelling using UML
is considered a very promising promising direction. The capability of synthesizing hardware implementations as customized datapaths directly from the UMLmodels is a key technology, because it can avoid manual and error-prone translations and thereby allows for a better handling of design iterations.
In order to avoid the traditional breaks in paradigms, languages and tools,
and to give the designer the maximum freedom when creating system designs,
hardware synthesis from object-oriented models should preserve the objectoriented properties of the design in the final implementation. In this paper we
present an approach to the synthesis of UML models to customized datapaths.
In contrast to current behavioral synthesis this approach supports the full implementation of object-oriented models into customized datapaths [6][7][2].
The presented approach is based on the Unified Modeling Language (UML)
and a dedicated action language. UML 2.0 and the action language are used
for the object-oriented system specification and design at the system level of
abstraction. The approach is backed by a dedicated tool called the MOCCA
compiler (Model Compiler for reconfigurable architectures). Given complete and
DAC Workshop, Anaheim, June 12, 2005
UML for SoC Design
precise models of the applications design and the design and implementation
platforms, MOCCA can automatically perform partitioning, estimation, and the
implementation of the system into hardware/software modules. The synthesized
implementation is directly executable and exploits the capabilities of the hardware architecture.
A system is designed as executable and platform independent realization of
the systems use-cases. This design model defines the structure and behavior of
the system. System structure is defined in terms of UML classes and interfaces
and their relationships, like dependency, generalization, and implementation. For
concurrency specification we support active classes. System behavior is defined
with operations, state-machines, and the MOCCA action language. Synchronization between concurrent control flows is supported with guarded operations. The
model of computation is objects communicating through structured messages.
The direct implementation of such models in hardware is problematic due to
the inherent dynamics of object-oriented models, polymorphism, and the communication between objects. In the following sections we outline the key concepts
of object-oriented hardware synthesis. For the lack of space we do not detail modeling, design space exploration and software generation here nor we can give a
thorough discussion of an application example. For a detailed discussion of these
topics and the related work the interested reader is referred to [4], [1] and [5].
2
The Hardware/Software Interface
The hardware/software interface of object-oriented implementations with reconfigurable hardware defines the life cycle and access mechanisms of objects and
components realized in reconfigurable hardware.
For efficiency reasons the life cycle of hardware objects is different from the
life cycle of software objects. In order to avoid costly reconfigurations hardware objects are reused as much as possible. Because a true dynamic instantiation/destruction of objects is not efficiently possible in hardware, these objects
are pre-instantiated at compilation time and synthesized into configuration bitstreams. The objects are dynamically allocated on demand. Object brokerage
is performed by a dedicated software service. Additionally, in run-time reconfigurable systems objects and hardware configurations are dynamically bound to
logic.
The mechanisms for the access of objects are defined by the object interfaces.
The interface of each object consists of a control interface, a data interface, and
an exception interface.
Control Interface The control interface allows for identification, typing, and
access to the object. This interface contains the object address, type and
signals for the execution of the operations provided by the object.
Data Interface The data interface allows one to access the object state and to
pass input/output parameters from and to objects. The interface contains
the entire public state of the object and the parameters to/from services
that are publicly accessible.
DAC Workshop, Anaheim, June 12, 2005
25
26
UML for SoC Design
Exception Interface The exception interface reflects exceptional conditions
that occur in the object. Depending on the exception handling of the object
the information on the position and type of exceptions is represented.
The interface of each component representing a configuration bitstream comprises all interfaces of the objects accessible through the component interface. An
implementation of the hardware object and component interfaces is presented in
the next sections.
3
Hardware Implementation of Components
Figure 1 shows a template for the implementation of UML components in hardware. The component contains the pre-implemented objects Oi . The objects
O0 , ..., On+4 are accessible via the communication interface. All other objects
are not directly visible outside the component. The component also contains
central circuits for the generation of clock and reset signals. There may be specialized clock generators for dedicated modules, such as external ZBT RAM
(zero bus turnaround random access memory) or peripheral devices.
Communication Channel
DC0
Communication Interface
R
DCM0
FPGA
O1
C
On
O2
DC 3
RAM0
External
Storage
Components
RAM1
OB1
OB0
On+1
On+2
On+3
External
Clock
Generator
DC 2
Register File
O0
DC 1
On+4
DC4
RAM2
Fig. 1. Hardware Component Template
The presented approach can integrate pre-implemented hardware building
blocks (IP) into the synthesized hardware. As illustrated in [5] IP is modeled in
an implementation platform model using components, classes and interfaces. The
model defines the interface of the building blocks, that can be used to establish
connections between internal logic resources and external devices through the
physical device interface.
Required components, that are modeled in the implementation platform
model, are instantiated on demand. For instance, if RAM0 was realized with
ZBT RAM Bank 0, a DCM Clock (Digital Clock Manager) component is instantiated (DCM0 ) and connected to RAM0 . The adaption of the external to the local
DAC Workshop, Anaheim, June 12, 2005
UML for SoC Design
interface is realized by an appropriate VHDL wrapper component. The reset and
clock signals of the design are automatically generated by the model compiler.
Multiple objects are clustered in a hardware configuration. The number and
type of the hardware objects being clustered in a single configuration is determined either manually or automatically. For this the global message exchange
of classes and their object creation/destruction characteristics is analyzed.
The public interface of publicly visible objects is realized by a register file.
The register file allows one to access the control, data, and exception interfaces of
the respective hardware objects. Collaborating objects communicate via direct
connections or object buses (OBi ). In order to minimize bus contention there
may be multiple object buses in one component.
Only the publicly visible objects can be instantiated by the software portion
of the application. The other objects are hidden from the outside and are used
as helper objects within the component. The access to an object of a given type
must be independent of the object template and the dynamic object type. In
order to accomplish this the public object interfaces of all objects of a given
type and all of its subtypes must be identical. The realization of polymorphism
is hidden behind the external object interface.
4
Hardware Implementation of Objects
Figure 2 shows a template for the implementation of objects in hardware. The
template shows the implementation of one object. The object contains the preimplemented operation Oi , the operation parameters Pi and the attributes Ai .
The object can be of type T0 or T1 . The sets Pi and Ai comprise the data
interface of the object. Operation O2 has a non-empty exception interface.
For each type the visible features must be provided in the interface. The set
of visible operations is a superset of the operations that are defined by a type.
Model compilers automatically eliminate unused features before design space
exploration.
A control and type register implement the control interface. The type register
holds the current dynamic type of the object. The control register contains the
two signals GO and DONE for each operation. An operation is started by setting
its GO signal. The end of execution is signaled by the operation when it sets its
DONE signal.
Operation O1 is polymorphic, that is, the executed behavior depends on the
current object type. The selection of the behavior to execute is performed by a
selector circuit whose implementation is depicted on the right hand side of Figure
2. Because the execution of both implementations of O1 does not necessarily
require the same time, the selector must also multiplex the DONE signal.
The object interface hides the execution of polymorphic behavior; that is,
for the sender of a message which is handled by O1 it is not relevant which implementation of this operation is executed. Consequently both implementations
of O1 share the same data interface. If both behaviors of the operations change
data in their data interface, the implementations must be decoupled from the
DAC Workshop, Anaheim, June 12, 2005
27
28
UML for SoC Design
Ctrl
GO,DONE(O
GO,DONE(O
1)
0)
SEL 1
O0
P 01
GO
O1
A0
type(T 0 )
OE(T 0 )
P 10
OE(T 1 )
T1
O1
GO,DONE(O 2 )
A i - Attributes
P j - Parameters
EX k - Exceptions
O2
OB
Ctrl
P 00
T0
Type
P 20
P 21
Type
DONE
type(T 1 )
MUX
OE(T 0)
OE(T 1 )
P 22
GO
DONE DONE
GO
T 1::O 1
T 0 ::O 1
EX 2
Implementation of SEL
1
Fig. 2. Hardware Object Template
actual data by appropriate logic. If no other output enable was specified in the
model the DONE signal is used.
The implementation of attributes and parameters is straightforward; they are
mapped to a storage component of an appropriate width. If the implementation
platform contains components with appropriate interfaces, the resources modeled
are used to generate the storage components. The data interface of publicly
visible objects is located in the register file.
Objects are connected to the data interface and other objects with direct connections or buses. This raises a synchronisation problem because multiple objects
or operations may access features concurrently. Synchronization of publicly visible objects is performed in software. Concurrent accesses of proxy objects and
their hardware counterparts are decoupled by the dual ported architecture of the
register file. Potentially concurrent accesses to an element in the same hardware
component are guarded with arbiters.
5
Hardware Implementation of Behavior
The behavior of classes and operations is implemented according to the FSMD
model (finite state machine with datapath) [3]. This model is especially suitable
for control oriented applications, and fits the message based computing paradigm
of the object based model of computation.
Each behavior is constructed as controller with an attached datapath. The
datapath performs the computations of the behavior, the evaluation of the conditions which control the datapath, and the components that store the inputs,
outputs, and intermediate results. For the realization of the computation operations and buffers the resource services that have been allocated during design
space exploration are used. The results of conditions are inputs of the controller.
Scheduling of the datapath is performed and assigned to the behavior during
DAC Workshop, Anaheim, June 12, 2005
UML for SoC Design
design space exploration. During implementation this schedule is then actually
realized.
The controller is realized as Moore FSM. Datapath operations which require
at most one clock cycle are associated with one FSM state. Multi-cycle operations
are associated with a number of consecutive states. Independent operations and
operations that execute at most one clock cycle may be chained to execute back
to back in the same cycle.
Behavior implementations are not shared among different objects. Hence no
synchronization of concurrent executions of the same behavior in different objects is required. To avoid write contention the datapath keeps local copies of attributes and inout-parameters. All modifications of the datapath are performed
on the copies. If no explicit output enable is specified in the model, they are
synchronized back at the end of execution and when the behavior executes a
message transfer.
6
Conclusions
In this article we have presented a novel approach to the object-oriented hardware synthesis from UML-models. This article has shown that such specifications
can also be realized with reconfigurable hardware in a straightforward and convenient manner. The paradigm of message based computation can be used to
generate very efficient and scalable hardware implementations. The development
of highly parallel applications is encouraged. Advanced model compilers for SoC
can automatically implement heterogeneous multiprocessor solutions from UML
models.
References
1. Thomas Beierlein, Dominik Fröhlich, and Bernd Steinbach. UML-Based Development of Applications for Run-Time Reconfigurable Architectures. In Proceedings
of the UML-SOC - International Workshop on UML for SoC-Design 2004 (UMLSoC’04), June 2004.
2. John. P. Elliott. Understanding Behavioral Synthesis. Kluwer Academic Publishers,
2000.
3. Daniel D. Gajski. Principles of Digital Design. Prentice Hall Inc., 1997.
4. Bernd Steinbach, Dominik Fröhlich, and Thomas Beierlein. Languages for System
Specification, chapter UML-Based Codesign for Run-Time reconfigurable Architectures, pages 5–20. Kluwer Academic Publishers, 2004.
5. Bernd Steinbach, Dominik Fröhlich, and Thomas Beierlein. UML for SoC Design,
chapter Hardware/Software Codesign of Reconfigurable Architectures Using UML,
pages 89–116. Kluwer Academic Publishers, 2005.
6. University Irvine, Center for Embedded Computer Systems. SPARK: High-Level
Synthesis using Parallelizing Compiler Techniques. http://mesl.ucsd.edu/spark/,
April 2004.
7. Xilinx Inc.
Forge - compiler for high-level language design.
http://www.xilinx.com/ise/advanced/forge.htm, 2003.
DAC Workshop, Anaheim, June 12, 2005
29
30
UML for SoC Design
Using UML Activities for
Synthesis on Reconfigurable Hardware
Tim Schattkowsky, Jan Hendrik Hausmann, Achim Rettberg
Paderborn University, Germany
1 Introduction
The Unified Modeling Language (UML) [3] has become the de-facto standard in
software systems modeling. Especially with the recent additions to Components and
Activities in the upcoming UML 2.0, we also see a large potential for application in
hardware design. For software systems, executable UML approaches like xUML from
Kennedy-Carter [4] target towards direct code generation from UML models for
software systems. The comparable XTUML approach from Project Technology [2] is
already moving towards generation of hardware specifications. Both approaches are
fully object oriented and employ synchronous object-oriented operation calls to model
system behavior (expressed by StateCharts)
However, hardware systems differ in several crucial aspects from software
systems. The application of UML for hardware design has to account for these
differences. Unlike in software systems, the number of instances for a particular block
in a hardware system is always determined. Inheritance, a fundamental concept of OO
software, is usually not present in hardware systems. Finally, asynchronous data flows
are essential in hardware systems and provide the coordination between concurrent
blocks. This does not match with the usually synchronous behavior of object oriented
systems. The token semantics provided for UML 2 Activity Diagrams are better
suited to express this kind of behavior (see, e.g. [5]).
Figure 1: Design Approach Overview
DAC Workshop, Anaheim, June 12, 2005
UML for SoC Design
31
We present an approach on hardware systems design based on interconnected
components (see Figure 1). These components may be assembled using aggregation
and composition to form a complete system. Each individual component may provide
and require several interfaces and its behavior is specified in terms of UML 2.0
activities. Component types are defined using Class Diagrams. Thus, the whole
design approach only relies on Class, Component and Activity Diagrams. The
resulting design models can be used to directly generate Handel-C code for hardware
synthesis.
2 System Specification
System
ComponentA
AnActiv ity
«delegate»
ComponentB
«delegate»
«delegate»
SubComponent
ComponentC
Figure 2: System Description using Component Diagrams
We employ a subset of UML Class Diagrams to provide type definitions for blocks
of synchronous logic. Components in our approach are instances of these classes
defined by their exposed interfaces. Each such block type is a special type of active
class where the class behavior is defined through a single private activity. This
activity may call sub-activities on the same class.
The complete system is assembled from components through composition or
aggregation. As dynamic instantiation is not possible in hardware, the concrete
assembly of a particular System on Chip (SoC) has to be determined at the design
time. This is described in our approach using a Component Diagram (see Figure 2).
Each component may expose required and provided interfaces. The behavior of each
component is specified as a UML Activity Diagram. Thus, the interfaces are defined
by the input and output parameters of these activities, which define typed token flows
at the model level and are comparable to electrical interconnects for typed data.
However, the token types are limited to primitive types (e.g., integer numbers) and
records composed from those types. Additionally, interfaces may expose attributes
which are equivalent to registers.
DAC Workshop, Anaheim, June 12, 2005
32
UML for SoC Design
AnActiv ity
Action1
Action3
RequiredInterface
ProvidedInterface1
Action2
Action4
Implicit
Replication
SubActiv ity
ProvidedInterface2
Figure 3: Activity Diagram mapping Pins to required and provided Interfaces
UML Activity Diagrams (ADs) represent activities and model behavior in terms of
data and control tokens flowing between executable nodes (see Figure 3 for an
example). Input and output pins describe the incoming and outgoing tokens for each
executable node. Such an executable node may be a single action (e.g., reading a
value or evaluating an expression) or a complete nested activity. Actions are the basic
units of computation used in an activity. Actions can execute whenever their inputs
are available. During execution, an action produces a set of tokens on its output pins.
Actions can also encapsulate more complex behavior, i.e., they can represent the
execution of nested components. This allows for a stepwise development of new
components as well as for the integration of existing blocks.
UML 2.0 introduces the concept of token competition where an output pin
provides its token to the first connected node that can process a complete set of
inputs. For hardware systems, it is more intuitive to assume the token to be replicated.
This corresponds to multiple blocks connected to the same output. In UML terms, we
assume an implicit fork for output pins. This assumption also enables the consistent
handling of data and control tokens in our approach, especially during code
generation.
3
Code Generation
Celoxica Handel-C [1] is a behavior-oriented programming language for hardware
synthesis that compiles directly to a Field Programmable Gate Array (FPGA). The
behavior is described in C-style syntax using essentially value assignments based on
registers and internal and external memory grouped by control constructs. For
DAC Workshop, Anaheim, June 12, 2005
UML for SoC Design
synthesis, the program code is transformed directly into equivalent gates and flipflops (e.g., for adders, multipliers, latches) representing the expression evaluation
trees and control logic. C-style flow control is achieved using conditional branches (if
and switch-statements) and loops (for, do and while-statements).
Handel-C code generation can be performed per component. A Handel-C function
is compiled from the component using a list scheduling algorithm to transform the
activity into parallel and sequential Handel-C blocks. Within these blocks, the
Handel-C functions of components implementing the required interfaces may be
activated by passing the respective tokens using communication channels. Thus, all
components are running concurrently and only interact through the implementation of
the token flows from the Activity Diagrams.
The code generation for a particular activity is essentially based on resolving forks
and joins to parallel and sequential blocks which contain do/while loops to implement
decisions. Hierarchically nested forks and joins are mapped directly to parallel blocks.
Forks and joins that break this hierarchy are implemented through explicit
synchronization.
4
Conclusion & Future Work
In this paper we have outlined a novel approach for model-based hardware design
based on UML 2.0 Activity Diagrams for modeling behavior. The approach enables
automatic code generation of synthesizable HDL for ASICs and FPGAs. Such code
generation has been sketched for synthesizable Handel-C code, but it is generally not
bound to a particular HDL. Future work will include the investigation of code
generation of other HDLs as well as a deeper evaluation of the approach in different
applications. Furthermore, the investigation of hardware/software co-design based on
our approach seems to be interesting
References
[1] Celoxica: Handel-C language Overview, http://www.celoxica.com, 2002.
[2] Mellor, S.J., Balcer, M.J.: Executable UML - A Foundation for Model-Driven
Architecture. Addison-Wesley, 2002.
[3] The Object Management Group: Unified Modeling Language: Superstructure.
OMG ad/2004-10-02, 2004.
[4] Raistrick, C., Francis, P., Wright, J.: Model Driven Architecture with Executable
UML. Cambridge University Press, 2004.
[5] Bock, C.: UML 2 Activity and Action Models. Journal of Object Technology,
2(4):43–53, July/August 2003. available at www.jot.fm.
DAC Workshop, Anaheim, June 12, 2005
33
34
UML for SoC Design
On the Integration of UML Sequence Diagrams and
Actor-Oriented Simulation Models
Leandro Soares Indrusiak, Andreas Thuy, Manfred Glesner
Microelectronic Systems Institute – Technische Universität Darmstadt
Karlstr. 15, 64283 Darmstadt, Germany
{lsi, glesner}@mes.tu-darmstadt.de, [email protected]
Abstract. This paper provides an overview of the ongoing work on integrating
UML sequence diagrams and actor-oriented modeling and simulation
frameworks. A case study using PtolemyII and its graphic interface Vergil is
presented.
1 Actor orientation and UML
This work aims to approach the problem of validating subsystems developed in UML
together with complex application testbenches. While many approaches have been
presented previously on executing UML models or generating executable code from
them, the approach presented here allows the co-simulation of UML models and
actor-oriented models which can represent (1) other subsystems that complement the
functionality described in UML or (2) the environment where the UML-modeled
system will be deployed. While both cases could be modeled completely in UML,
there are many legacy models which were already implemented using actororientation. For instance, in communication engineering there are many subsystems,
channel models, user mobility patterns already designed in SDL or Matlab/Simulink;
and in computer enginnering, most of the legacy subsystems are designed in HDLs
such as Verilog, VHDL or SystemC. As it is unrealistic to expect that new designs
will not rely on previous developments and legacy subsystems, the frame of this
research is to provide means for the co-validation of UML and actor-oriented models.
The definition of actor-orientation considered here is that of Lee et al. [1]. The
components in actor-oriented models are concurrent objects that communicate via
messaging, rather than abstract data structures that interact via procedure calls (which
is the picture in object-oriented programming languages). A distinct feature of actororiented models is the formalization of the concurrent behavior of model components
using well defined models of computation. While many actor-oriented tools like
Simulink or LabVIEW rely on a single model of computation, the PtolemyII [2]
project has provided a platform for experimenting with heterogeneous models
combining different models of computation.
In this work, we use the PtolemyII framework to integrate UML sequence
diagrams and actor oriented models. The composition of actors supported by
DAC Workshop, Anaheim, June 12, 2005
UML for SoC Design
35
PtolemyII is used to allow the description of the dynamic behavior of an actor using
UML. In other words, we encapsulate an UML sequence diagram within an actor. To
do so, we consider each of the objects of the sequence diagram as a role that will be
played by an external actor in the model. For each role, there is an interface definition
that includes the methods that must be provided and required on the communication
described in UML. This interface is then used to define the input and output ports of
the actor. Figure 1 depicts this approach. In Figure 1a, a simple UML sequence
diagram is presented. It follows the UML 2.0 notation for synchronous and
asynchronous messages. Figure 1b shows the PtolemyII composite actor notation of
the encapsulated UML sequence diagram of Figure 1a. Each synchronous message is
modeled as four ports in the actor interface: two input ports, one where the caller
actor posts the message and one where the callee posts the return; and two output
ports, one for the callee to receive the message and one for the caller to receive the
return. Similarly, asynchronous messages are modeled as two ports only, one input
for the caller to post the message and one output for the callee to receive it.
A
B
C
x
y
Ax
By
Cyr
Bx
Cy
Byr
yr
(a)
(b)
Fig. 1. UML sequence diagram and corresponding composite actor
2 Case study: PtolemyII extensions
In order to integrate the actor-encapsulated UML diagram within a simulation
environment, we follow PtolemyII architecture for heterogeneous composites of
models of computation. The actor encapsulating the UML diagram has its own
director, which schedules the incoming messages according to the UML-defined
communication semantics. At present, only the data dependencies and sequences are
being observed, but in the future we plan to investigate the support to real time
constraints described using the UML Profile for Schedulability, Performance and
Time [3]. Figures 2 and 3 show snapshots of an extended version of Vergil, the
graphical user interface of PtolemyII, including a basic implementation of the
presented approach.
DAC Workshop, Anaheim, June 12, 2005
36
UML for SoC Design
Fig. 2. Snapshot of Vergil extensions supporting UML sequence diagram
Fig. 3. Snapshot of Vergil displaying actor encapsulation of UML
sequence diagram from Figure 2
References
1. Edward A. Lee, Stephen Neuendorffer and Michael J. Wirthlin, "Actor-Oriented Design of
Embedded Hardware and Software Systems," Journal of Circuits, Systems, and Computers,
Vol. 12, No. 3 pp. 231-260, 2003
2. C. Hylands, E. A. Lee, J. Liu, X. Liu, S. Neuendorffer, Y. Xiong, H. Zheng (eds.),
"Heterogeneous Concurrent Modeling and Design in Java (Volume 1: Introduction to
Ptolemy II) ," TechnicalMemorandum UCB/ERL M03/27, UC Berkeley, 2003.
3. UML Profile for Schedulability, Performance and Time Specification. OMG, September
2003.
DAC Workshop, Anaheim, June 12, 2005
UML for SoC Design
UML based modeling of Process Classes for
System Level Design
Ankit Goel, K.D. Nguyen, Abhik Roychoudhury, and P.S. Thiagarajan
School of Computing, National University of Singapore
{ankitgoe,kathyngu,abhik,thiagu}@comp.nus.edu.sg
1
Introduction
Modeling, simulation and code generation from UML notations is a viable route for
pushing up the abstraction level in design of reactive embedded systems. A standard
approach in this context consists of grouping behavioral entities with similar behavior into a single class, using class diagrams to capture the interconnections between
the classes and specifying the behavior of a class -i.e. that of the objects grouped together into the class- with the help of state machine diagrams. In UML 2.0, the class
notion is considerably expanded and in the new “structured classes” interaction relationships between the sub-classes or even specific objects of the classes can be captured
by using entities such as ports, interfaces and connectors. It is however the case that
the behavioral aspects of the interactions is defined implicitly, via the communication
actions mentioned in the state machine diagrams associated with the classes. Protocol
state machines can be used in UML 2.0 to specify the allowed access patterns of an
interface. However this mechanism, bound to the ports of structured classes still has an
intra-component flavor.
In this paper, we present a modeling framework in which the interactions between
the classes of behavioral objects are described by sequence diagrams. We take the view
that interactions are naturally specified and analyzed if they have an inter-component
flavor. Even a single unit of interaction between a pair of components often involves
bidirectional flow of control signals, if not data. Hence we advocate the use of simple
sequence diagrams -a standard UML notation- to capture the unit interactions between
the classes. We note that a sequence diagram with its multiple lifelines is inherently
an inter-component based behavioral description. However, the execution semantics
of system descriptions must be intra-component based. In general it is quite a challenge to bridge the gap between inter-component based system descriptions and their
intra-component based executions [2, 4]. It is particularly so, when instead of concrete
behavioral objects one has to cope with, as we do here, classes of behavioral objects.
To be more specific, we study a system description framework in which, as usual,
similar behavioral objects are grouped together into classes, the behavior of a class is
described by state machine diagrams and the main structural relationships between the
classes are captured by class diagrams. The key new feature is, in addition, we use
sequence diagrams to specify the interactions between the classes at a behavioral level.
In this first stage of our work, we do not exploit the modeling features offered by
structured classes. We feel however that the relevant extensions of UML2.0 can be
DAC Workshop, Anaheim, June 12, 2005
37
38
UML for SoC Design
achieved in the future without any disruptions to the basic framework that we have
constructed. Our work is related to and strongly influenced by the Play-in-Play-out
approach to system modeling and executions based on Live Sequence Charts (LSCs)
[4]. There are also many other related works in the context of UML-based system design
methods (see for example [6] for references) but we will assess these in more detail in
the full version of the paper.
1
(Call,snd) (Call,rcv)
(Rlc,rcv)
2
3
(Ring,local)
(Ring,remote)
5
4
(Rlc,snd)
(Busy,local) (Connected,rcv) (Connected,snd)
(Busy,remote)
6
(Disconnect,snd)
(Disconnect,rcv)
7
8
Fig. 1. State Diagram for Switch
A
(Call,_)
B
(Busy,calling)
(Busy,called)
(Ring,local)
C
(Ring,remote)
D
(Busy,called)
(Busy,called)
(Disconnect,snd)
(Connect,remote)
(Connect,local)
E
(Busy,called)
Fig. 2. State Diagram for Phone
DAC Workshop, Anaheim, June 12, 2005
(Disconnect,rcv)
UML for SoC Design
2
39
Modeling and Simulation
In this section, we explain the key features of our work with the help of an example.
It consists of three groups of phones located in three different areas with each area
containing a switch through which the users can make both local calls and also connect
to phones in the other areas. The three switches are assumed to be connected to each
other. There are two main classes: Switch and Phone. In the actual system as shown in
Figure 3, we have three subclasses of the Switch class, namely, Switchi , i = 1, 2, 3 and
similarly the phone classes P honei , i = 1, 2, 3. For convenience, we have suppressed
showing the master Switch and P hone classes. Each of the classes such as P hone1 ,
Switch2 will contain a number of objects. Thus, the specification may contain the
information that there are 20 phones in the geographical area captured by the subclass
Switch2 ; however, the individual names/identities of these 20 objects in P hone2 are
not maintained.
sw_sw_connect
sw_sw_connect
ph_sw_connect
Phone1
Switch1
sw_sw_connect
Phone2
Switch2
Phone3
Switch3
sw_sw_connect
sw_sw_connect
ph_sw_connect
ph_sw_connect
sw_sw_connect
Fig. 3. Telephone Network Class Diagram
2.1
Modeling
In our setting, a class is a collection of processes with similar functionalities. Consequently, the behavior of a class is specified as a finite state machine. In general, the
actions specified in the transitions will describe both the computational and communication steps. Our focus is on the interactions between the classes and hence we will
suppress the computational aspects. A communication action associated with a transition will be represent a snippet of a protocol, namely, the part played by an object of
the class taking part in this instance of the protocol. Each such action will be a pair of
the form (transaction, role) where “transaction” is a sequence diagram together with a
set of constraints collectively called the guard of the transaction, and “role” is a particular lifeline in the sequence diagram. For example, in the state machine of the class
Switch shown in Figure 1, the transition from the state 1 to 3 has the communication
label (call, rcv). The transaction call in turn is specified in Figure 4.
DAC Workshop, Anaheim, June 12, 2005
40
UML for SoC Design
We note that the “call” transaction also has a second role called “snd” which will
have to be assumed by some other object of the switch class and this object will also
have to be in the state 1 and will go to the state 2 when the “call” transaction executes.
As this notation shows, for convenience, we have abstracted away the inner workings
of a telephone switch and view its various components as simply objects belonging the
Switch class.
The state machine for the class P hone is shown in Figure 2. One phone object, say,
ph0 will have to be in state A and two switch objects say sw-snd and sw-rcv in state 1
for the transaction call to execute. When it does so, ph0 will go to the B, sw-snd will go
to the state 2 while sw-rcv will go to the state 3. Thus multiple objects belonging to the
same class -possibly residing at different control state in the state diagram- will assume
different roles in a transaction. Of course more than one class can contribute objects in
the execution of a transaction.
(phone, )
(switch,snd)
(switch,rcv)
offhook
dialtone
digits
iam
acm
waittone
Fig. 4. The Call Transaction
We allow a variety of constraints to be expressed to form the guard of a transaction
which decide whether a transaction is enabled for a particular assignment of objects to
lifelines. They are as follows. To avoid clutter, we have not spelled out the constraints
associated with the “call’ transaction shown in Figure 4.
1. History constraints specified by regular expressions which demand that for an object to play a certain role in a transaction, the sequence of control states it has gone
through to reach the current control state must fall within the language of the regular expression. Such history information can also include truth values of predicates
concerning the values of the local variables possessed by the object.
2. Relational constraints between the objects assuming two different roles in a transaction. These relations could be static ones such as proximity (a phone object in an
area can only connect to the switch in that area) or dynamic ( for a phone object
and switch to engage in the disconnect transaction, they must be currently in the
“connected” relation).
In addition, the messages exchanged by the lifelines of a transaction can also be
parameterized with their values determined at run time by the binding of the objects to
DAC Workshop, Anaheim, June 12, 2005
UML for SoC Design
the lifelines. As mentioned in the preceding, the guard of a transaction decides whether
the transaction is enabled for a particular choice of objects for different lifelines. But
since we do not keep track of identities of objects, what do we mean by a choice of
objects ? This brings us to our notion of “behavioral subclasses” which is crucial for
our execution semantics.
2.2
Simulation
Our execution semantics is a symbolic one and crucially uses the notion of behavioral
subclasses. We avoid representing the name space of the concrete objects unless the
specification itself singles out concrete objects. Instead, we group together subclasses
of objects according to their potential future behavior and often this will depend only on
their past. Thus in the example shown in Figure 2, at the initial state all the objects belonging to P hone1 will reside at state A. Suppose now the transaction “call” is executed
with (switch, snd) and (switch, rcv) being bound to (different objects in Switch1 and
phone being bound to an object in P hone1 . As a result of the transaction, the P hone1
class will split into two behavioral subclasses: one residing at A representing all the
phone objects in P hone1 which did not take part in this transaction, a second subclass
representing the phone -but whose name is not kept track of- that took part in this transaction. The actual creation and merging of behavioral subclasses is more involved but
this is the essence of the idea. In addition, our simulation must also keep track of the
history information (but only a bounded amount) as well as the static/dynamic relationships between (behavioral) subclasses.
The symbolic execution mechanism is the main distinguishing feature of our model
in contrast to other works [4, 8]. In [4], the concrete identities of processes of maintained
and this leads to a blow-up of the number of chart-copies, while in [8] this blow-up is
reduced by maintaining constraints on the process identities.
3
Implementations
SystemC Translation We have constructed a translator for a subset of our language
through which designs can be automatically converted to SystemC code. This subset is
quite restricted in the sense each class is assumed to consist of a finite set of concrete
objects. Furthermore, only very primitive and purely static relationships can be specified
between the objects that can play different roles in a transaction. One of our future
goals is certainly to extend this translator to handle the full language. Experimental
results obtained via this translator can be found in http://www.comp.nus.edu.
sg/∼kathyngu/CTP2SystemC.pdf
Customized Simulator For the full modeling language we have constructed a customized simulator and we have experimented with non-trivial examples of reactive
control systems with many similar processes. For initial experiments, we modeled a
simple telephone switch drawn from [5]. It consists of a network of switch objects with
the network topology showing the connection between different geographical localities. Switch objects in a locality are connected to phones in that locality as well other
DAC Workshop, Anaheim, June 12, 2005
41
42
UML for SoC Design
switches as dictated by the network topology. Next we modeled the rail-car system
whose behavioral requirements have been specified using Live Sequence Charts in [2].
This is an automated rail-car system with several cars operating on two parallel cyclic
paths with several terminals. The cars run clockwise on one of the cyclic paths and
anti-clockwise direction on the other. This example is a substantial sized system with
a number of process classes: car, terminal, cruiser (for monitoring speed of the cars),
proximity-sensor (for checking whether cars are approaching a terminal) etc.
We have also modeled the requirement specification of two other systems - one
drawn from the rail transportation domain and another taken from air traffic control.
We now briefly describe these two systems. The automated rail-shuttle system [7] consists of various shuttles which bid for orders to transport passengers between various
stations on a railway-interconnection network. The successful bidder needs to complete
the order in a given time, for which it gets the payment as specified in the bid; the shuttle needs to pay the toll for the part of network it travels. If an order is delayed or not
started in time, a pre-specified penalty is incurred by the responsible shuttle.
The weather update controller [1] is a an important component of the Center TRACON Automation System (CTAS), automation tools developed by NASA to manage high
volume of arrival air traffic at large airports. The case study involves three classes of
objects: weather-aware clients, weather control panel and the controller or communications manager. The latest weather update is presented by the weather control panel to
various connected clients, via the controller. This update may succeed or fail in different
ways; furthermore, clients get connected/disconnected to the controller by following an
elaborate protocol.
For each of the above examples we have performed random/guided simulation.
Detailed results of these simulations appear in the technical report [3] and the simulator can be downloaded from http://www.comp.nus.edu.sg/∼ankitgoe/
simulator.
References
1. CTAS. Center TRACON automation system. http://www.ctas.arc.nasa.gov.
2. W. Damm and D. Harel. LSCs: Breathing life into message sequence charts. Formal Methods
in System Design, 2001.
3. A. Goel, A. Roychoudhury, and P.S. Thiagarajan. Dynamically grouping active objects based
on behavior. Technical report, National University of Singapore, 2005. http://www.
comp.nus.edu.sg/∼abhik/pdf/TR-05.pdf.
4. D. Harel and R. Marelly. Come, Let’s Play: Scenario-Based Programming Using LSCs and
the Play-Engine. Springer-Verlag, 2003.
5. G.J. Holzmann. Modeling a Simple Telephone Switch, chapter 14. The SPIN Model Checker.
Addison-Wesley, 2004.
6. K.D. Nguyen, Z. Sun, P.S. Thiagarajan, and W.F. Wong. Model-driven soc design via executable uml to systemc. In The 25th IEEE International Real-Time Systems Symposium. IEEE
Press, 2004.
New rail-technology Paderborn.
http://wwwcs.
7. Shuttle Control System.
uni-paderborn.de/cs/ag-schaefer/CaseStudies/ShuttleSystem.
8. T. Wang, A. Roychoudhury, R.H.C. Yap, and S.C. Choudhary. Symbolic execution of behavioral requirements. In Practical Appl. of Declarative Languages (PADL), LNCS 3057, 2004.
DAC Workshop, Anaheim, June 12, 2005
UML for SoC Design
!#"%$&"'(*),+-
. /$0)1**)1+2+3!#"4657)189
#8: ;<>=(<>?>=A@CB>=(<EDF=HGI:=KJMLONQP>RS=HGUT4V4WXWZYA[\=(]^YHWXY_NQP>=H<>?RS=(LEGUYa`,GUV4bKYKJMcedX<EdXf
gA‹ h:iyzjlkŒm4knzmpŽMoC~Kqp‰zrMm‚s^tv‡qpr^uUtvr^uxwwzt‘s“’yz{|qp”\uUknr^tv•K}/m(–‡~_m4‚€qKr^~‚tv‚kn}x•Kue–‡s^qQm4A‚qKh:~Cƒ|Š(—,„Q…‡t‘s^†˜xˆ‡uU„(r^™š~_m4‰9_›ŠHy
w–4œtvrMo‚€mp™v{|u
žxŸx{›K ¡_uxmpw¢poKtvŸQ–p™vu£ #w7qQ}e©K™š™vm4•HqQss^tv”¤tš}xq4qpuxr^‚w{¥w\tvmp#o_oKm4qp™vwu rMu/›Ks^›'q:uer›H}xuxqps^wqaªCtv–Qu {¦—,m4r^t‘ux¬‡s^§(©¦u|•Ks^t‘t‘s©Kr^uxu ªCwO}xqQs^•Hwqzwrtvr^r^o‚uxux™vFw¨uss€r^s^}xtvqa}UqQs€{|}xs^qQªK©K{|™vu uUu|­H(tv•‚s“•K{¦’9ªqpoC—,”EuUrOŠ(t‘s^’Hq4©#”Cw¨s^ªCªKuxr^qQ{®qpw¨«««
s^qp¯ ©K™šqpHuz–p«¨”¶j’|m4©K}U{¦stvª±•‚s^w¨©‚°²s\Š(m4ªKs,qFr^j1m4q*³9(tš›Kue›K·Euxu,wuxtvm9}U–ps^‚wtvªC‡wxuµ´nux}xh:i7t‘»‚q/™vux}¼—1}Uwsmp•Kr^›‚qpª‚mx‚ªC’Htvq4wµ}rs^s\Š(©‚’H”XuUqpw¨r^rs^u®uxª‚{¸tv™šwm4knsm
”XuUqp‡–pr^uxux{½‚™€ue°¹wrMiºªCmpŠKux™ }xkO}Ut‘»_³\qQ}/‚›Kmwuxs^uUwtv‚tvqQ–pwn
•‚~(wµ{|©‚s^m4uUq/rMs^—›(©K—1m4q(rM›Hm4› ««
r^s^uq
¾mpwqp™v™v”Zq/s—¿—1m4›Hr^uxu¦wtvª_–QmKruUs^r^tvs^wµtvqps^‚q
tv‚ue­K–ªKm4™vqQ_t‘›sµªHs^©‚r^qQu–pªCrMm4qp{|s^uU{(s^m4tšm4s^tv™š}9w9tvq4F”s^uUw¨sMrm”¶m4s^}xuUux«²qpw¼”Xw¨«¹s^’K©KFuUs^«“©Km4uxrwsµtvw¼s^uxtvA}M©‚q4KrMqQ›K™vuUqpr«
–poKtš•‚uUtvwx™š´C›KtvŽÀ‚–s^©KKtvuUw¼—— qpm4r^r^¬
}M©‚— t‘s^uux}eªKs^r^•KuxrMwmpux™zFs:ª‚™šm®m4s{|”XqpuUr^s^{|©‚w|q(›Hs^qQq™vqQoC–4ua’
•Ks^©‚wu/m4›±sz™vtvuxÃ‡uUs^rM©‚m4ua–Quxw¨wz’Hw¨qQs^Aux{‰µÁA›Huxkwtv”¤–Qqp r
ªHªKr^™ZmqFs}x”¤uxq4wr^wx{|´‚wµÄoFuµ’w©‚mQq/›K—Å›Ktv‚©‚–q/—Ɓ‚ueqp—•Kr,m4{|r^}MuU©‚s^t‘s^©Kuxq(}U›Ks^qQ•H™vrMqpmp–p™€’
}xqp}/{|mpªCmpqQ™vK™vqux—ŁFs^wµs^q¦mp‚r^uU›a•‚wo(u9’AªK}xr^•‚uew¨«Às^›Hqpux{|wtv–Qtš˜UKtšKu/›–
s^©Kuxt‘rztvFs^uUr^}xqp‚Kux}Us^tvqQKwx´
Ç È‚É¼ÊCËEÌ9ͦÎόÊEÐ^̼É
Ñ=(dXBEÓAV,JÒEceGUYYHҌ=HYKJUJeJMVpd¤J^?'cÓAceBEVVAcUBE?CYCVp?CJeYHdXÔHWXYH<EÔKVpÕGWXdZV4<SbHVpceBEGU=HVÔHB>VQJn=(GxYK?C<®Ûµce=(BEGUVzV‡;Ü(JMÖ:YHݶ×zceÛµ@®=(TGUYCV¦?CVQÒ>JM=HdXGMÔHcU<®dšcUVpdZYK<‚<Eb_dXdX<EGeYKÔÞÓA=(V4<n<‚?#c,ؚ=(Ù4GxÚKTxÛ9BEdšBEcUd¤VpTxTB ß
ceT4LE=(GU<ÞVänJMV'VpWZÓaVQT/=(cUdZÒEYKҌ<
VpÒE?ÞBnYH=H<‚JeceVpYJpàF=|á<cU=HØZGeÙÔKÚnVÛzcµV9=(GxJeBETxBEYFdšÛzcUVpVQT?*ceLEB>GxYF=(ÛâW>ce='V4ÓAݹLEÒE<>W¤T=FcecUdXYHV<>cU=HB>W>=FJec9ÒnT4VQ=HT<ÞdZãnäŒT4=(V'ceJedXYHV4WX<VpTY(ce݀VQ='?AJeݹÕCGeYKJ^cUÓåV4Ó =
ceWZdXLEäEGxGx=(á=(WO<SGUÕæcUceV4B>ÓAYHdXÝ,J®ÒEÒEW¤Ò>=FGe=HV4ceVQߨÒn?EJ9VpVpG®ÛµJedZÛz=HÔKJ:V<EÒEVpÒE?GUGUYFVpcUb‚JeV4d¤V4ÓA?C<‚VQc®ÒE?ÞW¤=æ=FdXcU<ÓAVpJpceVàŒB>cUç=(BEcYCYæ?CÛzJeYHYKLEWXGeYHÒEDOÔKҌà ÕæYHGecUc¦B>ݹ=FYKcG=HcUWZBEWXYFV
ÛT4JGeVQcU=FYcedXã>YHWZ<ÃW cUY(BEÝ,dXJ®<EVpԂÛè=(Ò±=(Gxä‚TxÕ#BEdšÒ>cUGeVpYHTßß
b‚WZYFd¤Û¿?CdX<E?CÔAVpJecedZB>ÔKV|<EV4ÓGxJ:VQ=(ceY<>J:JeҌcUYaVpT?CdZݹVpÕÞJedZ<>ÔKV4<Ûê<EV4=(Û¿GxTxBE=(dšGxcUTxVpBETdšcecULEVpGxT=(ceLEWOGxÒE=(W¤=FWOcecUݹV4YHÓAGUÓAÒEW¤Jµ=Fceä_VQÕJ4à TÑYHÓ
BEV®äEdXÓA<EdZ=H<>dZÔ<#Ò>=HGedZV4Óéߨ?Cd¤VQJµJMcUdXÔHY<>=(VpWZ? ß
ÒETYHWX=(ÓAcMݹҌYKYHGe<EÓaVpJ<‚cU=(JA<>WX?âdZDKTV±L>Ö:JMce`¼YKÓïdXJpë4P,VæäEceLnB>JMV4VQÓìJa=(ä_<>ÕÆ?ð=HB>?E=H?EGUdZ?C<EÛµÔí=(=(GUV<n?lLE<EGeVpdZcUÓAJpàzYFb‚@_dXҌ<EVpÔîTdZJMãnVpT#WZVQáT/<‚ceVQcUV4?ÅWXWZVQ=HT/GUceTxLnBE=(dZceWVQT/`¼cUGeLEYKGUÒC=HßW
ceV4dZ<‚BEGecec^V¦VpÕîGUã>T4ñ²<>á^YH=H`z<EWnòµ<>ÒEVpäEW¤T/=FWXcUYCcedZݹTxYKYHDC<æGUJÓóÓAT4=HVQdZ<<STxB>YK=(=(GUW¤<EJM?EYad¤V4JeG,ÓAäŒcUV
J:Y*cUJeÒEÒnYGUVQceYFTBEb_dZã>V|dX?EVpYFV?#bKÒEV4=(GUGxcYH=(ceÔHWXWŒB>Gx=H=(VGUÓAݹTxLEBEÓa<>dZce=(TVQä>ceT/dXWZYHcUV9LE<>GUGe=HLEVKW\<Cà WXßÀV4cebKdXÓAV4WºV'=HT4<>YH?#<Cã>JeՂÔK<‚LEcUGxBE=FVpceJedXYHdZëp<aVp?=H<>dX<?
ô õîö÷êøË>Ì,ø|̼ù‚÷\ÍÍ÷ºù‚ÐMú¼Éüû¦Ìºý
ceþ BEdXÔHV®L>cUGeYHVAÒ7ÙPCYKJe<æBEYFcUÛBEV®J:ceWZV4BEݶV|cÒ>Û:WXV'=(cMBnݹYH=‡GUbHÓÿV¦ceÔKBEV4V®<EݹVpLEGU<n=(ceT/dXceYHdXYH< <n>Y=(FW7Û½JeÒndXVQ<TdZYHãnLET4G=(ceÓdXYHV4<ceBEY(YCݺ?CceYKBEWZVYKÔHT4ÕKYHà>ÓA@‚ÒncU=HYKGM<EcUV4dZ<‚<EcxÔJ:ݹceGUB>YH=(Ó c
DAC Workshop, Anaheim, June 12, 2005
43
44
UML for SoC Design
>BJMҌ=‡VpbHT4V¦dšãnceYATp=FäŒcUdZV'YK<dX<>JeYHV4ݺGecUceBEVQ?ÞVä>dX<Þ=KJMcUd¤BET|V®=(<EGxTxV4BEÛ¿dZce=(VQGxT/TxceBEL>dZGUce=HVpW7TceTLEYHGxÓA=(ҌWŒYHÒE<EW¤=FVpce<‚ݹcUYHJ:GUÓceBnà=F¦<cæÛ:V|ceB>Û:V'=HGU<‚dXÔHc9B‚cec:YaÛ:B>V®=‡bKB>V'=‡bHdX<V¦ceceB>B>VV
ã>?C<>VpJU=(TWCGUÒ>dZäŒWX=(VpcM?ݹYHdXGU<ÅÓØZàÙÚÑ =(BE<>Vp?JeV:cUc^BEÛzVY®Ý¹YK?CWZd¤WX=(YFÔHÛ9GxdZ=(<>ÓaÔaJ B>=(=(GUGxV¼?CcUÛµBE=(V4GU<V‡ÜFdX<EJeÒEY(ݶLCcUc,Û:dX=H<‚GeceV¦Y'Ò>ce=(BEGeV9ceT4dZceY_dXYH?E<>VpJedZ<EdZÔKÔæ<*=(V4<><_?b_dXdXGe<‚YKce<EV4ÓAGeݲ=HV4<‚T4Vc
cedZJM<‚BEÕ_ce<‚V®YceäŒBEcUY(VQBEcMJMV|cUd¤J|YHWZdXÓéäEJMceGxV4YH=(ÒnÝGUJ®Õþ ÒndZY(ÔKVpÝLEGM=(ݹGUYKGxV
TxGeBEÓAÙ'dZceÛ9VpVp?±BETced¤dXTxLE<±BGxcU=(T4BEWŒYHd¤cUGUJ|V4GeÓAVQV4JM<_ÒEҌb_W¤YHdZ=FGU<>ceYHVQ?><>J9J1ÓÒEceVpYaGU<‚YF=
c®b_dX<EGU?CVpV4VQJeÛ½?LEWZä_ÒEc|ÕæWX=(dZ<îcM;ݹYKceÖ:B>Ge×:ÓóVA@O?EcUà dXB>=H=FÔHcGx=(T4Ó=H<ÞJeäŒBEV|YFÛ9=H?E<Ã?CYKVQ<?
Top level view
Processor
Tile1
Tile2
B
U
S
H/W
Software1
(V850)
Bus1
UML specification
of a single Tile
Library of
architectural
components
Bus2
BusIntfc1
Mem1
Memory
Software2
(V850)
Mem2
Hardware1
BusIntfc2
Hardware2
tile_top
SW2_packet_valid_I0
SW2_input_payload_I0
SW2_input_header_I0
SW1_O_valid_out_a00
SW1_O0_payload
SW1_O0_header
SW1:SW
SW1_input_header_I2
SW1_input_payload_I2
SW1_packet_valid_I2
SW2:SW
RE_O0_header
input_header_I0
RE_O0_payload
input_payload_I0
RE_O_valid_out_a00
packet_valid_I0
RE_O1_header
input_header_I1
RE_O1_payload
input_payload_I1
RE_O_valid_out_a01
packet_valid_I1
RE_O2_header
input_header_I2
RE_O2_payload
input_payload_I2
RE_O_valid_out_a02
packet_valid_I2
RE_req uestAccepted
<<net>>
input_header_I0
RE_O0_header
input_payload_I0
RE_O0_payload
packet_valid_I0
RE_O_valid_out_a00
input_header_I1
RE_O1_header
input_payload_I1
RE_O1_payload
packet_valid_I1
RE_O_valid_out_a01
input_header_I2
RE_O2_header
input_payload_I2
RE_O2_payload
RE_O_valid_out_a02
packet_valid_I2
RE_requestAccepted
<<net>>
Initial architectural platform
SW2_input_header_I2
SW2_input_payload_I2
SW2_packet_valid_I2
1
1
SW1_input_header_I0
SW1_input_payload_I0
SW1_packet_valid_I0
SW2_O0_header
SW2_O0_payload
SW2_O_valid_out_a00
SW2
SW1
1
itsReceiver:receiver
O_offset
I0_H
I0_P
O_payload
I0_valid
requestAccepted_a00
I1_H
requestAccepted_a01
I1_P
requestAccepted_a02
I1_valid
requestAccepted_a03
I2_H
I2_P
I2_valid
I3_H
I3_P
I3_valid
<<Partitionable_Text>>
1
object_0
port_0
port_1
port_3
receiver
pkt_gen
port_2
port_4
SW4:SW
SW3:SW
SW3_input_header_I2
SW3_input_payload_I2
SW3_packet_valid_I2
SW1
SW2
SW4_input_header_I2
SW4_input_payload_I2
SW4_packet_valid_I2
1
1
SW3_packet_valid_I0
SW3_input_header_I0
SW3_input_payload_I0
SW2
SW1
SW4_packet_valid_I0
SW4_input_payload_I0
SW4_input_header_I0
SW3_O_valid_a00
SW3_O0_payload
SW3_O0_header
input_header_I0
input_payload_I0
packet_valid_I0
input_header_I1
input_payload_I1
packet_valid_I1
input_header_I2
input_payload_I2
packet_valid_I2
RE_req uestAccepted
RE_O0_header
RE_O0_payload
RE_O_valid_out_a00
RE_O1_header
RE_O1_payload
RE_O_valid_out_a01
RE_O2_header
RE_O2_payload
RE_O_valid_out_a02
input_header_I0
input_payload_I0
packet_valid_I0
input_header_I1
input_payload_I1
packet_valid_I1
input_header_I2
input_payload_I2
packet_valid_I2
RE_req uestAccepted
RE_O0_header
RE_O0_payload
RE_O_valid_out_a00
RE_O1_header
RE_O1_payload
RE_O_valid_out_a01
RE_O2_header
RE_O2_payload
RE_O_valid_out_a02
receiver
SW4_O0_header
SW4_O0_payload
SW4_O_valid_out_a00
V850
pkt_gen
receiver
V850
pkt_gen
SW4
SW3
<<net>>
<<net>>
Bus2
Bus1
<<top_level>>
BusIntfc1
BusIntfc2
Mem2
Mem1
Hardware1
Hierarchical functional
specification
SW3
Hardware2
SW4
SW3
SW4
£_£ 7™Zms”¤q4r^{–pux‚uerMm4s^tvqQA”Zr^qQ{è‰9ÁAkÞwªCux}xt‘»_}/ms^tvqQ‚wx´
Synthesized architectural platform
!#"$%&'$)(*&+)",-./01243)/53%&6"768(
ecYH¦äV4ÔHCGUÕ#Óa]^Vp=HJT<>cYH?#Ý1ÓÒEänYCGUYH?CY(cecUVpBÃY_W¦T4dX?C<‚YHd¤ceWº=(VpL>ÔKGeGUJM<>VQ=H=H?#ÓaW\B>JaݹYK=HG¦=(GUGU?EdXV#<‚Û:ceL>=HV4GeJMGxVFVQT?âÜFYKJe<EY(ݹ<EYHݶVQceGÞÛµT/ceJe=(dXÒn<EGUVQV¦ÔTݹdZ?CVpݹÕ_d:=F9OdZcU<EV4LEÔÆGUGUV4Vp<‚ceJBEc®=KVSJMJLEÒ>Û:äEWXߨ=(V4=HWXcMWGUݹYHTx=KBEGUJÓ6dZcedXVQ<#T/T4cUceYHLEVp<CGeGeãnÓaVQÔHJ4J¦LEà GxÑ Y(=FÝBEcUdZced¤YKJ¦YK<âÒnd¤J'YKdXWš<= ß
BEÒndZVQVpT/GUcU=HJGUYHTxB>ÝEdXceTpB>=(V:WºÒ>?EWXVp=(JUcMTݹYHGUdZGUÒCÓ cUdZYKWXdZ<ÃDKV¼TcUYKBE<‚VµcU=(ändX<EVpB>dX<E=‡Ôæb_dZ=æYKGºJMYHV4Ý>c'B>YH=(ݼGxT?CW¤Ûµ=HJU=(JGUV,dX<>á^JM`îcU=HT<>YHTGUVQVpJJpP ÓA; YCÑ ?C®@V4WX
dX<ETÔYK<CJeã>V4bKÔKV4LEGxGU=(=(W cedX=HYHJM< ß
GeB>YK=(LCGxce?CdXÛµ<EVp=(JpGUPHV'ÓA=H<>VpÓ?æYKJeGeY(ÕAݶc^ÛµÓA=(YCGU?CV'LEá^WX`¼VpJpJµPKdXÔK<æWZL>cUVBEV|WZYKÒEÔHd¤W¤T=Fce=(ݹYH<nGU?Ó?Cà V4b_d¤TV'?CGedXbHVpGUJ1ݹYHGzT4YH<E<>VpT/cUdZ<>Ô
?Cd9ŒVpGeVp<‚c
ÓY(Ý YC?= ?CÑ Vp>‡BEWEߐVA?C?CdXd¤ceÓA=(YKÔHV4ÒCGx<>ßÀ=(WXJeÓèVdZݶYKc<>?E=(ÒEVpWOJUd¤T/T<EceGUV4L>dZäEc^GeÛzdXVa<EYKÔ'YHGeÝDAceB>þ YKVµdX<ÔHT4LETxYHBEGUÓAV#dXÒæÓ*ÙÞ=HL>JeGU<EBETxdXB>YFTpdšÛ=FcUcUVpJ|dZT/YKcU=(<
LE<lGUÛ9VH=V Gxà<E=(Ñ=(ÒEÓABEҌV'V4ÒEGxWXc^JVaÛzY(Y(Y
ÝnÝc^ceÛz=dXWXVpY¦BEJ9cedXV4=(dXWZGxGUVQ=(V'JGxdXTxce?CBnBEVpdX=F<‚Tpc,=(ced¤=(W1T4GUYK=(VzW€äCÒn]^=HVp=(<>TGe? cc
T=HYH?‡<n]M=KJMTd¤J^V4c:<‚Y(c®Ý7ceݹdXYKWXVpLEJ®GµdXJM<ÃÛ9cUdZcUBETxVABEVQ<EJ:Vc^L>Û:JMYHVQ?AGUDOݹàOYH;&GµdXÓAGUVpÒET4V4WZVpdXbHÓAV4V4G®<‚LEcedX<><EdšÔ
c|ceÒEBEGUV®YCTTVpYKJUÓJeVpÓ
J'LEdZ<n<ETd¤T4YH=(ÓAcedXdXYH<E<ÔÛ9Ò>=HdZceTxBÞDKVcecxBEJV¦Ý¹Ý¹GUYHYHLEÓ G
ݹ=(YHWXW>LEݹG9YKҌLEYKG:JUJeJMÛ9dXäEdZWXcUV|TxBE?CVQdZJzGUVp=HT<>cedX?YH<>=*JpJeà V4<n?CV4G:LE<EdZcµ?EV4WXdZbKV4GxJ¼=Òn=HTxDHV4c,ceYA=(<>Y(ceB>V4G,cUdZWXV'dZ<YK<EVYHÝ7ceB>V
DAC Workshop, Anaheim, June 12, 2005
UML for SoC Design
( /0 & #*&+'$%(*&+)" 3)/ 42/0 3)&+7"762(
"/0)/ *&+' ( /0& #6&+)(
EÒWZÑ d¤GeJ^BEc®YKV
ÒnY(Y‚?CÝzJMVpÒEVQÒE?SGeWXVQYF?CÓAՂVÓAVãncUVp<EBE<KVpYCc'?Ã?C?CYHÒEdXWX=HWXYH=(ÔHÔKcMGxÕHݹ=(YKà€ÓGeçÓaYKT4J¦Ge=HÓace<#Y=HänWZänWXV
ÕVAL>ceTJMBEYKVQVA<>?JeL>dXce?CJeYV4VpG®GeJMVQҌB>?#Vp=KT4dXJ¦dš<ÃݹÕ#ceY#cUBE=ÞJMVVpÒEWZT4WXVQ=(YCT/cM?CcݹVpYK=(JeGedZ<îÓÔK<S=(=(GxÒEGxTxTxB>BEBE=KdZcedZJMceVpVKVpTàTceceLEÑ LEGUBEGUV
VVpJeݹdXGeV
<SYKÒ>Ó YHGeL>V4= Gß
?CÖ:V`¼ã>ï<>VpJp?âPEB>ÒE=HWXGU=(?EcMÛ:ݹYK=HGeGeÓaV'JaV4WX=(V4GUÓAVV4JM<‚BEcxYFJÛ9=(<ð<>?=HJaÓAVp=HÓ<ÅYKdX<KGedXcUVpV4JpGxPETTYKYK<E<E<E<EVpVQTT/cecedXYHVQ<â?ä‚Y(ÕæݦBnÓA=(VpGx=(?C<nÛ:J9=HY(GeVæÝ1äEGeL>VQJMJeYKVpLEJGxYHTGVpJ
?CVQWXdZ?CDKdšV ß
ÓT4JMҌ=FYCcUYHVp?C<>?|L>?EWZҌdZV<EYHÔ*V4dX<‚dZV4cecMWXBEßÀV4ceVpÓAYHGßÀV4ҌcU<‚YæYHcUdXJ,Bn<‚dZ=(c <aGxT?CcUYKÛ:BE<EV=H<EGeVQ=HV|T/GUceTxYKdXBEYHG'dZ<nceJeVQJ4Y(T/àݶcUc^LEÛµVpGU=(Òn=HGUVpWCVH<>ÒEP>?CW¤ce=FdXBE<EcMVݹÔYKÓAGeYKÓ<YCà?CcUBE¥LEV¼WXVpdšL>cUJ'BJe=(V4GeGGUVQV
JºJMҌ?CTxBEVpVpTÒEYKc1WZdXYFT4ceV1ÕKYÞVpce?Y¦ØZÙÚ¨ÓacUPHYÛ:=(cUÒ
V9BE=ÒEVGU?CT4YHVpYHҌJeGUdZYKGeÔKJeV4< V ß
=(JMҌ<±VpT4=Kdš?Eã>?CVQdZ?cedXYHÔH<>Gx=(=HÒEW1B>J^dXcxTp=(=(ÔHWXV
WZÕadZ<±ä_ÕYHLEcUBEG|V?CL>VQJMJedXV4ÔHGQ<ÃPCÓaÓ=(V4D_cedXBE<EYCÔa?CYKL>WZJeYKV|ÔHY(Õ#Ý Û9ceBEBEV*VpGeï¦V*RSceBE[ÆVA?CÒEVpW¤=FÒEceWXݹYFYHՂGUÓAÓ Vp<KT4c=H<Ã?Cd¤=(=(W¤ÔKJMGUY=HÓäŒV à
ceceá<BEBEVîVA=K?EL>Ö:?CJe`zV4dZceG®ïdXYHT4Jp<æ=HP¼<±JeceÛ9YJeV4dšcecxWXBEVpTxV|BET/cQVpÒ>P7JpGeP,=(VQ<>B>?C?±=HVã>GUT?C<>YKÛµVp<E?æ=(<EGUVpÒEVTWX=(c¦V4cMWXcUݹV4BEYKÓAGeV4ÓaÓV4<‚JpcUP‚L>JpÛ:JMP¼dXV|<Eä>ÔL>=(JMW¤TJMVQYKYJ4ÓP¼ÒEäEÓ
GUYFL>LEb_J<EdX?Cd¤ä>T4V¦Ge=(d¤cece?CB>dXÔHYHV'VQ<ÃJ4änP1Òn=HV4=FJecUdXceT¦THBnàZJGeP¼VQcUݹJMGeYæYKYKLEä>Ó%GxLETdZVpÛ9W¤Jz?±BEWXd¤dZBETxDKdXB VJ
YFTYHÛ9GU<ÞGUVpÒET/W¤cU=F<EceVpݹJUYHJGUÓYHݼà>cUÖzBEYKV
<>LnJMd¤JeJM=HceÔHV4V*<nTYHÕÝ,TxceBEB>VQVATxD_=HJµGUTx=HB>GedšV'cUVp<ET/VpcULET4VpGxJU=(JeW=HTGeYHÕAÓAdX<ÞҌYHYK<EGU?CVp<‚VpcUG:J'ceY=HJ'V4<>ÛzJeVpLEWZW1GUV=KJcUBEcUVBEV4JMdXVpG|ÓadZ=(<‚<‚cUV4ceGed¤T ß
dceZT<BEYHVp<>cU<æ<EBEVpV
äŒTV¦=HcedXGUV=YHTx<C<ÞBEÒndZÒ>ceYKVQGeGMT/YHcUcUceVpLEYC?AGUT=HcUYKY*W7W“à ÒEcUÑ BEW¤=FBEV|ceV|ݹTYHYC?CGU?CÓVpVpJedXà>JeÔHdXáÔH<æ<C<ݹT4YHVpYHGU<‚ÓAÓab_Ҍ=FdXGeYHceYKdX<EYH<EVp<ÓA<KcxݹV4GUJµ<‚YHc¼T4Ó =(ݹYK<ÞceG¼B>ceݹBEV*L>VpGM?C<æcUV4BEÒ>äŒV4WZV|G9YFÕ_?CJMceÓAV4V4Ò>ÒnV4WZ<‚YFJ¼c¦ÕKcUVpY?C?ad¤T4=(cUYKÔKY*JeGUdZ=HcUÓ
BEÓéLEV®W¤Û:<E=FceYCYHdXLE?CYHVpW¤<\? J à
ݹceYHV4GµÓaÑ=*JæBE?CÛ9V|L>dš=HcUceWOB¸YKÒCÒE=ߨGeGeYCdX
T4ÔHVpB‚JUcJMYKâÒEG¼d¤T/Ö:=(cUGx`¼LETxGeï*BEV*dZP:ceY(Vp=ÅÝ Tceþ ÒELEdZGeGUÔKYCVLET4GeT4VpVÞYHJU<>JMÙYKJeGdXJMJMBEceäEYFdX<EL>ÛÔ
JpJP:Y(=(=Æ݀<#c^B>Û:V =(<EY*Gx=H?Cd¤Ó?CÛµV4Ò>=(<‚WZGUceVV#d¤T4YH=HLEÝ,W€<E?CJMdZcV4dX<EÒET4ÔHWXYHYFWXV<EÕ_ÓA<EÒ>VQGeV4T/YC<‚cUTc¦VpVQ? Je?CJed¤YHcU=(YÆGzÔKGUJMce=HÕCB>Ó JMV ß
äEÒEL>GeYCJ*T4ceVpBEJUJMGUYKYHG9LEÔKLEBÆ<EdZcU=SJ?C=HVQGe?CV®dXTpWXV=FݶcUc®Vp?lTYHäEÓALnÒEJWXVdXcU<KV4cUWXV4ÕÞGeݲLE=H<nT4VÞTYH=(<><><E?ÅVpT=#ceVp?ÓAV4dX<ÓAceYHB>GUdXÕ±J¦ÓA?CdXYC=H?CÔHGxLE=(WXVHÓÿà Ñ =H<>BE?VÞcec^B>ÛzV4YÃdXG¦JeTdX<EYKÔHÓWXV ß
Ó*LE<Ed¤T4=(cedXYH<dZ<EݹGU=KJ^cUGeL>TceLEGUV®Û9dZWXW7äŒVJMҌVpT4dšãnVp?dZ<æceB>V®Ý¹YHWXWZYFÛ9dX<EÔAÒEB>=KJMVKà
Ge<EÑ VFV4EB ÜFÛðV
JeY(ÒE<>ݶceW¤V4=FÛµÛÂcM=(ݹYKGU=HGeV1GUÓ0TxÒ>BE=HdXdZGMJ¼cecUVQGedšT/cUVpcUdZÒEYKLEGU<EGUVp=HdZJe<>W\V4Ô¦<‚ÒEce=(W¤=FVQ<nce?*?|ݹYHL>dZGU<‚JeÓdXcU<EV4ÔGedXݲJ=H=(ceT<EB>V:YHV4ceJM<íBEÕ_Vp<‚=(G,ceLCB>?CcUVpV4YHJeÒ>ÓadXJWZYF=FJMÕ_cUL>dXÓATpÒE=(ÒnV4WX<‚YKWZÕc¼GMc ?CÔHÒEd¤Vp=(GU<EÔKYFV4GUb‚Gx=Hd¤=F?CÓÂcUVQVp?|=H?J1ä_L>dZÕ®c,JedX;d¤<EJ¼Ö:ÔæJe×:BEBnYF@O=(Û9Gxà ?CÑ<
Û:BEYK=(dX< Jß
ceTBEW¤=HVJUJ®änYHdZ<>cMcUJMYHcU=HÓ<>TY(VQÝ J'þ ÒEdXGeÔHVQL>JMGeVpVæ<‚c®ÙHàOdX<îá<SceBEcUVaBEdXdXJ®<EdZ?Cced¤d¤=(=(ÔKW,GUYK=HäCÓ]^VpP>TÓAc|YCÓ?CYCLE?CWXVpVpJ'W,Ge?CVpd¤ÒE=(GUÔHVpGxJe=(V4Ó<‚ceà VQÑ ?#BEdZVQ<±JMVÛ9T4BEYHdZceÓAVAÒn=(YKGU<EVV4ce<‚B>cxVJ
B>?CLE=‡bHGUdZV¦<EänÔVpceV4BE<VJMBnÕ_=(<‚Gxce?CBEÛ:VQJM=HdXGeë4VFVQÜF?JeY(ä_ݶÕacUÛ:cUBE=HV'GeV¦T4Ò>YC?C=(GeVpceJedZdZceÔKdX<YH<EcUdXY‚<EYKÔaW€ÒE?CBnV4Ҍ=HJeV4VH<>à>?EádZ<<EÔAcUBEYKd¤<ÞJcUT4BE=KV®JMVÓA=H=HWZWºÒEÓAÒEdXY_<E?EÔALEJMWZҌVQVpJT4B>dšã>=‡VQbK? V
ceänLEBE<EVpVaV4dZcU< YKJ9<EÓacUWZB>ÕÃ=(=FÒEc¦äEҌL>ÛzVpJ®Vp? GedX<±VdX< =HcUWZBEB>GUVVp=(=KGxce?C?CdXWZÕÞÛµVKà=(ÒEGUÑ GUVVpBEJe=HVV4<><‚T4?ðcYHÓAdXBE<V4Ònce<>YKBET4<EV*VV4<‚YHcecxGUBEdZJ¦VpÔKÕÅdXdZ<í<>=HGUÔHVpW7GxJeÒELE=‡W¤Õ#WZ=Fcce=(ݹdZYHGU< VGUÓ ÒŒdX<>V4=(JMGUcedZ<nÒEVQ?#=HB>?ÃV4=(GxÓAce=(BEW¤YHJaV<ETÔA=HYHGUcU<>TxBEBE<EV4dZVpÓceTVQceT/VpcecU?âB>LEV4GUcUGU=HYV W
änÛ9=(GUVdZVAWXW7=‡cebFäŒBE=(VVdXW¤JM=(VpäEWZVQWXV'T/ceݹVQYH?G9"!$ݹB>#
YK=HGLEGU?C<E=AÛµdZcU<EJ=(V4GUÛ¿ñÀV‡Ö:Ü(TJM`¼YCYHï¦?CݶceVQJ*ÛµJMdX=(=HÔHGU<><V9?lJ^Ò>cU?C=(V4VpGeÒ7?EceàdZdXceTpdX=FYHce<>VQdZ?í<EÔAB>=V=(<_Gx?CҌ۵V4GU=(dXÓGUVaVpT<‚YHcUJ9ÓAÛ9ҌYHBE<EVp<Vp<‚cecUBEJxò'd¤Jce?CB>d¤=(=(c
ÔKGUÛ9=HdXÓ WZW
%
& ù‚(Ð '&*
ø )^,÷ +Ë>ÐeÍú,÷êÍ÷ºù‚ÐMú¼Éü.÷ -0/1'0ø )^÷
áV4<Gx=FceYHdXGxYH?C< V4G>YFceYÅÛ|P1L>Û:<>?CV#V4ݹGxYCJMcUT=(Ln<nJa?ðYH<ðceBEceV±B>ä>VÃ=H?CJedXVpT±JedXÔHJ^cU< V4Ò>Y(JÝce=íB>=(ä>cÞ=KJMcxd¤=(TDHLEVÃ<EÒEd¤?CWX=KdXGeTVQVST/cedXdX<YH<nYK=(LEWGÞäEÒEGUd¤W¤?C=FceÔHݹV#YHGUL>Ó JeVp?âÔHV4cU<EY ß
DAC Workshop, Anaheim, June 12, 2005
45
46
UML for SoC Design
¹ÝceTV4V4YHGUÓA<>V4<E<‚ÒEVpc,W¤=FTÒEc¼cUB>VHc^P=KÛ:JMJMY
VQB>J1YF?CY(Û9d¤J^݀<lcU=®dZ<ndZÒE<íT/W¤c9=FcUJMcMBEdXݹ<EYKVGeÔHcUÓ&WXYHVߨÒCTÒEߨYKGUGe<CYCdXÔHã>TB‚VpÔHc*JUL>JeGUÒnYH=(=(G,ceGedXäEcYHLn<Y(J:Ý9dZ=H<aceGUB>Û9TxB>VÞBEdšcUd¤ÒETxVpd¤BAT/T/cUcUÛzLELEGUVGeVpVKJMJpPºcUà =HT4þ YHGMc1dZ<>ÔKݹJeLEGUdXJMYHGUceV Ó&dX<E>ÔS=(?E<YHV4ÒE=HݵGUd¤c^T/TxÛzcxBEJ¼YSdZcecUVQd¤BET/?CV®cUVpLE<K?CGUcUdš=Hݶdšßß W
äET4TYH=(LEW1<>dXWX<EÒ>?íVpGeTV4=ceßÀVpdX?C<‚?æL>ceV4=Hä_GxW,ÕæTÒEYK=A<EGUY_<EJeT4dZVQ<EVpT/ÔKJUceJMWZVQV®YK?SG'LEJe<>JedZÕC<EdX?CJ^ÔKcUdXWZGUV4VAVpÓ T/ÒEcUGUdZdXYKYC<í<>TÛ9VQ=(JeW€BEJeä>YHd¤TxGeG¦BÃd¤?CcecUVpÔHBEÓV'VAÒ>ݹGUc^WXYH=(ÛzÓceY#VpJpJeà€dZ<>á<±ÔH WXVceBEcUÒ>Yd¤J®GeYCV T<EVQ=(JeÓAJeYHà ÒEG¦WXVHceVpP€ÓAÛ:ÒEVAWX=(Û:ce=HVQ<‚Jc¦=(cUGUYV
N VÃäŒV4B>=‡b_fdXYHGx=(W9WXV4bHVpWdX<¥ceB>V
E
B
#
V
¹
Ý
E
L
>
<
T
e
c
X
d
H
Y
>
<
H
=
Z
W
Z
d
^
c
ð
Õ
(
Y
|
Ý
e
c
>
B
S
V
E
ä
U
G
X
d
C
?
K
Ô
S
V
¤
d
Þ
J
e
J
n
Ò
Q
V
T
Z
d
>
ã
p
V
?
(
=
c
e
c
>
B
Ñ
YHänäCVpV4]^VQ<aT/c,?CVpÓAT4YHYCÓA?CV4ҌWŒYK?CJedXVp=H?
ÔHGxdZ<=(ÓÂc^Û:JeY'BEYF?CÛ9d 9O<AV4GUYHV4<<‚c,cUBELEV9<EcedZcUYKJ ÒCߨ
WZVpbHV4WCÒn =(Gec,Û9Y(BEÝOd¤ceTxBEB
VBnÒE=(dX<>Tce?CLEWXVpGUVHJ1à ceÑBEVBEVJeWXäE=‡bKGUdXV:?EJeÔHd¤V9?CVµB>=KY(JÝ
ceceBEBEV¦V|äEäEGeGUd¤d¤?C?CÔKÔHVV®TTYHYK<><E<E<EVpVpTTceceVpVQ??cUcUY Y N à =(Ñ<n? BEV®
änVpB>=‡b_dZYK G:N^YHf ݺNMÛ9äŒf BEY(cUd¤TxBBa
B>=(<n?CWZ VQJ1cUBE=H<>V?Óa
=HJMceVpG¼JedX ?CV Y(Ý
T4JMҌ=(<½VpT4dšÝ¹ãnYHTpG=FcUV dZ<EYK=H<îÓJMÒ>cU=HWZVîÔHVHänP€VläŒY(?CcUVQBíJeT4LEGedX<EäŒdZVpcUf ?J®Y(LnÝ:JMcedX<EB>Ô VaäEïGeRSd¤?C[óÔKVAJMT4cUYH=F<‚cUVîcU=H?EdZ<îdX=HJMÔHҌGxVp=(T4ÓadšãŒJ4Taà:N^f á=H<?E?CcUGUBEVpd¤JUJJpPOݹLE?><>=FT/cUcU=dZYK=H<><>N^=(? f W
cece;9B>BE< V
=( cceVpÛ9ÓÒndZWXYKÒ>WGMWXcx=(B>Jce=‡VHcUbKà B>VÞ
=FcUc|Yl!GUV4änÒEV±GUVpTJeYH V4<><‚<Ec|VpT=TYHce<><‚Vp?Åcx=(=(ÓAdXce<>dXYÆ<EJÔ=l=HWXT4JeJeYHYҌ<_VpGUbHTV VpdZ"‚ãn<‚LETcedXVpYHäEJM<ÃcLnJaLn$ñ #&JMdZVQ<ð%?S' cUcUBEòYV#=(d¤<>ã>?C?S<>Vp<K=H=KcUWTxdšÝ¹D_TÕS<EYK<CYFceÛ9BEã>VAÔKWZVQLEäE?CGUL>ÔH=(V|J®cedXYHҌҌ<âYHYHGeGeY(cUcUJJ Ý
ñäE)( L>Jµ*+ cUf Yò9Û9ݹYKB>GdXTxcUBBEV
dZcT4dXYHJ9ÓAT4YHÓ*<EL><E<EVQdXT/TpNMcU=Ff VpcU?€dZYKà <SÛ9dšcUBScUBEV
ä>L>J¦=HGeä>dšcUV4GQPŒJefdZ<nTV*dZc®dXJ'=Óa=HJMceVpG¦YK<#ceB>V
F
R
u
n
W
,
Addr
D
a
,,
nc
t a
t io
nal
S
pe
c
s
o
f
t h
e
I
nt e
r c
o
R
BrgUp12
Ac
k
n
W
-
Addr
BrgDown12
- D
R
a
e
--
nne
t a
c
t s
I
nit ial
A
r c
h
it e
c
t u
r al
t e
CPU1
Bus2
BusIntfc1
Mem1
pl at e
CPU2
Bus1
q
m
BusIntfc2
Mem2
HW1
HW2
Mapping
R
n
W
,
Addr
D
a
t a
,,
R
BrgUp12
n
- -D
Ac
k
W
Addr
BrgDown12
S
R
9
.25 3/6 47 3 01 11
y
a
e
t a
--
CPU1
Mem1
q
nt h
e
Bus1
Mem1
BusIntfc1
Bus2
BusIntfc1
s is
5 67 8
2. 3 / 4 3 0 8 8
HW2
BusIntfc
BrgUp12
BrgDown12
:
CPU2
R
Bus2
e
q
Arb2
HW1
Mem2
£;>£ y¼uU­Km4{|ª‚™vuµqp”OoKr^tš›K–pu›Kuxwtv–Q>´
Ac
BusIntfc2
Mem2
HW1
BusIntfc
CPU1
CPU2
Bus1
k
BusIntfc2
HW2
Y(?CÝEV4ÒEcUBEád¤T/<®VµcUceVpdZ<‚BE?æceV¼VpdZ<ÞݹGUYHT4WXceYHWZBEYF<EV'Û9<>VpÓAdX<ET/dXÔcx?>J\ÒE?CYKBnWZ<‚V|=HceJeJeYVHVpcUP4TBEÛ:cedXVµYHV,LE<Ҍ<>V4YHT4GeÝ YHݹYHþ<EGU<EdZÓ¿ÔKVQLET/ceGecUBEV VpVz?*>ÓA?EL>Û9=H=(ÒEBEWZÒEV4ßÀÒ>dXGU<EV<GeÔYC
TYHVQÝCJeceJeBEYHV¼G\ ݹceLEVpÓ<>B>T/Ò>=KcUWXdZJzYK=(äŒce<>VHV4=(àVpW‚Ñ<ÞJMҌBEÓaVpd¤J T4=(dšÒEÒ>ãŒB>ÒnT4=K=FVQJM?æcUV:dZYK=KdX< JJ
N^f
DAC Workshop, Anaheim, June 12, 2005
UML for SoC Design
>BTYH=(<>Gx?C<EÛµVpT=(ceGUVpV'?ÞT4ceYHY<E<EVQT/cUVp?æà ceY N P>Û9BEdZWXV
! NMf B>=KJ9äŒV4V4<Óa=(Ò>ÒnVQ?#=HJµB>=HGU?CÛµ=(GUV
f BEV¦ã><>=(WOJeՂ<‚cUBEVpJedXJ:JMceV4ÒæT4=(<æJ^cx=(Gecpà‚á<aceBEd¤J:ÒEB>=KJMVKP(ceB>V¦<EVpÛ=(GxTxBEdZß
:
;
¼
c
e
c
>
B
X
d
:
J
Œ
Ò
H
Y
X
d
K
<
Q
c
H
P
U
c
cedZ<EVpÔTce=HLE<>Gx=(?AWndXÒE<KW¤cU=FV4cMGeݹݲYK=HGeT4ÓóVJMd¤Õ_J¼<‚=HceLCBEceVQYKJMÓAd¤J1=(JeceLEd¤ÒET4=HҌWZYHWXÕ
Gec¼ÔKÒEV4GU<EYFVpb‚GUd¤=(?CceVQVQ?*?Aä_L>Õ
JMdX<E;ÔÖ:Bn×:=(@OGxà?CÑ Û:B>=HV9GeVFGeÜFVQJeJMY(LEݶWZcUceÛ:dX<E=HÔ|GeV:YKÒ>LC=(cUT4GeYHcedZÓAcedXV9YH<EdXJß
ceceBEBEV®VݹänLEYHWXcMWXÕÞcUYHTÓYK<EY(<EÝ VpTþ cedXVQÔH?æL>Ge=H?V GUTx>CBEàOdZceáVQ<ST/cUcULEBEGUdXJ®=HWŒ?Cced¤V4=(ÓAÔKGUÒE=HW¤Ó=FcUP>V|ÓAJMBEYCYF?CÛ9LEWX<VpJ'dX<ÞGeVpcUÒEBEGUVVpJe?CV4V4<‚Ò>ceWZVQYF?#Õ_ÓAdZ<±V4<‚Û9c9BE?CdZcedX=HVAÔH=(GxGU=(VÓéceB>=(Vc
B>T?CW¤LE=‡=HbHGUJUdZV¦J®<EänÔÆdZ<>VpJMceV4cUBE<=HV±<>JMÕ_TB>VQ<‚=(J'ceGxBE?CÒEVQÛµGeJMVQdX=(ë4JMGUVpVQV‡<‚?ÜFc®Jeä_Y(dXÕa<îݶcUcUÛ:ceBEBE=HV'VaGeVæT4dXYC<EÒ>?CdZ=(ceVpd¤GeJe=(cedZW,ÔKdZce<YKdXYHäCcU<>]^Y‚dZVp<EYKTW€ÔÅc|?CÓÒEV4B>ҌYC=HV4?C<>JeVpVH?EW,àzdZ?C<Eád¤ÔA<¥=(ÔHYKceGx<ÞB>=(dXÓcUJBEà V®T4Ñ=KÓAJMBEVK=HVQP ÒEJM
VÒEdXT4<EYHÔAÓAJM ÒnҌYKVp<ET4dšV4=Hã><‚<>VQcx?? J
N^f B>=‡bHVäŒV4Vp<¥dZÓAÒEWXV4ÓAV4<‚cUVp? dX<ðBn=(Gx?CÛ:=HGeVKà Ñ BEV4dXGҌYHGecMßÀceYHßÀҌYHGecTNMYHf <><EVpTß
ce=(dXGxYHTx<>BEJdšcUJeVpÒnTVQceTLEdZGxã>=(VpW7??C=Fd¤=(c ÔKceGUBE=HV:ÓݹLEà <n¦<T/æcedXYHcUBE<nV|=(WCY(WXcUV4BEbHV4VpGW_GeB>Vp=(ÓA<>=H?7dZPE<
ceÒnB>YKV4dXGMGceߓTcUYKY(<EߨÒn<EYKVpGMTccedXTYHYK<><EJ:<EcUVpYÞTce=(dXYH<#<>=HJ ä>dX<J^cUGUcU=KBET/V:c9ã>äE<>L>=(J W
ceB>YA=‡bHceV1B>V®äŒV4JeVpҌ<|VpTGedZYKãnLCT|ceVQ=H?€GUTxPBEcUBEdZceGeVQYKT/LEcUÔHLEB|GU=H?CWOVQäE?CL>d¤T4J=F=(cUcµVp?|Û9ä>B>L>dXTxJ7BdX<‚ceceB>V4V4GeÕÞݲ=HBnT4Vp=‡J,bHV'ñ$änVpV4<#TYK<E* <EN Vp=(T<>ceVQ?&?€à * f ò/P
JdXMJÕ_<‚=ceÑ äEBEBELnVQVpJMJ9d¤JeJ¼V
ÓacedX=HY_<‚JMYHceceVpWŒV4GMݹGQݲYHPE=KG9=HTVp=?>J'?CJMdš=(V4cUc:GUdZYKVAYH<>ݺ=(=(W¤JeW\JMLEYæGeÒEV dZҌ"K<>YHL>JMGeVpcUce=HJMVpc9<>?ÞT=Hd¤äE<>=FL>?cUVpJµ=H?±=(TxGxD_=(Tx<ELCBEcUYFdZYHceÛ9VQÓaWXT/Vpce=F?CL>cUÔKdXGeTpVVQ=(J4WXWXàdZWZ<>Õ#þ VpYHJ9ä_G Õ<E
VpceVpB>?æ!VAce;YaÖ:äŒ×:V@#NMTf YKdXPE<‚<EJMce<EdXV4<>VQGeTT/ݲV'ce=HVQT4dZ? Vc
ceceY|BEVcUBEÒnVY‚JeäEJeLndXäEJ¼dZ=(WXdZGUc^äEÕædZcecUVpYæGpàKT4áL><AJ^cUceYHBEÓAV'dXTë4LEV|GUcUGeBEVp<‚Vc¼=HbHGeVpä>GUdšJecUdZGUYK=(<
cedXYHYHÝ7<#YHҌLEYHG¼WXdXÒET4WXÕ=(cMä_ݹYKÕ#GeÓóTxBEY_?CYKVpJeJedXdX<EÔHÔ<AceäŒY_VYKc^Û:W“PKV4ÛzV4V<±Ò>=GeYFä>b_=Kd¤JM?Cd¤VT
Ge=(YKLCLEcUYH<>Óa?=FGeYKcUdXäETpdX=(<WXWZÕañ²<ETY|YKÒE<CGUã>dZÔKYKLEGedZGec^VQÕE?ò =(?C<>LE?aGUdX<E=®ÔJMcUcU=FBEcUV'dXTJeÕ_ÒE<‚GedXceYHBEGUVQdZJMc^d¤Õ*J¼=(Ò>WXB>ÔH=HYKJeGeV¦dZceBEdX<ÞÓYKà GUÑ ?EBEV4G,V9cUä>YL>=KJ¼T4=HT4GeYHäEÓAdZceYCVp?EG1=FdXJ1cUVceBEceVpB>< V
ceceGeBEBEV"KVVL>ä>?CdZGUL>V4VpݲJ,=(?A=(LE<_GUWZcäELEdZÓ
YHceGx<>än=FVHVpcUà GzdZYKYH<Ý7=HÓAWZÔK=KYHJ^GUcUdšV4cUGxBEJ,ÓÂ=(<nT?AYKÓAceBEÒEV®WZV4JeceV4VpWXWZVpÕAT/cU=FVpc1?AcUBEÒEV9GUdXYHݹLEGU<>dšc^TÕKceàKdXYH;<><=HWE=(WXWZV4ceVpbHGeVp<>W>=(=(ce<ndXbH?V9=‡d¤bKJ,YHcUd¤Y*?ÓAcUY|YCL>?CJeV4V W
dXV4JWXV4d¤ÓA?CÑ V4V4<‚BE<‚cUV|cUdšJã>=(VQGxdZ<?
TxBE?EcUdšBEcULEVpV*GeTdXce<EdX<ELEÔ¦dZGxcece=(d¤BE=(W€VµW äE=(ÓaLnGxJ=(TxBE=FÒ>c9dšÒEcUdZVpÛ9<>TBEÔ'ceLEd¤Ò>TxGxB#B>=(=HW7=*JeÒ>VzݹWXL>=(ä_<>cMÕ|ݹT/YHcUcUGUdZBEYKÓV:<>ݲ=(=(=HW\GUTVT4c YHcUTÓAB>YH=F<>Ҍc1<EYHVpäŒ<ETY(Vpce<KcUVpBac?BnÖ:cU=HYÞ`zJ:ï=AceJYaLE=(<EäŒ<>d V"‚?
LETB>YKV*=H<Eä>GU<E?CL>VQÛµJ4T/ànce=(VQáGU<? V
ceÛzBEVd¤J9D_Ûµ<EYF=‡ÛðÕHPCcUÛ9BEBEVVpäE<L>Û:J:V=FczJeÒnÛ9VQBETdXdZTxݹBaÕæÛ:=AVB>B>=H=‡GU?CbKÛµVµ=(ceYGUV'TÓAYH<>=H<EÒEVpÒETdXc,<EceÔABEY(VÝ1äE=AL>Jz<EV4dZ<‚Û¸ceVpݹGMLEݲ<>=KTTVcedXYHҌ<>YH=HGecUW\J1TceYKB>ÓA=(ÒnczYKÓA<EdZV4ÔK<‚B‚cpc P
=(TYHÒE<>Ҍ<EVpVp=HTGcdZ<#YH<EdZcUVaJ'ݹ?CL>VQ<>JeT/T4cUGedZdXYKÒC<>ce=(dXYHW¼<\T4àEYHáÓA<ҌceYHBE<EVVp<KTLEc*GUceGUY#V4<‚Ó*cL>bHWšVpcUGUdZÒEJedZWXYKV<äEY(LnÝ1JMVQYHJ4LEàºGáce<îY_YHYKWÀGUP>?EÛ:V4G®Vce?CY±Y?C<EYYHc¦ceBE=(d¤WXJpWXYFP\Û½dZc*cUdXY J
<ELEVp<ET4dZcUVpJpJUP_Je=H=HGeWZW€Õ|T4cUYHY|<EÒ><E=(VQGeT/cecUdZVpce?adXYHcU<Y
cUYKBE<EV9V¦Ý¹LEJedX<><ETÔHceWXdXV¦YH<>ä>=HL>WZJ4dZc^à Õ*Ñ YHBEÝnd¤cUJzBEdXVJ:Û9T4YHB>ÓA=(c:ÒnYKB><E=KV4J¼<‚äŒc,V4dXVp<‚<ceY?EJeYHÓA<EV¦=HWZdZWX<æV4G,ceݹBELEd¤<>JµT/JMcUdXdZÓAYK<>ÒE=(WXV W
äETYHGed¤ÓA?CҌÔKVAYH<E?EVpVp<‚JecUdZÔKJ9<îTYKV=<E<E<E=(VQÓAT/ceÒEVQWX?æVacedZ<íYa?CÛ9d BE9Œd¤VpTxGeBîVp<KcecBEVä>L>ä>JMGeVQd¤J4?Cà ÔHVAB>=KJ|äŒV4V4<íÒ>=HGMcUdšcUdZYK<EVp?îdX<‚ceYc^Û:YJeLEäCß
±ÌzÉ.Ï )MΦù_Ð^̼ɦù
ÔHÔHÑ GxYKBE=(=HVÅÓAW“P ÓaTäEYKLC=(ÓAäEcaÒEWXVdXWZ<â=V JM<CYKYKdšWZc^GULEÕ¸?EceV4dXY(YHG
Ý<>ceJpYîTànLE`¼änGUGUVWX=(V4<‚cMV ݹcS9OYHVpGUV4TÓüÓ
cedXänbHä>VKVQ=HP?EJeVp?Cce?#BEVp?Vp?CÕlVQJeJMGeÕCdXV ÔHJ^"KcU<SV4L>ÓadZT4GUYHVæJ#<>VT4GUV4V ÒC"‚TLEcxdXJdXV4Ge<‚TpVQc
=(J<ScUceVpB>=(TxWXVÅBEWXYF<>=HÛ¸d "‚?CLEYKcUYÞÒCVQJ*ce=HdXYHݹTxYKB><êGAdZVpYHÓbHÝAV|YCÒ>cU?CBEGeVpYHdXWšJßß
dZGe<EVpÔL>JM<EVKVpàKÛ0á<Þ=HceGUBETxd¤BEJ:dZÒ>ceVQ=(T/ҌcUV4LEG:GU=HÛ:W1VJMҌB>Vp=‡T4bKdšVãnTpÒE=FGUcUVpdZJeYKV4<><‚J®ceVQ=(?<>=?±ÓAÓaV4= ce<CBEdZYCÓA?CdXYKë4WZVYKÔHceB>ÕVceB>YK=(ÒEcµÒŒ=HYHWZGeWXceYFLEÛ<EJ1dZceݹdXYKVpG¼J'cUݹBEYKG|V®?C?CVpVpJeJedZdZÔKÔK<<
DAC Workshop, Anaheim, June 12, 2005
47
48
UML for SoC Design
Y(JMҌݼVpGUT4V4dšL>ãnJUTp=(=Fä>cUdZWZYKV<>ÒEJ9W¤=F=(cM<>ݹYK?Ge=(Óa<J'V=Û9<_dZd¤ceJMBîcedX<EÒEÔAGeYKB>ÔH=(GxGx=(?CÓAÛµÓa=(GU=(V‡äEÜFWXJeVY(ݶdXcU<‚Û:ceV4=HGxGeTVYKT4<EYC<E?CVQVpT/JecUdZJ¦ÔK<Þä_Õ#cUVpWZVpTxBEbHVp<>GUYH=HWXÔHYHdXÔH<EÕKÔÞà YK<±ïRÃ[
÷ U÷\ËE÷\ÉÏO÷ºù
´9y´m4w•n~_Áæ´CknmÀqQ™vqK~Em4_›Áæ´C€r^ux‡qQw¨s^tvKt¹~À‰µÁAktvampi\™vux}esr^qQ‚tv}¦Š(’Hw¨s^ux{êknux‡uU™
uUwtš–pÁuUs^©Kq(›KqQ™vqp–p’E~ *tv "!$#%'&(*),+.-0/1(32547689.:;!<=?>@(*6$9BA < CD(.)E:1<?9p~
ªKªn´K5ˆ F7G(B† HFI~ Hp„p„pˆH´
DAC Workshop, Anaheim, June 12, 2005
UML for SoC Design
A SoC design flow based on UML 2.0 and SystemC
Sara Bocchio1, Elvinia Riccobene2, Alberto Rosti1, and Patrizia Scandurra3
1 STMicroelectronics, AST Agrate Lab R&I, Italy
{sara.bocchio, alberto.rosti}@st.com
2 Università di Milano, Dip. di Tecnologie dell’Informazione , Italy
[email protected]
3 Università di Catania, Dip. di Matematica e Informatica, Italy
[email protected]
Abstract. In this paper we show how to improve the system level design flow
for System-on-Chip currently used at STMicroelectronics exploiting the use of
lightweight modeling methods, like UML, to be used as higher system-level
languages operating in synergy with some other lower level languages, like
SystemC. Such an improvement it was possible through the definition of a
UML 2.0 profile for SystemC. High-level functional UML models or platform
independent models (PIMs), as conceived by the current Model Driven Architecture (MDA) vision, can be “refined” down to platform specific models
(PSMs) written in the UML SystemC profile for the final implementation. A
case study based on a 802.11.a physical layer application mapped on a hardware software platform is presented, in order to validate the UML-SystemC
generation flow.
1 Introduction
The conventional design process starts from a functional executable model, usually
done in a software programming language (like C/C++) or by modeling tools such as
Simulink, capturing the system behavior from the requirements, usually written in
natural language. The partitioning between hardware and software follows to decide
the final destination of the design components. The software parts are compiled for
the target processing elements, whereas the hardware part is initially expressed in an
hardware description language at RTL, and then refined to a structural representation
using the logic synthesis which produces a netlist that can be mapped on a library of
standard cells or hard-macro blocks (blocks for which the layout is already available)
for the final implementation. This structural representation is used to produce the
final physical layout. However, there is still a large gap between the functional executable model level and the implementation level. In addition, since the verification of
an integrated hardware and software system takes place after both components are
completed, errors discovered in the verification phase are often uncorrectable.
We claim that this gap can be reduced by leveraging the joint capabilities of UML
and SystemC to provide a modeling framework for systems in which high-level functional models can be “refined” down towards an implementation model directly connected to the final physical implementation (see [9]).
DAC Workshop, Anaheim, June 12, 2005
49
50
UML for SoC Design
As shown in Fig. 1, the UML may improve the SoC design flow essentially in three
ways: (i) the UML in a platform-independent manner can be adopted at system functional executable model level to describe the specification, like Simulink; (ii) the
UML profile for SystemC can be used for the hardware description at the abstraction
layers (functional untimed/timed, transactional, behavioral, bus cycle accurate) on top
of the RTL layer; (iii) UML profiles tailored for programming languages like C/C++,
Java, etc. can be used, instead, for the software parts. Moreover, the availability of
UML profiles for other languages (JHDL, SystemVerilog, etc.) currently used in the
SoC design and the definition of suitable PSM bridges - as conceived by the current
MDA vision [6] - among profiles may allow to move from the description of a system
in a given language to the description of the same system in another language at the
same level of abstraction or lower.
Fig. 1. New SoC Design flow
2 A UML 2.0 profile for SystemC
The UML profile for the SystemC language is based on the UML 2.0 specification
[7] and on the SystemC 2.0 specification [5]. The profile definition is organized in
four parts, reflecting the architecture of the SystemC definition as built on top of the
standard C++. The complete UML profile definition for SystemC is described in [10].
1. The SystemC core layer - structure and communication - defines stereotypes
of the core layer of SystemC which can be used in various UML structural diagrams to represent the structural and communication building blocks of a SystemC specification like modules, interfaces, ports and channels.
2. The SystemC core layer - behavior and synchronization - defines stereotypes
of the core layer of SystemC which lead to a variation of the UML method state
machines, called SystemC Process State Machine (see [8]), to allow high level
specification of the SystemC processes functionality in modules and channels.
3. The SystemC core layer - data types - defines a UML class library to represent
the set of SystemC data types.
DAC Workshop, Anaheim, June 12, 2005
UML for SoC Design
4.
The SystemC layer of predefined channels, interfaces and ports provides
concepts for the layer of the predefined channels, interfaces and ports of SystemC. These concepts are implemented both as a class library, built applying the
basic group of stereotypes of the SystemC core layer (or the basic SystemC profile), and as a group of standalone stereotypes that specialize those of the SystemC core layer (the extended SystemC profile).
3 Tool Support
In order to develop our SoC design flow, we decided to rely on tools supporting
UML 2.0 with the standard extension mechanism of UML profiles, and (possible)
model transformations. Using such UML tools allows modeling the system by means
of a diagrammatic UML representation, then to refine it in a UML-like SystemC
model and to perform code generation in SystemC. Our current implementation is
based on the Enterprise Architect tool [3], but any other tool supporting UML 2.0 can
be also used and easily customized since our profile has been defined relying only on
the standard UML 2.0 specification instead of tool’s “implementations” of UML 2.0.
We added to the Enterprise Architect the capability to generate complete SystemC
code from the UML models for both structural and behavioral aspects. This feature
can be obtained either by customizing the C++ code generation templates of the UML
tool or by exporting the model in the standard XMI (XML Metadata Interchange)
format and generating the SystemC code from it.
4 HW/SW co-design
Our approach to SoC design trough UML allows modeling the hardware and software
parts together in a unique UML environment. The hardware architecture is modeled
by constructs from the UML profile for SystemC, so it can also be refined down to
the register transfer level, modeling the details of the implementation. The application
can be modeled in software at two levels of abstractions: transactional or instruction
level. When modeled by transactions, it works as a library encapsulated in a SystemC
module. Processes are associated to the software functional description to sustain its
concurrent activity within the system, whereas communication is implemented by
transactions that model the interactions with the hardware architecture. This level of
abstraction allows testing the correctness of the application on a high level description of the hardware, focusing on the communication and on its performances. The
application can be also modeled at the instruction level by integrating an instruction
set simulator of the target processing unit within the SystemC environment, to execute the compiled application code together with the SystemC model that implements
the hardware. In this case both hardware and software models provide cycle accurate
simulation.
DAC Workshop, Anaheim, June 12, 2005
51
52
UML for SoC Design
5 Case Study
We provide an application example related to a system that implements an 802.11.a
physical layer transmitter and receiver described at instruction level. Therefore from
one side the C/C++ application code will be encapsulated as a library functions in a
UML class. This class provides through ports the I/O interface of the software layer
to the hardware system. From the other side a ISS encapsulation in UML is also provided, in order to represent all the elements of the system. The UML encapsulation of
the ISS is built by the UML profile for SystemC, in order to generate a SystemC
wrapper for the ISS and to allow an hw/sw cosimulation at transactional or cycle
accurate level. The application code generated by UML diagrams – EA tool already
provide this feature - will be executed by the LX ISS.
Fig. 2. The StdBus module
The system is composed by a VLIW processor developed in ST, called LX [4], with
a dedicated hardware coprocessor that implements an FFT operation. The processor
acts as a master to the hardware module and the memory components, where code
and data are stored. The communication is realized by a system bus: in particular we
use On Chip Configurable Network [1], a transactional level cycle accurate SystemC
model available at [2]. All the blocks of this system are modeled in UML class diagrams using our profile, in order to automatically generate the SystemC code. As an
example, Fig. 2 and Fig. 3 show the class diagram of the StdBus model and the state
machine of the SC_THREAD stdbus_process.
DAC Workshop, Anaheim, June 12, 2005
UML for SoC Design
Fig. 3. The stdbus_process state machine
In Fig. 4 the UML composite structure diagram of the overall system is shown. It
describes the hierarchical structure of the platform. Several UML object diagrams can
describe different configuration scenarios. This separation allows generating different
parametric platform instances starting from the same model, i.e. structure diagram.
The design has been imported from the C++/SystemC reference description into
EA, empowered by the UML 2.0 profile for SystemC, then the code generation has
been tested to cross-check the generated C++ code and the original code.
DAC Workshop, Anaheim, June 12, 2005
53
54
UML for SoC Design
Fig. 4. The Platform internal structure
Acknowledgements
We would like to thank Marcello Coppola, Andrea Council, Stephane Curaba, Andrea Giorgi and Francesco Papariello for their precious work.
References
[1] M. Coppola, S. Curaba, M. D. Grammatikakis, G. Maruccia and F. Papariello, OCCN: A
Network-On-Chip Modeling and Simulation Framework. In DATE 04.
[2] M. Coppola, S. Curaba, M. Grammatikakis, G. Maruccia and F. Papariello
On-Chip Communication Network: User Manual.
At OCCN Project Website
http://occn.sourceforge.net/
[3] The Enterprise Architect Tool. http://www.sparxsystems.com.au/
[4] P. Faraboschi, G. Brown, J. A. Fisher, G. Desoli, and F. Homewood. Lx: A Technology
Platform for Customizable VLIW Embedded Processing. In Proceedings of International
Symposium of Computer Architecture, June 2000.
[5] G. Martin, S Swan, T. Grötker, and S.Liao System Design with SystemC. Kluwer Academic
Publisher, 2002
[6] OMG. Model Driven Architecture. http://www.omg.org/mda/
[7] OMG. UML 2.0 Superstructure Final Adopted Specification, document ptc/04-10-02.
[8] E. Riccobene, P. Scandurra. Modelling SystemC Process Behavior by the UML Method
State Machines. In RISE 04, Springer-Verlag 2004.
[9] E. Riccobene, P. Scandurra, A. Rosti, S. Bocchio. A SoC Design Methodology Based on a
UML 2.0 Profile for SystemC. In DATE 05.
[10] E. Riccobene, P. Scandurra, A. Rosti and S. Bocchio. A UML 2.0 Profile for SystemC. ST
Microelectronics Technical Report, 2004.
DAC Workshop, Anaheim, June 12, 2005
UML for SoC Design
Performance Analysis of Sequence Diagrams for
SoC Design
Alexander Viehl1 , Oliver Bringmann1 , and Wolfgang Rosenstiel2
1
FZI Forschungszentrum Informatik, Haid-und-Neu-Str. 10-14, 76131 Karlsruhe,
Germany
{viehl, bringmann}@fzi.de
2
Universität Tübingen, Sand 13, 72076 Tübingen, Germany
[email protected]
Abstract. Sequence Diagrams of the Unified Modeling Language (UML)
are used for the description of the interaction and the collaboration of
instances in systems. In UML2.0, sequence diagrams are extended by
control flow constructs and timing annotations, which are important for
SoC design. In this paper we present an approach for the analysis and the
evaluation of the performance of systems described with Sequence Diagrams even at the design stage. The basis of our analysis is the detection
of communications that synchronize the control flow of the corresponding
processes and set them in relation. Using this knowledge, we are able to
determine a global timing behavior and violations of this effected by preset constraints. Hence, it is also possible to detect potential conflicts on
shared communication resources if there is a specification of the targeted
architecture. This architectural description can be stated by the use of
structured classes, that were introduced as a part of the UML2.0/SysML
specification. With this kind of information it is possible to evaluate an
SoC architecture at an early design stage.
1
Introduction
The Unified Modeling Language (UML) is a general-purpose modeling language
widely used in the software development process for the specification of systems
or typical use cases. The requirements in the area of hardware design, especially
in the area of Systems-on-Chips, demand for quantitive evaluations of different
design alternatives. Even though the complexity of complete systems on chips
is steadily increasing, the demanded time-to-market for them is shortening. The
earlier design decisions can be verified, the earlier conflicts and violations of
constraints can be recognized. Requirements like response times or throughput
have to be considered and conflicts on shared resources have to be identified and
cleared. The analysis of the control flow as represented in sequence diagrams,
that support loops, alternative execution and several other new statements since
UML2.0 [2] and the related communications allow the estimation of communication schedules and possible conflicts caused by overlaps in the schedules. The
assumption is that the instances in the (time annotated) diagramm will be realized either as specialised hardware or as processors or microcontrollers executing
DAC Workshop, Anaheim, June 12, 2005
55
56
UML for SoC Design
software threads. Depending on the realisation and the partitioning of the instances, the communications will be handled as IPC between threads or they will
be mapped to communication resources like on-chip-busses, on-chip-networks or
dedicated wires. Depending on the targeted functional mapping and the selected
communication architecture, the expected timing of the related blocks between
the communications has to be estimated. Whereas for a single software task,
worst case execution time (WCET) analysis is sufficient, it is not applicable for
systems of communicating processes.
We developed a method for timing analysis in time-annotated sequence diagrams to determine the influence of blocking communication on the timing
behaviour of the system. Therefore the presented control flow and the timing
information from the sequence diagram is transformed to a communication dependency graph (CDG). This kind of representation has a more formal semantics than the original format. The runtime of blocks between the communication
events can be determined by execution time analysis of the existing behavioural
description or by user annotations originating from the specification. With those
information, it is possible to analyse the temporal behaviour of the cooperating
processes.
Our method is not restricted in use with the complete description of the
system. Often some typical use cases, which embody the critical situations by
the meaning of timing or communication of the envisaged system are modeled
with sequence diagrams. The validation of these szenarios helps to detect presumable bottlenecks from the developers point of view without having to model
the complete behaviour of all parts. As a constraint for our analysis, the targeted architecture has to be specified. For this specification, structured classes
[9] provide a flexible framework to define arbitrary architectural designs. The
previously determined results will be used to evaluate the defined architectural
alternatives and decide if all constraints are met and the compliance with the
specification. The combination of the performance estimation and the evaluation of specified architectures at an early design stage results in a very valuable
approach in the area of SoC design.
In the next section, we shortly present related work in the area of performance
analysis in UML. Chapter 3 describes our approach to extract the semantics of
sequence diagrams, to formalize the notation by reducing the amount of different
used expressions. We present examples for this technique. Chapter 4 describes
our communication analysis and illustrates the method using an example. The
analysis of the mapping between the information stored in the sequence diagram
and the architectural desription are shown in chapter 5.
2
Related Work
The complexitity of tasks for the designer of SoC is steadily increasing. Decisions about the communication structure, the hardware/software partitioning,
the speed and the type of microcontrollers and microprocessors have to be made.
DAC Workshop, Anaheim, June 12, 2005
UML for SoC Design
Subsequent changes in the configuration often need a redesign of the complete
architecture.
The application of UML in the design process of SoC tries to provide a
structured view and an exchange mechanism. Analysing the relations presented
with UML tries to compare preset constraints with the targeted architecture or
exposes expected performance characteristics as throughput or response time.
Several approaches aim towards a formalisation of the UML to avoid disaccords
between developers and to provide better consistency between the different representation styles of UML [4, 1]. The different approaches can be initially distinguished by the elements of the UML standard they are examining. Sequence
Diagrams are widely used in the analysis process. There are methods of performance engineering distributed software systems. On account of their targeted
application domain, SoC problems like conflicts on shared ressources are not
detected by these approaches [13, 8]. Additionally there has been presented a
method to check timing consistency of sequence diagrams [5]. Other analytical models analyse time-enhanced UML-Diagrams with the aid of stochastic
processes [7, 3, 6]. Whereas it delivers good results in application domains like
mobile communication, we demand for worst case estimations in the area of SoC.
Relating to this, there have been work towards communication analysis we are
setting up our concept [10, 12]. Whereas the scope in these works concerns the
analysis of implemented systems, we are focusing the design stage.
3
Analysis of Sequence Diagrams
Sequence diagrams allow a graphical presentation of interactions and causal relations between instances in the system. The temporal behaviour is covered by
UML2.0. The ability to specify constraints like maximum durations and characteristics as execution times and communication delays enable the description
of various temporal behaviour and dependencies. Although they are easy to understand, the notation is due the arbitrary expressions not as formal as needed
to be directly analysed with regard to performance aspects. The approach presented in this chapter demonstrates the transformation of sequence diagrams to
communication dependency graphs (CDG). A CDG represents a consolidated
representation of communications and the temporal and causal behaviour between them. Depending on the synchronisation behaviour, there exist four basic
communication primitives. These primitives are classified by the characteristics
of the sender and the receiver, depending on their synchronous or asynchronous
behaviour. A communication dependency graph can be defined as follows: A CDG
is denoted by
CDG :=< VCDG , ECDG , ECOM , τCDG , lCDG >, where
– VCDG is a set of nodes representing communication nodes or loops with
unbounded data dependent delay.
– ECDG ⊆ VCDG × VCDG is a set of directed edges describing the precedence
dependencies between nodes.
DAC Workshop, Anaheim, June 12, 2005
57
58
UML for SoC Design
– ECOM ⊆ Vsend × Vrec , with
Vsend = v ∈ VCDG : τCDG (v) ∈ sendasync , sendsync and
Vrec = v ∈ VCDG : TCDG (v) ∈ receiveasync , receivesync is a set of directed
edges describing the communication
– The function τCDG (v) :
VCDG → sendasync , sendsync , receiveasync , receivesync denotes the type of
each node.
– The edge weights are represented by the function lCDG : ECDG → N0 × N0
with minimal and maximal execution time lCDG (v1 , v2 ) = (csmin , csmax )
between the nodes v1 , v2 ∈ VCDG .
The first step for the construction of the CDG is the identification of communication events as send and receive in the system described by sequence diagrams.
These events embody the nodes of the CDG. Obviously this information can be
directly adopted from the sequence charts. The paired nodes from each communication are connected by communication edges in the CDG. The control flow
between these nodes is expressed by edges connecting nodes, if the lifeline of the
instance in the sequence diagram connects both events directly without passing any other communication event. The needed precedence information can be
extracted from the specified sequence diagram. The investigated representation
style can contain several new expressions since version 2.0 of the UML standard, like loops, alternative and optional statements, that influence the control
flow. Hence, these statements have to be transformed context and semantics
preserving to the analysis graph, the CDG. Interaction occurences become inline expanded. The treatment of statecharts, that allow the parallel definition
of states containing a behavioural description using sequence diagrams, and the
switch between these depending on external events is in principle possible but
out of the scope of this paper. After all, the timing informations contained in
the sequence diagram have to be used to annotate the edges in the CDG. This
informations can be assumed as constraints for the specified case or they can
be initially derived by existing implementations with static timing analysis. For
the annotation, the different possible expressions of time included in sequence
diagrams have to be converted to durations as it is needed in the CDG.
Process P1
Process P1
Process P2
Process P3
Process P2
(0, 0)
Process P3
(0, 0)
(0, 0)
(0, 0)
t=now
{0..0}
(2, 4)
{2..4}
Loop
t..t+3
(0, 3)
(1, 1)
{1..2}
{1..2}
(1, 2)
{2..3}
(2, 3)
{1..1}
(1, 1)
(0, 0)
{0..0}
t+1..t+2
(3, 7) (1, 1)
{3..7}
(1, 1)
{1..1}
t=now
(1, 2)
(1, 2)
(0, 0)
Fig. 1. (a) Time-annotated sequence diagram and (b) the related CDG
DAC Workshop, Anaheim, June 12, 2005
UML for SoC Design
Figure 1 presents an example of a time annotated sequence diagram. Precondition for our later analysis steps is the consideration of the different statements
and the check if the annotations lead to an absolutely defined CDG. The resulting CDG from the application of the algorithm is presented on the right side of
the figure.
The definition of multiple use cases as sequence diagram implies the transformation of each of them to a CDG. After the transfer of the content to our analysis
format, we are able to perform communication analysis.
4
Communication Analysis
The approach presented in this section allows the estimation of the temporal
behaviour of concurrent processes. The representation of the processes is done
by communications and the timing behaviour between these nodes as this is considered in the CDG. The set of use cases defined at the design stage as sequence
diagrams can be later used as a test suite for the evaluation of architectural
designs in the stages of the architectural modification and refinement .
Objective of our communication analysis approach is the impact of blocking
communications on the runtime behaviour of processes. These blocking communications synchronise the involved processes. Based on the communication dependency graph, a synchronicity condition can be formulated in order to describe
the influence of blocking communicationsto the inter-process-synchronisation.
Each communication edge embodies a potential candidate for a synchonisation
point. Obviously, the blocking communication partner has to be reached before the non blocking one. Our algorithm for the calculation of synchronisation
equations has been presented in [10]. The next step in our analysis towards the
estimation of a given target architecture is the determination of a communication schedule, that describes the order of the communication of the processes
using the results of the communication analysis. This kind of information can be
used to gain knowledge about conflicts on shared (communication) ressources.
The idea is, that the determined synchronisation points are setting the parallel processes into relation and allow to put all communications into a temporal
order. The position of communications in a schedule depends on their duration
an the jitter of the execution times and slacks in the control flow to any other
communication. The result of the analysis can be presented by an access graph
with potential overlapping intervals [11]. In the case of an overlap, it does not
automatically implicate the parallel access to a shared ressource at the same
time. Further analysis must attend the sequentiality of the communications ordered by the control flow in the CDG. Using the knowledge about conflicting
access, now the specified architecture of the system can be examined.
5
Architectural Mapping
The architecture of the system defines location, type and relation of the instances
of the system. The access on shared ressources as communication busses can be
DAC Workshop, Anaheim, June 12, 2005
59
60
UML for SoC Design
analysed with the knowledge about the processes, their communication schedule
and their architectural mapping. Structured classes provide a flexible and powerful framework for the definition of system architectures. An essential feature
for the description of communication structures is the ability to define ports and
connectors between the instances of the system.
After having analysed the temporal behaviour of the communicating instances, we are now able to evaluate different hardware mappings. Therefore
we use structured classes for defining an SoC architecture. With the knowledge
of the communication schedule, we can now compare and estimate different architectures. The following Figure 2 shows two architectures for an SoC, mapping
three communicating instances to structural elements. In both cases, they are
connected to an on-chip-bus, the difference is a dedicated communication line
connecting P1 and P2 and the architectural refinement, using concrete platforms.
asm: SoC1
asm: SoC2
:P2
:P1
:OCB
P3:Embedded
Processor
:P1
:P2
<<amba>>
:OCB
<<arm7>>
P3: Embedded
Processor
Fig. 2. Modelling of SoC architectures described with UML2.0 structured
classes/SysML assemblies
Furthermore, the similarity of the semantics of ports and channels in SystemC provides a good basis for the automatic generation of structural code
skeletons according to a graphically specified architecture. The resulting temporal behaviour of our analysis delivers the knowledge to back-annotate this
information into the SystemC code as a basis for the simulation.
6
Conclusion
The complexity of SoC is steadily increasing, demanding for the validation of
typical use cases relating to a given architecture even at the design stage. We presented an approach that is able analyse the performance of typical use cases given
by time-annotated sequence diagrams and structured classes. We can decide, if
specified constrains are met. Another result of our analysis is a communication
DAC Workshop, Anaheim, June 12, 2005
UML for SoC Design
schedule graph, we can use to evaluate a given architecture. The architectural
description can be done by structured classes. This type of architectural description allows an architectural refinement and modification, and for every step of
this, we are able to evaluate the architecture using the specified use cases.
References
1. Gregor Engels, Jochen M. Küster, Reiko Heckel, and Luuk Groenewegen. A
methodology for specifying and analyzing consistency of object-oriented behavioral models. In 8th European Software Engineering Conference and 9th ACM
SIGSOFT Symp. on the Foundations of Software Engineering, 2001.
2. Object Management Group(OMG). Uml profile for schedulability, performance
and time specification, final adopted specification. Technical report, OMG, March
2002.
3. Peter King and Rob Pooley. Derivation of petri net performance models from
uml specifications of communications software. In Proceedings of the 11th International Conference on Computer Performance Evaluation, Modelling Techniques
and Tools, 2000.
4. Jochen M. Küster and Joachim Stroop. Consistent design of embedded real-time
systems with uml-rt. In Fourth International Symposium on Object-Oriented RealTime Distributed Computing, 2001.
5. Xuandong Li and Johan Lilius. Timing analysis of UML sequence diagrams. In
Robert France and Bernhard Rumpe, editors, UML’99 - The Unified Modeling
Language. Beyond the Standard. Second International Conference, Fort Collins,
CO, USA, October 28-30. 1999, Proceedings, volume 1723 of LNCS, pages 661–
674. Springer, 1999.
6. Christoph Lindemann and Axel Thümmler. Performance analysis of the general
packet radio service. In Proceedings of the 21th International Conference on Distributed Computer Systems, 2001.
7. Christoph Lindemann, Axel Thümmler, Alexander Klemm, Marco Lohmann, and
Oliver P. Waldhorst. Performance analysis of time-enhanced uml diagrams based
on stochastic processes. In Proceedings of the third international workshop on
Software and performance, 2002.
8. Jose Merseguer and Javier Campos. Software performance modeling using uml
and petri nets. In MASCOTS Tutorials, 2003.
9. SysML Partners. Systems modeling language (sysml) specification version 0.9.
Technical report, SysML Partners, 2005.
10. Axel Siebenborn, Oliver Bringmann, and Wolfgang Rosenstiel. Worst-case performance analysis of parallel, communicating software processes. In Proceedings of
the Tenth International Symposium on Hardware/Softwarw Codesign, 2002.
11. Axel Siebenborn, Oliver Bringmann, and Wolfgang Rosenstiel. Communication
analysis for network on chip design. In International Conference on Parallel Computing in Electrical Engineering (PARELEC), 2004.
12. Axel Siebenborn, Oliver Bringmann, and Wolfgang Rosenstiel. Communication
analysis for system on chip design. In Proceedings of the Design Automation and
Test in Europe Conference (DATE), 2004.
13. Coonie U. Smith and Lloyd G. Williams. Performance and scalability of distributed
software architectures: An spe approach. Parallel and Distributed Computing Practices, 2002.
DAC Workshop, Anaheim, June 12, 2005
61
62
UML for SoC Design
Embedded SW Design Exploration Using UML-based
Estimation Tools
Marcio F. da S. Oliveira1, Lisane Brisolara1, Flávio R. Wagner1, Luigi Carro1,2
1
Computer Science Institute, Federal University of Rio Grande do Sul (UFRGS), Brazil
{mfsoliveira, lisane, flavio, carro}@inf.ufrgs.br
2
Electrical Engineering Department, UFRGS, Brazil
[email protected]
Abstract. This paper presents an approach for the estimation of memory,
performance, and energy from an initial UML specification. It allows the
designer to evaluate and compare different modeling solutions, thus supporting
design space exploration at a very high abstraction level. An experiment
demonstrates our approach, in which an application is modeled in different
ways and the solutions are compared using the high-level estimates.
Experimental results are presented and demonstrate the effectiveness of the
estimates in an early design space exploration. These results present a very
small error when software components are reused and their costs are already
known, achieving errors that are smaller than 10%.
1
Introduction
The increasing complexity of embedded systems design, which is derived from the
amount of functionality that is required from these systems, together with the
shortening of the life cycle of embedded products, results in a design scenario where
productivity and quality are simultaneously required in order to deliver competitive
products. Selic [1] emphasizes that the use of techniques starting from higher
abstraction levels is crucial to the design success.
Platform-based design and IP reuse are techniques that improve the design
productivity [2]. In platform-based design, design derivatives are mainly configured
by software, and software development is where most of the design time is spent.
Moreover, in platform-based design, different granularities can be used to provide a
rich and pre-characterized library of software and hardware components to rapidly
assemble a system. Furthermore, this pre-characterized library reduces the uncertainty
about the system properties.
The UML language has gained in popularity as a tool for specification and design
of embedded systems. Efforts that describe the use of UML during the different
phases of an embedded system design can be found in [3].
It is widely known that design decisions taken at higher abstraction levels can lead
to substantially superior improvements. This context suggests the support to a fast
design space exploration in the early design steps. However, software engineers,
DAC Workshop, Anaheim, June 12, 2005
UML for SoC Design
when developing an application using UML, do not have a concrete measure of the
impact of their modeling decisions on issues such as performance and energy for a
specific embedded platform.
This paper proposes an approach that allows a better evaluation of modeling
solutions, through the estimation of the final system physical characteristics directly
from UML models, thus supporting a very early design space exploration. Our
approach provides the estimation of memory, performance, and energy consumption
for a system modeling solution.
An experiment demonstrates that different UML modeling solutions for the same
application result in different physical costs. When components are reused and the
costs of their functions are previously known we achieve estimation errors smaller
than 10%. It is shown that, by using our approach, the designer can really explore the
system software architecture, already at the UML level.
This paper is organized as follows. Section 2 gives an overview of related work.
Section 3 introduces our proposal for embedded software design exploration. Section
4 presents the experiment that illustrates a scenario of design space exploration.
Section 5 presents main conclusions and discusses future work.
2
Related Work
Bernardi et al. [4] propose the automatic translation of state and sequence diagrams
into a generalized stochastic Petri net and a composition of the resulting net models in
order to reach an analysis goal. This proposal allows the analysis of the system
execution time, but the operation times have to be manually included in the model.
An UML profile and an methodology for performance modeling of UML-based
systems are proposed by Theelen et al. [5]. The UML models are translated into an
executable model specified by POOSL (Parallel Object-Oriented Specification
Language). Some behavioral aspects and time delays can be specified in a
probabilistic way, through provided libraries. However, the designer needs to go
down the abstraction level from UML to POOSL to estimate system properties.
Petriu and Woodside [6] present an approach that uses the UML-SPT profile,
where desired values for performance measures are manually added to the model. A
performance model is then derived, from which the performance analyses are
computed by simulation or by analytical techniques.
Smith et al. [7] propose a quantitative approach for system analysis, called SPE
(Software Performance Engineering). SPE focuses on use cases and on the scenarios
that describe them. It allows the identification of the workloads that are most
significant to the performance. The sequence diagram representing a key scenario is
translated into an execution graph. Software and computer resource requirements are
then added to this graph and the model is solved.
All previous works lack an efficient estimation method to obtain information
related to performance, such as number of instructions or execution time, and usually
this information must be manually specified in the models. Moreover, these
approaches do not consider important costs for embedded systems, such as memory
and energy consumption. This work proposes a multi-variable methodology, where
DAC Workshop, Anaheim, June 12, 2005
63
64
UML for SoC Design
energy and memory footprint can also be estimated, not only performance. Moreover,
our approach is not based on simulation, thus requiring less time to provide estimates
and less detail about the system implementation, when compared to other approaches.
3
Embedded Software Design Exploration Approach
We propose an UML-based estimation approach that allows the estimation of the
system properties by mapping the application model into a given pre-characterized
platform. It can be used to support design space exploration at a very high abstraction
level. In order to support the estimation process, rules for modeling the application
and a way to represent information about a given platform have been defined. An
estimation tool called SPEU has been developed to implement this approach.
The UML diagrams used in the application model are Use Cases, Interaction
Diagrams, and Class Diagrams. These diagrams can be decorated with UML-SPT
stereotypes. Structural information can be specified in the class diagram, such as
multiplicity of values. The behavioral information is captured from the interaction
diagrams, in which we can specify interaction, conditional execution, and
dependencies between execution scenarios.
Access methods and delegations of these methods are usually employed in the
object-oriented programming approach. In order to identify these methods, some
restrictions are imposed to the designer: (i) the “get” or “set” prefix must precede the
class field name that has its method invoked; (ii) if the class does not have a field
specified in its method name, this means that the method delegates an access to
another class; (iii) the suffix “Content” should be used, indicating that the method is
accessing the structure like vector or matrix positions. A distinction between these
methods is important because they have different costs.
The platform model can contain information on processor architecture, API,
operating system, application components, and device drivers. Currently, for the
platform model, we use architectural aspects, scheduler and timer services, a real-time
API [8], and a math library. As architectural model, we use information such as data
types and instruction set (sizes and number of execution cycles). Also program and
data memory allocation aspects are considered, including allocation rules of dynamic
frame and reserved memory. When timer and scheduling services are required, the
overhead added in the system should be specified. In the same way, the real-time API
and the math library were characterized, including resource usage information.
The estimation is evaluated for a key use case of the application, as proposed in
[7]. Following this approach, the use cases that are critical to meet the application
requirements are identified. After, key scenarios for these use cases are selected and
represented using interaction diagrams. The estimates are computed for each scenario,
and best-case and worst-case analyses can be performed.
The estimation process starts with a static analysis of the application model, which
does not require simulation. From the class diagrams, structural and static
information, like memory required by classes are extracted. Moreover, access
methods and number and types of parameters are also identified. Furthermore,
DAC Workshop, Anaheim, June 12, 2005
UML for SoC Design
behavioral information is extracted from the interaction diagrams, including the
number of method calls and of conditional and loop operations.
From the interaction diagrams analysis, a pseudo-trace is generated that contains
symbolic instructions like “getField”, “getMatrixContent”, “interactionExecution”
and “loadParameterByValue”. The analysis result is mapped into the platform model,
in order to obtain the estimates of system properties.
The information provided by the platform memory model is used to determine the
required memory size. Information about fields in classes, together with their
multiplicity, is used to compute the data memory. Moreover, the worst-case scenario
of nested invocation methods is identified, and the memory volume of allocated
methods is computed. The sizes of instructions and method declarations are added to
estimate the program memory size, using the information about the instruction set and
program memory allocation model specified in the platform. Then, this result is added
to the data memory to determine the total memory size.
From the pseudo-trace and the performance and energy costs associated with the
symbolic instructions, the performance and energy estimates can be computed. As
there is no knowledge about the algorithms executed by the objects, just
collaborations between objects and information on conditional and iteration
executions are used. However, it is important to highlight that the behaviors that are
most relevant to the performance estimation are captured by this methodology.
4
Experiments
In order to illustrate a design space exploration scenario, alternative solutions for a
wheelchair control system were developed. For each solution, the application model
was mapped into the femtoJava platform [9], based on a Java microcontroller.
Afterwards, these solutions are compared using the SPEU estimations as a guide.
This experiment focuses on the wheelchair movement control, following an
approach based on use cases, only the key use case and its main scenarios are
evaluated. We illustrate our approach with the Movement Actuating scenario. Two
different models of this scenario were developed and are illustrated in Fig 1 and Fig 2.
The SPEU estimates for the two models are compared to the results obtained
through a cycle-accurate simulation of the system implementation using the CACOPS simulator [10]. The Java byte codes of the application are obtained using
SASHIMI [9], the femtoJava platform synthesis tool. The results for the first and
second solutions are depicted in Table 1, where it can be observed a large variation
between the performance and energy for each solution. The second solution presents
better results, an improvement of 66.01% in its performance and of 65.93% in its
energy consumption for the best-case analysis. Similar improvements can be also
observed for the worst-case analysis. The best results in the second solution are
mainly due to the use of a different concurrency model, in which the scheduler needs
to control only one periodic task and the system is idle for more cycles.
DAC Workshop, Anaheim, June 12, 2005
65
66
UML for SoC Design
Fig. 1. First solution: Sequence for Movement Actuating
Fig. 2. Second solution: Sequence for Movement Actuating
As shown in Table 1, estimates for data memory are almost exact, while for the
program memory errors of 4.6% are achieved. Performance estimates present an error
of at most 7.7%, and energy consumption estimates are smaller than 8.7%.
These results demonstrate that at a very high abstraction level it is already possible
to explore the design space according to the system requirements, since alternative
modeling solutions present different estimated results that are highly correlated to the
results obtained in the real implementation. Very good estimates are obtained because
the implementation reuses software components – scheduler and timer services, a
real-time API, and a math library – that have been previously characterized for the
hardware platform (the femtoJava processor).
DAC Workshop, Anaheim, June 12, 2005
UML for SoC Design
67
Table 1. Design exploration results for the alternative solutions
Property
SPEU
First Solution
Exact
Data memory
350
356
Program Memory
4,990
5,231
Performance best-case
20,732
21,089
Performance worst-case
27,068
27,856
Energy best-case
29,109,084 29,773,764
Energy worst-case
38,218,589 39,383,757
5
Error
Second Solution
SPEU
Exact
Error
00.27
351
354
04.60
4,983
5,266
01.69
7,045
7,217
2.82
23,725
25,710
03.28 9,915,714 10,250,063
02.95 33,298,001 36,476,430
00.84
04.64
02.38
07.72
03.26
08.71
Conclusions and Future Work
This paper proposes an approach for embedded software design space exploration
using an UML-based estimation tool. To support this approach, an estimation
methodology has been implemented, which allows the evaluation of models while
exploring the design space, in order to find a model that better fulfills the application
requirements. As expected, knowledge on the costs of reused components allows
considerable improvements in the estimates.
Results have confirmed the hypothesis that it is possible to explore the design
space based on modeling decisions taken at high levels of abstraction. Selecting the
best modeling approach already at the UML level might result in considerable gains
in terms of memory, performance, and energy consumption.
Future work will address the study of MDA in order to improve the mapping of
models. Moreover, an approach for better representing the platform and its services
must be defined to facilitate the system modeling. Efforts to completely automate the
estimation methodology are required to make it more usable.
References
1.
2.
3.
4.
5.
6.
Selic, B.: Models, Software Models and UML. UML for Real: Design of Embedded
Real-Time Systems. Kluwer Academic Publishers, 2003. Chapter. 1, p. 1-16.
Verkest, D.; Kunkel, J.; Schirrmeister, F.: System Level Design Using C++. In: Design,
Automation and Test In Europe, Date, 2000, Paris, France, 2000.
Lavagno, L.; Martin, G.; Selic, B.: UML for Real: Design of Embedded Real-Time
Systems. Kluwer Academic Publishers, 2003.
Bernardi, S.; Donatelli, S.; J. Merseguer: From UML Sequence Diagrams and StateCharts
to Analyzable Petri Net models; In ACM Proc. of the 3rd Int. Workshop on Software and
Performance (WOSP02), p. 35-45, Rome, July 2002.
Theelen, B.D.; Putten, P.H.A. van der; Voeten, J.P.M.: Using the SHE method for UMLbased performance modeling; In: System Specification and Design Languages, Chapter
12, pp. 143-160. Kluwer Academic Publishers, 2003.
Petriu, D.C.; Woodside, C. M.:. Performance analysis with UML: layered queueing
models from the performance profile. In: UML for Real: Design of Embedded Real-Time
Systems. Kluwer Academic Publishers, 2003.
DAC Workshop, Anaheim, June 12, 2005
68
UML for SoC Design
7.
Smith, C. U.; Williams, L. G. Software Performance Engineering. In: UML for Real:
Design of Embedded Real-Time Systems. Kluwer Academic Publishers, 2003.
8. WEHRMEISTER, M. A., BECKER, L. B., PEREIRA, C. E. Optimizing Real-Time
Embedded Systems Development Using a RTSJ-base API. Proceedings of Workshop on
Java Technologies for Real-Time and Embedded Systems 2004.
9. Ito, S.; Carro, L.; Jacobi, R.: Making Java Work for Microcontroller Applications. In:
IEEE Design & Test of Computers. vol. 18, n. 5, Sept-Oct 2001.
10. Beck, A. C.; Mattos, J. C. B.; Wagner, F. R.; Carro, L.: CACO-PS: A General Purpose
Cycle-Accurate Configurable Power Simulator. In: SBCCI'03 – 16th Symposium on
Integrated Circuits and Systems Design. São Paulo, Brazil, 2003.
DAC Workshop, Anaheim, June 12, 2005