System on Chip Co-Design MR 2005/06 inclus des extraits de P 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 http://www.irisa.fr/archi03/Presentations/presentations.htm Extrait de http://www.irisa.fr/archi03/Presentations/Calvez.pdf Et de http://tima-cmp.imag.fr/~lyonnar2

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

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 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 Means 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 Byte code skeleton Application translation Lex & Yacc analysis Execution

20 years of modeling New model implies new language No reuse 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 using TAU G2 MOF domain UML Profile Metamodel application Ptolemy Internal representation PIM Refinement Mapping rules Platform description SystemC code generation Internal representation PSM Metamodel execution

Model and Metamodel Meta-metamodel 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 User applications Models Compilers  VC ISP applications Target architectures Mapping of applications on architectures Model separation allows reuse Typical programming techniques in SoC design User applications Application Hardware Architecture Association Deployment Models Compilers  VC

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

interoperability Model Methodology View ISP-UML hardware architecture 1 2 1b association PIM SynDEx AAA 2b 3 deployment transformations 2c PSM automatic transformation 4 Java Model DPN Model interoperability Model SystemC Model VHDL Model 5 automatic generation Java code C++ code SystemC C++ code VHDL 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 metamodel based on is defined by is defined by mapping rules PIM 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 ;-) 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 rules rules model model model transformation 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 Modeling (UML 2) UML2 metamodel ISP metamodel hardware metamodel is defined by is defined by is defined by save / load transf. engine application hardware drives UML2 -> application transf. rules model transformation application -> Pt II transf. rules drives transf. engine model transformation transf. engine SystemC transf. rules drives Ptolemy II Simulation, code generation SystemC metamodel import / export Ptolemy II SystemC Ptolemy II metamodel C++ Code

TLM & Caba Interop Bridge Appli PIM archi PIM Association PIM PIM Java PSM Corba PSM SystemC PSM VHDL PSM Java code Corba code SystemC code VHDL files Association PIM PIM produce - Specify platform for each part - Map application on architecture independently of targeted platforms TLM PIM RTL PIM Verilog PSM Verilog files - 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 SE : UML for System Engineering RFP (ad/03-03-41) SysML : proposition (réponse à SE) : Profiles (existants) - UML Profile for Schedulability, Performance, and Time (formal/03-09-01), called SPT below. - UML Profile for Modeling QoS and FT Characteristics and Mechanisms Final Adopted Specification (ptc/04-09-01) UML 2.0 Testing Profile Final Adopted Specification (ptc/03-08-03)

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