La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

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

Présentations similaires


Présentation au sujet: "System on Chip Co-Design MR 2005/06 inclus des extraits de P. Marwedel, Univ. Dortmund, Informatik 12, 2003."— Transcription de la présentation:

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

2 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 quil fonctionne à linstant t – Sûreté: aucun dommage – Sécurité: confidentialité et authenticité des communications

3 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…)

4 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 lenvironnement. – 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 dun système ne peut être statistique, elle est au pire des cas.

5 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 à linstant courrant. Modèle dautomate approprié, modèle de fonctions exécutables est inapproprié.

6 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 linformation présentant la plupart de ces caractéristiques est appelé système embarqué: embedded system.

7 Specification des systèmes embarqués(1) Hierarchie Lhomme nest pas capable de comprendre un système contenant plus de ~5 objets. La plupart des ES manipulent plus dobjets – 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.

8 Specification des systèmes embarqués(2) Event-handling (événement interne ou externe) Pas dobstacles pour une implémentation efficace Support pour la conception de système sûrs Sémantique non ambiguë...

9 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

10 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

11 Modélisation à différents niveaux dabstraction A visiter – ions.htm ions.htm Extrait de – df df Et de –

12 Objectif : une architecture de SoC

13 OMAP 1510

14 Omap

15

16 Evolution de larchitecture

17 Techniques de conception : full-custom – Schéma – Dessin des masques – Simulation electronique : 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

18 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

19 Quelle architecture? Architecture Généraliste ou Spécialisée?

20 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).

21 Conception de SoC

22 Réalisation dun 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 lentreprise.

23 Notion dIP (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é)

24 Utilisation dIP Bloc réutilisable (IP) – connaître les fonctionnalités – estimer les performances dans un système – être sûr du bon fonctionnement de lIP – intégrer cet IP dans le système – valider le système

25 Commerce d IP « design & reuse »

26 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 lapplication de la méthodologie (gestion de version, rapports, accélération des itérations).

27 Buts de la conception Performances. – Rapidité globale, échéances. Fonctionnalité et interface utilisateur. Coût de fabrication. Consommation. Divers exigences (encombrements, etc.)

28 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 dune opinion – est élaboré pour répondre à la question qui conduit au développement dun système

29 Rôle dun 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 dautres personnes – Echanges entre outils Génération/Production – Produire une représentation dun autre niveau (autre modèle) – Produire le système réel => Modèle à retenir: fonction de lobjectif visé

30 Modèle de cycle de développement en V

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

32 Développement de systèmes

33 Nouveau développement de systèmes

34 Flot de conception

35 Le codesign

36 Les niveaux d'abstraction Niveaux dabstraction: – système – Macro-architecture – µ-architecture – Physiques Sémantique des objets pour chaque niveau dabstraction? – Responsabilités? – Destinations?

37 Le model Y

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

39 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

40 Model is not new Language spec Model definition Byte code skeleton Application translation Lex & Yacc analysis Execution

41 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

42 Model Driven Engineering Metamodel application UML Profile Metamodel execution Mapping rules Visual specification of application mode using TAU G2 Internal representation SystemC code generation Internal representation MOF domain Refinement Platform description PSM PIM Ptolemy

43 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

44 « 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 Application Hardware Architecture Association Deployment User applications Compilers VC Models

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

46 Metamodels ISP-UML (application) PIM hardware architecture PIM Ptolemy II Model DPN* Model SystemC Model VHDL Model Mapping rules use model - Platform specification concepts PSM PIM associations PIM deployment PSM interoperability Model - Application and architecture association concepts independently of targeted platforms. *Distributed Process Network

47 hardware architecture Methodology View Java Model DPN Model SystemC Model VHDL Model Java codeC++ code SystemC C++ code VHDL files PSM PIM interoperability Model software / hardware interoperability automatic transformation ISP-UML association deployment automatic generation 11b b 2c transformations SynDEx AAA refinement 6

48 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 mapping rules is defined by based on

49 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

50 Model to Model Transformation Engine Home made and working ;-) – Open source and customizable – Others can use it, improve it, provide other rule representation, … Takes into account the remarks on OMG- QVT proposals

51 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 model rules transformation engine

52 A Model to Model Transformations ISP (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 driv es application Pt II transf. rules transf. engine transf. engine SystemC transf. rules tran sf. engi ne UML2 application transf. rules driv es is defined by Ptolemy II application is defined by driv es C++ Code

53 TLM & Caba Interop Bridge Appli PIM archi PIM Java PSM Corba PSM SystemC PSM VHDL PSM Java code Corba code SystemC code VHDL files Association PIM PIM produc e - Specify platform for each part - Map application on architecture independently of targeted platforms TLM PIM RTL PIM Verilog PSM Verilog files SystemC PSM SystemC code - Refining the PIM models

54 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

55 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

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


Télécharger ppt "System on Chip Co-Design MR 2005/06 inclus des extraits de P. Marwedel, Univ. Dortmund, Informatik 12, 2003."

Présentations similaires


Annonces Google