System on Chip Co-Design MR 2005/06 inclus des extraits de P. Marwedel, Univ. Dortmund, Informatik...

System on Chip Co-DesignMR 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 applicationsConnaissance 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…)


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.


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é.


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)

HierarchieL’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érarchiqueExemples: states, processes, procédures.

– Structure hiérarchiqueExemples: processors, racks, printed circuit boards

Comportement du temps.

Comportement orienté état :StatePour des systèmes réactifs;Automates classiques sont insuffisants.


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ë ...


ConcurrenceSystèmes réels sont concurrents

Synchronisation et communicationComposants doivent communiquer!

Présence d’éléments de programmationPar 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– http://www.irisa.fr/archi03/Presentations/presentat

ions.htm

Extrait de– http://www.irisa.fr/archi03/Presentations/Calvez.p

df

Et de – http://tima-cmp.imag.fr/~lyonnar2

Objectif : une architecture de SoC

OMAP 1510

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 SoCConception 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é)

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 separationOf the fundamental logic of the specification From the particular implementation technologies

Model is not new

Languagespec

Model definition

Byte codeskeleton

Application translation

Lex & Yaccanalysis

Execution

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

Metamodel application

UML Profile

Metamodel execution

Mappingrules

Visual specificationof application mode using TAU G2

Internal representation

SystemC code generationInternal representation

MOF domain

RefinementPlatform Platform

descriptiondescription

PSM

PIM

Ptolemy

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

« Y » model In GasPard

3 models– ISP applications– Target architectures– Mapping of applications

on architectures

Model separation allows reuse

Typical programming techniques in SoC design

ApplicationHardware

Architecture

AssociationDeployment

User applications

Compilers VC

Models

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(application)

PIM

hardwarearchitecture

PIM

Ptolemy IIModel

DPN*Model

SystemCModel

VHDLModel

Mapping rules

use model use model

- Platform specification concepts

PSM

PIM

associationsPIM

deploymentPSM

interoperability Model

- Application and architecture association concepts independently of targeted platforms.

*Distributed Process Network

hardware architecture

signals frequencies

et :FFT

'signal' frequencies

inTiler:ComplexInputTiler<<aolTiler>>

array pattern

outTiler:ComplexOutputTiler<<aolTiler>>

pattern array

Methodology View

JavaModel

DPNModel

SystemCModel

VHDLModel

Java code C++ codeSystemC

C++ codeVHDL

files

PSM

PIM

interoperability Model

software / hardware interoperability

automatic transformation

inputSignal outputSignal

fft:InfFFT

signals frequencies

abs:InfAbsoluteValue

values

abs

square:InfSquare

values

squares

energy:InfEnergy

values

energies

threshold:InfThreshold levels

thresholds

rejection:InfRejection

inFrequencies

squaredModulesthresholds

outFrequencies

ifft:InfIFFT

frequencies

signals

ISP-UML

association

signals frequencies

et :FFT



array pattern


pattern array


fft:InfFFT

signals frequencies


values

abs

square:InfSquare

values

squares

energy:InfEnergy

values

energies


thresholds


inFrequencies


outFrequencies

ifft:InfIFFT

frequencies

signals

deployment

signals frequencies

et :FFT



array pattern


pattern array


fft:InfFFT

signals frequencies


values

abs

square:InfSquare

values

squares

energy:InfEnergy

values

energies


thresholds


inFrequencies


outFrequencies

ifft:InfIFFT

frequencies

signals

automatic generation

1 1b2

3

4

5

2b

2ctransformations

SynDEx AAA

refinement6

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

PIM PSM

metamodel metamodel

mappingrules

is defined by

is defined by

based on

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 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

Transformation Engine:Basic 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

rules

modelmodelmodel model

rules

transformationengine

A Model to Model TransformationsISP (Ptolemy II; SystemC)

Application High Level

Modeling (UML 2)

Ptolemy II Simulation,code generation

save /

load

UML2 metamodel

is defined by

ISP metamodel

import / export

Ptolemy II

metamodel

model transformation

hardware metamodel

SystemC metamodel

model transformatio

n

SystemC

hardware

drivesapplication Pt II

transf. rulestransf.engine

transf.engine SystemC

transf. rules

transf.

engine

UML2 applicationtransf. rules

drives

is defined by

Ptolemy II

application

is defined by

drives

C++ Code

TLM & Caba

Interop Bridge

Interop Bridge

AppliPIM

archiPIM

JavaPSM

CorbaPSM

SystemCPSM

VHDLPSM

Java codeCorba code

SystemC code

VHDL files

Association PIMPIM

produce

- Specify platform for each part

- Map application on architecture independently of targeted platforms

TLM PIM

RTL PIM

VerilogPSM

Verilog files

SystemCPSM

SystemC code

- Refining the PIM models

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

System on Chip Co-Design MR 2005/06 inclus des extraits de P. Marwedel, Univ. Dortmund, Informatik...

Documents

Transcript of System on Chip Co-Design MR 2005/06 inclus des extraits de P. Marwedel, Univ. Dortmund, Informatik...