System on Chip
Co-Design
MR 2005/06
inclus des extraits de
P. Marwedel, Univ. Dortmund, Informatik
12, 2003
Caractéristiques des systèmes
embarqués (1)
Doit être sûr,(à considérer dès la conception)
– Fiabilité R(t) = probabilité pour que le système fonctionne
correctement si c’était satisfait à t=0
– Maintenabilité M(d) = probabilité pour que le système
fonctionne correctement d unités de temps après une erreur
– Disponibilité: probabilité pour qu’il fonctionne à l’instant t
– Sûreté: aucun dommage
– Sécurité: confidentialité et authenticité des
communications
Caractéristiques des systèmes
embarqués(2)
Doit être efficace
– Energie
– Taille du Code
– Run-time
– Poids
– Coût
Dédié à certaines applications
Connaissance du comportement à la conception facilite
la minimisation des ressources et la maximisation de la
robustesse
User interface dédiée(pas de sourie, clavier ,
écran…)
Caractéristiques des systèmes
embarqués(3)
ES doit répondre à des contraintes real-time
– Un système real-time doit réagir à un stimuli dans un
intervalle de temps dépendant de l’environnement.
– Un système temps réel qui produit une bonne réponse mais
trop tard est faux.
– „A real-time constraint is called hard, if not meeting that
constraint could result in a catastrophe“ [Kopetz, 1997].
– Les autres contraintes sont appelées soft.
– La réponse d’un système ne peut être statistique, elle est au
pire des cas.
Caractéristiques des systèmes
embarqués(4)
Généralement connecté à un environnement physique tels que
capteurs, acteurs…
Système hybride
(analogique + digital).
ES sont des systèmes réactifs:
„A reactive system is one which is in continual interaction
with is environment and executes at a pace determined by
that environment“ [Bergé, 1995]
Le comportement dépend des entrées à l’instant courrant.
Modèle d’automate approprié,
modèle de fonctions exécutables est inapproprié.
Caractéristiques des systèmes
embarqués(5)
Tous les ES ne possèdent pas toutes ces
caractéristiques.
Définition: Un système de traitement de
l‘information présentant la plupart de ces
caractéristiques est appelé système
embarqué: embedded system.
Specification des systèmes embarqués(1)
Hierarchie
L’homme n’est pas capable de comprendre un
système contenant plus de ~5 objets.
La plupart des ES manipulent plus d’objets
– Comportement hiérarchique
Exemples: states, processes, procédures.
– Structure hiérarchique
Exemples: processors, racks, printed circuit boards
Comportement du temps.
Comportement orienté état :State
Pour des systèmes réactifs;
Automates classiques sont insuffisants.
Specification des systèmes embarqués(2)
Event-handling (événement interne ou externe)
Pas d’obstacles pour une implémentation
efficace
Support pour la conception de système sûrs
Sémantique non ambiguë ...
Specification des systèmes embarqués(3)
Concurrence
Systèmes réels sont concurrents
Synchronisation et communication
Composants doivent communiquer!
Présence d’éléments de programmation
Par exemple, opérations arithmétiques, loops, et
function calls doivent exister
Exécutable (pas de spécification algébrique)
Support pour le design de grands systèmes
( OO)
Support spécifique au domaine
Specification des systems embarqués(4)
Lisibilité
Portabilité et flexibilité
Terminaison
A quel moment tous les calculs sont terminés.
Support pour de devices I/O
Accès direct aux switches, displays, ...
Propriété non-fonctionelle
fault-tolerance, jetable, poids, taille, user friendly,
extensibilité, life time, power consumption...
Modèle adéquate de calcul
Modélisation à différents niveaux
d’abstraction
A visiter
– [Link]
[Link]
Extrait de
– [Link]
df
Et de
– [Link]
Objectif : une architecture de
SoC
OMAP 1510
Omap
Evolution de l’architecture
Techniques de conception
70-80 : full-custom
– Schéma
– Dessin des masques
– Simulation electronique
80-90 : Précaractérisé FPGA
– Réutilisation de briques élémentaires
– Modélisation, simulation
00-xx : SoC
– Réutlisation du matériel et logiciel
– Co-design, vérification
Principes de conception
Une architecture matérielle
– Blocs standards (CPU, mem)
– Blocs spécifiques
– Bus de communication
Des ressources logicielles
SoC = cohabitation de ces ressources sur un
même chip, prise en compte globale pour la
réalisation hard/soft
Quelle architecture?
Architecture Généraliste ou Spécialisée?
Application Specific Circuits
(ASICS)
Circuits custom-designed sont
nécessaires pour une recherche de
vitesse et d’économie de
consommation dans une grosse
production.
Cette approche nécessite un temps
de conception important et un coût
de fabrication élevé (e.g. Mill. $ pour
le masque).
Conception de SoC
Réalisation d’un SoC
Réutiliser les blocs déjà conçus dans la
société ;
Utiliser les générateurs de macro-cellules
(Ram, multiplieurs,…)
Acheter des blocs conçus hors de
l’entreprise.
Notion d’IP (Intellectual Property)
Blocs fonctionnels complexes réutilisables
– Hard: déjà implanté, dépendant de la
technologies, fortement optimisé
– Soft: dans un langage de haut niveau (VHDL,
Verilog, C++…), paramétrables
Normalisation des interfaces ( OCP)
Environnement de développement (co-
design, co-specif, co-verif)
Performances moyennes (peu optimisé)
Objectif : une architecture de
SoC
Evolution de l’architecture
Techniques de conception
70-80 : full-custom
– Schéma
– Dessin des masques
– Simulation electronique
80-90 : Précaractérisé FPGA
– Réutilisation de briques élémentaires
– Modélisation, simulation
00-xx : SoC
– Réutlisation du matériel et logiciel
– Co-design, vérification
Objectif : une architecture de
SoC
Principes de conception
Une architecture matérielle
– Blocs standards (CPU, mem)
– Blocs spécifiques
– Bus de communication
Des ressources logicielles
SoC = cohabitation de ces ressources sur un
même chip, prise en compte globale pour la
réalisation hard/soft
Utilisation d’IP
Bloc réutilisable (IP)
– connaître les fonctionnalités
– estimer les performances dans un système
– être sûr du bon fonctionnement de l’IP
– intégrer cet IP dans le système
– valider le système
Commerce d ’IP « design & reuse »
Méthodologies de conception
Procédure pour concevoir un système.
Comprendre une méthodologie aide à garantir la
sécurité de la conception.
Flot de conception : de compilateurs, outils de
développement logiciel, outils de conception assistée
par ordinateur (CAD), etc., permettant de:
– aider à automatiser les étapes de la méthodologie;
– garder trace de l’application de la méthodologie (gestion de
version, rapports, accélération des itérations).
Buts de la conception
Performances.
– Rapidité globale, échéances.
Fonctionnalitéet interface utilisateur.
Coût de fabrication.
Consommation.
Divers exigences (encombrements, etc.)
Définition
Méthode:
– technique de résolution de problème caractérisée par un
ensemble de règles bien définies qui conduisent à une
solution correcte
Méthodologie:
– un ensemble structuré et cohérent de modèles, méthodes,
guides et outils permettant de déduire la manière de
résoudre un problème
Modèle:
– une représentation d'un aspect partiel et cohérent du
«monde» réel
– précède toute décision ou formulation d’une opinion
– est élaboré pour répondre à la question qui conduit au
développement d’un système
Rôle d’un modèle pour les
systèmes
Abstraction
– Eliminer des détails, focaliser sur un point de vue du système
– Travailler à différentes échelles de complexité et de temps
Analyse
– Etude des propriétés du modèle (vérification de propriétés)
– Extrapolation au système réel représenté
Communication
– Discussion et échanges avec d’autres personnes
– Echanges entre outils
Génération/Production
– Produire une représentation d’un autre niveau (autre modèle)
– Produire le système réel
=> Modèle à retenir: fonction de l’objectif visé
Modèle de cycle de
développement en V
Top-down, bottom-up & co.
Conception top-down :
– Commencer par une description très abstraite;
– Enrichir de détails solutions spécifiques.
Conception Bottom-up :
– Assembler des petits composants pour obtenir un
gros système assemblage spécifique.
Conception à base de plate-formes :
– Cas réels utilisent ces deux techniques
assemblage et configuration spécifique.
Développement de systèmes
Nouveau développement de
systèmes
Flot de conception
Le codesign
Les niveaux d'abstraction
Niveaux d’abstraction:
– système
– Macro-architecture
– µ-architecture
– Physiques
Sémantique des objets pour chaque niveau
d’abstraction?
– Responsabilités?
– Destinations?
Le model Y
Model based Codesign
Visual modeling
– Intensive Signal Processing Application (ISP-A)
– Hardware architecture
– Hardware/software association/deployment
Automatic exploitation of metamodel specification
– Simulation
– Refinement, transformations
– Code generation
Reuse of application and Hardware architecture
– Other simulation, other middleware…
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
Model is not new
Model Language
definition spec
Application translation
Lex & Yacc
analysis
Execution
Byte code
skeleton
20 years of modeling
New model implies new language
– Thousands of dialects
– Syntaxic/semantic analyzers (Lex-Yacc like)
– Code generators
No reuse
No capitalization
No tool for automatic production
Model Driven Engineering
Visual specification
of application mode
MOF domain using TAU G2
UML Profile
Metamodel
application Ptolemy
Internal
representation
PIM
Mapping Refinement
rules
Platform
description
Internal SystemC code generation
PSM Metamodel representation
execution
Model and Metamodel
Meta-metamodel
Described with the MOF (Meta Object Facility) meta metamodel
Provides XMI production rules, JMI M3
specification, … metamodel
Metamodel M2
– Can be seen as a “language” definition:
model
Available modeling elements M1
Construction rules
application
Model
M0
– Follow the rules expressed in the “language”
– Describe an application
Application
– Concrete realization of a model
– Example : generated code
« Y » model In GasPard
3 models
– ISP applications
– Target architectures
User applications
– Mapping of applications
on architectures Hardware
Application
Architecture
Association
Model separation allows
Models Deployment
reuse
Typical programming
Compilers VC
techniques in SoC design
Why three levels of formalism
Application:
– Complete formal description (a priori validation )
– Hardware independent
– Simulation and compilation compatibility
Hardware architecture
– Functional description : active and passive elements
– Iterative refinement
– Application independent
Association/deployment
– Association of one application on one architecture
– Data allocations
– Data transfers
– Processing distribution (on different platforms)
Metamodels
ISP-UML hardware
(application) architecture
PIM use model use model PIM PIM
associations
PIM - Application and architecture
association concepts
independently of targeted PSM
deployment platforms.
- Platform specification
concepts PSM
Mapping rules
Ptolemy II DPN* interoperability SystemC VHDL
Model Model Model Model Model
*Distributed Process Network
Methodology View
inputSignal
ISP-UML outputSignal
hardware
architecture
fft:InfFFT
signals frequencies
signals
ifft:InfIFFT
frequencies
1 2 1b
values
abs:InfAbsoluteValue
abs
inFrequencies
outFrequencies
association
rejection:InfRejection
values
<<aolTiler>> <<aolTiler>>
squaredModules
square:InfSquare thresholds inTiler:ComplexInputTiler outTiler:ComplexOutputTiler
squares pattern pattern
array array
values
energy:InfEnergy signals frequencies
energies
inputSignal outputSignal et :FFT
levels 'signal' frequencies
threshold:InfThreshold
thresholds
fft:InfFFT
PIM
signals frequencies
signals
ifft:InfIFFT
frequencies
values
abs:InfAbsoluteValue
abs
inFrequencies
outFrequencies
rejection:InfRejection
values
squaredModules
square:InfSquare thresholds <<aolTiler>> <<aolTiler>>
squares inTiler:ComplexInputTiler outTiler:ComplexOutputTiler
array pattern pattern array
values
energy:InfEnergy signals frequencies
energies
et :FFT
'signal' frequencies
levels
threshold:InfThreshold
thresholds
SynDEx AAA 2b
3 deployment
inputSignal outputSignal
transformations 2c
fft:InfFFT
PSM
signals frequencies
signals
ifft:InfIFFT
frequencies
values
abs:InfAbsoluteValue
abs
inFrequencies
outFrequencies
rejection:InfRejection
values
squaredModules
square:InfSquare thresholds <<aolTiler>> <<aolTiler>>
squares inTiler:ComplexInputTiler outTiler:ComplexOutputTiler
array pattern pattern array
values
energy:InfEnergy signals frequencies
energies
et :FFT
'signal' frequencies
levels
threshold:InfThreshold
thresholds
automatic transformation 4
Java DPN interoperability SystemC VHDL
Model Model Model Model Model
5 automatic generation
SystemC VHDL
Java code C++ code
C++ code files
software / hardware interoperability
6 refinement
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 based metamodel
on
is defined is defined
by by
mapping
PIM rules PSM
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
Model to Model
Transformation Engine
Home made and working ;-)
– [Link]
Open source and customizable
– Others can use it, improve it, provide other rule
representation, …
Takes
into account the remarks on OMG-
QVT proposals
Transformation Engine:
Basic Principle
rules
rules
model transformation model
model engine
model
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
A Model to Model Transformations
ISP (Ptolemy II; SystemC)
Application High
Level UML2 ISP hardware
Modeling (UML 2) metamodel metamodel metamodel
is defined by
save is defined by
/ is defined by
tran
load sf.
engi
ne application hardware
driv
UML2 es
application
transf. rules model
transformation
driv
application Pt II es model
transf.
transformatio
transf. rules engine n
transf. driv
engine SystemC
Ptolemy II Simulation, es
transf. rules
code generation
import / export Ptolemy SystemC
SystemC metamodel
II
Ptolemy II
C++
metamodel Code
TLM & Caba - Map application on
architecture independently
of targeted platforms
Appli archi
PIM PIM
Association
PIM
PIM
- Refining the
PIM models
TLM
- Specify platform PIM
for each part
Java Corba SystemC
PSM PSM PSM
produce
RTL
Corba SystemC PIM
Java code
code code
Interop Bridge
SystemC Verilog VHDL
PSM PSM PSM
SystemC Verilog VHDL
code files files
Interop Bridge
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
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 QoS&FT, Testing
Forthcoming UML profile for SE (SysML)
– It shall update the SPT profile 1.1
Roadmap
RFP voted at Burlingame (February 2005)
LOI: June 05 (Boston meeting)
Initial submission: November 0
Revised submission: June 06
Vote : September 2006