Model Driven Engineering for Regular MPSOC Codesign

1
Model Driven Engineering for Regular MPSOC
Co-design

• Jean-Luc Dekeyser al.
• dekeyser_at_lifl.fr

2
Motivations

• Embedded High Performance Application Development
• MPSoC, NoC, Coarse Grained FPGA
• Model driven approach UML profile for co-design
  of System on Chip
• Verification formal models
• Simulation Co-simulation using SystemC
• Execution Transformations, code generation
• Synthesis SystemC/VHDL for FPGA
• Diversity of
• Programming languages (software, hardware)
• Abstraction levels (functional, TLM, CABA, RTL,
  etc)

3
MDE/MDA Focus

• Proposes
• Increase the reuse of existing developments
• Reduce the time to market
• Increase the lifetime of current and future
  developments
• Ease the integration of new technologies with
  long proven business models
• Means
• Clear separation
• Of the fundamental logic of the specification
• From the particular implementation technologies

4
Model and Metamodel

• Meta-metamodel
• Described with the MOF (Meta Object Facility)
• Provides XMI production rules, JMI specification,
  
• Metamodel
• Can be seen as a language definition
• Available modeling elements
• Construction rules
• Model
• Follow the rules expressed in the language
• Describe an application
• Application
• Concrete realization of a model
• Example generated code

meta metamodel M3
metamodel M2
model M1
application M0
5
PIM/PSM and transformations

• A platform is the specification of an execution
  environment for models. The term platform is used
  to refer to technological and engineering details
  that are irrelevant to the fundamental
  functionality of a system.'' -- OMG Architecture
  Board
• A system described at the Platform Independent
  level
• Can be mapped to several Platform Specific Models
• By the way of mapping rules
• Transformations from model to model
• Defined between the metamodels
• Allow to keep the models in sync

metamodel
metamodel
based on
is defined by
is defined by
mappingrules
PIM
PSM
6
SoC future is parallel!

• Parallelism exists in applications
• Multimedia/Telecom/Detection system
• Need for efficiency
• Power/Speed/Cost,
• Design Time/Customization,
• Economical Reason
• Developing cost
• Manufacturing Cost
• All together implies Re-Usability needs

7
Regular ArchitectureExamples

• Processor Array.
• PicoChip(430 processors )
• D-Fabrix (Toshiba MeP RISC processor based)
• PACT XPP(64 ALU-PAEs with 8 8 array)
• BRESCA from Silicon Hive(Philips)(44 VLIW PEs)
• QuickSilvers
• ACM architecture (64 Arithmetic(RISC)cluster)
• FPGA
• DP-FPGA
• SIMDVLIW
• XeTaL (320 PEs)
• TriMedia (5-way VLIW processor)

8
REMARC Reconfigurable Multimedia Array
Co-Processor

• (a) Block Diagram of a microprocessor with REMARC

• (b) Block Diagram of REMARC(Nano-processor)

9
A General NoC Architecture
10
 Y  model for co-modelling

• 3 models for co-modelling
• Application
• Hardware architecture
• Association
• Independent of platforms (PIM)
• Compilation
• Simulation / verification
• Synthesis
• Heterogeneity of targets
• Definition of PIM interoperability model

11
The Y Model and MDA Methodology
12
Metamodels overview
Common factorization mechanisms Repetition of
structural elements, compact description of
regular complex topologies
Common component paradigm Composing,
Assembling, Encapsulation gt reuse
13
Common component paradigm
Encapsulation
Repetition of structural elements
Composing
Assembling
14
Common factorization mechanisms

• Compact description of link topologies

15
Application specifications

• Data flow dependencies graph on arrays
• Repetitive computing Dependencies between array
  elements
• Inter repetition dependencies Delay
• Infinite data flow by infinite array
• Data flow / control flow mixed Synchronous
  languages

16
Application PIM

• UML 2 Component based
• Component models some computation
• Ports model input and output capabilities
• Three kinds of components
• Compound component
• Task parallelism as a dependency graph
• Repetitive component
• Potential concurrent computations (pure SPMD)
• Elementary component
• Basic computation unit
• May be implemented by an IP (Hard/Soft)
• Hierarchical description

17
Application PIM Example
18
Hardware architecture specifications

• Structure and behaviour of the hardware
• Hierarchical and repetitive modeling
• Multi-proc Itanium, ARM Grid, SIMD
• Hardware component classification based on the
  resource classification of SPT profile
• Processor Code storage and execution
• Communication for inter-resource communications
• Device neither CPU nor Communication

19
Hardware Architecture PIM

• SPT classification modified and extended

20
Hardware Architecture PIM

• Memory refinement example

21
Hardware Architecture PIMExample
Characterization based on QoS profile
Date04 SocLib Demo Example
22
Factorization mechanisms in Hardware model
InterRepetitionLinkTopology example
23
Common factorization mechanisms
RepetitiveLinkTopology example
24
Association PIM

• Expresses mapping and scheduling
• Of an application
• On a hardware architecture
• Includes the application and hardware
  architecture models
• Adds an association view
• Links between application components and active
  hardware components
• Links between application ports and dependences
  and passive hardware components
• Takes advantage of
• Repetition expression
• Hierarchy

25
Deployment

• Multi-platform selection for the same design
• SystemC, SpecC,
• Abstraction level selection
• IP libraries
• Interaction between different abstraction levels
  
• Functional
• Timed
• TLM
• Caba
• Just a PSM selection (multi-PSM selection)

26
PSM and model transformations

• Definition of the abstraction models for
  different platforms
• SystemC
• SpecC
• Ptolemy
• Esterel/scade
• Tool for model transformation (MODTransf)
• Transformation rule definition for each PSM

27
Model to ModelTransformation Engine

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

28
Transformation EngineBasic Principle

• Models contain concepts
• Defined in metamodel
• A transformation submit a concept to the
  engine
• The engine chooses the appropriate rule
• The rule performs the transformation of the
  concept
• The rule calls the engine for nested concepts

29
A Model to Model TransformationsISP (Ptolemy II
SystemC)
30
Towards standardization

• A part of the UML2.0 profile dedicated to
  Real-Time and Embedded systems
• RFP at OMG call MARTE.
• Collaboration with a lot of partners is starting
• Presentation in UML for SoC workshop, (DAC 05)
  available

31
General Requirements

• UML Profile for modeling and analysis of
  real-time and embedded (MARTE) systems including
  its software and hardware aspects
• The Proposals will define a UML profile
• Relying on a conceptual model definition
• It shall be possible to use independently
  software and hardware parts of the profile
• It shall comply with standards
• UML 2.0
• UML profiles for QoSFT, Testing
• Forthcoming UML profile for SE (SysML)
• It shall update the SPT profile 1.1

32
Roadmap

• RFP voted at Burlingame (February 2005)
• LOI June 05 (Boston meeting)
• Initial submission November 05
• Revised submission June 06
• Vote September 2006